Port Control Protocol (PCP)
draft-ietf-pcp-base-29

Note to responsible AD. This document requests the creation of
regsistries that use the "specification required" allocation policy.
That means you will need designated experts.

---

Please consider addressing the minor points and questions raised by
Loa Anderson in his Routing Directorate review especially the question
about Section 15.

Additionally, I have some comments as follows. There are quite a few
and some of them are relatively significant. None of them merits a 
Discuss, but I do hope you will take them seriously.            

---

Section 6.3

   It is the
   responsibility of the PCP client to ensure the server has sufficient
   room to reply without exceeding the 1024-byte size limit.

This is the first mention of the "1024-byte size limit" (I think you 
mean the 1024=byte message size limit") and it would be helpful to 
explain why that limit applies.

---

Section 7

   Every PCP request    
   generates at least one response, so PCP does not need to run over a
   reliable transport protocol.

Now, I can see how this would be made to work by a protocol spec that
implements a timer waiting for a response and a retransmission (as 
described in Section 7.1), and a "more responses to follow mechanism"
(as possibly hinted at in Section 7.3), but your statement is too bold
as it stands. Perhaps you could rewrite as:

   Every PCP request generates at least one response, amd PCP is 
   responsible for retrying requests and correlating responses, so PCP
   does not need to run over a reliable transport protocol.

It would also be good (maybe in 7.3) to clarify the processing when 
there are multiple responses to a request. How does the client actually
know that it has received all of the responses?

---
   
Section 7.1

   Prior to sending its first PCP message, the PCP client determines
   which server to use.  The PCP client performs the following steps to
   determine its PCP server:

   1.  if a PCP server is configured (e.g., in a configuration file or
       via DHCP), that single configuration source is used as the list
       of PCP Server(s), else;

   2.  the default router list (for IPv4 and IPv6) is used as the list
       of PCP Server(s).

   For the purposes of this document, only a single PCP server address
   is supported.  Should future specifications define configuration
   methods that provide a list of PCP server addresses, those             
   specifications will define how clients select one or more addresses          
   from that list.

It seems to me that the second option listed here is exactly a case of
a configuration method where there is a list of PCP server addresses.
So don't you need to define the method of selection (probably, first in
the list is selected)?

Furthermore, a couple of paragraphs later you have:

   When attempting to contact a PCP server, the PCP client sends a PCP
   message to the first server in its list of PCP servers, 

which seems to be exactly the specification of how to select a server
from a list.

---

Section 7.1

   As with all UDP or TCP client
   software on any operating system, when several independent PCP
   clients exist on the same host, each uses a distinct source port
   number to disambiguate their requests and replies.  The PCP client's
   source port SHOULD be randomly generated [RFC6056].

I suggest you don't need/want to mention TCP here. While what you say is
true, it is not relevant to this spec.
                                                               
---

Unless I missed it, you have not described the fact that a client can
receive an apparently unsolicited response from a server. This could
happen after client restart.

---

Section 10.1

There is some fluff in the terminology where (e.g.) the figure is
described as showing the packet format where it actually shows the
opcode-specific data.

Same issue in Section 11.1 and Sections 12.1, 12.2 etc.

---

Sections 17.2, 17.3, and 17.4

It seems entirely perverse to me to have just one code point available
in each registry (and three in one of the registries) for future 
Standards Action, but many for specification required and private use.

I am still convinced that the notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol.

I am still convinced that sections 11-13 should move earlier in the document so that you can get the definitions of the opcodes done early and then you can refer to them. I understand that you want to use MAP and PEER throughout the earlier sections because people couldn't track the difference between static and dynamic, but if you're going to do that, you should move the sections up.

That said, I don't think you have to use the opcodes earlier in the document, especially in the definitions. For instance:

Section 3:

Please define "Peering" in this section.

In the bit on "Third Party", don't mention "THIRD_PARTY Option" or "MAP request" here; they are undefined, and they're not needed. Instead, change to:

      In the case where one device is managing Mappings on behalf of
      some other device that does not implement PCP, this protocol
      supports the ability of a Third Party to supply a specific
      address as the Internet Address for a Mapping, rather than the
      PCP server inferring the Internal Address from the source IP
      address of the PCP request.

Where you say:

      *  Explicit dynamic mappings are created as a result of explicit
         PCP MAP and PEER requests.

You could instead say:

      *  Explicit dynamic mappings are created as a result of explicit
         PCP protocol Mapping or Peering requests.  Like a DHCP address
         lease, explicit...

Section 7.3

   PCP clients are free to ignore any or all Options included in
   responses, although naturally if a client explicitly requests an
   Option where correct execution of that Option requires processing the
   Option data in the response, that client is expected to implement
   code to do that.

Clients aren't just *free* to ignore Options they don't understand in responses; they ought to (MUST?) ignore such things. The above paragraph doesn't say that.

Section 14:

   There are two mechanisms to perform rapid recovery, described below.
   A PCP server that can lose state (e.g., due to reboot) or might have
   a mapping change (e.g., due to IP renumbering) MUST implement either
   the Announce Opcode or the Mapping Update mechanism and SHOULD
   implement both mechanisms.  Failing to implement and deploy a rapid
   recovery mechanism will encourage application developers to feel the
   need to refresh their PCP state more frequently than necessary,
   causing more network traffic.

Please just swap the last two sentences. I think it makes it clearer.

Other reviewers have provided significant input. I have a few additional comments.

In Section 7.5, is the recommendation about 6.25% clock skew based on empirical evidence?

In Section 8 (bullet 6), why would the client expect that the server might support its old version after 30 minutes?

The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few
  concerns.  Please consider these points:
  
  (a) The document says that v4-mapped addresses are not used as source
  or destination addresses for real IPv6 packets.  Richard is aware of
  some work on IPv6 traceroute scanning where numerous routers will
  respond from v4-mapped addresses.  It probably would be accurate to
  say that these addresses would never appear in a mapping.

  (b) In Section 6.4, the first paragraph says that each error is "long"
  or "short", but they're not all marked.  Is there a default?  It also
  seems like some of these errors are effectively permanent, such as
  UNSUPP_VERSION; the PCP NAT isn't going to support a new version of
  the protocol half an hour from now.

  (c) In Section 7.1, you first say that "only a single PCP server
  address is supported", but then in a couple of other places mention
  a "list of PCP servers".  Which is it?

  (d) In Section 7.1, it seems like it would be pretty unusual for the
  PCP server to be the first-hop router, at least outside of the CPE
  case.  Would it be better to use an anycast address to find the server?

  (e) I did not find that the code samples in Section 9 added any
  information.  The one case where one would have been helpful (9.4),
  there was none.

I've cleared my discuss since the THIRD_PARTY feature is now
constrained as discussed. However, I still feel that section 17 could
do with some substantive editorial work. But since that's editorial
work, I've made this a comment. I hope that the authors will
try to take this into account. The suggested edits below are based
on version-25 but I think still apply for -26.

I think that sections 17.1 and 17.2 are still all wrapped around one
another and more work is needed.

I *think* that's editorial work mainly, but I just can't tell from
reading it for sure. I'd start by moving any "meta" text such as chunk
"A" below into a bit of introductory text, and by breaking complex
conditions such as chunk "B" below into bullet lists so that e.g. its
clear what's a conjunction and what's a disjunction.

17.1.2 is now wrong since it has only 1 example and the sub-structure
doesn't seem worth it.

There is still a mention of, but no reference to, "a PCP security
mechanism" that "would need to be specified" - I'd say what's needed
there is an informative ref to the I-D for the security mechanism and
to say that if the advanced threat model applies then you need to
implement that spec or an equivalent or else you're not safe.

There's also "meta" text in 17.2 that probably ought be moved - that's
chunk "C" below.

And I've made a suggestion for a way this might all be restructured
which is just after chunks A-C.

Chunk A:
   PCP Servers that comply with the Simple Threat Model and do not
   implement a PCP security mechanism described in Section 17.2 MUST
   enforce the constraints described in the paragraph above.

That chunk is at the end of 17.1 before 17.1.1 so its not clear if
"Simple Threat Model" means only 17.1 text before this or all of 17.1
or not.

Chunk B:
   A PCP Server is secure under this threat model if the PCP Server is
   constrained so that it does not configure any explicit mapping that
   it would not configure implicitly.  In most cases, this means that
   PCP Servers running on NAT boxes or stateful firewalls that support
   the PEER Opcode can be secure under this threat model if all of
their
   hosts are within a single administrative domain (or if the internal
   hosts can be securely partitioned into separate administrative
   domains, as in the DS-Lite B4 case), explicit mappings are created
   with the same lifetime as implicit mappings, the PCP server does not
   support deleting or reducing the lifetime of existing mappings, and
   the PCP server does not support the third party option.  PCP Servers
   can also securely support the MAP Opcode under this threat model if
   the security policy on the device running the PCP Server would
permit
   endpoint independent filtering of implicit mappings.

Parsing chunk B is too hard IMO if you're trying to figure out what to
implement, or trying to compare it the simple and advanced threat
models to try figure what's safe and what's not.

Chunk C:
   PCP Servers implementing the PCP security
   mechanism MUST enforce the constraints described in Section 17.1
   above, in their default configuration, when processing
   unauthenticated requests.

That seems generic. I don't get why it only applies in the "advanced"
threat model.

Here's my suggestion for a new way to lay all that out:

17 - intro text
17.1 - attacks considered (current 17.1.1)
17.2 - threat models - text chunks A & C here
17.2.1 - simple threat model - chunk B here as bullets
17.2.2 - advanced threat model
17.3 - residual threats (17.3)

Finally, a new comment (not discuss point) I'd make:

17.1 has added the claim that: "PCP is secure against off-path
attackers who can spoof the PCP server's IP address." That's a bit too
terse, can you explain what's meant by "secure against"
there? I suspect the claim would be ok if it were a bit more precise.

my DISCUSS comments are addressed in the current version; it looks good now