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. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
