> On Apr 26, 2017, at 6:06 AM, Tero Kivinen <kivi...@iki.fi> wrote: > > 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.
Ah, I didn’t realize 1-255 were reserved. It might be worth a mention that if future protocols are added, their prefixes must be registered with IANA. (I note that 2 are registered already.) Am I correct to assume the draft did not also add a prefix for ESP is due to performance reasons? Doing so would completely avoid any possible collisions between the prefix value and the SPI. > >> -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.) Got it. I propose the following: OLD: The SPI field in the ESP header MUST NOT be a zero value.” NEW: [RFC4303] forbids a value of zero in the SPI field. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
