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

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

Hi, Karl,

Thanks so much for your feedback. (I've removed 6man from the
recipients, and have added v6ops which is the wg at which this draft is
aimed).

On 06/01/2011 09:36 PM, Karl Auer wrote:
> 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"

Done.

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

Really? i.e., they are now in the public domain (that's why I used past
tense). -- (sorry, English as second language here)

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

Not quite "probably". They *are* effective against rafixd and others....

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

Fixed. ("no legitimate use")

> 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.

I was referring to end-system implementations (rather than RA-Guard or
the like), and thus in that case it *is* simple.

The text now reads:
"While there is currently no legitimate use for IPv6 Extension Headers
in ICMPv6 Router Advertisement messages, Neighbor Discovery
implementations allow the use of Extension Headers included in these
messages, by simply ignoring the received options."

Please let me know if it looks okay now.

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

Fixed.

> 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. 

That's the point. See the figure in Page 6: How could an RA-Guard
implementation locate the RA in the second fragment without performing
fragment reassembly?

> It has all the info it needs in
> the fragment with the RA. 

Not at all. All it can tell from that fragment is that the original IPv6
packet (prior to fragmentation) contained a Destination Options header.
Since the length of that Destination Options header cannot be inferred
from the second fragment, it is impossible to locate de RA. -- Not even
to tell that the packet actually is an 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.

Please see above. -- and also let me know if you think that this should
be clarified or additional text should be added.

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

Excellent!

Thanks!

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

---

From: David Farmer <[email-masked]>
Date: Thu, 02 Jun 2011 00:14:30 -0500

Fernando,

Excellent draft and some important research, you and Karl covered a 
number of issues I noticed as well.  However, I have an additional comment;

While this is an important attack vector, and must be mitigated, and I 
agree that draft-gont-6man-nd-extension-headers seems like the best way 
to accomplish that in the long-term.  Nevertheless, it should also be 
noted in this draft that while many current RA-Guard implementation are 
vulnerable to these attack vectors, such implementations are still 
useful and an effective means of mitigating several misconfiguration 
issues detrimental to the operation of a large number IPv6 networks.

Put another way, many IPv6 networks are still better off implementing 
RA-Guard with these vulnerabilities, then not implementing GA-Guard at all.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

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

Hi, David,

Thanks so much for your comments! - Please find my responses inline...

> RA-Guard with these vulnerabilities, then not implementing GA-Guard at all.

Agreed. In which section do you think I should add some text along these
lines?

Thanks!

Best regards,

---

From: Arturo Servin <[email-masked]>
Date: Thu, 2 Jun 2011 09:52:23 -0300

Fernando,

	I agree with David. At least for me, 100% of the identified attacks (excepting your demo the other day) have been because of a missconfigured host and ramond has been very useful. I think important to note that even though complex attacks are possible, current mechanism are useful and recommended to use instead of "nothing at all".

	May be in the "introduction" or in "other implications" you could add the text.

regards,
.as

On 2 Jun 2011, at 03:46, Fernando Gont wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops