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

[Paul Wouters <[e-mail]>]

On Fri, 16 Jul 2021, Bottorff, Paul wrote:

> Somehow I think we are mis-understanding. Please excuse the long introduction to answer your question.

I am also very confused.

> Consider an IPSEC initiator sitting behind a NAPT talking with an IPSEC responder on the Internet (within a DC).
>
> The initiator will start with IKE. The IKE packets will not be LB and since a NAPT would be detected, the IKE packets would use source and destination port 4500.

Just to clarify, on the initiator those source/dest ports will be 4500,
but on the responder the source port can be anything and the destination
port will be 4500.

> After IKE established the SA, load balancing will be used with ESPinUDP packet exchanges.
>
> Both the initiator and the responder can exchange ESPinUDP with LB after the SA is established.

Which SA? The initial IPsec SA ?

> For ESPinUDP with LB the source port will be used for entropy. This does not necessary mean the source port is random, however does mean the source port must cover a range of values sufficient to provide the required level of entropy. Draft-xu-ipsecme-esp-in-udp-lb does not provide specific guidance on entropy values, however for NAT interoperability it is desirable to limit the number of entropy values.

I think you are saying "pick a random port and keep using it" and not
"use a random port for each packet", right ?

> At an IPSEC initiator (behind NAPT) using draft-xu-ipsecme-esp-in-udp-lb will generate LB ESPinUDP packets with the entropy value in the source port and a new destination port

Where does this "new destination port" come from? You only have a NAT
mapping for port 500 and a NAT mapping for port 4500. Did a new
destination port get negotiated over IKE? I don't see that specified in
the draft. Or do you expect the non-NAT IPsec endpoint to auto-detect
these packets to random ports based on encap payload and SPI ?

> , however the use of a new port to designate LB complicates the situation. Instead, if we consider both ends of the SA being configured for LB, then we can simply use the existing 4500 port to designate the ESPinUDP encapsulation. Using this observation IPSEC LB packets transmitted from the initiator (behind the NAPT) would have entropy in the source port and 4500 in the destination port.

But when using only destination port 4500, then you run into the
problem of NAT mapping updates. If you send a ESPinUDP packet to
port 4500 from source port X, the peer will update its IPsec SA
endpoint and start sending all packets to that single source port.
So any entropy gain is lost.

> Each IPSEC initiator LB packet with a different entropy value will result in a new mapping at the NAPT.

Yes, a new mapping, but the old mapping will be deleted. Is your draft
saying we should _keep_ those mappings? If so, how would you ever detect
a _rela_ IKE/ESP port remapping from the NAPT router between the
endpoints?

> The normal behaviour of the responder (outside the NAPT) is to transmit to the destination address and port of the last packet source address and port (from the initiator)

Not without MOBIKE. And with MOBIKE this requires explicit signaling via
the INFORMATIONAL IKE message containing an UPDATE_ADDRESS payload.

> however this is where we deviate for a LB implementation. Instead the responder (outside the NAPT) transmits all responses to the address and port established for IKE, however with an entropy value in the source port. Since the NAPT has the IKE mapping this will deliver the ESPinUDP packet to the initiator where the destination port will be restored to 4500 and the source port will be the entropy value.

I don't see how this can properly work. It would be really helpful if
you can explain this with ASCII art in your draft document.

> So to your question about NAPT filtering. If the NAPT follows REQ-8 in RFC 4787, then filtering will pass the responder packets since the destination address and port will be mapped and the source address will also be known. In the event a NAPT violates REQ-8 and does Address and Port - Dependent Filtering then the responder packets might be filtered. There may be solutions for this case, however for the present discussion it does not seem worth pursuing the case were a NAPT violates REQ-8.

I still don't see how you avoid reducing everything to 1 NAT mapping on
the NAPT router, and thus with no extra entropy, as it seems multiple
different source IPs are racing with the regular endpoint NAT mapping
update. And if you change that behaviour to not update but keep the
old NAT mappings, you need to not only change the kernel behaviour,
you also need to signal whether this is supported through IKE, and
whether you want it activated. Eg you would need some _SUPPORTED notify
and then some USE_ notify.

Paul W