Re: [BEHAVE] (no subject)

"Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> Tue, 18 June 2013 19:24 UTC

Return-Path: <ssenthil@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 6DE9211E80FA for <behave@ietfa.amsl.com>; Tue, 18 Jun 2013 12:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.723
X-Spam-Level:
X-Spam-Status: No, score=-9.723 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8]
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 wWKWTwXfVQsA for <behave@ietfa.amsl.com>; Tue, 18 Jun 2013 12:24:52 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05111E80F6 for <behave@ietf.org>; Tue, 18 Jun 2013 12:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4062; q=dns/txt; s=iport; t=1371583492; x=1372793092; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=omyAhBnL+HKOtcZl7u9vAuntLu2Ym6c8Qi4JElcNFXs=; b=KXX5TSiBgfC+J7xyai5ioQuMm9mhYc8cnVx3YyR7+gf+2Q3wpEz6ZbNs yMGpk5CtSnIaJld3y8eUVa10nST0ocgm62mp6/lbyU1FvAC43QC7cqBHb zb5iLD9YKP8X2e1wBhGU5DNtveiPsStQ9Q19dKPRhF4mapW40hLQj2JQq Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAPeywFGtJV2Z/2dsb2JhbABZgwl6gwG8Dw12FnSCIwEBAQQ0VwkYBAYiBDAlAgQBEgiIBo1/mzUGkUaBIIxjgQcWIoJHOWEDoVSHMIMPgWhA
X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224216674"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2013 19:24:51 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5IJOpVQ010583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 19:24:51 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 14:24:51 -0500
From: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
To: "ivan@cacaoweb.org" <ivan@cacaoweb.org>, Behave <behave@ietf.org>
Thread-Index: AQHObFmAgdHlRyxSR02wAQ7tdo7juA==
Date: Tue, 18 Jun 2013 19:24:50 +0000
Message-ID: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com>
In-Reply-To: <29cbc62347efa3a4efcf6105d04e531d@cacaoweb.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [64.102.83.125]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <64B5F9250930354A9695958C16900D8B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Tue, 18 Jun 2013 19:24:58 -0000

Hi Ivan,

On 6/18/13 1:10 PM, "ivan c" <ivan@cacaoweb.org> wrote:

>Hi Senthil,
>
>See my comments below.
>
>On Tue, 18 Jun 2013 16:16:33 +0000, "Senthil Sivakumar (ssenthil)"
><ssenthil@cisco.com> wrote:
>
>> 
>> I just want to add that I did a port preservation implementation a while
>> ago, but realized that the number of times that the ports couldn¹t be
>> preserved were getting more and more. Even though this wasn't causing
>any
>> application behavior issues, the customers were complaining because they
>> construed that as NAT not working properly, (whether their assumption
>that
>> is right or wrong is a different discussion), so we ended up not using
>the
>> port preservation as a default behavior in later implementations. It
>also
>> improves the performance.
>> 
>
>Are you talking about UDP port preservation? I think we all agree UDP port
>preservation is not necessary, as long as the NAT is EIM for UDP.
>About TCP port preservation, most NAT implementations have it. In some
>countries (like France), all ISP-provided gateways have it.
>As you note, TCP port preservation improves latency and thus performance,
>when compared to the alternative of using a STUNT server.
>It does not need the intermediate step of contacting the STUNT server to
>perform TCP port prediction.

Both TCP & UDP. The latest implementation in some router families is not
to have port preservation
(for both TCP & UDP).

>
>
>> 
>>>
>>>- Port preservation is not applicable to CGN, where a subscriber often
>>>only has access to a limited range of external ports.
>> 
>> Exactly, with the allocation of port sets in CGN, it becomes very
>> difficult to do any kind of port preservation.
>> 
>
>Nope, you would need to elaborate on this.
>The probability that of an internal port collision is high because of the
>birthday paradox, but port overloading is perfectly acceptable, and when a
>full collision occurs (when internal ports and remote endpoints are the
>same for two outgoing TCP connections), which is supposed to be a rare
>event, the CGN can fallback on EDM or simply drop the connection.

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.


Thanks
Senthil
>
>
>
>>>
>>>- There are ways to improve the scalability of EIM without killing it.
>>>I've been advocating for some time that NATs should be allowed to use
>>>EDM for protocols that they know will not break, with EIM as a default.
>>>For example, using EDM for TCP port 80 and UDP port 53 is easy,
>>>harmless, and has a big impact.
>> 
>> For allowing EDM, one has to know their applications they are using, but
>> as you say port 80 can work well with EDM.
>> 
>
>Exactly, see my message to Simon for a more in-depth discussion about this
>topic.
>
>
>
>-- 
>_Ivan Chollet_