Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality
RFC 8061
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Deborah Brungard; former steering group member) Yes
(Stephen Farrell; former steering group member) Yes
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 steering group member) No Objection
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 steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
Section 12.1 seems unnecessary.
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
Susan Hares <shares@ndzh.com> provided the opsdir review
(Kathleen Moriarty; former steering group member) No Objection
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 steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection