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

[Simon Perreault <[e-mail]>]

Reinaldo Penno wrote, on 2009-12-07 02:15:
> 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?

The situation: Two NATs, state synced, one sending ICMP errors and the other not.

To elaborate further: Suppose I'm talking about a small/medium enterprise with
the two NATs in sync sitting at the border of the Internet and their LAN. There
are people working in the LAN, with, say, web browsers. They absolutely don't
care about the difference in ICMP behaviours.

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

Sure, I don't disagree. But there are tons of other cases where it doesn't matter.

So we could want the sync protocol to negotiate or not these differences in
behaviour.

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

Example: You power up the NAT and put it in service. It has no
bindings/sessions. As packets traverse it, bindings and sessions get created,
deleted, etc. So the binding and session tables vary over time. Also known as
"dynamic".

The behaviours such as "sends ICMP errors" do not vary. They are always the same
(or at least, remain constant during the lifetime of a NAT state sync session).
Therefore the state sync protocol has nothing to do with them. It may need to be
restarted to renegotiate their values if they change, but that's it. Also known
as "static".

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

No. This is not dynamic state, it's static configuration. The static
configuration needs to be the same, or could also be negotiated at the
beginning. It is completely separate from state sync and does not run under the
same constraints. For example, the state sync protocol needs to be very
efficient. But to negotiate static configuration this constraint is relaxed.

If you want to do this "at random" then yes it would be dynamic and need to be
synchronized. But I suggest this be out of scope.

>> "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?

I suppose that the correct answer is "no."

Note that a NAT state sync protocol would be useful to much more than just
service providers.

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

I'm feeling that this discussion is becoming less constructive.

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

Sure, why not? It's just a matter of propagating changes to the binding/session
tables.


To recap our discussion:

- An eventual state sync protocol would need an init phase where static
configuration and behaviours would be negotiated.

- The level to which the static stuff needs to be similar (or made similar) will
differ in different cases.

- After the negotiation is successful, only dynamic state updates will be
propagated.

Is this right? Does anything else need to be said at this point?

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org