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

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 May 2013 14:57:56 +0200

On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) <[email-masked]> 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.

Iljitsch

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 17 May 2013 19:24:25 +0000

Thanks for the review Iljitsch.

I think you have a good point on the separation of what can be done with
the discovery of Pref64 alone versus coupled with other mechanisms. The
bitorrent use-case is certainly a good representation of that.

Load-blancing is also something was discussed but never got into the
draft. There were other initiatives around that, specially in BEHAVE WG
and med was involved in that. This might be something that could be
incorporated into the draft.

Regards,

Reinaldo

On 5/17/13 9:57 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:

>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:
>
>2. Unless I misunderstood, a lot of what happens here is pure NAT64, and
>unrelated to the knowledge of the Pref64:
>
>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.)
>
>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.
>
>Iljitsch

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 18 May 2013 06:40:12 +0000

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Friday, May 17, 2013 6:28 PM
> To: Reinaldo Penno (repenno)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using
> PCP
> 
> 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
> 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.)
> 
> 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.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 May 2013 16:52:39 +0200

>> URL    : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00

And here's my review...

The draft is almost ready. One remaining issue that should be easy to 
fix: the reference to draft-boucadair-pcp-rtp-rtcp should be replaced by 
one to draft-ietf-pcp-port-set, and the example in section 3.3 adjusted.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 21 May 2013 05:45:55 +0000

> From: Reinaldo Penno (repenno)
> Sent: Saturday, May 18, 2013 12:54 AM
> To: Iljitsch van Beijnum

Load balancing can be solved using PCP authentication, each user-group could be assigned a different Pref64.

--Tiru.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 21 May 2013 05:55:43 +0000

I believe the idea is to do it dynamically since depends on load, it can
not be pre-configured.

There was a lot of good discussion on this topic a while back on BEHAVE.
This draft captured some of that:

http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-03

This presentation is very interesting

http://www.ietf.org/proceedings/79/slides/behave-1.pdf

---

From: <[email-masked]>
Date: Tue, 21 May 2013 08:08:10 +0200

Hi Simon,

Agree. Fixed in my local copy.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de Simon
>Perreault
>Envoyé : lundi 20 mai 2013 16:53
>À : [email-masked]
>Objet : Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s
>using PCP
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp