[IPsec] 答复: New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

Xuxiaohu <xuxiaohu@huawei.com> Thu, 03 November 2016 06:29 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62BE129407 for <ipsec@ietfa.amsl.com>; Wed, 2 Nov 2016 23:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level:
X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 MxAQCrDUkyzB for <ipsec@ietfa.amsl.com>; Wed, 2 Nov 2016 23:29:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EC51293E8 for <ipsec@ietf.org>; Wed, 2 Nov 2016 23:29:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUK65791; Thu, 03 Nov 2016 06:29:46 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 06:27:49 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 14:27:43 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Thread-Topic: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt
Thread-Index: AQHSM2gb01BpbARQ5EG6ZJX9p7ME46DDW/lw///ayQCAA5cDAA==
Date: Thu, 03 Nov 2016 06:27:42 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822D@NKGEML515-MBX.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> <ACF099F0-FA39-42A0-A4A7-A2E6CCBF136A@gmail.com>
In-Reply-To: <ACF099F0-FA39-42A0-A4A7-A2E6CCBF136A@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.184.181]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822DNKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.581AD95A.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f5a56d0a497d419baf9b3b3967f15b8d
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/q67AkbyIUEg4JdAoGNDk4QsviII>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [IPsec] 答复: New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 06:29:53 -0000

Hi Yoav,

The load-balancing mechanism as described in this draft would ensure a given traffic flow to be forwarded over a certain path. In other words, there is no disordering issue. The destination port is assigned by IANA while the source port is dynamically calculated by the ingress of the IPsec/UDP tunnel. Furthermore, a given traffic flow would be forwarded over a certain path and therefore this is no disordering issue. As for why do we need a new port, I had attempted to reply in another email.

Best regards,
XIaohu

发件人: Yoav Nir [mailto:ynir.ietf@gmail.com]
发送时间: 2016年11月1日 15:31
收件人: Xuxiaohu
抄送: ipsec@ietf.org
主题: Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

Hi, Xiaohu

A few comments. Actually, they’re more like questions.


  1.  How are IPsec SAs mapped to UDP pseudo-connections?  Is it a 1:1 mapping between SPI and source port?
  2.  If now, how do you deal with the packet reordering that the load balancer will do? IPsec requires ordered or nearly-ordered delivery.
  3.  How is this negotiated?  In IKE? Prior agreement?
  4.  Why do we need a new port?  What goes wrong if the packets go to port 4500?

Thanks

Yoav
On 1 Nov 2016, at 3:45, Xuxiaohu <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote:

Hi all,

Any comments and suggestions are welcome.

Best regards,
Xiaohu


-----邮件原件-----
发件人: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org]
发送时间: 2016年10月31日 19:15
收件人: Xuxiaohu; zhangdacheng; Xialiang (Frank)
主题: New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt


A new version of I-D, draft-xu-ipsecme-esp-in-udp-lb-00.txt
has been successfully submitted by Liang Xia and posted to the IETF repository.

Name:      draft-xu-ipsecme-esp-in-udp-lb
Revision:  00
Title:     Encapsulating IPsec ESP in UDP for Load-balancing
Document date:    2016-10-31
Group:     Individual Submission
Pages:     7
URL:
https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-udp-lb-00.txt
Status:
https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb/
Htmlized:       https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-00


Abstract:
 IPsec Virtual Private Network (VPN) is widely used by enterprises to
 interconnect their geographical dispersed branch office locations
 across IP Wide Area Network (WAN). To fully utilize the bandwidth
 available in IP WAN, load balancing of traffic between different
 IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link
 Aggregation Group (LAG) within IP WAN is attractive to those
 enterprises deploying IPsec VPN solutions. This document defines a
 method to encapsulate IPsec Encapsulating Security Payload (ESP)
 packets inside UDP packets for improving load-balancing of IPsec
 tunneled traffic. In addition, this encapsulation is also applicable
 to some special multi-tenant data center network environment where
 the overlay tunnels need to be secured.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
IPsec mailing list
IPsec@ietf.org<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec