Re: [lisp] Murray Kucherawy's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS and COMMENT)

[Luigi Iannone <[e-mail]>]

Hi Murray,

Thanks a lot for your review.
Please see inline.

> On 30 Jun 2022, at 09:29, Murray Kucherawy via Datatracker <[e-mail]> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-lisp-sec-27: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Sections 8.1 through 8.5 all create registries with "Specification Required"
> rules.  RFC 8126 says this about "Specification Required":
> 
>   As with Expert Review (Section 4.5), clear guidance to the designated
>   expert should be provided when defining the registry, and thorough
>   understanding of Section 5 is important.
> 
> Only Section 8.5 includes any such guidance.  Is none needed for the other
> four?

Actually all of them need guidance which is basically the same and could be provide at the beginning of the IANA section.

>  Also, I'm having trouble understanding the advice that Section 8.5 does
> give.
> 

The beginning of the IANA section  can be:

IANA is requested to create the sub-registries listed in the
following sections in the "Locator/ID Separation Protocol (LISP)
Parameters" registry.

New values beyond this document have to be assigned according to  the 
"Specification Required" policy defined in [RFC8126]. 
Expert review should assess the security properties of newly added 
functions, so that encryption robustness is remains strong.
For instance, at the time of this writing the use of SHA-256-based functions is 
considered to provide sufficient protection. Consultation with security experts may be needed.

Does the above text look good to you or do you have any suggestion of a better formulation?




> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I concur with John; this was generally well-done and easy to understand.  Nice
> work.  A couple of suggestions:
> 
> In Section 6.1 has:
> 
>   E: ETR-Cant-Sign bit.  This bit is set to 1 to signal ...
> 
> I think you mean "If this bit is set to 1, it signals ..." or something
> similar.  Taken literally, the current text means you always set it to 1, but I
> don't think that's what you meant to say.

You are right: it should read:

E: ETR-Cant-Sign bit. If this bit is set to 1, it signals to the ITR
            that at least one of the ETRs authoritative for the EID prefixes
            of this Map-Reply has not enabled LISP-SEC.

> 
> I think the fifth paragraph of Section 6.4 is missing a period or something.  I
> found it hard to parse toward the end.
> 
> 
> 


   The ITR-OTK is wrapped with the algorithm specified by the OTK
   Wrapping ID field.  See Section 6.5 <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-sec-27#section-6.5> for further details on OTK
   encryption.  If the NULL-KEY-WRAP-128 algorithm (see Section 8.4 <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-sec-27#section-8.4>) is
   selected, and no other encryption mechanism (e.g.  DTLS) is enabled
   in the path between the ITR and the Map-Resolver, the Map-Request
   MUST be dropped, and an appropriate log action SHOULD be taken.
   Implementations may include mechanisms (which are beyond the scope of
   this document) to avoid log resource exhaustion attacks.


Two commas and a period were missing…. Does it read better?

Ciao

L.