Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT

Sami Boutros <sboutros@vmware.com> Wed, 12 July 2017 20:56 UTC

Return-Path: <sboutros@vmware.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431A212ECED; Wed, 12 Jul 2017 13:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-8pkY5MVzsy; Wed, 12 Jul 2017 13:56:50 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0075.outbound.protection.outlook.com [104.47.33.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6116126B6D; Wed, 12 Jul 2017 13:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y1ff1M0GOApA1yf6D6YBJPapxpTfafDRNQXMNQs33zU=; b=dDZnrG2z809JJ4wXX0Jw5qCk69OVEgadmFz7IjWD1Vv4mt/PxTeqp5sqzWLtWmtKhlYmkc/eE7HTlae5YJgd8znJDWtnVafSqGvvvDqyP4knogz8SZey9xuxyBzKTWUc9tbpC5xiM9waa2FSzUxwOtQ+k/q6gt3SqBDtgd/Ohb8=
Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3138.namprd05.prod.outlook.com (10.172.146.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Wed, 12 Jul 2017 20:56:48 +0000
Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.1261.015; Wed, 12 Jul 2017 20:56:48 +0000
From: Sami Boutros <sboutros@vmware.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, NVO3 <nvo3@ietf.org>, "draft-ietf-nvo3-encap@ietf.org" <draft-ietf-nvo3-encap@ietf.org>
Thread-Topic: draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
Thread-Index: AdL7Q+/ZfEDwvo9TRzm5LoTlMhYAfP//pYYA
Date: Wed, 12 Jul 2017 20:56:48 +0000
Message-ID: <324EE94E-0ADE-4153-8B3C-5D973A8EF710@vmware.com>
References: <4A95BA014132FF49AE685FAB4B9F17F6593FAA91@SJCEML702-CHM.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6593FAA91@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=vmware.com;
x-originating-ip: [208.91.2.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR05MB3138; 20:ADhIgz/cBrx7yE1+Mh18I45TSQaggBD1z7Dwd5gzFnqoZB7AhsMNCw+qmpMx8eXy3heRr4pPetTC0juNzpof3j2bI1AkGpRQ6Q92jjlK5bMibe5qxjRGQvzjbaQLmORf2Lh0rCVfj0HlSUM9ZvGeNPDY430itnx3SxbF3Gw3xe4=
x-ms-office365-filtering-correlation-id: 932fa412-f893-4104-b0c9-08d4c968834e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR05MB3138;
x-ms-traffictypediagnostic: BN6PR05MB3138:
x-exchange-antispam-report-test: UriScan:(151999592597050)(61668805478150)(133145235818549)(26388249023172)(236129657087228)(50582790962513)(48057245064654)(21748063052155)(228905959029699)(247924648384137);
x-microsoft-antispam-prvs: <BN6PR05MB313888BA4A6C09236AC5CBEBBEAF0@BN6PR05MB3138.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3138; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3138;
x-forefront-prvs: 036614DD9C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(377454003)(33656002)(790700001)(86362001)(36756003)(230783001)(3846002)(102836003)(6116002)(81166006)(8936002)(25786009)(8676002)(3660700001)(53546010)(45080400002)(14454004)(2501003)(3280700002)(2906002)(7736002)(6306002)(99286003)(53936002)(6512007)(54896002)(236005)(38730400002)(2950100002)(478600001)(6506006)(6436002)(229853002)(6486002)(5660300001)(2900100001)(82746002)(50986999)(54356999)(189998001)(6246003)(76176999)(66066001)(83716003)(77096006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3138; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_324EE94E0ADE41538B3C5D973A8EF710vmwarecom_"
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 20:56:48.0492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3138
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/68HiPDuGrUSf_rUmhgPqFsUjNm0>
Subject: Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jul 2017 20:56:53 -0000

Thanks Linda for your comments,

Let’s discuss more in Prague to understand the use case.

Thanks,

Sami
From: Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>>
Date: Wednesday, July 12, 2017 at 12:37 PM
To: NVO3 <nvo3@ietf.org<mailto:nvo3@ietf.org>>, "draft-ietf-nvo3-encap@ietf.org<mailto:draft-ietf-nvo3-encap@ietf.org>" <draft-ietf-nvo3-encap@ietf.org<mailto:draft-ietf-nvo3-encap@ietf.org>>
Subject: draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent-To: Sami Boutros <sboutros@vmware.com<mailto:sboutros@vmware.com>>, <ilango.s.ganga@intel.com<mailto:ilango.s.ganga@intel.com>>, <pankajg@microsoft.com<mailto:pankajg@microsoft.com>>, <rajeev.manur@broadcom.com<mailto:rajeev.manur@broadcom.com>>, <talmi@marvell.com<mailto:talmi@marvell.com>>, <davidm@mellanox.com<mailto:davidm@mellanox.com>>, <nordmark@sonic.net<mailto:nordmark@sonic.net>>
Resent-Date: Wednesday, July 12, 2017 at 12:37 PM

Sami, et al,

The draft-ietf-nvo3-encap-00 is written very clear.

However, the Section 6 (Common Encapsulation Considerations) should add a sub-section on the consideration of traversing NAPT.  Encapsulated traffic could go to different data centers or WAN, which could go through Network Address Port Translation devices

Using VxLAN as an example: VxLAN specification [RFC 7348] uses a set of Port numbers to achieve better traffic distribution among multiple paths, which is fine within one data center, but causing trouble when traversing NAPT. NAPT use Port number to map back the source address. With a set of port numbers, NAPT can’t easily figure out the reverse direction traffic’s final IP addresses.

In addition, since the IP of packets change through NAPT device, it can mess up the learning of the peer NVE used in encapsulation.

STUN can be used to get changed IP and port from NAPT device, but it requires NAPT device support STUN. That’s not available in some scenarios. Furthermore, it can’t solve the aforementioned five-tuple issue.

VXLAN over IPSec may be used to deal with the above problems, but IPSec brings up to 88 bytes of overhead plus the key distribution management, which can lower the efficiency.


Suggestion: Add Section 6.10 Traversing NAPT consideration.
I can help to provide the text if you all think the suggestion is acceptable.

We can discuss more in Prague.

Thanks, Linda Dunbar

Huawei USA IP Technology Lab
5340 Legacy Drive,
Plano, TX 75024
Tel: +1 469-277 - 5840
Fax: +1 469 -277 - 5900