Port Control Protocol (PCP)
draft-ietf-pcp-base-29
Yes
(Jari Arkko)
No Objection
(Dan Romascanu)
(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)
Note: This ballot was opened for revision 23 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Ralph Droms Former IESG member
(was No Objection, Discuss)
Yes
Yes
(2012-07-19 for -26)
Unknown
I've cleared. Thanks for addressing my Discuss and Comment points.
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-02-27 for -23)
Unknown
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.
Dan Romascanu Former IESG member
No Objection
No Objection
(for -23)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -23)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2012-11-08)
Unknown
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.
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2012-02-29 for -23)
Unknown
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?
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
(2012-07-06 for -26)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -23)
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2012-02-27 for -25)
Unknown
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.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2012-06-06 for -26)
Unknown
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.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -23)
Unknown
Wesley Eddy Former IESG member
(was Discuss)
No Objection
No Objection
(2012-03-18 for -24)
Unknown
my DISCUSS comments are addressed in the current version; it looks good now