Bottorff, Paul writes: > The RFC3948 specifies one pair of UDP ports 4500-4500.
No it does not. It says you must use same ports than what you do for IKE traffic. > 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? The reason NAT-T uses same ports for both ESP and IKE is to make sure that responder will know the port mapping from the IKE packets for ESP packets too. If they would use different port numbers, then responder would need to wait for first ESP packet to come in from the initiator before it can send any ESP packets back, as it would be able to know which port numbers to use for ESP traffic. Also keepalives would be needed to do for both IKE and ESP separately. > 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. > << As there is no way for the responder to know whether the initiator sent the packet out using source port of 4500 and then NAT changed it to port number of xxxx, or whether the initiator sent the packet out using port number of xxxx himself, the RFC7296 do require that responder MUST accept incoming packets regardless of the source port, and MUST always respond back to exactly same IP and port than what was in the source packet of the request: >From the 2.11 of the RFC7296: An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. There is text in 2.23 of the RFC7296 which do say: For this reason, even though IKE packets MUST be sent to and from UDP port 500 or 4500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. Which is bit funny, as the "even though" claims that IKE packets must be sent to and from UDP port 500 or 4500, and there is no such claim anywhere else in the RFC7296. I think it was supposed to say that "even though IKE packets are normally sent ...", as this is not correct place to make this kind of new requirement. So making IKE implementation which uses some other source port than 500 or 4500 is common way to force NAT-T traversal and UDP encapsulation on, and in that way allow user mode IKE + IPsec to be implemented without affecting the in kernel version of the IPsec in the host. I.e., user mode application wanting to use IPsec in usermode without affecting host IPsec in any ways can use any random port as source port and port 4500 as the destination port, and make sure that NAT_DETECTION_SOURCE_IP does not match, so responder will enable udp encapsulation. The responder MUST work even with that setup, so there is no reason why there should be requirement for the oritinal sender should be mandated to use source port 4500... > 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? For the load balancing I think it is enough for just one of the ports to be different, thus initiator could simply allocate n random source port numbers, and initiate IKE from each of them to responder, and then create SAs for each of them separately, thus allowing load balancing using UDP encapsulation using existing hardware. The real issue is that if you do not want to create n separate IKE SAs, then you need to do something special, and there are other things that needs to be considered then. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec