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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]]
> Sent: Monday, February 27, 2012 5:11 AM
> To: [e-mail]; [e-mail]
> Subject: Gen-ART review of draft-ietf-pcp-base-23
> 
> 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

Thanks for your review.  Comments below.

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

We added a section that explains this design decision, which
is at http://tools.ietf.org/html/draft-ietf-pcp-base-24#section-6

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

To accomplish that attack the off-path attacker would need to spoof the 
PCP server's IP address, which means spoofing the default router's IP 
address and causing that packet to be routed to the victim.  For IPv6,
Simple CPE Security [RFC6092] says filtering has to be employed (which 
prevents this attack).  For IPv4, existing practice of NAT devices and 
ISP filtering prevents attackers from using source address of internal 
nodes.

Are you looking for guidance that PCP deployments follow Simple CPE
Security, and that we write similar guidance for IPv4 -- or perhaps
there something to cite for IPv4 that says filters should drop packets
from the Internet that spoof infrastructure IP addresses.

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

Yes, such an attacker would need to be able to spoof the PCP server's
IP address, as above.


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

Adjusted in -24, thanks.

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

Adjusted in -24, thanks.

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

During IESG review, there were two Comments of a similar nature.  It seemed
the "list" is what triggered the confusion, so I added the sentence starting
with "Thus," which tries to explain what we meant by the "default router 
list".  -24 now reads:

  2. the default router list (for IPv4 and IPv6) is used as the list	
  of PCP Server(s). Thus, if a PCP client has both an IPv4 and	
  IPv6 address, it will have an IPv4 PCP server (its IPv4 default	
  router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6	
  default router) for its IPv6 mappings.

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

We seriously considered using an IANA-assigned address to go 'up'
towards the Internet.  It has some useful advantages.  However,
a disadvantage is we could not identify non-PCP-speaking firewalls
on the path, so it would be difficult to establish state in those
firewalls without knowing they are on path.  As PCP is intended
to work with IPv6 firewalls as well as NAT64 (and a NAT64 might 
have embedded IPv4 firewall or NAPT44-like function), we needed
a mechanism that touched all the stateful packet filtering devices
on the path towards the Internet.

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

-d