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

[Reinaldo Penno <[e-mail]>]

Thanks for the reply. Comments inline...


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

> Reinaldo Penno wrote, on 2009-12-07 02:15:
>> On 12/5/09 3:50 AM, "Simon Perreault" <[e-mail]> wrote:
>> 
>> 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.

I'm not sure about the people in the LAN but the enterprise operating the
NAT boxes cares. 

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

If all you send to the slave NAT is the private (IP address, port) protocol,
public (IP address and port), how will the slave box know which ICMP and
filtering behavior to apply to a certain NAT binding?

Example:  

In vendors' 1 box the NAT mapping is

SRC IP 2000::1, SRC PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port
2000 

That mapping was a result of a 'rule match' in which amongst many rules
there was one saying:

From: incoming interface 1, SRC IP 2000::/96 SRC PORT 10000-10500, protocol
UDP
To: outgoing interface 2, DST IP 2001::2,
NAT pool: 200.1.1.20-200.1.1.30,
Log: outgoing, binary
Timeout 30 seconds,
ICMP: no ICMPv4 for unsolicited
Filtering: allow incoming from 100.1.1.1-100.1.1.100, syslog
Port: Port parity.

The part that you proposing to synch is the mapping ( SRC IP 2000::1, SRC
PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port 2000 ), correct?

So, how will NAT slave determine all other behavior for each different
mapping as it receives the NAT state from the master?

> 
>> 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. 
> 
> 
> To recap our discussion:
> 
> - An eventual state sync protocol would need an init phase where static
> configuration and behaviours would be negotiated.

Scope clarification question based on what you said above:  Since each
vendors' boxes are configured differently are you saying you will come up
with a configuration scheme common and acceptable by all vendors as part of
this effort so negotiation (configuration and behaviors) can succeed?

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

See question in beginning with example.

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

A few things come to mind as discussed.

* Need to mention how the protocol will synch UPNP and NAT-PMP info
* How the protocol will synch ALG info.
* IPSEc and other VPN/VRF issues
* others that will discuss later.

Thanks,

Reinaldo


> Thanks,
> Simon