IETF Logo Mail Archive

Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07

Antony Antony <antony.antony@secunet.com> Wed, 31 March 2021 10:32 UTC

Return-Path: <antony.antony@secunet.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 E38EA3A2381 for <ipsec@ietfa.amsl.com>; Wed, 31 Mar 2021 03:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fnGWtlEj2gcT for <ipsec@ietfa.amsl.com>; Wed, 31 Mar 2021 03:32:31 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DB73A237C for <ipsec@ietf.org>; Wed, 31 Mar 2021 03:32:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 195C0204B4; Wed, 31 Mar 2021 12:32:28 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZXv9BeGfw9N; Wed, 31 Mar 2021 12:32:27 +0200 (CEST)
Received: from cas-essen-01.secunet.de (unknown [10.53.40.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 40A1120185; Wed, 31 Mar 2021 12:32:27 +0200 (CEST)
Received: from mbx-essen-01.secunet.de (10.53.40.197) by cas-essen-01.secunet.de (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 31 Mar 2021 12:32:27 +0200
Received: from moon.secunet.de (172.18.26.121) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 31 Mar 2021 12:32:26 +0200
Date: Wed, 31 Mar 2021 12:32:20 +0200
From: Antony Antony <antony.antony@secunet.com>
To: "Bottorff, Paul" <paul.bottorff@hpe.com>, IPsec <ipsec@ietf.org>
CC: antony.antony@secunet.com
Message-ID: <20210331103220.GA21137@moon.secunet.de>
Reply-To: antony.antony@secunet.com
References: <CS1PR8401MB11928BE251D4B6E05184D941FE619@CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CS1PR8401MB11928BE251D4B6E05184D941FE619@CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM>
Precedence: first-class
Priority: normal
Organization: secunet
User-Agent: Mutt/1.10.1 (2018-07-13)
X-ClientProxiedBy: cas-essen-02.secunet.de (10.53.40.202) To mbx-essen-01.secunet.de (10.53.40.197)
X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/LeJF6lyWUKnGsKmFQvLrrMyFaqY>
Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 31 Mar 2021 10:32:34 -0000

Hi,

This is an interesting draft. I would love to see a generic
solution for network paths and receiver use cases, such as RSS.

The RFC3948 specifies one pair of UDP ports 4500-4500.
Both the IKE flow and the ESP in UDP flow should use the same UDP flow.
The draft seems to suggest new destination port and source ports are
only for ESP? How would this change work with IKE?
May you are not intending to use IKE?

How would the new ESP flow work when there is a NAT gateway along the path?
I ran into issues with both sides choosing different source ports.
It would cause SADB mapping changes which force changes IKE flows. One coul
disable SADB mapping changes. However, that would break real NAT changes.

Should both sides use the same source port? Or can each peer choose its
own source port independently? If both have to use the same port how do
peers negotiate on the ephemeral source port. I ran into issues with or
without NAT. Or do you disable SADB mapping completely?

When the source port is chosen independently the flow will be asymmetric.
The NAT gateway drops the ESP flow in one direction. A typical NAT gateway
only allows symmetric UDP flows. And this flow must be initiated from one
side, the side behind the NAT. So, I wonder how changing the source port
alone would work.

regards,
-antony

On Fri, Mar 26, 2021 at 18:07:37 +0000, Bottorff, Paul wrote:
>    Hi Xu:
> 
> 
>    We’ve got a lot of interest in your draft. Are you going to move this
>    forward to a working group draft and RFC? We would be happy to help
>    where needed.
> 
> 
>    Cheers,
> 
> 
>    Paul Bottorff
> 
>    Aruba a Hewlett Packard Enterprise Company

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



On Fri, Mar 26, 2021 at 18:07:37 +0000, Bottorff, Paul wrote:
>    Hi Xu:
> 
> 
>    We’ve got a lot of interest in your draft. Are you going to move this
>    forward to a working group draft and RFC? We would be happy to help
>    where needed.
> 
> 
>    Cheers,
> 
> 
>    Paul Bottorff
> 
>    Aruba a Hewlett Packard Enterprise Company

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

v2.23.0 | Report a Bug | By Email