Ben Campbell writes: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive Comments: > > -3, first paragraph: > Are people confident there will never, ever be a need to demux protocols > other than IKE and ESP? If not, this approach may paint people in a > corner in the future. I ask because we made similar choices with > DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. > See RFC7983 for a discussion. (Note that this would have been a DISCUSS > point, but I think it's reasonably likely that there really won't be > other protocols here. But I want to make sure people have thought about > it.)
If we ever want to run other protocols there, we still have 255 reserved values we can use as Non-ESP marker. The reason the 0x00000000 is selected as Non-ESP marker in the UDP encapsulation (and here) is because first four octets of the ESP packet are SPI, and SPI MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by the Internet Assigned Numbers Authority (IANA) for future use" in the RFC4303. So if we need to run something else than IKE and ESP over that tunnel we just reserve one of the other reserved IANA numbers for it and use it as protocol marker for this new protocol. > -3.2, " The SPI field in the ESP header MUST NOT be a zero value." > Is this a new requirement for this draft? That is, does ESP otherwise > allow zero value SPIs? If not, please consider dropping the MUST NOT. RFC4303 reserves value zero for the "for local, implementation-specific use and MUST NOT be sent on the wire.". I.e., conforming ESP packet coming the to the UDP or TCP encapsulation layer cannot have SPI of zero ever. And we are not using SPI zero, we are using it as marker that this is not ESP packet, but this is IKE packet. The full text from the RFC4303 about the reserved SPI numbers is: ---------------------------------------------------------------------- 2.1. Security Parameters Index (SPI) ... The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.) -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
