Re: [BEHAVE] (no subject)

ivan c <ivan@cacaoweb.org> Tue, 25 June 2013 16:45 UTC

Return-Path: <ivan@cacaoweb.org>
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 3D98E21F92D3 for <behave@ietfa.amsl.com>; Tue, 25 Jun 2013 09:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
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 3cIyXtGItF15 for <behave@ietfa.amsl.com>; Tue, 25 Jun 2013 09:45:41 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1529121F9A1A for <behave@ietf.org>; Tue, 25 Jun 2013 09:45:41 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UrWO2-0002yn-5e; Tue, 25 Jun 2013 18:46:34 +0200
To: Simon Perreault <simon.perreault@viagenie.ca>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Tue, 25 Jun 2013 18:46:34 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <51C40374.8080403@viagenie.ca>
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <f8741fad1af1cee094de9c59408b7425@cacaoweb.org> <51C40374.8080403@viagenie.ca>
Message-ID: <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Cc: behave@ietf.org
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
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: Tue, 25 Jun 2013 16:45:46 -0000

On Fri, 21 Jun 2013 09:40:36 +0200, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
>>
>> (1) one UDP socket (local endpoint) can have multiple communication
>> sessions. (with multiple remote endpoints)
>> (2) one TCP socket can have only one session.
>> (...)
>> Consequence:
>> Applications don't need to use more than one UDP local endpoint, but
need
>> to use many TCP local endpoints.
>> (...)
>> Consequence (1):
>> The use case for port overloading should be TCP, not UDP.
> 
> I don't understand how you jump from sockets on the host to external 
> ports on the NAT. I don't see how you reach this conclusion.
> 

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


>> 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.
Nevertheless, NATs that do look at the full 5-tuple are free to implement
port overloading if they wish. The purpose of my text was to explain how
p2p applications interact with this, and in particular the relationship
with TCP Hole Punching.

Hope this helps.


-- 
_Ivan Chollet_