Re: [BEHAVE] (no subject)

Simon Perreault <simon.perreault@viagenie.ca> Wed, 26 June 2013 08:10 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE6C21F9A3F for <behave@ietfa.amsl.com>; Wed, 26 Jun 2013 01:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJULKY7Mb78n for <behave@ietfa.amsl.com>; Wed, 26 Jun 2013 01:10:55 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 85C2E21F9967 for <behave@ietf.org>; Wed, 26 Jun 2013 01:10:54 -0700 (PDT)
Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9B3494043D; Wed, 26 Jun 2013 04:10:53 -0400 (EDT)
Message-ID: <51CAA20F.4070307@viagenie.ca>
Date: Wed, 26 Jun 2013 10:10:55 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: ivan@cacaoweb.org
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <f8741fad1af1cee094de9c59408b7425@cacaoweb.org> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org>
In-Reply-To: <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 26 Jun 2013 08:10:57 -0000

Le 2013-06-25 18:46, ivan c a écrit :
> We have, for all UDP communications and all outbound TCP sessions:
> - one socket is bound to one local endpoint on the host. Additionally, two
> sockets have to bind to two different local endpoints.

Not true. If you call connect() on a UDP socket, it behaves just like a 
TCP socket.

> - one internal endpoint (=local endpoint) is mapped to one external
> endpoint on the NAT
> As a result, if no overloading, the NAT has to allocate a new external
> endpoint for every outbound TCP session.
> This doesn't apply to UDP.

Not true because of the above.

>>> Back to NAT port overloading. A collision occurs when 2 sessions share
>>> the
>>> same 5-tuple.
>>
>> Stop right here. Some NATs don't track sessions. Those NATs don't care
>> about 5-tuples. All they do is map internal 3-tuple to external 3-tuple.
>
>> So for those NATs there is no conflict. They will just translate the
>> packets according to the existing mapping.
>>
>> All the following doesn't make sense to me given this.
>>
>
> Sure, *stateless* NATs also can't do much endpoint dependent filtering and
> lots of other
> things. They certainly can't do port overloading and are out of scope of
> this discussion.

I'm not referring to stateless NATs. I'm referring to stateful NATs that 
only map internal 3-tuple to external 3-tuple and do not do anything 
with 5-tuples.

> Nevertheless, NATs that do look at the full 5-tuple are free to implement
> port overloading if they wish.

I still haven't seen any explanation why the following excerpts do not 
apply.

RFC 4787:

    REQ-3:  A NAT MUST NOT have a "Port assignment" behavior of "Port
       overloading".

    Justification:  This requirement must be met in order to enable two
       applications on the internal side of the NAT both to use the same
       port to try to communicate with the same destination.  NATs that
       implement port preservation have to deal with conflicts on ports,
       and the multiple code paths this introduces often result in
       nondeterministic behavior.  However, it should be understood that
       when a port is randomly assigned, it may just randomly happen to
       be assigned the same port.  Applications must, therefore, be able
       to deal with both port preservation and no port preservation.

RFC 5382:

    REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
       overloading" for TCP.

    Justification:  This requirement allows two applications on the
       internal side of the NAT to consistently communicate with the same
       destination.

Simon