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

[<[e-mail]>]

Re-,

Agree. 

Let's do this. 

Cheers,
Med 

-----Message d'origine-----
De : Reinaldo Penno [mailto:[e-mail]] 
Envoyé : vendredi 8 octobre 2010 08:22
À : 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

Med,

More comments inline....Trying to steer away from semantics discussion.


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

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

Well, in summary some service providers care and others do not. Just like
Stateful NAT synch, some providers care and others do not. And therefore the
protocol can not work only if you keep state. Keeping state should be seen
as a bonus in some recovery situations.

On a more practical note, applications can not really rely on port
forwarding state being foolproof to work. IMHO trying to offset application
limitations on the network is the wrong thing to do - it is ALGs all over
again. 

That is why 'new' applications leverage EIM/EIF, AP, connection symmetry,
etc. 

I prefer dealing with failure and recovery in the protocol, specially since
there are other situations:

* CPE changing of IP address,
* Use of anycast address for AFTR/BR/CGN (do we create PCP entries in all
devices under the same anycast? How?)
* others.

I propose we go back and revisit the protocol to make sure clients/servers
can deal with failure within the protocol. Maybe a combination of Epoch and
PING/PONG would take care of most of the failures, maybe not, but let's take
to a logical conclusion before throwing the towel and saying all state need
to be kept.

Thanks,

Reinaldo







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


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