Skip to main content

Telechat Review of draft-ietf-p2psip-drr-11
review-ietf-p2psip-drr-11-secdir-telechat-weis-2014-02-06-00

Request Review of draft-ietf-p2psip-drr
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2014-02-04
Requested 2014-01-23
Authors Ning Zong , XingFeng Jiang , Roni Even , Yunfei Zhang
I-D last updated 2014-02-06
Completed reviews Genart Last Call review of -10 by Francis Dupont (diff)
Genart Telechat review of -11 by Francis Dupont
Secdir Last Call review of -10 by Brian Weis (diff)
Secdir Telechat review of -11 by Brian Weis
Assignment Reviewer Brian Weis
State Completed
Request Telechat review on draft-ietf-p2psip-drr by Security Area Directorate Assigned
Reviewed revision 11
Result Ready
Completed 2014-02-06
review-ietf-p2psip-drr-11-secdir-telechat-weis-2014-02-06-00
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 document describes a routing mechanism for Peer-to-Peer Session Initiation
Protocol (P2PSIP). The routing mechanism in the base P2PSIP protocol specifies
an initiator sending a request message hop by hop through a DHT to a responder,
with the responder returning a reply using the reverse path. The alternative
routing method defined in this I-D describes a shortcut for the response
message. The response is returned directly to the initiator using an IP address
provided by the initiator. This shortcut method is described as an optimization
that is useful in private networks where a self-reported IP address is likely
to be reliable (i.e., no NAT).

I previously reviewed draft-ietf-p2psip-drr-10 and had some clarification
questions and minor comments. This version adequately addressed those comments,
and I have no additional concerns.

The only thing that I wish could be clarified in the draft is that the
"DRR(DTLS)" values for "No. of Msgs" values in Table 1 and Table 2 assume that
the DTLS session had been setup previously, so the cost of those messages is
thus not included in this table. That's fine, but the cost of setting up that
session might not be obvious to someone looking at the tables and it would be
worth pointing it out explicitly in the text. But this is not a security
consideration concern, only a suggestion to make the draft easier to understand.

Brian