Hi Tobias: Somehow I think we are mis-understanding. Please excuse the long introduction to answer your question.
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. 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. 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. 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, 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. Each IPSEC initiator LB packet with a different entropy value will result in a new mapping at the NAPT. 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), 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. 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. Cheers, Paul -----Original Message----- From: Tobias Brunner [mailto:tob...@strongswan.org] Sent: Thursday, July 15, 2021 11:52 PM To: Bottorff, Paul <paul.botto...@hpe.com>; Valery Smyslov <smyslov.i...@gmail.com>; 'Tero Kivinen' <kivi...@iki.fi>; antony.ant...@secunet.com; 'IPsec' <ipsec@ietf.org> Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Hi Paul, > The ports used for IKE packets would not be randomized since IKE would not > use source port for LB and so should be stable at the NAT. I was not referring to the IKE but the ESP packets sent by the responder to the natted IKE port for LB. Wasn't that what you were proposing? Regards, Tobias _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
