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 -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
