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

[Tero Kivinen <[e-mail]>]

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?

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. 

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