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

From: "Bottorff, Paul" <[email-masked]>
Date: Fri, 26 Mar 2021 18:07:37 +0000

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

---

From: Antony Antony <[email-masked]>
Date: Wed, 31 Mar 2021 12:32:20 +0200

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
> 

> _______________________________________________
> IPsec mailing list
> [email-masked]
> 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
> 

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Bottorff, Paul" <[email-masked]>
Date: Wed, 31 Mar 2021 23:38:01 +0000

Hi Antony:

Below,

Cheers,

Paul

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Antony Antony
Sent: Wednesday, March 31, 2021 3:32 AM
To: Bottorff, Paul <[email-masked]>; IPsec <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07

Hi,

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

PB>> Can you explain your use case for RSS a little more? I'd guess you are looking at LB around the RSS queues to get better distribution for the decodes.
<<

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?

PB>>Our use cases use IKE, however as stated in RFC3948 ESPinUDP does not have to be tied to IKE, it is just advantageous to do so for the NAT case since this allows a single mapping for both at the NAT rather than two mappings.
PB>>I've wondered why we could not use the RFC3948 encoding for ESPinUDP, but allow the source port to be chosen differently than IKE. Perhaps Xu has some thoughts on this. 
<<

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.

PB>>We are mostly interested in data centre use cases which don't have intervening NATs, however I believe SD-WAN cases could have NAT and FW traversals between tunnel end points. As it stands draft-xu-ipsecme-esp-in-udp-lb does not specify how the source port value is determined. It seems like it could be based on a hash value within the ESP or based on the SPI and IPs.
<<

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

> INVALID URI REMOVED
> man_listinfo_ipsec&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=CCwOcKkISkWxd8Y
> my11M8VW3U6Peq8aJ_DDlgVbQW5E&m=JX7bpCQ1LIaZ00nq77roZTAocRKYbZN5xrZg1Tz
> h2NI&s=6atEv9EBVlm0kUTnUkms-8dETilNOS_OnjeAFn_MGkc&e=

> INVALID URI REMOVED
> man_listinfo_ipsec&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=CCwOcKkISkWxd8Y
> my11M8VW3U6Peq8aJ_DDlgVbQW5E&m=JX7bpCQ1LIaZ00nq77roZTAocRKYbZN5xrZg1Tz
> h2NI&s=6atEv9EBVlm0kUTnUkms-8dETilNOS_OnjeAFn_MGkc&e=