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

[Luigi Iannone <[e-mail]>]

Great!

Thanks Murray.
They will be part of the next revision.

Ciao

L.


> On 30 Jun 2022, at 19:57, Murray S. Kucherawy <[e-mail]> wrote:
> 
> Hi Luigi,
> 
> All of your proposed changes look good to me.
> 
> -MSK
> 
> On Thu, Jun 30, 2022 at 2:47 AM Luigi Iannone <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Murray,
> 
> Thanks a lot for your review.
> Please see inline.
> 
>> On 30 Jun 2022, at 09:29, Murray Kucherawy via Datatracker <[e-mail] <mailto:[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/ <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/ <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.
>