Any status on this? Dino
> On Sep 5, 2016, at 10:07 AM, Dino Farinacci <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
