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

From: Brian Haberman <[email-masked]>
Date: Mon, 14 Jan 2013 10:10:04 -0500

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.

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.

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.

4. It would also be useful to discuss if there are limitations on simply 
blocking fragmented NDP traffic.  Since this traffic is limited to a 
single L-2 link, dropping fragments may be a simple mechanism for 
dealing with fragmentation-based attacks.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Jan 2013 17:01:23 -0300

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

> to focus on the use of fragmentation within NDP messages.

Fixed.

> things, so I am not sure why 4862 is getting put into this statement.

Fixed.

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

> 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

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-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492