On Wed, 14 Oct 2020, Christian Hopps wrote:
I really don't understand the extreme back pressure against using ESP the way
it was designed. The next-header field is supposed to identify the payload, it
does so for every other
payload ESP carries. Any other solution to somehow infer the payload type some
other way *has* to be seen as a hack. Why do we need a hack?
The fact that using a payload identifier the way ESP intended also allows us to
do things like handle receipt of said payload without extra configuration, or
use the payload outside
of ESP are just benefits from good design, they aren't indicative of doing
something incorrectly, the opposite in fact. They also shouldn't even be needed
to justify using ESP the
way it was designed to be used.
This is all very strange to me, this want to not use the next-header field to,
you know, identify the next header.
I see it as a useful feature that I can "enable" IPTFS on my existing
IPsec connection dynamically. Perhaps to avoid always sending traffic
when I have none, and mostly wanting my decoy traffic when I am doing
things (like typing over ssh, sending an email, etc)
I don't see how this would happen "automatically". It would be a user
invoked event.
Based on that, userland has to somehow trigger to kernel to switch from
regular ESP to IPTFS. We would need to define that (eg via Netlink or
PF_KEY).
But why not use a NOTIFY with a REKEY event to USE_IPTFS ? No need for
new PF_KEY/netlink messages, no new userland <-> kernel signaling. Just
use existing implemented IKE/IPsec protocols.
So I think I agree with Valery (and Tero). It is not really about what
the ESP packet format can or cannot do, but using existing channels for
on-the-fly reconfiguration. It would work the same as if you wanted to
switch a transport mode to tunnel mode or IPCOMP, rekey with(out)
USE_TRANSPORT or USE_IPCOMP.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
