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 protected]] >> Sent: Thursday, August 10, 2017 12:30 AM >> To: BRUNGARD, DEBORAH A <[email protected]> >> Cc: Manav Bhatia <[email protected]>; [email protected]; > [email protected] >> 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 protected]> 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 protected]] >> Sent: Thursday, June 22, 2017 10:11 AM >> To: Manav Bhatia <[email protected]> >> Cc: BRUNGARD, DEBORAH A <[email protected]>; [email protected]; > [email protected] >> 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 protected]> > 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 protected]> 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 protected]> wrote: >> Hi Manav, >> >> Much thanks for your review! >> >> Authors, please address Manav’s comments. >> >> Thanks, >> Deborah >> >> >> From: lisp [mailto:[email protected]] On Behalf Of Manav Bhatia >> Sent: Wednesday, May 17, 2017 4:41 AM >> To: [email protected] >> Cc: [email protected]; [email protected]; [email protected] >> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
