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

Simon Perreault <simon.perreault@viagenie.ca> Fri, 21 June 2013 07:48 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 39E7511E8166 for <behave@ietfa.amsl.com>; Fri, 21 Jun 2013 00:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 XnrvNv5+saYS for <behave@ietfa.amsl.com>; Fri, 21 Jun 2013 00:48:15 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 443C711E816D for <behave@ietf.org>; Fri, 21 Jun 2013 00:48:15 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 97F5F40426 for <behave@ietf.org>; Fri, 21 Jun 2013 03:48:14 -0400 (EDT)
Message-ID: <51C4053D.5050703@viagenie.ca>
Date: Fri, 21 Jun 2013 09:48:13 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: behave@ietf.org
References: <CB1B483277FEC94E9B58357040EE5D02325AA8EE@xmb-rcd-x15.cisco.com> <9637befefe07c43417c758a004e03f3c@cacaoweb.org>
In-Reply-To: <9637befefe07c43417c758a004e03f3c@cacaoweb.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs
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: Fri, 21 Jun 2013 07:48:16 -0000

Le 2013-06-20 21:20, ivan c a écrit :
> On Wed, 19 Jun 2013 14:38:12 +0000, "Senthil Sivakumar (ssenthil)"
> <ssenthil@cisco.com> wrote:
>>
>> Ok thanks for the pointers. The NATs that I was talking about were
>> enterprise/SP NAT boxes,
>> not the home routers. Many of the CGN implementations don¹t do port
>> preservation.
>>
>
> Yes, CGNs are not expected to be p2p-friendly at this stage

I, for one, would expect them to be! See RFC 6888.

> and I don't
> think having any MUST requirements to help with TCP Hole Punching would do
> any good. EIM for TCP can probably be safely ignored too as there is no
> real use case,

 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?

> however if there is one thing they should try to implement
> that's RFC 4787 for UDP.
> Having said that, I would support mentioning TCP Hole Punching and its
> subvariants in the document and what a NAT should do to support them as a
> recommendation.
>
>
>>
>> There are two distinct things here:
>> 1. Port preservation is a must
>> 2. Port preservation requires port overloading to work
> deterministically.
>
> Not exactly, port preservation can *never* work deterministically.
> Consider the rare case where the two remote endpoints are the same too.
> This breaks port preservation.

Many NATs don't care about remote endpoints.

> Not that it matters anyway, what we want is the interface provided by the
> TCP Hole Punching protocol to be deterministic. The NAT falling back on EDM

Assuming that NATs will "fall back on EDM" seems very risky.

> in case of a collision is a case that is taken care deterministically by
> the TCP Hole Punching protocol. (See my email in reply to Simon a few
> minutes ago)
> 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.

>> I don¹t have a lot of problem with an implementation choosing to do port
>> preservation if it can.
>> I do have issues with doing port overloading. Two reasons again.
>> 1. Port overloading requires the destination information to be tracked
> by
>> NAT devices. That kills scalability.
>> 2. Port overloading causes packets to be dropped if two connections
> going
>> to the same destination, causing indeterministic behavior.
>
> (my email to Simon is more detailed regarding TCP port overloading and the
> relationship with TCP Hole Punching)
> I restrict the discussion to port overloading for TCP.
> 1. It kills scalability when logging is required (but in that case a CGN
> would probably use static port ranges to segregate subscribers).
> As far as session tracking is concerned, port overloading only makes the
> key of the NAT's mapping hashtable twice as big. Not a concern for
> scalability.

Some NATs don't track sessions.

> 2. That's a bit extreme, the NAT doesn't need to drop packets, it just
> switches to EDM. This only adversely affects TCP Hole Punching, which is
> prepared to deal with the case in its protocol.

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

Simon

>> Maybe as Rajiv suggested in another thread, maybe we need a CPE NAT
>> requirements document where the above requirement might be placed.
>> But I don¹t know what good it is, if there is another CGN on the headend
>> that would not honor the port preservation. As I said, in my earlier
>> Email, the CGNs can now have a pre-allocated set of ports (like 1k
>> ports/sub), where there is no way to do port preservation.
>>
>
> At this stage, CGNs are not very keen on EIM for TCP, and TCP port
> preservation is a stronger condition, so it looks like a lost battle to me.
> And in my opinion, if CGNs could at least do EIM for UDP, it would be a
> good start indeed. That would have a higher priority.
>
> There is one big difference between home NATs and CGNs: behind a home
> NATs, users know each other, and can have a friendly policy to share
> resources like ports forwardings. As opposed to a CGN which is more
> concerned about isolating users from one another for privacy and security
> reasons.
> This makes a big difference in what you can require from a CGN.
>
>
>


-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca