[apps-discuss] APPSDIR rdraft-ietf-pcp-base-22

["Vijay K. Gurbani" <vkg at bell-labs.com>]

Document: draft-ietf-pcp-base-22
Title: Port Control Protocol (PCP)
Reviewer: Vijay K. Gurbani
Review Date: Feb-10-2012
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is almost ready for publication as a Proposed
Standard but has a few issues that should be fixed before publication.

Major issues: 0
Minor issues: 11
Major issues: 0

Issues listed below are in document order.

- S5, the all zeroes IPv4 address as defined by the draft is a
 contribution of the draft itself, right?  That is, at least I am not
 aware whether ::ffff:0:0 is generally used as the all-zero IPv4-mapped
 IPv6 address.  It may well be, in which case this comment can be
 ignored.  But if it is not a general use address and is intended to be
 defined by this draft, I wonder if rfc2119 MUST is appropriate here (as
 in "The all-zeroes IPv4 address MUST be expressed as: 80 bits of
 zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0).").

- S6.1, the "Opcode-specific information" block of Figure 2 is not
 discussed at all in the text following Figure 2.

- S6.1, the "PCP Options" block of Figure 2 is not discussed at all in
 the text following Figure 2.  You do provide a Section 6.3 that
 discusses options; perhaps it is sufficient to say the following at
 the end of the text following Figure 2: "PCP Options: Please see
 Section 6.3".

- Ditto for S6.2 and Figure 3's use of "Opcode-specific response data"
 and "Options" block.

- S7.1, second-to-last paragraph: I suspect that if more than one server
 was specified in the server list, the client will cycle through and
 try the next server.  I also note that this document only considers
 one server, so exact guidance is not provided on what to do when a PCP
 client has more than one server.

 But I think it possible that the default router list (mentioned earlier
 in the section) creates a list of two servers: an IPv4- and
 IPv6-server.   Would it be prudent to try the IPv6 server if the IPv4
 server --- and vice-versa --- did not result in any response within
 the maximum retransmission interval of 15m?

- S7.3, the third paragraph from the end of the section ("For both ...
 is RECOMMENDED."): Here you say that "A limit of 24 hours for success
 responses and 30 minutes for error responses is RECOMMENDED."

 However, in S6.4 you said that, "It is RECOMMENDED that short
 lifetime errors use a 30 second lifetime and long lifetime errors
 use a 30 minute lifetime." So --- is S7.3 treating *all* error
 responses as long lifetime errors?

- S9.1: The algorithm provided is excellent, but can only be used
 when writing new servers (since it requires sending and receiving
 PCP messages).  This should be made clear before the algorithm.  (I
 believe that this stands to reason, but being explicit does not
 hurt.) Existing servers that need to be reachable from the outside, but
 ones whose source code cannot be modified, will need to arrange for
 an explicit static mapping to happen before they are started.

- I believe that the above issue is true for S9.{2,3} as well.

- S16.1.1: I am not sure how to interpret the listed attacks
 in this section.  Is it the case that these attacks can happen
 even if PCP servers comply with the Simple Threat Model?  Or is
 it the case that the Simple Threat Model mitigates these attacks?

- S16.2: To protect against Advanced Threat Model attacks, the
 draft assumes a PCP security mechanism that provides channel
 authentication and encryption.  However, no further information
 is provided for such a mechanism.  Will it help to provide
 any candidates for such a mechanism (TLS?  S/MIME?) or is there
 something entirely different in mind?

- S16.3.1: As far as I can see, there is no mitigation for Denial
 of Service attack mounted by an attacker on the path between the
 PCP client and PCP server, yes?  If so, it will be nice to
 explicitly state this.

Nit:

- S3, while discussing Internal Host: The term "PCP MAP" request is used
 here without further context, like a short definition.  Clearly, the
 PCP MAP request arranges for a mapping to occur in the NAT ... the
 reader can tell that much.  But all the same, for the sake of
 completeness, it will be good to provide a quick definition when the
 term is first used.

- S3, while discussing Explicit static mappings: any reason why a GUI
 (distinct from a web-based UI) is omitted?  I suspect the answer is
 just plain oversight, but just the same, I think it will not hurt to
 include it in, or simply take out the text in the brackets.

- S16.2: s/mechanism which provides/mechanism that provides

That's it.  Thanks!

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg at {bell-labs.com,acm.org} / vijay.gurbani at alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/