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

[Christian Hopps <[e-mail]>]

> On Oct 14, 2020, at 6:19 AM, Tero Kivinen <[e-mail]> wrote:
> 
> Christian Hopps writes:
>> What is intended is that an implementation can process inbound IPTFS
>> payloads w/o actually explicitly configuring the inbound SA to be in
>> "IPTFS-mode" (zero-conf). That is all.
> 
> And if IKE is used what is the use case for that?

The text Lou and Valery ended up with indicated this was not used in the IKE case.

> IKE allows easy way of agreeing on the set of parameters for each
> IPsec SA, and agreeing on the mode of the encapsulation is one thing
> it already does. It does negotiate whether the IPsec SA is in tunnel
> or transport mode, and for my view the IPTFS is just one more mode for
> that, i.e., something that can be negotiated when IPsec SA is created
> using IKE, and then that encapsulation mode is used. There is no need
> to know or do that per packet basis.
> 
> In theory in recipient we could detect tunnel mode by looking at the
> next header field of the inner packet, and if we see it is IP inside
> the packet, then we would assume it is tunnel mode, and enable tunnel
> mode processing. We do not do that, we do negotiate whether the IPsec
> SA is tunnel or transport mode and create IPsec SA either in tunnel or
> in transport mode.
> 
> Earlier there was also another encapsuluation mode called a Bound
> End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and
> in that case it would have been impossible to detect the mode from the
> incoming packet, as lots of the information needed to reconstruct the
> end to end IP header is stored in the SA.
> 
> Anyways we do store things in the IPsec SA when we create them, we do
> have negotiation mechanism to agree on those parameters and we can use
> them, we do not need to process things per packet basis.

Are you saying that the next-header field is useless then? I mean the code I've worked on parses the next header field on a per packet basis to handle the inner packet payload. I'm not interested in trying to redesign ESP with IPTFS, just use it as provided.

Thanks,
Chris.

> 
> [1] https://tools.ietf.org/html/draft-nikander-esp-beet-mode-09
> --
> [e-mail]
>