Any status on this?

Dino

> On Sep 5, 2016, at 10:07 AM, Dino Farinacci <farina...@gmail.com> wrote:
> 
> See responses inline. A new draft is attached (but not submitted since I had 
> some open questions).
> 
>>> Document: draft-ietf-lisp-crypto-06.txt
>>> 
>>> Reviewer: Danny McPherson
>>> 
>>> Review Date: August 24, 2016
>>> 
>>> Intended Status: Experimental
> 
> Thanks for the review Danny.
> 
>>> Summary:
>>> 
>>> I have some minor concerns about this document that should be considered 
>>> before publication.
>>> 
>>> Comments:
>>> 
>>> I believe the draft is technically sound. 
>>> 
>>> Major Issues:
>>> 
>>> I have no “Major” issues with this I-D.
> 
> Good to hear.
> 
>>> Minor Issues:
>>> 
>>> In the Security Considerations section a small amount of text might be 
>>> useful that discusses end-end v. encryption from middle boxes, and the 
>>> risks therein.  There are clearly benefits to this over no encryption, but 
>>> there are risks about assumptions that may be made thereafter as well.
> 
> I added some text. Please review.
> 
>>> Nits:
>>> 
>>> S.1: s/typically not modified.  Which means/typically not modified, which 
>>> means/
> 
> Changed.
> 
>>> S.1: Is there in fact a case where asymmetries result in the *same* egress 
>>> xTRs but different keys are used?  I believe this would just apply to 
>>> "different xTRs", no?  :
> 
> Right, when the same ETR is used by different ITRs to encapsulate traffic, 
> different keys are used.
> 
>>>        However, return traffic uses the same procedures but with different 
>>> key values by the same xTRs or potentially different xTRs when the paths 
>>> between LISP sites are asymmetric.
> 
> Right, a unique set of keys are used for each {ITR, ETR} combination. Did you 
> want me to say something specific here?
> 
>>> S.1: Regarding "[t]his document has the following requirements for the 
>>> solutions space", it might be useful to reference some general IETF privacy 
>>> work, even RFC 6973 or the like.  Given that it's Experimental I think it's 
>>> fine as is, but some references for the broader community may be in order.  
>>> In particular, references to not requiring a separate PKI (and therefore 
>>> external or circular dependencies!), avoiding third party trust anchor, 
>>> rekeying as good operational practice, not just compromises,  and other 
>>> such arguments might be reinforced. 
> 
> I added a reference to 6973.
> 
>>> S.3: Could include LCAF here, perhaps.
> 
> Added plus its reference.
> 
>>> S.4: You could probably strike this entire sentence and lessen confusion: 
>>> "When an ETR (when it is also an ITR) encapsulates packets to this ITR 
>>> (when it is also an ETR), a separate key exchange and shared-secret 
>>> computation is performed.”
> 
> Okay, removed.
> 
>>> S.7: It’s unclear what constitutes “Diffie-Hellman *group*”.
> 
> I will change “group” to “parameters”.
> 
>>> 
>>> S.7: s/the the/the/
>>> 
>>> S.7: s/integrity-check/integrity check/
> 
> Changed both.
> 
>>> S.8: Editors note to strike text in last paragraph here, unclear what 
>>> resolution was from this text.  
> 
> We allocated two new bits from a 3-bit reserved field now leaving 1 reserve 
> bit. I added that the reserved bit remaining is documented in RFC6830.
> 
>>> S.12.1: A reference to the SAAG comments might be useful here?
> 
> We don’t have one. But I will add a list of recommendations they provided.
> 
>>> S 13: Are you sure you want a default FCFS allocation policy here and not a 
>>> slightly higher bar?
> 
> I have no opinion. What is the benefit on not doing FCFS?
> 
>>> Throughout: Consistent hyphenation in the document would help (e.g., 
>>> “network-byte” ..).  
> 
> Done.
> 
>>> Throughout: Expanding on first use of each acronym would be useful, perhaps 
>>> with references.
> 
> Done.
> 
> A new revision is attached (plus a htmlized diff file). Let me know if you 
> like the text and then I’ll submit -07.
> 
> Thanks again,
> Dino & Brian
> 
> <rfcdiff.html><draft-ietf-lisp-crypto-07.txt>
> 
> 
> 
> 

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to