Skip to main content

Telechat Review of draft-ietf-pcp-server-selection-07
review-ietf-pcp-server-selection-07-secdir-telechat-inacio-2015-01-08-00

Request Review of draft-ietf-pcp-server-selection
Requested revision No specific revision (document currently at 10)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2015-01-07
Requested 2014-12-18
Authors Mohamed Boucadair , Reinaldo Penno , Dan Wing , Prashanth Patil , Tirumaleswar Reddy.K
I-D last updated 2015-01-08
Completed reviews Genart Last Call review of -07 by Alexey Melnikov (diff)
Genart Telechat review of -08 by Alexey Melnikov (diff)
Secdir Telechat review of -07 by Christopher Inacio (diff)
Assignment Reviewer Christopher Inacio
State Completed
Request Telechat review on draft-ietf-pcp-server-selection by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has issues
Completed 2015-01-08
review-ietf-pcp-server-selection-07-secdir-telechat-inacio-2015-01-08-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 with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

Generally the document is in good shape, and I would like to see one minor
issue at least commented upon.

I have a single security related comment on this draft; the last sentence of
section 3:

> For efficiency, the PCP client SHOULD use the same Mapping Nonce for
>   requests sent to all IP addresses belonging to the same PCP server.

Normally, I would simply say this is a crazy recommendation.  But after looking
a little into what the Nonce is used for in the PCP protocol, I am slightly
less distraught.  This Nonce does not appear to necessarily provide any huge
amount of security except allowing the client to generate a unique token per
PCP server.  Presumably there is a general MITM attack on the PCP protocol
related to the Nonce as a transaction ID which is prevented by using other
security protocols, TLS, etc.  (And another well known attack with the
THIRD_PARTY option and lack of authentication…) Therefore, this Nonce is
critical as a synchronization point between the client and the potential PCP
server.  It would be nice (assuming all that is correct) to make that clear in
the document, especially with a recommendation to reuse the Nonce.

Nits:

In Figure 1, the lines are not aligned to the “+” on the diagrams.

In Figure 3, “rtr1” is missing a “+” on the right side connection from the top.

--
Chris Inacio
inacio at cert.org