Re: AD Review: draft-ietf-6man-nd-extension-headers

[Fernando Gont <[e-mail]>]

Hi, Brian,

Meta-comment: All proposed changes have been applied, and the rev'ed
draft has been posted -- readt for IETF LC?

More comments in-line...

On 01/14/2013 12:10 PM, Brian Haberman wrote:
> All,
>      I have completed my AD evaluation of
> draft-ietf-6man-nd-extension-headers.  The following comments need to be
> addressed prior to progressing this draft to IETF Last Call.
> 
> 1. The first sentence of the Abstract appears to be a remnant of when
> this draft discussed Extension Headers in general.  It should be updated
> to focus on the use of fragmentation within NDP messages.

Fixed.



> 2. The first sentence of the Introduction is a bit misleading.  NDP is
> specified in 4861.  RFC 4862 specifies SLAAC.  They are two different
> things, so I am not sure why 4862 is getting put into this statement.

Fixed.



> 3. The Intro also contains rudimentary discussion of existing tools for
> monitoring/protecting NDP traffic.  It would be good to also discuss the
> KAME rafixd tool, as it as similar capabilities.

I've added rafixd.. although the list wasn't meant to be exhaustive --
for instance, all of the listed "tools" can be fooled by employing
extension headers and/or fragmentation...


> 4. It would also be useful to discuss if there are limitations on simply
> blocking fragmented NDP traffic. 

Please see draft-ietf-6man-oversized-header-chain (and the figures in
draft-ietf-v6ops-ra-guard-implementation). Short story: with the current
specs, you might not be able to tell whether a packet is NDP or not --
hence your policy ends up being "drop fragmented v6 traffic"
(draft-ietf-v6ops-ra-guard-implementation is "as good as it can get" for
this specific case)


> Since this traffic is limited to a
> single L-2 link, dropping fragments may be a simple mechanism for
> dealing with fragmentation-based attacks.

The current packet structure is a nightmare for any device willing to
perform any sort of inspection. So at the very least you need to process
the entire IPv6 header chain -- and some devices cannot even do this.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492