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 in informational document describing a technical trial of a
proposed approach to peer-to-peer traffic flow improvement. Here's the
security considerations section:

"7.  Security Considerations

   There are no security considerations in this document.

   NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO
   PUBLICATION."


The current instructions to RFC authors are at



http://www.rfc-editor.org/rfc-editor/instructions2authors.txt



This document says "All RFCs must contain a section that discusses the
security considerations relevant to the specification in the RFC; see
       [Secur03] for more information.", so the RFC editor is probably
not going to remove this section. RFC 3552 (referenced as Secur03 above)
gives further guidance.

I believe that the mechanism proposed/described by the document
certainly has security considerations, and any developers/deployers of
such a protocol should do a thorough analysis as a fundamental element
of the effort. However, since this document is an informational
presentation of a study that was undertaken, it is probably most
appropriate to simply state how security considerations were addressed.

If security was entirely ignored (the network was assumed to be benign,
messages between clients and trackers were sent in the clear with no
authentication), it is probably important to explicitly say so. If
security mechanisms were employed, then I think that a discussion of
what threats were perceived and addressed might be helpful in
interpreting the data.

--Scott
_______________________________________________
secdir mailing list
secdir at mit.edu


https://mailman.mit.edu/mailman/listinfo/secdir