> On Oct 14, 2020, at 6:19 AM, Tero Kivinen <kivi...@iki.fi> 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 > -- > kivi...@iki.fi >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
