Re: [pcp] GET and GETNEXT OpCodes

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 10, 2011 4:57 PM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]; 'Simon Perreault'
> Subject: Re: [pcp] GET and GETNEXT OpCodes
> 
> 
>  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.

Is there such a requirement, today, for ISP-provided dynamic
IPv4 addresses (e.g., assigned via PPPoE or DHCP) -- in IETF 
specifications, service level agreements, or similar?

I do not believe there is.  But if there is, let's copy that 
wording from the DHCP RFC.

If there isn't, I do not see why PCP needs to go above and
beyond current industry practice and current behavior for
dynamic IPv4 address assignment.

-d


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