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

[<[e-mail]>]

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.

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