Re: [BEHAVE] (no subject)

Dan Wing <dwing@cisco.com> Thu, 20 June 2013 03:25 UTC

Return-Path: <dwing@cisco.com>
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 0586711E80E9 for <behave@ietfa.amsl.com>; Wed, 19 Jun 2013 20:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.572
X-Spam-Level:
X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 8-gLZbYYQn-N for <behave@ietfa.amsl.com>; Wed, 19 Jun 2013 20:25:15 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5F02211E80E6 for <behave@ietf.org>; Wed, 19 Jun 2013 20:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5557; q=dns/txt; s=iport; t=1371698715; x=1372908315; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/GY8UY86OtjQv4U5JkPMC86mM4fwagcHMFbBS9jzdvc=; b=F65wWFujxEYTkVDLOUeHIlPJaBjzNernsTmKbvQT6gSCxoixDl4KTm3b HRCfHYvZRqpPA3Wko6QC2aqzc9D/iikiI6RSpXlYiHJZ2f8CSEAGLBeps QFVVs398iKoLaxJ/w4g9nJr5lKDly+KGS5bLlNDlMUHJlhCcKgYvJkvNV I=;
X-IronPort-AV: E=Sophos;i="4.87,901,1363132800"; d="scan'208";a="83943923"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 20 Jun 2013 03:25:15 +0000
Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5K3PE3x024295; Thu, 20 Jun 2013 03:25:14 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CB1B483277FEC94E9B58357040EE5D02325AA8EE@xmb-rcd-x15.cisco.com>
Date: Wed, 19 Jun 2013 20:25:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <80BFC9AE-2ADD-4F5D-9229-FBD6B0E403F3@cisco.com>
References: <CB1B483277FEC94E9B58357040EE5D02325AA8EE@xmb-rcd-x15.cisco.com>
To: Senthil Sivakumar (ssenthil) <ssenthil@cisco.com>
X-Mailer: Apple Mail (2.1508)
Cc: Behave <behave@ietf.org>, "ivan@cacaoweb.org" <ivan@cacaoweb.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: Thu, 20 Jun 2013 03:25:20 -0000

On Jun 19, 2013, at 7:38 AM, Senthil Sivakumar (ssenthil) <ssenthil@cisco.com> wrote:

> Hi Ivan,
> 
> On 6/18/13 4:33 PM, "ivan c" <ivan@cacaoweb.org> wrote:
> 
>> Hi Senthil,
>> 
>> Thanks for your message. You might want to read
>> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00
>> It features the list of updates to the existing RFC, adapted to new usage
>> contexts such as CGNs, mobile networks, etc.
> 
> I have reviewed this draft and we had a bit of discussion around these
> topics in the last IETF.
>> 
>> 
>> On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)"
>> 
>>>> 
>>>> Are you talking about UDP port preservation?
>>> 
>>> Both TCP & UDP. The latest implementation in some router families is not
>>> to have port preservation
>>> (for both TCP & UDP).
>>> 
>> 
>> The discussion here is not about UDP. UDP port preservation should
>> generally not be implemented by NATs, as it could generate conflicts when
>> 2
>> internal hosts using the same local port, each with a session to the same
>> endpoint. This would break end-to-end connectivity in rare cases, as there
>> is no fallback mechanism (as opposed to TCP).
>> 
>> To be clear, the requirements are as follows:
>> * NAT SHOULD NOT use UDP port preservation
>> * NAT SHOULD use TCP port preservation
>> 
>> Here are some NATs that have been tested and implement TCP port
>> preservation:
>> in the UK:
>> BT (British Telecom) (house-made gateway) - number 1 provider
>> Virgin (house-made gateway) - number 2 provider
>> Sky (Sagemcom) - number 3 provider
>> 
>> in France:
>> Orange (Livebox) (house-made gateway) - number 1 provider
>> Free (Freebox) (house-made gateway) - number 2 provider
>> SFR/Neuf (Neufbox) (house-made gateway) - number 3 provider
>> 
>> This covers the overwhelming majority of subscribers.
> 
> 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. 
> 
> 
>> 
>> We have the same results in Spain in Italy.
>> 
>> Misc:
>> Linksys E1200, latest generation.
>> Netgear, various models
>> 
>> 
>> It is difficult to find any NAT that does *not* implement TCP port
>> preservation in these countries.
>> If you think some gateway implementations have dropped TCP port
>> preservation, you need to substantially support your claim by a reference.
>> We are not aware of anything that would support it.
>> 
>> 
>>> 
>>> Most of the NATs that I know don¹t do port overloading any more.
>>> RFC 5382 also says,
>>> REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
>>>      overloading" for TCP.
>>> 
>> 
>> This is the purpose of the new draft
>> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 , to
>> make the use case for port overloading, as it is needed in CGNs. It wasn't
>> needed nearly as much in 2005 when RFC 5382 was first written.
>> 
>> REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port
>> overloading" for TCP
>> is too stringent, as proved in my earlier message and in the
>> draft-ietf-behave-requirements-update-00, and not needed.
> 
> There are two distinct things here:
> 1. Port preservation is a must
> 2. Port preservation requires port overloading to work deterministically.
> 
> 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.
> 
> 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.

The impact to applications is the same, no matter if the NAT function is within the user's home or in the service provider's network.  With some of the A+P techniques, the ISP controls the in-home CPE behavior, assigning it a limited number of ports.  Thus the difference between a "carrier" NAT and the "consumer" NAT is far too blurred to make a useful distinction between port overloading behavior.

This discussion should continue, even if to repeat the arguments that were made years ago when the port overloading text was the WG's consensus.  If WG consensus has changed, let's change the updated document.  But we do need a careful analysis and discussion of the impact of such a change to applications and to NATs.

-d


> 
> Senthil
> 
>> 
>> Port overloading is perfectly acceptable when the remote endpoints are
>> distinct, as it preserves the uniqueness of the 5-tuple.
>> 
>> As a result, REQ-7 must be corrected.
>> 
>> 
>> 
>> -- 
>> _Ivan Chollet_
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave