Re: [pcp] PCP Failure Scenarios - Re: draft-wing-pcp-proposed-packet-format-00

[Reinaldo Penno <[e-mail]>]

On 10/7/10 10:40 PM, "[e-mail]"
<[e-mail]> wrote:

> 
> Dear all, 
> 
> Please see inline.
> 
> Cheers,
> Med 
> 
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : jeudi 7 octobre 2010 19:18
> À : Reinaldo Penno
> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Dan Wing; [e-mail]
> Objet : Re: [pcp] PCP Failure Scenarios - Re:
> draft-wing-pcp-proposed-packet-format-00
> 
>  In your previous mail you wrote:
> 
>    I disagree with such statements at this point since I still need to see
> data
>    to back them up.
>    
>    For example,
>    
>    1 - First and foremost, please define CGN.
> 
> => a NAT which is so big and noisy I don't want one at home.
> Seriously I have a convenient definition for this particular discussion:
> a NAT where clients (guys at the internal side, the other/external is
> the or to the Internet) may not trust together. As an immediate
> consequence to forward a packet from the Internet to the wrong client
> is a major security issue.
> 
>    2 - Then we please define a reliable NAT - such that state is never ever
>    lost. Please see (4)
> 
> => reliable for the port forwarding entries. Note this is done even with
> not CGN NAT (the NAT in front of me is not a CGN and its (port forwarding)
> config is very reliable (save in a flash memory and downloaded at each
> reboot)).
> 
> Med: Agree. I'm mainly concerned with a basic requirement which is the
> following excerpt from
> http://tools.ietf.org/html/draft-xu-behave-nat-state-sync-02:
> 
> "The NAT states mentioned in this document only mean those NAT states
>    which are created dynamically, rather than those static NAT states
>    which are configured manually on NAT devices. For those static NAT
>    states, they are essentially part of the configuration data. The
>    replication of configuration data among a group of devices is
>    absolutely outside the scope of this document."
> 
> "Static entries" mentioned above apply also for PCP-instructed ones.

I disagree according to
http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework/

"State:  "State" refers to dynamic information that is stored in a
      network element.  For example, if two systems are communicating
      using a TCP connection, each stores information about the
      connection, which is called "connection state".  In this context,
      the term refers to dynamic correlations between IP addresses on
      either side of a translator, or {IP address, transport protocol,
      transport port number} tuples on either side of the translator.
      Of stateful algorithms, there are at least two major flavors
      depending on the kind of state they maintain:"

PCP entries are clearly dynamic state created by protocol exchange and have
a lifetime. 




> 
> BTW, I think we need to have a clear definition somewhere to agree on the
> terminology. Note that several levels of reliability in the NAT can be
> envisaged as described in
> http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-04.
> 
>    3 - The BEHAVE RFCs do not mention the necessity of keeping NAT binding
>    state across reboots/power off, why keeping PF dynamic state is needed?
> 
> => PF is *not* equivalent in the security point of view to a dynamic
> NAT binding (*) so BEHAVE RFCs are right but don't apply.
> 
>    4 - CLI to clear mapping state will be implemented for sure due to security
>    reasons. How should we deal with that?
>    
> => yes, when my PCP server crashes (or when I kill it) all the PF entries
> it has installed are flushed, and this is done by the AFTR code as fast
> as possible. There are many reasons for this and security is one of
> them as lifetimes are managed by the PCP server, and when the PCP server
> restarts its first action is to reinstall the PFs it keeps in stable
> storage (a BSD DB which is my approximation from the top of stable storage).
> BTW a missing PF is bad but is not a security issue.
> 
>    Therefore, I'm fine with removing the Epoch, but clients will need to deal
>    with the PCP Server loosing all state during certain types of events - such
>    event could be a admin clearing all mappings due to a security concern.
>    
> => the Epoch doesn't help you because it doesn't provide an usable
> proactive way to warn clients about such events.
> 
> Regards
> 
> [e-mail]
> 
> *********************************
> This message and any attachments (the "message") are confidential and intended
> solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed
> or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender.
> ********************************
>