How to preempt rogue RAs?

[Leen Besselink]

On 10/31/2010 10:17 PM, Mark Smith wrote:
> On Sun, 31 Oct 2010 14:07:28 -0700
> "George Bonser" <gbonser at seven.com> wrote:
>
>>
>>> From: Mikael Abrahamsson 
>>> Sent: Sunday, October 31, 2010 1:49 PM
>>> Subject: RE: How to preempt rogue RAs?
>>>
>>>
>>> Yes, it's really bad that this wasn't done a long time ago.
>>>
>>> It's being done now anyway:
>>>
>>> <http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm>
>>>
>>> --
>>> Mikael Abrahamsson    email: swmike at swm.pp.se
>> And as has been typical with v6, they are apparently overreaching.
>> Strong encryption should be an option but there should also be a weak
>> option as well that doesn't require as much processor overhead.  A
>> simple md5 signature doesn't take a lot of processing power and protects
>> against the case where someone brings a laptop into the network that
>> generates RAs. It won't secure against a determined attack, but most
>> cases of rogue RAs aren't the result of a determined attack, they are
>> the result of an accident or other unintentional cause.
>>
>> The whole history of v6 has been one of making things "perfect" or
>> "correct" to the point where people avoid using it.  "Useful" trumps
>> "correct" almost every time. What will be the cost of all this
>> encryption on a busy network?
>>
> Encryption is pretty light these days. AES is part of the IEEE LowPAN
> wireless standards, and those types of embedded devices are intended to
> run for years on batteries. Intel have fairly recently added
> instructions to their CPUs specifically for accelerating encryption
> ("AES-NI").
>
> Key management is usually more of an issue. I've wondered, but haven't
> looked into, whether 802.1x can be used to boot strap IPv6 SEND,
> facilitating a simple username/password authentication model that we're
> all quite comfortable with.
>
> Regards,
> Mark.
Hi,

As I've mentioned before in other places. Why not DNSSEC ?

Why not have validating resolver-library (with a resently downloaded
trust-anchor for the root) on the host trying to connect to the network
so it can verify a full trust-chain ?

If the router sends a RA with RDNSS, then you have a recurive
DNS-server you can ask for the complete trust chain to check the
reverse DNS-entry for the router. That is where a (trust anchor for
a) public-key could be kept for SEND.

If the router / prefixes / public key / recurse DNS-server is known
and validated, I'm sure it is possible to bootstrap anything else
from that.

The 'only thing' you need to have is an up to date trust anchor for
the root.

The host probably wants/needs that anyway, when browsers start to
support DNSSEC-validation for HTTPS public-keys/trust-chains. [1]

Because the current situation where every trusted CA can create
certificates for any domain. [2]

When CNNIC issues certificates for gmail and uses that to MITM on
Chinese citizens, then I consider that a bug in the protocol.

Maybe I'm just to positive about DNSSEC, but if .com is really going to
be signed before 3Q 2011, then DNS is a great please for storing
trust-anchors / public keys.

Have a nice day,
    Leen.

[1] http://www.imperialviolet.org/2010/08/16/dnssectls.html
[2] first link I found about it from a search engine:
http://www.freedom-to-tinker.com/blog/felten/mozilla-debates-whether-trust-chinese-ca