Re: [pcp] GET and GETNEXT OpCodes

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

> -----Original Message-----
> From: [e-mail] [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Friday, March 11, 2011 2:16 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE:[pcp] GET and GETNEXT OpCodes
> 
> 
> |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,
> 
> xiaohong: that could help, but how long would be the perfect lifetime
> that niether too long
> for healing nor too short to limit the amount of PCP chatter?

There isn't any ideal value.

The exact same problem occurs with DHCP, today -- the DHCP server
can crash and lose state (forgetting which clients had leased
which addresses), and a different host can acquire that address.

Even if there was a way to inform a host, immediately, that the
PCP server lost state (e.g., using a multicast message, as done
by NAT-PMP), one host could beat another host.  The window of
opportunity would be shorter, but something as simple as being
connected to wired Ethernet (rather than wireless) or a faster
Ethernet driver or faster CPU would allow someone to win.

I don't see a solution.


As my proposed text suggests, if this is a concern, use TLS
on the connection itself.

-d



> |   increases the amount of PCP chatter.  Connection authentication
> |
> BR,
> Xiaohong
> opensource A+P: http://opensourceaplusp.weebly.com/