Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

[Reinaldo Penno <[e-mail]>]

On 12/5/09 3:50 AM, "Simon Perreault" <[e-mail]> wrote:

> On 12/05/2009 03:27 AM, Reinaldo Penno wrote:
>> If a certain mapping on NAT64-A does not send ICMPv4 packets back
>> for unsolicited sessions and another mapping does, this behavior must remain
>> the same on the fail-over box.
> 
> This is arguable. IMHO, this behaviour could be different without
> negative impact in many situations.

This is a vague statement. Can you please elaborate which situations are
these without negative impact?

In my experience there are usually negative impacts ranging from from legal
requirements, DDoS & security and last but not least performance.

> 
>> NAT state is the mapping state + ICMP behavior (discussed above) + filtering
>> behavior + timer settings (discussed below for ICMP) + log behavior
>> (yes/no/format) + others not discussed. Each of these can be different for
>> different NAT entries.
> 
> We have different definitions of state it seems.
> 
> ICMP behaviour, filtering behaviour, timer settings, log behaviour, and
> others do not vary over time. (Or we could impose the constraint that
> the state sync connection be renegotiated when they do vary.)
> 
> The state sync protocol is only concerned with stuff that varies over
> time, i.e. bindings and sessions. That's it.

Can you explain what exactly and how is your definition of 'vary over time'?
When a NAT binding is created with certain parameters, do you foresee the
same NAT binding varying over time before the session is over?

I certainly foresee that the same private address can get a different
bindings when it goes to different destinations over time. But then it can
also get a different ICMP handling, filtering, logging and timer behavior.
Therefore this state also needs to be synched with each new different
binding. 

> 
>> Some people made the opposite case and it brings to some of the basics. NAT
>> operational complexity is high and therefore brings special requirements to
>> the table. Based on your statement it seems you think there are similar
>> cases.
> 
> "NAT operational complexity is high" is a blanket statement. For
> example, nowadays most everyone has a NAT at home without even knowing it.

Right, one vendor, one box, one interface in-out, box wide knobs for most
NAT behavior. Is that how you see service providers NAT boxes?

Because that would explain where you are coming from in relation to NAT
state, filtering, etc.

Thanks,

Reinaldo

PS: One thing NAT home devices have that is very useful is UPnP and NAT-PMP
(but that is being implemented in some large NAT boxes). Thinking about that
makes me wonder if the protocol will synch dynamic NAT port forwarding state
established through UPNP and NAT-PMP across boxes.