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

["Vijay K. Gurbani" <[e-mail]>]

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@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/