Skip to main content

Last Call Review of draft-ietf-lisp-pubsub-10
review-ietf-lisp-pubsub-10-secdir-lc-lonvick-2023-01-26-00

Request Review of draft-ietf-lisp-pubsub
Requested revision No specific revision (document currently at 15)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-01-26
Requested 2023-01-12
Authors Alberto Rodriguez-Natal , Vina Ermagan , Albert Cabellos-Aparicio , Sharon Barkai , Mohamed Boucadair
I-D last updated 2023-08-04 (Latest revision 2023-02-28)
Completed reviews Secdir Early review of -06 by Chris M. Lonvick (diff)
Rtgdir IETF Last Call review of -10 by Mike McBride (diff)
Opsdir IETF Last Call review of -10 by Al Morton (diff)
Genart IETF Last Call review of -10 by Roni Even (diff)
Tsvart IETF Last Call review of -10 by Magnus Westerlund (diff)
Secdir IETF Last Call review of -10 by Chris M. Lonvick (diff)
Intdir Telechat review of -10 by Sheng Jiang (diff)
Assignment Reviewer Chris M. Lonvick
State Completed
Request IETF Last Call review on draft-ietf-lisp-pubsub by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/sMxz2TKMhwsw15SDJBQYO760WyU
Reviewed revision 10 (document currently at 15)
Result Has nits
Completed 2023-01-26
review-ietf-lisp-pubsub-10-secdir-lc-lonvick-2023-01-26-00
Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

It appears that the issue that I brought up in my early review of the draft has
not been addressed. The draft continues to use the term nonce in a way that is
not consistent with RFC 4949. This is likely not an operational problem as the
rules defined for using it are well described in the document. This could be
addressed by stating that a nonce is generated in the Map-Request, and the
value of the nonce is used in subsequent exchanges.

The TSVART reviewer of the draft seems to be much more familiar with LISP than
I, and brings up a lot of security issues. I would like to see those issues
addressed.

Regards,
Chris