Subject: [lisp] Any status on resolving issues with draft-ietf-lisp-sec-12?

From: Dino Farinacci <[email-masked]>
Date: Thu, 14 Sep 2017 09:41:43 -0700

I am wondering since its been stuck for 110 days. Albert? I think ball was in your court last?

Dino

>> From: Albert Cabellos [mailto:[email-masked]]
>> Sent: Thursday, August 10, 2017 12:30 AM
>> To: BRUNGARD, DEBORAH A <[email-masked]>
>> Cc: Manav Bhatia <[email-masked]>; [email-masked];
> [email-masked]
>> Subject: Re: [lisp] RtgDir review : draft-ietf-lisp-sec-12
>> 
>> Hi Deborah
>> 
>> I apologize for the delay, I´ll reply ASAP
>> 
>> Kind regards
>> 
>> Albert
>> 
>> On Thu, Aug 10, 2017 at 5:02 AM, BRUNGARD, DEBORAH A
> <[email-masked]> wrote:
>> Hi Albert,
>> 
>> This was the last mail which I have on this?
>> 
>> Please answer Manav’s concerns so we can prep for Last Call.
>> 
>> Thanks,
>> Deborah
>> 
>> 
>> From: Albert Cabellos [mailto:[email-masked]]
>> Sent: Thursday, June 22, 2017 10:11 AM
>> To: Manav Bhatia <[email-masked]>
>> Cc: BRUNGARD, DEBORAH A <[email-masked]>; [email-masked];
> [email-masked]
>> Subject: Re: [lisp] RtgDir review : draft-ietf-lisp-sec-12
>> 
>> Hi Manav
>> 
>> I apologize for the very slow reply, I´ve been swamped with other duties.
>> 
>> I´ll get back to your comments ASAP
>> 
>> Kind regards
>> 
>> Albert
>> 
>> On Thu, Jun 22, 2017 at 3:49 PM, Manav Bhatia <[email-masked]>
> wrote:
>> Folks,
>> 
>> Did i miss the response? I dont think i did, but just wondering ..
>> 
>> Cheers, Manav
>> 
>> On Wed, May 31, 2017 at 5:57 PM, Albert Cabellos
> <[email-masked]> wrote:
>> Hi Manav, Deborah
>> 
>> Thanks for the review, we are working on it, we´ll get back to you ASAP
>> 
>> Albert
>> 
>> On Fri, May 26, 2017 at 10:00 PM, BRUNGARD, DEBORAH A
> <[email-masked]> wrote:
>> Hi Manav,
>> 
>> Much thanks for your review!
>> 
>> Authors, please address Manav’s comments.
>> 
>> Thanks,
>> Deborah
>> 
>> 
>> From: lisp [mailto:[email-masked]] On Behalf Of Manav Bhatia
>> Sent: Wednesday, May 17, 2017 4:41 AM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: [lisp] RtgDir review : draft-ietf-lisp-sec-12
>> 
>> 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
> seehttp://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