Dan, I think the intent of that text was to read "non-UDP encapsulated" as "non-UDP encapsulated [ESP]". I.e., it is not saying you should support both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you should support UDP encapsulation for an ESP tunnel even if a NAT was not detected for that tunnel.
So it might be good to reword it to clarify, Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Dan McDonald <dan...@sun.com> To: ipsec@ietf.org Date: 01/08/2010 02:20 PM Subject: [IPsec] No UDP encapsulation with IKEv2 over port 4500? I read this sentence in IKEv2bis... If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. ... and thought of my own implementation. The background reading is here: http://blogs.sun.com/danmcd/entry/detangling_ipsec_nat_traversal_and Today, my implementation marks a port (a socket option to be precise) as a NAT-Traversal port. Traffic to this port that has the zero-SPI gets the zero-SPI stripped and the datagram passed to UDP like any other UDP datagram. If the SPI is non-zero, the UDP portion is stripped, and the packet is passed to ESP for lookup. If there's no SA, the packet is dropped like any other ESP packet with a bad SPI. The text above suggests that if I'm to build IKEv2 properly, I need to not drop these bad-SPI ESP-in-UDP packets (local-port == 4500), but instead pass them up as a UDP datagram without any strippage. Am I understanding this correctly? Or does the text need some more rewhacking? I'm not sure what problem 4500-with-no-encapsulation solves. If you use port 4500, you're most likely going to be doing ESP-in-UDP anyway, and will need the zero-SPI for IKE traffic anyway. And what if you hit that N-in-2^32 chance (where N is the number of inbound SAs) where the high 32-bits of the IKE SPI value is the same as some IPsec SA? Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
