Subject: [v6ops] Fwd: Re: Ra-Guard evasion (new Internet-Drafts)

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Jun 2011 21:47:15 -0300

FYI

-------- Original Message --------
Subject: Re: Ra-Guard evasion (new Internet-Drafts)
Date: Thu, 02 Jun 2011 10:36:12 +1000
From: Karl Auer <[email-masked]>
To: IETF IPv6 <[email-masked]>

On Wed, 2011-06-01 at 14:20 -0300, Fernando Gont wrote:
> * "IPv6 Router Advertisement Guard (RA-Guard) Evasion", available at:
> http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt

Section 1, second para: "of identifying" should be "to identify"

Section 1, third para: "had so far been" should be "have so far been"

Section 1, third para: "deemed as appropiate" should be "deemed
appropriate"

Section 1, fourth para: The techniques could *probably* be exploited.
And maybe mention DHCPv6 here as well...?

Section 2.1, first sentence is missing words or something. No legitimate
what?

Section 2.1 first para: should be "simply ignoring". Suggest leaving
"simple", "simply" etc out of such sentences. It might not be simple at
all.

Section 2.1 second para: should be "implement" not "implements"

Page 6: This might be a silly thought, but why would the implementation
need to do fragment reassembly? All it needs to do is locate RAs,
whether they are in fragments or not. It has all the info it needs in
the fragment with the RA. That is, it passes earlier packets, but if a
fragment arrives with an RA in it, it checks the RA. The destination
might end up with a partial packet, but it will never get the damaging
fragment, and will eventually discard the partial.

End of Section 2.2: "it should be obvious" - well, it isn't :-)
Definitely expand on precisely why.

Regards, K.

PS: Responding on this list, rather than NANOG - is that OK?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: james woodyatt <[email-masked]>
Date: Thu, 02 Jun 2011 09:30:35 -0700

everyone--

What if the list of More Specific Route options is large enough that they won't all fit in a single Router Advertisement message?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 Jun 2011 15:36:03 -0300

James,

> What if the list of More Specific Route options is large enough that they won't all fit in a single Router Advertisement message?

You send them in separate RAs.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: james woodyatt <[email-masked]>
Date: Thu, 02 Jun 2011 11:49:46 -0700

> You send them in separate RAs.

A less aggressive alternative solution would permit Router Advertisement messages to be fragmented but to simply require the whole ICMPv6 header to be present in the initial fragment of the message and require the RA Guard to follow the extension header chain properly all the way to the ICMPv6 header.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Jun 2011 15:39:08 -0400

> You send them in separate RAs.

Right. You fragment at the transport layer.

That said, I am not at all convinced that we should outlaw the use of
fragmentation for ND.

RA-Guard is not a perfect solution to RA spoofing. It never will
be. It has limitations (and always will). ND packets that using
extension headers or fragmentation are just one specific example.

Thomas

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 Jun 2011 17:46:13 -0300

Hi, Thomas,

> Right. You fragment at the transport layer.

Isn't this even suggested by the existing specs, btw?

> That said, I am not at all convinced that we should outlaw the use
> of fragmentation for ND.

So far the only updates to SLAAC seem to be in the area of new options
(e.g. RDNSS), and nothing that requires fragmentation (or that couldn't
be addresses by "fragmenting at the transport layer", as you indicate).

Outlawing the use of fragmentation for ND -- particularly when there's
no legitimate use for it, and doesn't look like there's going to be --
allows IPv6 network to match the security level to the IPv4 counterpart
(where, as a result of the limited header length, you can always
successfully enforce an IPv4-version of the RA-Guard mitigation).

> RA-Guard is not a perfect solution to RA spoofing. It never will be.
> It has limitations (and always will). ND packets that using extension
> headers or fragmentation are just one specific example.

Can you think of any other way to circumvent RA-Guard (when extension
headers are outlawed for ND)?

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 Jun 2011 17:53:47 -0300

Hi, James,

On 06/02/2011 03:49 PM, james woodyatt wrote:
> A less aggressive alternative solution would permit Router
> Advertisement messages to be fragmented but to simply require the
> whole ICMPv6 header to be present in the initial fragment of the
> message and require the RA Guard to follow the extension header chain
> properly all the way to the ICMPv6 header.

Then you open the door to an attacker sending a packet with multiple
instances of different extension headers, requiring RA-Guard to follow
the packet chain, which could not only be expensive, but maybe not even
possible.

I'd keep it simple, particularly when there's no real motivation for the
converse, and when the proposal in draft-gont-6man-nd-extension-headers
would make it possible for the v6 countermeasures to be as simple as the
v4 counterpart...

Thoughts?

Thanks!

Best regards,

---

From: Philip Homburg <[email-masked]>
Date: Thu, 02 Jun 2011 23:09:53 +0200

In your letter dated Thu, 02 Jun 2011 11:49:46 -0700 you wrote:
>A less aggressive alternative solution would permit Router Advertisement messa
>ges to be fragmented but to simply require the whole ICMPv6 header to be prese
>nt in the initial fragment of the message and require the RA Guard to follow t
>he extension header chain properly all the way to the ICMPv6 header.

Given that it is L2 devices that have to filter ND messages, it is important
to keep them as simple as possible.

I would suggest to disallow any extension headers unless we can find a clear
case where they are required. And then allow any IPv6-over-foo document to
define additional extension headers for that particular medium.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 Jun 2011 16:07:59 -0300

John,

> You send them in separate RAs.

By the way, I thought this was already implied from the current
specifications... But please do let me know if you think this should be
clarified.

Thanks!

Best regards,

---

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Jun 2011 13:43:12 +0300 (EEST)

> extension headers or fragmentation are just one specific example.

This has happened with radvd.

There was one individual who very strongly insisted (by filing and 
bugging about that in a bug report at Red Hat Bugzilla) that he must 
be able to advertise his whole /48, i.e., 64K prefix information 
options.  That resulted in the implementation fragmenting packets at 
the IP layer.  Transport layer would fragmentation to multiple RAs 
would have been possible as well but there was no point in 
implementing that.  I solved the "problem" by restricting radvd send 
buffer size to 1452B, so both are prevented. I wouldn't be sad to see 
the RA transport/IP layer fragmentation go.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Jun 2011 05:35:45 -0300

Hi, Pekka,

> This has happened with radvd.

You mean that at some point radvd was sending fragmented IPv6 traffic,
even when it was "unexpected"?

> bugging about that in a bug report at Red Hat Bugzilla) that he must be
> able to advertise his whole /48, i.e., 64K prefix information options. 
> That resulted in the implementation fragmenting packets at the IP
> layer.  Transport layer would fragmentation to multiple RAs would have
> been possible as well but there was no point in implementing that. I
> solved the "problem" by restricting radvd send buffer size to 1452B, so
> both are prevented. I wouldn't be sad to see the RA transport/IP layer
> fragmentation go.

This is a good datapoint to have (i.e., radvd never sending fragmented
ND traffic) -- I will try to include a note about this in the next rev
of the I-D.

Thanks!

Best regards,

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Jun 2011 11:11:49 +0200

>> restricting radvd send buffer size to 1452B

(that obviously doesn't prevent fragmentation in all cases...)

Gruesse, Carsten