Hi Paul, My comment was only about using the next header field in ESP to identify the ESP payload. I believe we've already agreed to remove the zero-conf section as too controversial.
Tero, is suggesting that we should not use the next header field at all. That is what I don't understand. Thanks, Chris. > On Oct 15, 2020, at 4:06 PM, Paul Wouters <p...@nohats.ca> wrote: > > 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 >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
