Skip to main content

Last Call Review of draft-ietf-p2psip-service-discovery-13
review-ietf-p2psip-service-discovery-13-secdir-lc-melnikov-2014-08-15-00

Request Review of draft-ietf-p2psip-service-discovery
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-08-05
Requested 2014-06-26
Authors Jouni Maenpaa , Gonzalo Camarillo
I-D last updated 2014-08-15
Completed reviews Genart Last Call review of -13 by Suresh Krishnan (diff)
Genart Telechat review of -14 by Suresh Krishnan (diff)
Secdir Last Call review of -13 by Alexey Melnikov (diff)
Assignment Reviewer Alexey Melnikov
State Completed
Request Last Call review on draft-ietf-p2psip-service-discovery by Security Area Directorate Assigned
Reviewed revision 13 (document currently at 15)
Result Has issues
Completed 2014-08-15
review-ietf-p2psip-service-discovery-13-secdir-lc-melnikov-2014-08-15-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.




I believe this document is "ready with issues."

REsource LOcation and Discovery (RELOAD) does not define a generic
service discovery mechanism as a part of the base protocol.  This
document defines how the Recursive Distributed Rendezvous (ReDiR)
service discovery mechanism used in OpenDHT can be applied to RELOAD
overlays to provide a generic service discovery mechanism.



The Security Considerations section points to the Security 


Considerations section of RFC 6940, which is quite extensive and relevant.






The document also defines a new access control policy called 


NODE-ID-MATCH. As only nodes that own service discovery information can 


update it, it looks like there are no additional security issue raised 


beyond what is already covered in RFC 6940. As the information is 


public, I can't think of any privacy concerns.






While I was able to follow the document, I think it lacks attention to 


details which are not obvious for somebody not following the technology. 


Minor issues that should be easy to fix:






 On page 4: H(x) - missing reference to SHA-1. Any specific properties 


required from H(x)?




 Namespace - missing reference to UTF-8.



 On page 6: H() with multiple arguments is not defined, especially if 


they can be both strings and integers (what byte order)? b' is not 


defined. Typo in the description?






In 4.2 I read "the mode of those depths". Can you explain what this 


means? Or is this a typo?