> On Apr 27, 2017, at 7:09 AM, Tero Kivinen <kivi...@iki.fi> wrote: > >>>> 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.) > > I do not think it belongs to this document. This is not actually using > reserved SPIs, but I think it should be enough to see that there is a > way to extend this, but as we do not see the need for extension now, > we do not need to think how we are going to do it. There are other > ways of doing that extension also and everything depends what we > really want to do. > > Trying to guess things now is not really useful.
The reason I thought it might be worth mentioning it would be to help prevent people from heading down a wrong path in future extensions. I’m okay with leaving it out if people think the probability of it coming up is low. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec