Last Call Review of draft-ietf-lisp-sec-12
review-ietf-lisp-sec-12-rtgdir-lc-bhatia-2017-05-17-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-lisp-sec-12

Reviewer: Manav Bhatia

Review Date: 17/05/2017
IETF LC End Date: Unknown
Intended Status: Experimental

Summary:

I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

The draft describes the protocol mechanisms to secure LISP messages to
provide origin authentication, integrity and anti-replay protection. The
draft is very well written and readable even for someone who had never read
LISP documents before.

Major Issues:

None

Minor Issues:

1. All one time keys are exchanged by encrypting those using preconfigured
shared keys (PSKs).  This is done for messages exchanged between ITR and
the MapResolver and the ETR and the Map-Server. Given that the entire
security of the LISP domain falls on the PSK I found it rather strange that
the authors have not spent any time discussing on the crypto life cycle of
the PSKs. I would like to see some discussion on whether the PSKs should be
long lived and need to be changed or whether they exist till eternity. I
would presume that they should have a limited lifetime and may need to be
changed when an operator who had access to them leaves. It can be argued
that the user will never even know if an attacker has compromised the key
if it remains "passive" till the d-day. Frequent key changes will limit
potential damage from compromised keys.

Another threat against the long-lived key is that one of the systems
storing the key, or one of the users entrusted with the key, could get
subverted. So, while there may not be cryptographic motivations of changing
the keys, there could be system security motivations for rolling the key.

2. Has the WG considered using a Key Management protocol to dynamically
distribute the keys, instead of using the PSKs? Can the authors add some
text around that?

3. I am afraid I dont see how the messages are protected against the replay
attacks.

Thanks, Manav