Re: [pcp] GET and GETNEXT OpCodes

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   Oh!  That must be the security problem you refer us back to, but
   have not re-explained to us.
   
=> yes, I am tired to explain it again and again.

   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).

=> yes, it exists for implicit dynamic mappings, explicit
dynamic mappings and static mappings, and its severity increases
for each kind of mappings.
IMHO it is unbearable for static mappings (i.e., if one of my ISPs
fails to protect a static mapping of mine I'll sue it),
critical for explicit dynamic mappings and perhaps to expensive
to solve for implicit dynamic mappings (i.e., if one of my ISPs
fails to protect an implicit dynamic mapping I'll just say it
is the way of life, @#$* NATs!). Of course this is based on
relative lifetimes and what is expected from each kind.

   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.

=> yes, it is a way a solve the problem but it is in fact
the sacrifice of the operation in order to save the security,
i.e., IMHO not the best solution. BTW its scalability is
questionable too. I put a (*) to this solution as I'll refer
to it below.

   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.
   
=> I'd *really* like to get something in the security
considerations.
   
   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.
   
=> two remarks: what subscribers want is to eliminate the threat and
at the exception of the cited solution (*) and similar ones the way to do
that is to REQUIRE that PCP Servers controlling NATs which serve
multiple subscribers and can reassign mappings to save the explicit
dynamic mapping state in stable/persistent storage.
(BTW it is well known such NATs have to use stable/persistent storage
for many other reasons so it is not a problem).
 And this belongs to security so should be in the security considerations
(at least the security requirements must be).

      Connection authentication (e.g., TLS) does eliminate this threat.   
   
=> unfortunately it is not the case: a perfectly authenticated
subscriber can acquire an explicit dynamic mapping of another
subscriber if the PCP Server lost the fact it was the explicit dynamic
mapping of another subscriber.

Thanks

[e-mail]

PS: BTW to explain to subscribers (victims?) of ISP CGNs they should
use IPsec (network layer), TLS (transport layer) and/or application
security for all communications is not very kind as they are likely in
countries where these security solutions are very far to be allowed.