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

[Éric Vyncke via Datatracker <[e-mail]>]

É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).

### 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.
```

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 ?

### 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 ?

## 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