Re: [pcp] GET and GETNEXT OpCodes

> -----Original Message-----
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> Francis Dupont
> Sent: Thursday, March 10, 2011 6:38 AM
> To: xiaohong.deng@orange-ftgroup.com
> Cc: pcp@ietf.org
> Subject: Re: [pcp] GET and GETNEXT OpCodes
> 
> 
>  In your previous mail you wrote:
> 
>    I want to make a comment :
>    usually UPnP IGD Control Point issues "AddPortMapping" after
> rebooting.
> 
> => yes, the failure model (which is IMHO *not* adapted to ISP CGNs)
> of UPnP IGD was explicited in the version 2 and is to reinstall
> mappings as the server (IWF in our case) is not required to use
> stable storage.
> 
>    I suppose PCP Client will do similarly, which means PCP client would
>    also make mapping requests on reboot, which look like renewals to
> the
>    server like Stuart stated.
> 
> => you assume implicitely two important things:
>  - a failure model where it is enough for the client to reinstall
>   its explicit dynamic mappings. This has two problems: it can take
>   time to detect a failure on the PCP server side (NAT-PMP uses
> multicast
>   to solve this point) and this opens the door of explicit dynamic
>   mapping thefts when the PCP server controls an ISP CGN (something
>   which is out of scope for UPnP IGD and NAT-PMP)

Oh!  That must be the security problem you refer us back to, but have not
re-explained to us.

So, the scenario is:

  1. PCP client does a MAP
  2. PCP server (or the CGN) crashes and loses state
  3. PCP client is, of course, unaware of that state loss until
     much later (whatever its refresh interval is)
  4. In that interval, another PCP client (or implicit dynamic
     mapping) could grab that port.

The same problem exists without PCP, of course, with an
implicit mapping (e.g., created with a TCP SYN).  And the
resolution is described in Section 6, "Cold Standby Mode" 
of draft-xu-behave-stateful-nat-standby-06:  that the 
CGN needs to use a different public IPv4 address pool 
when it crashes and loses state.   IMO, that advice 
belongs in BEHAVE's CGN Requirements document, as it 
does not solely affect PCP.  Simon Perreault, CC'd, 
is the editor of the CGN Requirements document.

In the PCP document, adding something along the lines of seems a reasonable
addition for the Epoch section:

   In the time between a PCP server loses state and the PCP client
   notices the lower-than-expected Epoch value, it is possible that the
   PCP client's mapping will be acquired by another host (via an
   explicit dynamic mapping or implicit dynamic mapping).  This means
   incoming traffic will be sent to a different host.  A mechanism to
   immediately inform the PCP client of state loss would reduce this
   interval, but would not eliminate this threat.  The PCP client can
   reduce this interval by using a relatively short lifetime; however,
   increases the amount of PCP chatter.  Connection authentication 
   (e.g., TLS) does eliminate this threat.

-d

>  - this doesn't solve the problem of 'stale' explicit dynamic
>   mappings, i.e., mappings which are installed on the PCP server but
>   the PCP client for any reason didn't delete.
> 
> 
>   That's why I don't see a use case of GET/GETNEXT for 'pure' PCP
> Clients.
> 
> => GETNEXT is the not-disruptive way to synchronize a PCP client and
> server pair (the disruptive way is to send first a 'delete all' so
> the PCP server 'starts' in a 'virgin' state).
> 
>    In case of a PCP Client, when does it want to know if the explicit
>    dynamic mapping was really installed by the server? In case of a
>    PCP proxy, it maintains a mapping table.
> 
> => as a co-author of the PCP Proxy I-D I can say it doesn't maintain
> a mapping table. It is *not* an option for a simple PCP Proxy
> and it is a by default NOT RECOMMENDED option for a smart PCP Proxy
> (of course to discuss further you need the whole text of the I-D,
> I expect it will be posted for the dead line, next Monday).
> 
> Thanks
> 
> Francis.Dupont@fdupont.fr
> 
> PS: BTW UPnP IGD has equivalents of GET/GETNEXT so the 'stale' mapping
> issue comes from a partial application of the UPnP IGD model to PCP,
> i.e., the first part of your argument is not sound.
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp