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: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
