• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: 6man

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

2013-04-16 09:54 Brian Haberman

State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup

2013-04-08 04:41 Stephen Farrell

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

2013-04-08 04:41 Stephen Farrell

[Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss

2013-03-29 06:30 Adrian Farrel

[Ballot comment]
Thank you for adding some good operational advice that addresses my Discuss.

2013-03-29 06:30 Adrian Farrel

[Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss

2013-03-25 03:33 Martin Stiemerling

[Ballot comment]
Thanks for addressing my DISCUSS.

2013-03-25 03:33 Martin Stiemerling

[Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss

2013-03-22 14:38 (System)

Sub state has been changed to AD Followup from Revised ID Needed

2013-03-22 14:38 Fernando Gont

New revision available

2013-02-26 13:03 Brian Haberman

Ballot writeup was changed

2013-02-26 07:54 Brian Haberman

Ballot writeup was changed

2013-02-21 11:10 Cindy Morgan

State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation

2013-02-20 20:19 Pete Resnick

[Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick

2013-02-20 19:46 Wesley Eddy

[Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy

2013-02-20 14:24 Benoit Claise

[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?

2013-02-20 14:24 Benoit Claise

[Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss

2013-02-20 12:51 Sean Turner

[Ballot Position Update] New position, No Objection, has been recorded for Sean Turner

2013-02-19 23:30 Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo

2013-02-19 18:21 Stephen Farrell

[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?

2013-02-19 18:21 Stephen Farrell

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

Viewing the last 20 entries. Show full log.