Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[e-mail]]
> Sent: Friday, May 17, 2013 6:28 PM
> To: Reinaldo Penno (repenno)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using
> PCP
> 
> On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) <[e-mail]> wrote:
> 
> >> Title  : Learn NAT64 PREFIX64s using PCP
> >> URL    : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00
> >> Authors: M. Boucadair
> 
> Ok, here is a brief review. Brief in the sense that I didn't re-familiarize
> myself with the related RFCs.
> 
> This is clearly useful.
> 
> I found 3.2, and especially 3.2.2 very sparse, I was looking to learn more
> about how this mechanism is useful in practice here. Some more
> applications/protocols could be listed. However, a lot of information is
> provided in 3.3. Unfortunately, there are two issues with this:
> 
> 1. SIP is a very complex protocol that not everyone may be familiar with
> 
> 2. Unless I misunderstood, a lot of what happens here is pure NAT64, and
> unrelated to the knowledge of the Pref64:
> 
> "the PCP Client issues a PCP MAP request with
>    PORT_RESERVATION_OPTION to reserve a pair of ports preserving parity
>    and contiguity [I-D.boucadair-pcp-rtp-rtcp].  A pair of ports and an
>    external IPv4 address are then returned by the PCP server to the
>    requesting PCP Client."
> 
> It would be more useful to concentrate on the functionality that is only
> possible when the Pref64 is known at this point. For instance, in the case of
> BitTorrent, IPv4 addresses of prospective peers may be learned from a tracker.
> In order for the client to connect to those peers, it needs to synthesize IPv6
> representations for those IPv4 addresses by combining them with the Pref64.
> 
> It would be useful to spell out that the ability to reserve ports and learn
> the external IPv4 address used by the NAT64 (or any NAT) allows for receiving
> incoming sessions. For this, the Pref64 is not needed. The Pref64, on the
> other hand, allows for setting up outgoing connections to systems for which
> only a literal IPv4 address (and not a fully qualified domain name) is known.
> But for this, no other PCP functionality is required. (Although in practice it
> gets more complex when ports are used in both directions simultaneously.)
> 
> The abstract starts with "This document defines a new PCP extension to learn
> the IPv6 prefix(es) used by a PCP-controlled NAT64 device" but the PREFIX64
> option only allows for one Pref64 and the option may only appear once, so the
> (es) part shouldn't be there. (Would the ability to learn multiple Pref64s be
> useful?? I guess load balancing across NAT64s with each a Pref64 of their own
> is possible.)
> 
> In 4.1 a reference to section 7.3 of RFC 6887 would be useful.
> 
> Although I was unhappy with the SIP example earlier, I think it's appropriate
> in section 5 as it shows the full complexity of a real-world system now that
> we've learned all the details of the mechanism. I think the section title
> should have "SIP" in it, though.
> 
> In the security considerations, I would expect a discussion about what happens
> when a malicious third party impersonates a PCP server and provides a fake
> Pref64.

This is not a problem when ICE is used. If during ICE connectivity checks, STUN request is sent to attacker. The attacker cannot send a valid
STUN response because it will not be aware the password using for STUN message integrity. Further RTCWEB (use case mentioned in 3.1) recommends SRTP, so DTLS will also fail. 

Anyway PCP client and server can be mutually authenticated using PCP authentication. This avoids the problem of attacker posing as PCP server.

--Tiru. 

> 
> Iljitsch