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

[Ballot comment]

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

[Ballot comment]
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?

[Ballot discuss]
(1) cleared

(2) cleared

(3) Doesn't the SHOULD NOT for certification path advertisement
messages in section 4 essentially make SEND unusable? If so,
why is that ok? If not, can you explain how a real
certification path can fit in a single packet?

(4) section 4 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?

(5) How does this draft work with RFCs 6494, 6495 and 6487?
Would it break deployments using those? Did the WG consider
that? Was there some review from the sidr wg?

[Ballot comment]
- 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.

[Ballot discuss]
1) cleared -- thanks for the information.

2)
Section 1., paragraph 8:

>    Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
>    Neighbor Discovery traffic in the hopes of detecting possible attacks
>    when there are discrepancies between the information advertised in
>    Neighbor Discovery packets and the information stored on a local
>    database. rafixd [rafixd] goes one step further, and tries to
>    mitigate some Neighbor Discovery attacks by sending "correcting"
>    Router Advertisement messages in response to incorrect/malicious
>    Router Advertisement messages.

  sending corrections can open another attack vector, if the
  information believed to be correct is simply wrong. I wouldn't
  add such a recommendation in any form to an IETF standards track
  document. I would even discourage any such action.

[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terribly wrong.

[Ballot comment]

  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.

[Ballot discuss]
I was just ballotting No Objection, when something in Stephen's Discuss
caught my eye.

It would appear that there might be implementations deployed that use
fragmentation of neighbor discovery messages (even though, as this
document correctly notes, they could achieve the same result by sending
multiple messages).

Nodes that conform to this document will silently ignore fragmented ND
messages, and that will make them unable to interoperate with deployed
nodes that implemented a standards track RFC in good faith.

While we should be free to modify and fix our protocol specifications,
we usually look to do it in a way that will be backward compatible with
existing deployments, or at least provide a migration path.

Given the quoted text in section 2 (by the way, quoted from where?) it
seems that some existing implementations will have interoperability
problems anyway, and this document is "only" increasing the number of
nodes that will silently ignore ND messages.

Perhaps this can all be addressed with a little advice to the operator
of a node that finds itself unable to be discovered?

[Ballot discuss]
Operationally, when can the sys admin turn on this feature?
Actually, we have two separate features:
  1. Nodes MUST NOT employ IPv6 fragmentation for sending any of the
  following Neighbor Discovery and SEcure Neighbor Discovery messages:

  2.  Nodes MUST silently ignore the following Neighbor Discovery and
  SEcure Neighbor Discovery messages if the packets carrying them
  include an IPv6 Fragmentation Header:

1. is straightforward, and could be done at any time, while 2. MUST NOT be done until all the legitimate hosts support 1.
Correct?
Does it imply that we need a way to detect that all legitimate hosts in the network support 1.?
This also leads to question: how do I know which hosts are legitimate or not...
Anyway, my point is that, if 2. is turn on without checking a few things, then it might result in loss of connectivity (example: NS from a legitimate host with fragmented packet)
This document requires some text around that.

[Ballot comment]
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?

[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terribly wrong.

- I couldn't find the shepherd write-up here in the datatracker. Gone missing or is it just me?

[Ballot discuss]
1) I'm with Stephen's point 1, about no existing implementations and also deployment experience of this.

2)
Section 1., paragraph 8:

>    Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
>    Neighbor Discovery traffic in the hopes of detecting possible attacks
>    when there are discrepancies between the information advertised in
>    Neighbor Discovery packets and the information stored on a local
>    database. rafixd [rafixd] goes one step further, and tries to
>    mitigate some Neighbor Discovery attacks by sending "correcting"
>    Router Advertisement messages in response to incorrect/malicious
>    Router Advertisement messages.

  sending corrections can open another attack vector, if the
  information believed to be correct is simply wrong. I wouldn't
  add such a recommendation in any form to an IETF standards track
  document. I would even discourage any such action.

[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terribly wrong.

[Ballot discuss]
1) I'm with Stephen's point 1, about no existing implementations and also deployment experience of this.

2)
Section 1., paragraph 8:

>    Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
>    Neighbor Discovery traffic in the hopes of detecting possible attacks
>    when there are discrepancies between the information advertised in
>    Neighbor Discovery packets and the information stored on a local
>    database. rafixd [rafixd] goes one step further, and tries to
>    mitigate some Neighbor Discovery attacks by sending "correcting"
>    Router Advertisement messages in response to incorrect/malicious
>    Router Advertisement messages.

  sending corrections can open another attack vector, if the
  information believed to be correct is simply wrong. I wouldn't
  add such a recommendation in any form to an IETF standards track
  document.

[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terrible wrong.

[Ballot discuss]

(1) I'm not comfortable with updating esp 4861 like this when
no implementations of this are known to exist as the write up
says. Wouldn't it be prudent to wait until an implemention is
done and tested before forbidding currently implemented
behaviours? I'll likely clear this when told that its not a
concern, but do want to check.

(2) Section 1 says the attacker can generate lots of
fragemented packets and implies that's a reason why
fragmentation support is a bad idea. Why can't a target node
normally handle fragments but turn off fragment support
handling if it detects an anomoly?  (Such as seeing a spike in
fragments.) Did the WG consider this possibility? If you say
that that'd involve keeping additional state and might impact
on performance then I'll buy that, but I don't know if that's
really the case or not.

(3) Doesn't the SHOULD NOT for certification path advertisement
messages in section 4 essentially make SEND unusable? If so,
why is that ok? If not, can you explain how a real
certification path can fit in a single packet?

(4) section 4 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?

(5) How does this draft work with RFCs 6494, 6495 and 6487?
Would it break deployments using those? Did the WG consider
that? Was there some review from the sidr wg?

[Ballot comment]

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

[Ballot comment]
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.

IANA has reviewed draft-ietf-6man-nd-extension-headers-03, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Security Implications of IPv6 Fragmentation with IPv6 Neighbor
  Discovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document analyzes the security implications of employing IPv6
  fragmentation with Neighbor Discovery (ND) messages.  It updates RFC
  4861 such that use of the IPv6 Fragmentation Header is forbidden in
  all Neighbor Discovery messages, thus allowing for simple and
  effective counter-measures for Neighbor Discovery attacks.  Finally,
  it discusses the security implications of using IPv6 fragmentation
  with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971
  to provide advice regarding how the aforementioned security
  implications can be prevented.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers/ballot/


No IPR declarations have been submitted directly on this I-D.