Hi Éric, Thanks for your review. Few answers inline.
> On 15 Jun 2022, at 19:12, Éric Vyncke via Datatracker <[email protected]> > wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-lisp-sec-26: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of > draft-ietf-lisp-sec-26 CC @evyncke > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education). > > Special thanks to Luigi Iannone for the shepherd's detailed write-up including > the WG consensus and the justification of the intended status. > > I hope that this helps to improve the document, > > Regards, > > -éric > > ## COMMENTS > > ### Section 5, trusts relationships > > This section mentions 'trust relationships', but do not explain how those are > created ? A forward reference would be welcome (e.g., to section 7.5 but even > this is rather weak). More details are actually in 6833bis. I think would be good to put both a forward reference and a direct reference to 6833bis (it is cited in section 7 but put also here does not harm). > ### Section 5, decrypting something that was not encrypted > ``` > 1. The ITR, upon needing to transmit a Map-Request message, > generates and stores an OTK (ITR-OTK). This ITR-OTK is included > into the Encapsulated Control Message (ECM) that contains the > Map-Request sent to the Map-Resolver. Good point the text is a bit unclear. The ITR-OTK is always encrypted, either with a pre-shared key or by simply using DTLS to send the whole ECM message. My Suggestion is to modify the first bullet as: 1. The ITR, upon needing to transmit a Map-Request message, generates and stores an OTK (ITR-OTK). This ITR-OTK is included into the Encapsulated Control Message (ECM) that contains the Map-Request sent to the Map-Resolver, and encrypted. The encryption is then already explained in Section 6.5. Do you consider this sufficiently clear? > ``` > > Based on the text following this bullet, should the ITR-OTK also be encrypted > (as it is decrypted in step 2) ? > > ### Section 7.5 > > Are the shared keys per ITR Map-resolver pair or are they shared by *ALL* ITR > and the Map-resolver(s). It is probably the former as the latter would be a > huge threat of impersonation among ITR. Should there be some text about this ? Excellent point. To me was so obvious that is by pair that never thought in a different way. I’ll ask the authors to clarify. > > ### Performance impact of LISP-SEC > > Did the authors have an estimate on the performance impact (crypto operations, > increased size of the messages) of LISP-SEC? Should there be a section about > this potential impact ? I am unsure whether the authors have any performance measure. Ciao L. > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
