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

Yoav Nir <ynir.ietf@gmail.com> Thu, 03 November 2016 07:02 UTC

Return-Path: <ynir.ietf@gmail.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 4270B129516 for <ipsec@ietfa.amsl.com>; Thu, 3 Nov 2016 00:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6YjPPr4PmkTB for <ipsec@ietfa.amsl.com>; Thu, 3 Nov 2016 00:02:51 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48237129496 for <ipsec@ietf.org>; Wed, 2 Nov 2016 23:57:09 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id t79so80430741wmt.0 for <ipsec@ietf.org>; Wed, 02 Nov 2016 23:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZlBqd+YFXXo+xijzoxhf+pszSBp34mEZfUqlKpBRlXY=; b=lzALecKoJpY6Ks8TJM1MdKxvWBvcO4oAR5oOVEb2KveZXiG+yEhoS3W9x2SntsVGHD twI7OU6I14WlhEyXUWH6AdF4eFeBTcCG2sAZiinMz8h1nZL8E1IUom9tfLa/kUO1aB4Y V3mSzyNJpNkB1NjNfuWS0V7kg3T2fthbEKlRQZi7U4u1INj6eGD4o3h8tDA1fTqCHgU6 3LgHxPeRT8jDBbR52hXn9ts6Bf27oEMxdv5yIu8EAhhwKhy+dYzdAnqcoRu45k7zXmgM 4mYV1vMrN4Qj3ICoFLVGmcWtL3cRT3fBdLr+jGSm06ZmCKTJx+zfilLrAjLIw9+h2UYF Mqqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZlBqd+YFXXo+xijzoxhf+pszSBp34mEZfUqlKpBRlXY=; b=PqCVxU07gWAu162tW1jOumUOqCT1LXWSgEB8rGvALNg+QVv3ueJA2dzrQlpzX1T6kX j0xOWhGO/zSVRetILovlULXHhmj/yo08aKvBVCi5bXg4vxBhedZpv7PIxO/phhaDDwB1 vii97jgE1UBMDENh5krwhAX9lyih2XQxIgedrOS461u8+NScT+8MT1lGc+y9r62qhuHZ NiagWvtglCUx5+xGjgtfpjMY3GizKXyog8NpkKxpoqaVoBM6ftTRAx0x5Hr0ZkvunpKI U4awgVzg+VVBVBu71x61ZyvglUKYtLPlt9s+wpcLujYbORmKfwfegG0NreS+E7BoY6ax 60rg==
X-Gm-Message-State: ABUngvf59WE8M8Yg0jGc0U8o6vHAZqBoxkA5eQSfkGa15waKozUWxgo2U9J/x/46Sbs90Q==
X-Received: by 10.194.188.83 with SMTP id fy19mr5817489wjc.227.1478156227816; Wed, 02 Nov 2016 23:57:07 -0700 (PDT)
Received: from [192.168.137.54] ([109.253.197.194]) by smtp.gmail.com with ESMTPSA id s133sm40388048wmd.19.2016.11.02.23.57.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 23:57:06 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <418DD440-B823-4AD2-8767-CB213DE8B538@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_095E6428-4FB7-42A4-904F-3149844DEC52"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Thu, 03 Nov 2016 08:57:01 +0200
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822D@NKGEML515-MBX.china.huawei.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> <ACF099F0-FA39-42A0-A4A7-A2E6CCBF136A@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822D@NKGEML515-MBX.china.huawei.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/FNxjWqcmZiQfQ4QpQhoohyfIpxQ>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [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 07:02:52 -0000

The draft has no text about mapping SA to source port. So if I’m understanding you correctly, the tunnel ingress calculates the port (is there actual calculation, or just picking?), so if it sends all packets for a particular SA with the same UDP source port, they will all traverse the same path and therefore will likely not get re-ordered, or at least will not get any more re-ordered than IPsec packets on the regular Internet.

Did I understand this correctly?

Yoav

> On 3 Nov 2016, at 8:27, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> 
> 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.
>  
> How are IPsec SAs mapped to UDP pseudo-connections?  Is it a 1:1 mapping between SPI and source port?
> If now, how do you deal with the packet reordering that the load balancer will do? IPsec requires ordered or nearly-ordered delivery.
> How is this negotiated?  In IKE? Prior agreement?
> 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 <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 <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/ <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 <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 <https://www.ietf.org/mailman/listinfo/ipsec>