> > I envision a lively discussion with INT folks if we ask them for a "fake" > > protocol number :-) > > I would not choose to refer to it as a fake protocol. The field is defined as > an IPv4 or IPv6 protocol value to > identify the ESP payload. IPsec/ESP is *the* standard for encrypting IP > traffic so this field has a valid claim to > make on that number space. Just b/c it may not (but see next point) be used > outside of IPsec/ESP doesn't > mean that IPsec should not be able to allocate a number from it.
I meant that this IP protocol number will never be seen (and used) outside ESP. So, it's an ESP-only protocol number, thus for INT folks it's a "fake" one. > >> 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 IP-TFS payload format allows for any-sized IP packet to be encapsulated > inside an MTU sized outer > header. Thus something like a GRE tunnel (with sequence numbers) with PMTU > size-limited packets would not > limit the inner payload packet size to the PMTU of the GRE tunnel. I'm not > proposing this right now, but it's > not hard to envision this use in the future, especially if IP-TFS is widely > adopted by vendors. Ah, I see - you want to use the same technique inside some other tunneling protocol. This is doable, but in my opinion you should have control layer to set up such a tunnel (like IKEv2 does for ESP), and you'll probably have this tunnel dedicated to IP-TFS traffic only, and the peers would negotiate this feature over the control layer. So, new protocol number seems redundant in this case too. I can't buy this argument. > >> 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 :-) > > I do not think this is strange, consider uni-directional data streams, e.g., > telemetry. ESP SAs are always created in pairs. And whether IP-TFS is enabled or not is common for both SAs. Even if you use only one SA for IP-TFS traffic, the other will have IP-TFS enabled too. How are you going with your spec to create a pair of SAs where IP-TFS is enabled in one direction and disabled in the other? Am I missing something? Even if you are able to create such a pair of SAs, is it justified? > >>> 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. > > ICMP echo request/reply? :) It's not for debugging, it's for testing network connectivity. >From what's written in you draft I made a conclusion that you want to help >debugging implementations, that's completely different thing. > More apropos, adding things to a protocol to make it easier to deploy/debug > is not uncommon, we certainly > have examples of this in routing (e.g., host identifier TLV in IS-IS etc)... > > If this were the only reason for using the next header field I'd say the case > is not strong for keeping it, but we > still have the uni-directional CC case, so this second use doesn't cost much > IMO. Hmm, see above about uni-directional CC. Regards, Valery. > Thanks, > Chris. > > > > > Regards, > > Valery. > > > >> Thanks, > >> Chris.= > > > > _______________________________________________ > > 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
