Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality
RFC 8061

Note: This ballot was opened for revision 08 and is now closed.

Deborah Brungard Yes

(Stephen Farrell) Yes

Comment (2016-10-13 for -09)
No email
send info
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.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2016-10-12 for -08)
No email
send info
Section 12.1 seems unnecessary.

(Spencer Dawkins) No Objection

(Joel Jaeggli) No Objection

Comment (2016-10-12 for -09)
No email
send info
Susan Hares <shares@ndzh.com> provided the opsdir review

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Alexey Melnikov No Objection

Comment (2016-10-13 for -09)
No email
send info
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?

(Kathleen Moriarty) No Objection

Comment (2016-10-12 for -09)
No email
send info
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