Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality
draft-ietf-lisp-crypto-10
Yes
(Deborah Brungard)
No Objection
(Alia Atlas)
(Ben Campbell)
(Benoît Claise)
(Jari Arkko)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 08 and is now closed.
Deborah Brungard Former IESG member
Yes
Yes
(for -08)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2016-10-13 for -09)
Unknown
Thanks for doing this. Great to see folks incorporating such things where we can and I'll be interested to see how the experiments with this pan out. - intro: (nit) "PKI infrastructure" - the I in PKI already means infrastructure:-) - intro: (another nit) I don't get why " o Packet transport is optimized due to less packet headers. Packet loss is reduced by a more efficient key exchange." is true. - 3: (more nittyness:) AEAD is defined in RFC5116. - section 6 non-nit: I don't see why you want cipher suites 1, 2 and 4. The set of 3,5 and 6 seems to me like it'd be plenty. If it's not too late, I'd encourage you to either drop 1,2 and 4 or say those are OPTIONAL and 3,5 and 6 are RECOMMENDED. - section 7: I think you should embed the KDF into the cipher suite. It's ok to only have one KDF now, but later you may want others and it's fairly easy to include the KDF as part of the definition of the ciphersuite. - section 7: Why didn't you choose RFC 5869 for the KDF? That's a more accessible reference I think and just as good.
Alexey Melnikov Former IESG member
No Objection
No Objection
(2016-10-13 for -09)
Unknown
Thank you for this document. I would like to double check that I understand the document correctly. Is the following scenario possible: ITR requests negotiation of 3 keys, then in a later request ITR can request change to 1 (or 2) of the keys, while continuing to use the remaining keys?
Alia Atlas Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2016-10-12 for -08)
Unknown
Section 12.1 seems unnecessary.
Ben Campbell Former IESG member
No Objection
No Objection
(for -09)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -08)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-10-12 for -09)
Unknown
Susan Hares <shares@ndzh.com> provided the opsdir review
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-10-12 for -09)
Unknown
Thanks for your work on this draft. I think the draft would read better if the content of the Abstract is repeated in the introduction. If you read just the introduction, it is not clear what this draft is about, the abstract text is needed to have an understanding. In the introduction, I'm not sure what this means: Packets that arrive at the ITR or PITR are typically not modified, which means no protection or privacy of the data is added. Do you mean modified as in 'not encrypted' or something else? It would be easier to read if what you meant was clearly stated. It's followed by this sentence: If the source host encrypts the data stream then the encapsulated packets can be encrypted but would be redundant. But the introduction doesn't clearly say what this would be redundant to. Can you clarify this text too? Thanks for addressing the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg06835.html
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -09)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -09)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -08)
Unknown