Subject: Re: New I-D: Neighbor Discovery and IPv6 Extension Headers (draft-gont-6man-nd-extension-headers)

From: Arturo Servin <[email-masked]>
Date: Mon, 6 Jun 2011 02:28:07 +0400

Fernando,

	Some comments.

	Minor, typos, etc.

	I think you missed the reference to RFC 6105, this is the same problem with the reference than http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt

	May be it is just me and the excess of caffeine but the third paragraph of section 1 is a bit long and hard to understand. I would recommend some rephrasing. 

	Other:

	In section 2. I think it has to be a MUST instead of SHOULD.

	In section 3, I think you should add a paragraph saying that even with the filtering rules described in http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt there is a important cost in complexity and performance for devices performing those filters (l2-switches, IDS/IPS/FWS, etc.)

Regards,
-as

On 1 Jun 2011, at 00:59, Fernando Gont wrote:

> Folks,
> 
> I have just published a new Internet-Draft
> (draft-gont-6man-nd-extension-headers) entitled "Security Implications
> of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery".
> 
> The I-D is available at:
> http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt
> 
> The Abstract of the I-D is:
> ---- cut here ----
>   IPv6 Extension Headers with Neighbor Discovery messages can be
>   leveraged to circumvent simple local network protections, such as
>   "Router Advertisement Guard".  Since there is no legitimate use for
>   IPv6 Extension Headers in Neighbor Discovery messages, and such use
>   greatly complicates network monitoring and simple security
>   mitigations such as RA-Guard, this document proposes that hosts
>   silently ignore Neighbor Discovery messages that use IPv6 Extension
>   Headers.
> ---- cut here ----
> 
> Note: A closely related (and just published) I-D is
> draft-gont-v6ops-ra-guard-evasion-00, which is aimed at the v6ops wg
> (rather than 6man).
> 
> Any comments on any of these I-Ds will be very welcome.
> 
> Thanks!
> 
> Best regards,
> -- 
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 07 Jun 2011 23:17:55 -0300

Hi, Arturo,

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

On 06/05/2011 07:28 PM, Arturo Servin wrote:
> I think you missed the reference to RFC 6105, this is the same problem
> with the reference
> than http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt

Good grief! -- There was an error in the xml source which resulted in
the reference not being included. I'll fix this in the next rev of the I-D.

> May be it is just me and the excess of caffeine but the third paragraph
> of section 1 is a bit long and hard to understand. I would recommend
> some rephrasing. 

With a bit more caffeine, it was parsable to me :-) . Anyway, I've
worked a little bit on the paragraph, to improve it. This is the
resulting text:

---- cut here ----
Since there is no current legitimate use for IPv6 Extension Headers in
IPv6 Neighbor Discovery packets, and avoiding their use in such packets
would greatly simplify the monitoring and mitigation of Neighbor
Discovery attacks, this document proposes that hosts silently ignore
Neighbor Discovery messages that employ IPv6 Extension Headers.
---- cut here ----

> In section 2. I think it has to be a MUST instead of SHOULD.

I'd probably agree with you but will leave this one for discussion...

> In section 3, I think you should add a paragraph saying that even with
> the filtering rules described
> in http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt there
> is a important cost in complexity and performance for devices performing
> those filters (l2-switches, IDS/IPS/FWS, etc.)

This is a very good point. Will craft some text about this and include
it in the next revision of the I-D.

Thanks!

Best regards,