Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
draft-ietf-6man-nd-extension-headers-05

Thank you for adding some good operational advice that addresses my Discuss.

Apparently, there is no issue with my DISCUSS, as it will not happen in real life. So I cleared.

Thanks for a nice introduction that gives a summary state of the art of IPv6 ND, related work, and problem statement.

- what is the impact on RFC 6105? I mean: should the L2 doing the IPv6 RA-Guard be blocking those fragmented packets?
Or actually this is solved in http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07, which is supposed to be updating RFC 6105? Note: I see [I-D.ietf-6man-nd-extension-headers] in the normative reference from http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07 but the reference is not mentioned in the text.
Disclaimer: I have not read draft-ietf-v6ops-ra-guard-implementation
Please discuss this issue with me.


- One editorial issue:

   For example, as noted in
   [I-D.ietf-v6ops-ra-guard-implementation], current RA-Guard
   implementations can be trivially evaded by fragmenting the attack
   packets into multiple fragments, such that the layer-2 device cannot
   find all the necessary information to perform packet filtering in the
   same packet. 

The link above points to 
   [I-D.ietf-v6ops-ra-guard-implementation] discusses an improvement to
   the RA-Guard mechanism that can mitigate Neighbor Discovery attacks
   that employ IPv6 Fragmentation. 

... because [I-D.ietf-v6ops-ra-guard-implementation] is not a link, and is 
   thought of being the reference itself.

- 
      Some Neighbor Discovery implementations are known to silently
      ignore Router Advertisement messages that employ fragmentation.
      Therefore, splitting the necessary information into multiple RA
      messages (rather than sending a large RA message that is
      fragmented into multiple IPv6 fragments) is probably desirable
      even from an interoperability point of view. 

The previous paragraph is indented, so it seems to be a cut/paste from a different document?
If yes, from which document?

-
   SEND packets typically carry more information than traditional
   Neighbor Discovery packets: for example, they include additional
   options such as the CGA option and the RSA signature option.

CGA and RSA?

Thanks for addressing my DISCUSS.

  In response to the Gen-ART Review by Meral Shirazipour on 29-Jan-2013
  the authors agreed to make some minor changes.  An update with these
  changes has not been posted yet.

- Used to be discuss point 3:

Adding a pointer to Section 6.4.2 of RFC 3971 from section 5 where
you discuss CPA messages would be good. That bit of 3971 says:

         A single advertisement SHOULD be broken into separately sent
         components if there is more than one certificate in the path,
         in order to avoid excessive fragmentation at the IP layer. 

So I'd suggest the following change here:

OLD;

   Nodes SHOULD NOT employ IPv6 fragmentation for sending the following
   messages:

NEW:


   Nodes SHOULD NOT employ IPv6 fragmentation for sending the following
   messages: (See  Section 6.4.2 of RFC 3971)

- Used to be discuss point 4:

section 5 says: "SEND nodes SHOULD NOT employ keys that
would result in fragmented CPA messages." That's wrong since we
don't know what algorithms will be needed in future, nor how
big their keys will need to be.  Its also imprecise, e.g. how
big an RSA public key is ok and how big is not? I think you
need to give some guidance here since otherise implementers are
likely to get this wrong, or just not do it. In addition, not
all those keys are under the control of the SEND nodes, e.g.
intermediate CA keys might be long so how can a SEND node
ensure that it meets this requirement? I suggest the following
replacement:

   SEND nodes and relevant certification authorities SHOULD NOT employ 
   keys that would result in fragmented CPA messages.

- Used to be discuss point 5:

Checking if this breaks rfc 6494... You checked and it doesn't
but it'd be good to incluide some text about that, for example
derived from your mail on that:

> I have contacted one of the co-authors of RFC6494 (Roque Gagliano), who
> confirmed that the size of the resulting packets is roughly the same
> (very similar). They did the corresponding math while pursuing RFC6494,
> but didn't include it in the RFC. HOwever, here it is:
> 
> Packet size from RFC3971: 1055 to 1066bytes
> Difference resulting from key length: 128 bytes
> IPv6 header: 40 bytes
> ICMPv6 header: 4 bytes
> Total: 1227-1238bytes << 1500 bytes
> (This has been veryfied doing packet sniffing... and I'm attaching a
> sample certificate, kindly provided by Roque Gagliano)




---- older comments


- section 1, 2nd para, says that trust anchors make deployment
hard, but doesn't say why. Given we do have cases where TA
deployment has been done, I think you ought back up the
statement.

- section 2: why the indentation of para 2? It looks like a
quote, but from where?

- section 3, 4th para, "Authorization Delegation Discovery"?
could do with a reference (3971 section 6), and I don't quite
get how this thwarts the attacks but doesn't leave open other
ways to get a node to fall back to unsecured mode, if a node is
configured to do that anyway.

This is a well written draft.

Nit:
If you edit the draft before it goes to the RFC-Editor it could use a scrub for undefined abreviations. I noticed CPA and RA.