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

[Qiong <[e-mail]>]

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