Hi Murray, Thanks a lot for your review. Please see inline.
> On 30 Jun 2022, at 09:29, Murray Kucherawy via Datatracker <[email protected]> > 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.
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
