Subject: Re: [pcp] Fw:I-D Action: New Version Notification for draft-tsou-pcp-natcoord-08.txt

From: Qiong <[email-masked]>
Date: Thu, 1 Nov 2012 20:18:53 +0800

Dear Dan,

Thanks a lot for your review :) Please see inline

On Thu, Nov 1, 2012 at 2:07 AM, Dan Wing <[email-masked]> wrote:

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Qiong
> > Sent: Wednesday, October 31, 2012 12:41 AM
> > To: [email-masked]
> > Subject: [pcp] Fw:I-D Action: New Version Notification for draft-tsou-
> > pcp-natcoord-08.txt
> >
> > Dear all,
> >
> > We have updated the pcp-natcoord draft according to the comments from
> > the wg before. The major changes in this version is as follows:
> >
> > 1) Update the PORT_SET_Nonce field and be consistent with the latest
> > pcp-base draft
> > 2) Encode the port-set in contiguous port mask, and remove the
> > Cryptographically_Random_Port_Range option
> >
> > 3) Add coexistence with MAP.
> > 4) Add security consideration and failover consideration
> >
> >
> > Your further comments are appreciated.
>
> draft-tsou-pcp-natcoord-08 says:
>
>   Using individual MAP requests to reserve all individual ports of a
>   given port set can not achieve this goal because an additional
>   indication is needed to instruct the PCP-controlled device to not
>   enforce a NAT for packets matching these ports.  A candidate solution
>   is to define a new Option to request for this feature be enforced by
>   the PCP-controlled device.
>
> The sentences above are not accurate.  A PCP-controlled device that does
> not NAT will simply return the same IP address and port for
> the externally-mapped IP address, as described in draft-ietf-pcp-base-28:
>
>    Mapping, Port Mapping, Port Forwarding:
>       A NAT mapping creates a relationship between an internal IP
>       address, protocol, and port, and an external IP address, protocol,
>       and port.  More specifically, it creates a translation rule where
>       packets destined to the external IP and port are translated to the
>       internal IP address, protocol, and port, and vice versa.  In the
>       case of a pure firewall, the "Mapping" is the identity function,
>       translating an internal IP address, protocol, and port number to
>       the same external IP address, protocol, and port number.  Firewall
>       filtering, applied in addition to that identity mapping function,
>       is separate from the mapping itself.
>
> [Qiong] Right. Thanks for pointing it out. My understanding is in pcp-base
pure firewall case, it only keeps record on the mapping rule and this
pcp-controlled device can be configured with non-NAT function. Am I right?
This can also be applied to pcp-natcoord where this port-set mapping rule
is recorded with no-NAT functionality.

>
>
> draft-tsou-pcp-natcoord-08 says:
>
>   Another issue, is when no NAT is enforced in the PCP-controlled
>   device but only a Port Range Router (PRR) function, the
>   request has not to indicate the internal ports.
>
> But then how does pcp-natcoord ensure the subscriber's equipment and
> the service provider equipment have the same configuration of
> the subscriber's port number range?  Seems it doesn't ensure the
> configurations are the same; something else does?
>
[Qiong] Sorry I'm not sure if I understand it correctly. The subscriber's
equipment (e.g. CPE) can initiate the pcp-natcoord request from the service
provider equipment (e.g. pcp-controlled device) to get the port range.
Since the subscriber's equipment will have distinct IPv6 address (e.g.
cpe's wan address), the pcp-controlled device can use the v6 address
(internal address) as an index to fetch proper mapping rule, including
internal v6 address, external v4 address and port set. Therefore, the
configuration consistency between the CPE and PCP-controlled devices can be
ensured. Does it address your concern ?

>
>
> The draft needs to consider what happens when the port-sets overlap
> or are supersets of each other.  Especially how the Mapping Nonce
> is handled in that situation.
>
[Qiong] In the draft, we say "However, this port set indicated in the
request of the PCP Client is only a hint; it is up to the PCP Server to
assign a port set". So the PCP server can guarantee that the port-sets will
not overlap with each other, right ?

Besides, since the pcp-controlled device can identify each client with the
internal address(IPv6 address), I think there will be no confusion in PCP
servers to assgin non-overlap port-set to clients.

I will add it explicitly in draft as a requirement to PCP server. Is it ok ?

>
>
> draft-tsou-pcp-natcoord-08 says:
>
>   The Client MUST use a different Mapping Nonce for
>   different MAP_PORT_SET requests.
>
> This is a MUST, which means there must be something that breaks if
> it violates that requirement.  What breaks?
>

[Qiong] This is used when one pcp-natcoord client is allowed to initiate
multiple port-set requests in case it has used out all the ports in one
port-set. As a result, one pcp client may get multiple mapping rules
including the same Internal address, external address and different
port-sets. In this case, one mapping rule should have one corresponding
mapping nonce, and the server should also keep the Nonce value for each
port-set mapping. Otherwise, the pcp server can not get the distinction
between a port-set request retransimission when the request is somehow lost
and a new port-set request to get another port-set mapping, since the
suggested port-set might be zero in both cases and the Internal address,
protocol is the same. So when the client is going to request a new
port-set, a different Mapping Nonce should be used with the previous
port-set request. Does it make sense ? Hope it clarifies -:)

Thanks again for your comments !

Best wishes
Qiong

>
>
> -d
>
>
> > BTW, you can also find the opensource project in sourceforge:
> > http://sourceforge.net/projects/pcpportsetdemo/
> >
> >
> > Thanks a lot!
> >
> > Best wishes
> >
> > --
> > ==============================================
> > Qiong Sun
> > China Telecom Beijing Research Institude
> >
> >
> > Open source code:
> > lightweight 4over6: http://sourceforge.net/projects/laft6/
> > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
> > ===============================================
> >
> >
>
>
>

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Nov 2012 07:49:12 -0700

> From: Qiong [mailto:[email-masked]]
> Sent: Thursday, November 01, 2012 5:19 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] Fw:I-D Action: New Version Notification for draft-
> tsou-pcp-natcoord-08.txt
> 
> Dear Dan,
> 
> [Qiong] Right. Thanks for pointing it out. My understanding is in pcp-
> base pure firewall case, it only keeps record on the mapping rule and
> this pcp-controlled device can be configured with non-NAT function. Am I
> right?
> This can also be applied to pcp-natcoord where this port-set mapping
> rule is recorded with no-NAT functionality.
> 
> 
> 
> 
> [Qiong] Sorry I'm not sure if I understand it correctly. The
> subscriber's equipment (e.g. CPE) can initiate the pcp-natcoord request
> from the service provider equipment (e.g. pcp-controlled device) to get
> the port range.

Ok.  Which UDP port does the CPE send that PCP request, if it does 
not yet already know the port range assigned to the CPE?

> Since the subscriber's equipment will have distinct IPv6
> address (e.g. cpe's wan address), the pcp-controlled device can use the
> v6 address (internal address) as an index to fetch proper mapping rule,
> including internal v6 address, external v4 address and port set.
> Therefore, the configuration consistency between the CPE and PCP-
> controlled devices can be ensured. Does it address your concern ?
> 
> 
> 
> 
> assign a port set". So the PCP server can guarantee that the port-sets
> will not overlap with each other, right ?

Let's say the PCP server assigns ports 100-199.  Then, because of another
request from the CPE, the PCP server assigns ports 200-299.  The draft
needs to explain if that second PCP response will be indicate just ports
200-299, or if it will indicate ports 100-299.  The server could send
either sort of response back, so it should more clearly explain that the
CPE needs to handle either response, or declare the 100-299 response 
as illegal, or something.

> Besides, since the pcp-controlled device can identify each client with
> the internal address(IPv6 address), I think there will be no confusion
> in PCP servers to assgin non-overlap port-set to clients.
> 

-d

> between a port-set request retransimission when the request is somehow
> lost and a new port-set request to get another port-set mapping, since
> the suggested port-set might be zero in both cases and the Internal
> address, protocol is the same. So when the client is going to request a
> new port-set, a different Mapping Nonce should be used with the previous

---

From: Simon Perreault <[email-masked]>
Date: Thu, 01 Nov 2012 17:31:39 +0100

Just replying to this one because the others seem clear to me...

> not yet already know the port range assigned to the CPE?

Uh?

MAP gives one port.
MAP_PORT_SET gives a set of ports.

MAP and MAP_PORT_SET have the same answer to your question.

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: "Dan Wing" <[email-masked]>
Date: Thu, 1 Nov 2012 13:53:15 -0700

> Simon Perreault
> Sent: Thursday, November 01, 2012 9:32 AM
> To: [email-masked]
> > Ok.  Which UDP port does the CPE send that PCP request, if it does not
> > yet already know the port range assigned to the CPE?
> 
> Uh?

Sorry, I meant to ask:

  *from* which UDP port does the CPE send that PCP request.

or can it use any source UDP port for its PCP request, or does it have
to be one of its assigned UDP ports (which aren't yet assigned until
PCP exchange)?

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Thu, 01 Nov 2012 22:04:47 +0100

> to be one of its assigned UDP ports (which aren't yet assigned until

That's what I understood. And the answer is still the same:

Q: From which UDP port does the CPE send a MAP request?
A: From any UDP port on the internal address it already has.

Q: From which UDP port does the CPE send a MAP_PORT_SET request?
A: From any UDP port on the internal address it already has.

There must be something else I'm not getting...

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Nov 2012 15:40:51 -0700

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Thursday, November 01, 2012 2:05 PM
> To: Dan Wing
> Cc: [email-masked]

If it doesn't get (learn) that UDP port via PCP, how does it
learn it?

-d

---

From: Qiong <[email-masked]>
Date: Fri, 2 Nov 2012 08:11:10 +0800

Dear Dan,

The learned port-set is only for restricted NAT on IPv4 packet.
MAP_PORT_SET is sent using native IPv6, and so there is no restriction on
the port-range. As Simon said, it can use any UDP port on the internal
address it already has.

Thanks for your comments :)

Best wishes
Qiong

Open source code:

---

From: Qiong <[email-masked]>
Date: Fri, 2 Nov 2012 08:17:13 +0800

Dear Dan,

For the second comment, please see inline :)

On Thu, Nov 1, 2012 at 10:49 PM, Dan Wing <[email-masked]> wrote:

> [Qiong] Right, we should make it clear. The PCP server should assign
individual port-set for each MAP_PORT_SET request, rather than an
aggregated one. This would simpilfy the implementation both for the pcp
server and pcp client, right?

Thanks for your comments!

Best wishes
Qiong

Open source code:

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Nov 2012 19:06:58 -0700

> Sent: Thursday, November 01, 2012 5:11 PM
> To: Dan Wing
> Cc: Simon Perreault; [email-masked]
> MAP_PORT_SET is sent using native IPv6, and so there is no restriction
> on the port-range.

Oh.

The draft doesn't say the PCP messages are always sent over IPv6.  Or,
I can't find that sentence.

-d

> As Simon said, it can use any UDP port on the
> internal address it already has.
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Nov 2012 19:07:32 -0700

> aggregated one. 

Yes, that would be good to explain in the document.

> This would simpilfy the implementation both for the pcp

Yes, I think so.

-d

> 	> I will add it explicitly in draft as a requirement to PCP server.
> Is it
> 	> ok ?
> 
> 
> 	-d
> 
> 
> 
> 	>
> 	>
> 	>
> 	>
> 	>       > PCP-natcoord:

---

From: Simon Perreault <[email-masked]>
Date: Fri, 02 Nov 2012 07:09:39 +0100

> I can't find that sentence.

It doesn't because it wouldn't be true. MAP_PORT_SET can be sent over 
any address family, just like MAP.

Remember: the only difference is that MAP gets one port, while 
MAP_PORT_SET gets multiple ports.

Simon

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Fri, 2 Nov 2012 08:52:57 +0000

Agree with Simon that the message could be sent over IPv4 as well. 
In this case, the message is sent using WAN side IPv4 address and the WAN side address 
should be planned well in advance. 

Best Regards,
Cathy

> Sent: Friday, November 02, 2012 2:10 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] Fw:I-D Action: New Version Notification for
> draft-tsou-pcp-natcoord-08.txt
>

---

From: Qiong <[email-masked]>
Date: Fri, 2 Nov 2012 23:33:40 +0800

Right, agree with Cathy. MAP_PORT_SET can be sent over IPv4 as well.
Sorry for misleading this discussion ~~

Best wishes
Qiong

Open source code:

---

From: Xiaohong Deng <[email-masked]>
Date: Sun, 4 Nov 2012 17:11:16 +0800

> should be planned well in advance.

Right. Address family doesn't matter, because in either IPv6 or IPv4 case,
PCP is as a means to obtain external IP plus port set information, other
than performing address assignment role.

Cheers,
Xiaohong