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

Simon Perreault <simon.perreault@viagenie.ca> Tue, 08 December 2009 00:53 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2EB28C13A for <behave@core3.amsl.com>; Mon, 7 Dec 2009 16:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5QmvdZ20GB7 for <behave@core3.amsl.com>; Mon, 7 Dec 2009 16:53:04 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1980F3A6896 for <behave@ietf.org>; Mon, 7 Dec 2009 16:53:04 -0800 (PST)
Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5A2A520DFB; Mon, 7 Dec 2009 19:52:53 -0500 (EST)
Message-ID: <4B1DA364.5040505@viagenie.ca>
Date: Mon, 07 Dec 2009 19:52:52 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4
MIME-Version: 1.0
To: Reinaldo Penno <rpenno@juniper.net>
References: <C742901E.BACF%rpenno@juniper.net>
In-Reply-To: <C742901E.BACF%rpenno@juniper.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Cameron Byrne <cb.list6@gmail.com>, "behave@ietf.org" <behave@ietf.org>, 'Xu Xiaohu' <xuxh@huawei.com>, Dan Wing <dwing@cisco.com>
Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2009 00:53:05 -0000

On 12/07/2009 01:57 PM, Reinaldo Penno wrote:
>> 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.

Actually in my mind I was referring to the people running the network. I 
think most of the time they will not care. I agree that someone could 
care, and that there should be a way to negotiate this as part of the 
protocol.

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

Correct.

(BTW, very good example!)

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

By ensuring that both NATs are configured with the same static 
configuration?

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

Yes, it is very important to get the scope right.

I think the scope should be limited to the choices that are present in 
the NAT64 spec. In your example above, the following would be out of scope:

- Logging
- Filtering (Not talking about NAT filtering behaviour. The example 
above is part of firewall functionality, not NAT.)

How about that?

> * Need to mention how the protocol will synch UPNP and NAT-PMP info

You mean static configuration or just the bindings? I don't see how 
bindings would be synchronized differently that those created by 
outbound connection initiation.

> * How the protocol will synch ALG info.
> * IPSEc and other VPN/VRF issues

In my mind the protocol would need to be extensible. The base spec would 
focus on NAT64. Extensions could be written for ALGs/IPsec/...

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