Re: [BEHAVE] TCP port overloading, preservation and CGNs

ivan c <ivan@cacaoweb.org> Tue, 25 June 2013 17:19 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 E2BE111E8129 for <behave@ietfa.amsl.com>; Tue, 25 Jun 2013 10:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 z0ByH7oIFR82 for <behave@ietfa.amsl.com>; Tue, 25 Jun 2013 10:19:06 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id BC75011E8124 for <behave@ietf.org>; Tue, 25 Jun 2013 10:19:06 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UrWuR-0003V3-4U; Tue, 25 Jun 2013 19:20:03 +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 19:20:03 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <51C4053D.5050703@viagenie.ca>
References: <CB1B483277FEC94E9B58357040EE5D02325AA8EE@xmb-rcd-x15.cisco.com> <9637befefe07c43417c758a004e03f3c@cacaoweb.org> <51C4053D.5050703@viagenie.ca>
Message-ID: <b863f14098e41ecbb3fe4ca56641d053@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Cc: Behave <behave@ietf.org>
Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs
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 17:19:12 -0000

Hi,

On Fri, 21 Jun 2013 09:48:13 +0200, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
>  From the start of this discussion, it has appeared to me like you do 
> have a use case for EIM TCP. Don't you want to do TCP NAT traversal?
> 

TCP NAT traversal has many variants but as far as I'm aware no application
has ever used EIM for TCP. It's nice for NAT to support different variants
for applications to fall back on.


> 
> Many NATs don't care about remote endpoints.

Senthil and I were making the point that port preservation can never be
satisfied for all TCP connections, regardless of whether we do port
overloading or whether the NAT looks at the whole 5-tuple or not.
Your comment is also a true statement, although not directly related to
this point.


>> This is what home NATs do: TCP port preservation (which implies EIM for
>> TCP, so makes it easy for them), and in case of a source collision,
>> fallback on EDM.
> 
> Please understand that there are many different ways to implement NAT, 
> and this is just one of them.
> (...)
> Some NATs don't track sessions.
> 

Sure, NATs can behave in many ways. The main point of the discussion is to
provide suggestions so NAT can have some support for p2p applications,
both
for UDP and TCP. It is expected that stateless NATs won't have too much
support for this.
On the other hand, home NATs do offer such support and have done so for
many years now.


> Some NATs don't implement EDM and thus cannot switch to it.
> 

By definition, all NATs are "EDM".
"Endpoint-dependent Mapping" really means "Address and port-dependent
Mapping". This is the most general case of NAT, where no requirement is
made on the type of mapping. For instance, "EIM" is a particular case of
this general case.
Maybe we should use the term APDM instead of EDM for the sake of clarity,
but the best is probably to avoid using the "EDM" acronym altogether if it
leads to confusion. Instead, we can use the term "no particular
requirement
on the mapping scheme" or something similar. This way, people new to the
discussion can understand the point immediately and we also avoid the use
of new obscure acronyms.


Again, the goal here should be to suggest options for NAT to behave in p2p
friendly ways. Some useful optional features for CGNs, like port
overloading, do have minor caveats that should be detailed in the
document,
and they also don't apply to "3-tuple" NATs as you mentioned. 
This is the best way in my opinion to write a Best Current Practices
document.



-- 
_Ivan Chollet_