On Tue, Jun 02, 2020 at 11:56:48AM -0400, Christian Hopps wrote: > > On Jun 2, 2020, at 10:21 AM, Tero Kivinen <kivi...@iki.fi> wrote: > > Christian Hopps writes: > > > I would assume those questions are going to be asked from chairs or > > area directors during the process anyways, so we need to have good > > answers to them ready (and for me it would be quite hard to explain > > why we cannot use warpped ESP, or dummy packet trick as I think we can > > do those and we do not need IP protocol number). > > > > Note, that if the answer is going to be that we want to use this also > > when we are not using IPsec, then this is even bigger can of worms, as > > that would most likely mean that this work does not belong to the > > IPsecME working group, but should be part of completely different > > area... > > As I mentioned above, people have already expressed interest in possibly > using the IPTFS framing outside of IPsec for some of its positive non-IPsec > properties. This doesn't mean we have to boil the ocean and standardize the > framing outside of IPsec, it just means we should be considerate about the > possible re-use while we do our work.
I'm one of those who was interested in a different usecase for the IPTFS payload. My plan was to present about that at the Linux IPsec workshop this year. Unfortunately, this workshop was canceled because of COVID-19 outbreak, so I never got feedback about the idea. Below is the Abstract of this presentation that sketches the idea (just for the case somebody finds it usefull). - An alternative usecase for IPTFS_PROTOCOL payload type tunnels. This alterative usecase tries to solve the 'small packet' tunneling problem. Sending small packets over a tunnel usually creates quite a lot of overhead, as each packet needs to get it's own tunnel header etc. For IPsec, the situation is even worse as a cpu intensive crypto operation has to be applied for each of these small packets. With the IPTFS_PROTOCOL payload type, we could group small packets and send them into one big packet over the tunnel. This can avoid tunneling overhead because we need only one tunnel header for multiple packets. Also this method would be very data and instruction cache effective because multiple packets are processed together. The good thing is that the Linux forwarding path can already provide packets chains (GRO), so we would just need to take these packets chains and put them into big tunnel packets with IPTFS_PROTOCOL payload type. As a side effect, having IPTFS_PROTOCOL as a general purpose tunnel payload, it might be easier to argue for a new IP protocol number allocation. Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
