[Gen-art] Gen-ART review of draft-ietf-pcp-base-23

[Richard Barnes <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pcp-base-23.txt
Reviewer:  Richard Barnes 
Review Date:  27 Feb 2012
IETF LC End Date: 27 Feb 2012
IESG Telechat Date: 01 March 2012

Summary: Almost ready

Major issues:

-- As I think others have noted during LC, it seems like it would simplify several aspects of the protocol if requests and responses could be correlated by means of a transaction identifier, instead of just by matching fields.  In addition to simplifying response processing and clarifying the meaning of lifetime parameters, this would also provide a measure of protection against address spoofing.

-- It would be helpful for the document to say a little more about risks posed from spoofed packets.  It seems like there are some cases where an off-path attacker could break synchronization in state between clients and servers, e.g., by sending gratuitous responses.  This is a rather serious attack, as it could be used by an off-path attacker to steal traffic:
1. Attacker obtains mapping from address:port=A:P on PCP controlled device to one of its ports B:Q
2. Attacker convinces client that it has a mapping from A:P to its port C:R
3. Attacker acts as a man in the middle: remote -> A:P -> B:Q -> C:R
Also, it seems the ANNOUNCE method provides an opportunity for an attacker capable of spoofing to cause an arbitrary number clients to flood the server with requests.


Minor issues:

-- The document says that v4-mapped addresses are not used as source or destination addresses for real IPv6 packets.  This is empirically not the case; in some work we have done on IPv6 traceroute scanning, we have encountered numerous routers that will respond from v4-mapped addresses.  It probably would be accurate to say that these addresses would never appear in a mapping.

-- 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, e.g., UNSUPP_VERSION; the PCP NAT isn't going to support a new version of the protocol half an hour from now.

-- 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?

-- 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?

-- 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.