Skip to main content

Early Review of draft-ietf-lisp-pubsub-06

Request Review of draft-ietf-lisp-pubsub
Requested revision No specific revision (document currently at 15)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2020-10-15
Requested 2020-09-17
Requested by Joel M. Halpern
Authors Alberto Rodriguez-Natal , Vina Ermagan , Albert Cabellos-Aparicio , Sharon Barkai , Mohamed Boucadair
I-D last updated 2020-10-08
Completed reviews Secdir Early review of -06 by Chris M. Lonvick (diff)
Rtgdir Last Call review of -10 by Mike McBride (diff)
Opsdir Last Call review of -10 by Al Morton (diff)
Genart Last Call review of -10 by Roni Even (diff)
Tsvart Last Call review of -10 by Magnus Westerlund (diff)
Secdir Last Call review of -10 by Chris M. Lonvick (diff)
Intdir Telechat review of -10 by Sheng Jiang (diff)
We are approaching WG LC on this document.  We would like to get the security review now, rather than waiting until IETF LC.  Thank you.
Assignment Reviewer Chris M. Lonvick
State Completed
Request Early review on draft-ietf-lisp-pubsub by Security Area Directorate Assigned
Posted at
Reviewed revision 06 (document currently at 15)
Result Has nits
Completed 2020-10-01

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.

This is an "Early Review Request" so I'm going to mark the draft as 

It appears that there's a raft of drafts of LISP documents progressing 
together through the WG that cross-reference each other in that they all 
provide foundation and support for their collective features. (I'll 
admit that I haven't been keeping up.) So if my nits have been addressed 
in another document, that just means that I didn't dig far or deep 
enough so please consider giving a pointer in the Security 
Considerations of this document so others won't similarly be left adrift.

In this document, and the associated others that I peered into, the term 
"nonce" seems to be used more as a "token" than, well, what I consider 
to be a nonce. In one case it may be a random value, but in several 
others the value is stored, compared, and reused.  This is inconsistent 
with the IETF's Security Glossary RFC 4949.

Also, there is a reference to increasing the nonce for a particular use. 
However, I saw no discussion of what to do when the value exceeds the 
field space.

Other than that, the document appears to be well written and well 
thought out.

Best regards,