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

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

> -----Original Message-----
> From: Qiong [mailto:[e-mail]]
> Sent: Thursday, November 01, 2012 5:19 AM
> To: Dan Wing
> Cc: [e-mail]
> Subject: Re: [pcp] Fw:I-D Action: New Version Notification for draft-
> tsou-pcp-natcoord-08.txt
> 
> Dear Dan,
> 
> Thanks a lot for your review :) Please see inline
> 
> 
> 
> On Thu, Nov 1, 2012 at 2:07 AM, Dan Wing <[e-mail]> wrote:
> 
> 
> 	> -----Original Message-----
> 	> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of
> 	> Qiong
> 	> Sent: Wednesday, October 31, 2012 12:41 AM
> 	> To: [e-mail]
> 	> 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.

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

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.
> 
> I will add it explicitly in draft as a requirement to PCP server. Is it
> ok ?

-d


> 
> 
> 
> 
> 	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/
> ===============================================
> 
>