Re: [pcp] GET and GETNEXT OpCodes

[<[e-mail]>]

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

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