Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-sec-26: (with COMMENT)

[Luigi Iannone <[e-mail]>]

Hi Éric,

Thanks for your review.
Few answers inline.

> On 15 Jun 2022, at 19:12, Éric Vyncke via Datatracker <[e-mail]> 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
> 
> 
>