Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

[Christian Hopps <[e-mail]>]

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 <[e-mail]> 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
>