Hi Chris, > > 2. I don't think new IP protocol number is needed at all. Since SA is > > created with IKEv2, > > it is always known whether it is IPTFS SA or ordinary SA, so "Next > > Protocol" > > field in ESP trailer is redundant and can be filled in with arbitrary > > value (say zero). > > If a new protocol number is allocated, it will never appear in any > > network header > > except for encrypted ESP trailer, still it will occupy a codepoint and > > some middle-box > > vendors will probably try to figure out what to do with it (nothing), > > adding some confusion. > > Moreover, I suspect that an idea to allocate a codepoint from rather > > limited resource > > (only 255 are available and more than half of them is already > > allocated), that will never > > appear in any network header and in reality is not needed, will meet a > > negative reaction from > > INT area guys. So, I think we should not go this way and just use zero > > (or other value) > > as a filler for "Next Header" field. > > > I read part of the above as more an argument for decoupling the ESP next > header number from IP protocol > number space, and not so much as a lack of need for a unique payload > identifier for the ESP next header field. > This might work if we really want to do this (i.e., create an ESP payload > registry separate from the IP protocol > numbers), but honestly I think it may be overkill given there are plenty of > IP protocol numbers available, and > we only need 1 protocol number which we can re-use later if need be. You may > be right that 1/2 of the > numbers are allocated; however, at least one is deprecated and others could > be deprecated (i.e., there's so > little pressure on this registry that deprecating unused numbers just hasn't > been something worth doing > AFAICT). With all that this represents 38 years of allocations. I think we > just need to make a clear case for the > use, and that we wont keep coming back for more is all.
I envision a lively discussion with INT folks if we ask them for a "fake" protocol number :-) > Additionally, I'm not sure that we should be so quick to say that the IP-TFS > payload would never be used > outside of ESP; as was pointed out by Michael using this payload does solve > the PMTU issue with (IPsec) > tunnels, it could be re-used for this purpose outside of ESP as well. Please, elaborate. > The next-header value is not always redundant, the use case where IP-TFS is > enabled in only one direction > with congestion control enabled requires being able to differentiate IPv[46] > packets from IP-TFS CC > information which is now sent in-band in the return direction. The CC > information was moved in-band out of > IKEv2 from the original -00 document based on comments from the WG (and I > agree is a much better solution > :) It's a strange use case. Both peers must support IP-TFS, but it is used only in one direction, so its usefulness is limited (you can gain quite a lot information from timing of return packets). Do we really need to complicate things to allow such asymmetric use case? BTW, you cannot negotiate it with your current spec :-) > So, I think we need to stick with explicitly identifying the payload inside > ESP. Using the next-header field feels > like the correct way of doing this; however, I haven't looked at ESP wrap > yet. I do have concerns (which Tero > also mentioned at the mic) that it might not be widely implemented. > > Possibly re-using the payload type outside of ESP someday is an additional > argument for doing the least- > disruptive thing and just allocating an IP number. We don't even need a *new* > IP protocol number, we could > re-use a deprecated IP protocol number. This seems like a nice option to look > into. I'm still not sure that it's really needed. > > 7. I don't think that late-enabling of IP-TFS described in section 2.4 > > is really needed. It adds unnecessary complexity and somewhat contradicts > > to what is stated in section 2.3. > > Having the late-enable could be useful for debugging tunnels during bring-up. > This does rely on having a way > to identify the payload, but as mentioned above this isn't the only thing > that relies on that. It didn't add much > complexity to my code, but I'm certainly curious on other opinions on this. Color me unconvinced. Debugging is a local matter and should not be reflected in the spec. Regards, Valery. > Thanks, > Chris.= _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
