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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Reinaldo Penno [mailto:[e-mail]] 
Envoyé : vendredi 8 octobre 2010 07:51
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [e-mail]
Cc : Dan Wing; [e-mail]
Objet : Re: [pcp] PCP Failure Scenarios - Re: draft-wing-pcp-proposed-packet-format-00




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. 

Med: PCP-unstructured entries or using any other tools to configure port forwarding on the CGN are not in the same level as dynamic mappings created by outgoing packets. Unlike other mappings which have system-wise timers (system-wise timers are configured for all UDP and TCP packets), these entries have their per-entry timers (a.k.a., lifetime). What we are saying here is that a basic reliability requirement for the CGN is to protect any static or automatic (e.g., PCP) port forwarding against failure. This requirement is not about imposing hot-standby or the recovery of all dynamic states instantiated by outgoing packets. We had this requirement about port forwarding in our CGN RFP and I don't remember I seen an objection from the vendors on having this requirement.

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


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