Subject: [pcp] Ask for your comments on PCP port-set extension

From: Qiong <[email-masked]>
Date: Fri, 30 Mar 2012 15:58:50 +0800

Dear all,

Thanks for your attention on PCP meeting for
http://www.ietf.org/id/draft-tsou-pcp-natcoord-05.txt

As Chairman encourages us to launch this thread due to limited times on the
meeting.
As discussed in the meeting, the general application secnario for this
requirement is described in
http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt, in
which NAT is offloaded into distributed CPEs. In this way, CGN does not
need to maintain per-session binding table, but rather per-subscriber
binding table (including IPv6 address, IPv4 address and port-set). And the
CPE will need to acquire an public external address plus port set.

The requirement to extend PCP is specifically useful in case an operator is
not willing to use DHCPv4 server (or do not have an existing DHCPv4 server)
in the IPv6 transition world. Since PCP protocol is quite flexible for port
management and can be located in AFTR naturelly, we choose to extend PCP
protocol and define a new OpCode for port-set management. The rationale
behind this choice is to avoid overloading MAP and to ease separating the
port-range function from the handling of individual mappings. And we also
define two port-set options to convey contiguous and non-contiguous
port-set.

So we would like very much to have your comments on this port-set extension
proposal. Thanks in advance!

Best wishes
Qiong

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 30 Mar 2012 10:30:27 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Qiong
> Sent: Friday, March 30, 2012 9:59 AM
> To: [email-masked]
> Subject: [pcp] Ask for your comments on PCP port-set extension
> 
> Dear all,
> 
> As Chairman encourages us to launch this thread due to limited times on
> the meeting.
> http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt,
> in which NAT is offloaded into distributed CPEs. In this way, CGN does
> not need to maintain per-session binding table, but rather per-
> subscriber binding table (including IPv6 address, IPv4 address and
> port-set). And the CPE will need to acquire an public external address
> plus port set.
> 
> The requirement to extend PCP is specifically useful in case an
> operator is not willing to use DHCPv4 server (or do not have an
> existing DHCPv4 server) in the IPv6 transition world. Since PCP
> protocol is quite flexible for port management and can be located in
> AFTR naturelly, we choose to extend PCP protocol and define a new
> OpCode for port-set management. The rationale behind this choice is to
> avoid overloading MAP and to ease separating the port-range function
> from the handling of individual mappings. And we also define two port-
> set options to convey contiguous and non-contiguous port-set.
> 
> So we would like very much to have your comments on this port-set
> extension proposal. Thanks in advance!

The Cryptographically Random Port Range Option will lead to 
interoperability problems, and is not worth pursuing.  There is only 
a slight gain to such pseudo-random port assignment (reference RFC6056), 
because an attacker can cause the victim to open 100's of ports to
a server owned by the attacker, thus the attacker learns allocated
port numbers and the port assignment algorithm (which could be 
leveraged against other subscribers using that same algorithm at
the same ISP).  Thus, the pseudo-random assignment of port numbers 
does not achieve the goals outlined in RFC6056.

The document needs to describe what happens in corner cases.  FOR
EXAMPLE, if a PCP sends a mapping request for a subset or superset 
of their allowed mappings.  For example, let's say a customer gets 
ports 500-600 (100 ports).  The PCP client  might issue a normal 
draft-ietf-pcp-base MAP request -- is that supposed to be handled 
normally?  Afterwards, the PCP client might request 300 ports, 
which I suppose results in an error (?) or an assignment of 100 
ports, or an assignment of 99 ports??  Then, what happens if the 
PCP client tries to renew that first port is requested?  I am not
interested in the answer to that specific example -- rather, I am
interested in new text in the document that describes what is 
supposed to occur when the PCP client asks for too many ports 
using MAP_PORT_SET, asks for fewer ports than permitted by the
CGN, and what happens if the PCP client sends a MAP request or
sends a combination of MAP_PORT_SET and MAP.

With that additional information, I can evaluate the proposal
better.  Right now, I don't know how well it will work when
a non-MAP_PORT_SET-capable PCP endpoint or NAT is introduced to
a user's home.

-d

---

From: Qiong <[email-masked]>
Date: Sat, 31 Mar 2012 06:55:05 +0800

Hi Dan,

Thanks a lot for your detailed comments on it. Please see inline.

> does not achieve the goals outlined in RFC6056.

[Qiong] We use the pseudo-random algorithm because it has been defined in
RFC6431.
The cryptographic mechanism ensures that the entire 64k port range can be
efficiently distributed to multiple nodes such that when nodes calculate
the ports, the results will never overlap with ports that other nodes have
calculated (property of permutation), and ports in the reserved range
(smaller than 1024) are not used.  As the randomization is done
cryptographically, an attacker seeing a node using some port X cannot
determine which other ports the node may be using (as the attacker does not
know the key). How do you think of it?
BTW, I'm not sure of what you have mentioned on interoperability problems
here. Would you please elabroate a little more ? Thanks a lot!

> sends a combination of MAP_PORT_SET and MAP.

[Qiong] Thanks a lot! This is very helpful. We will add new text for this
in the next version.
In general procedure, I think the PCP server should be configured with port
quota for PCP client, which is the maximum number of ports a PCP client
will get in total. And the PCP server will also be configured with the size
of port set to allocate each time. Then for the corner case, how about we
solve this problem in the following way:
1) If the PCP client asks for too many ports using MAP_PORT_SET, USER_EX_QUOTA
error code can be returned to the PCP client.
2) If the PCP client asks for fewer ports than permitted by the CGN, it is
still up to the CGN to determine the size of port-set allocated to the PCP
client, unless PREFERE_FAILURE option is used in PCP client.
3) For the combination of MAP_PORT_SET and MAP, since MAP_PORT_SET is
designed for PCP client to get the overall valid port set, while MAP is
designed to get the specific port for an application, I think there is no
confliction between them. The server should guarantee that the specific
port allocated via MAP should be within the valid port-set allocated to PCP
client via MAP_PORT_SET.  For example, the port-set returned by
MAP_PORT_STE is [1024, 2047], and the port returned by MAP is 2004. So if
the client renew MAP_PORT_SET several times, we only need to guarantee the
port returned by MAP is within the current valid port-set for the PCP
client.

Do you think it is fine to solve these corner cases ? Thanks a lot to point
out these problems.

Best wishes
Qiong