Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]

["Valery Smyslov" <[e-mail]>]

> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >