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

[Paul Wouters <[e-mail]>]

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

> Hi Paul:
>
> Below,
>
> Cheers,

The below did not clear things up for me. I think it would be useful to
describe things in the draft much more carefully and details with some
ascii art.

Paul

> Paul
>
> -----Original Message-----
> From: Paul Wouters [mailto:[e-mail]]
> Sent: Friday, July 16, 2021 12:46 PM
> To: Bottorff, Paul <[e-mail]>
> Cc: Tobias Brunner <[e-mail]>; Valery Smyslov <[e-mail]>; 'Tero Kivinen' <[e-mail]>; [e-mail]; 'IPsec' <[e-mail]>; Mahendra Maddur Puttaswamy <[e-mail]>; Shraddha Hegde <[e-mail]>; 徐小虎 <[e-mail]>
> Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
>
> 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.
>
> PB>No, on the responder the destination port is not 4500, but is the source port received from the initiator. The reason for this is the NAPT translated the source port of the initiator IKE packet and to reverse the mapping as the responder sends to the initiator it must use the port mapped by the NAPT as the destination. This port will be translated back to 4500 by the NAPT before it is delivered to the initiator behind the NAPT.
>
>> 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 ?
>
> PB>More precisely, pick a range of ports for use as entropy code points and use them by mapping the flows of the packets within the ESP to them. The source port picked is not really random since for LB to work properly we must retain flow integrity. Typically the port would be determined by a hash of the packet now encrypted with as an ESP. Also we can't choose a single port for entropy since the objective is to use the source port for spreading traffic over multiple paths. What I am saying is that for most applications we can choose (preferably contiguous) a port range (which might be as small as 2 ports or as large as 256 ports) which would be used for LB. The choise of these ports would then depend on the hash function applied to inside packet before ESP.
>
>> 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 ?
>
> PB>The new source port is proposed by draft-xu-ipsecme-esp-in-udp-lb and is to be obtained from IANA. This is a point of disagreement between myself and the authors of draft-xu-ipsecme-esp-in-udp-lb which I describe in a little more detail as follows.
>
>> , 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.
>
> PB>We are in agreement here. What I am proposing is that this IPSEC behaviour (dynamic updating) needs to change to support LB through NAT. To support IPSEC LB through NAPT. For LB the IPsec SA endpoint needs to NOT update its end point, but instead use the end point established for IKE.
>
>> 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?
>
> PB>The mappings generated by ESPinUDP with LB don't need to be preserved, only the IKE mapping needs to be preserved. Since IKE used a different source port (4500) from the ESPinUDP LB packets these should appear at different non-overlapping translations.
>
>> 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.
>
> PB>I not certain we disagree since this is a matter of frame of reference. The initiator will always see the same destination port and addresses.
>
>> 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.
>
> PB>I have not put forward any draft on this topic, because my use case does not have any need for NAT. See draft-bottorff-ipsecme-mtdcuc-psec-lb. The only reason I bring it up is that NAT was raised as an issue in the previous email thread on draft-xu-ipsecme-esp-in-udp-lb. My only intent is to suggest that there probably is a way to solve NAPT traversal combined with LB.
>
>> 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
>