Thanks Tobias for bringing this topic. I would rather go with option 2). As EHC is not guaranteed to work for every packets, when a SA using EHC is activated, the host may associate to that SA an alternate SA for traffic where EHC does not apply (SA*). In some case SA* will not be different from a standard SA and USE_COMPRESS could be seen as a way to indicate this is the alternate SA. If we want to specify that this is an alternate SA, maybe an explicit signalling such as a ALTERNATE_SA( SA_SPI ) notification may be considered.
The drawbacks I see in using EHC parameters while not activating EHC is that it would prevent the Alternate SA to still benefit some compression. More specifically, the inner packet may not be compatible with the EHC defined in the initial SA. However, the Alternate SA may for example benefit from the compression of ESP parameters... Yours, Daniel On Thu, Oct 18, 2018 at 6:57 AM Tobias Guggemos <[email protected]> wrote: > Hey all, > > > > ESP Header Compression (EHC, [1]) defines a set of rules how to compress > ESP for specific scenarios, e.g. IoT and [2] describes how to negotiate > this rules with IKEv2. > > Due to some suggestions we defined a new IPsec mode (COMPRESSION_MODE), > which is necessary in order to prevent decompression failures in certain > maybe unforeseen situation (e.g. IP fragmentation, or the use UDP options). > > > > With the new mode, the sender can decide to send certain packets > “uncompressed” if the receiver may not be able to decompress properly. The > sender notifies the receiver by using a different SA and thus a different > SPI. > > We believe this is more clean than defining something like a “compressed” > bit in the ESP packet.. > > > > That’s why we also thought about how to negotiate this new mode with IKEv2. > > We believe that a clean way to negotiate this new mode is with a new > Notify Payload, namely “USE_COMPRESSED_MODE”. > > The question is, do we need an explicit agreement of the COMPRESSED_MODE > or is the negotiation of using EHC [1] enough to figure out that the two > peers have to use COMPRESSED_MODE anyways? > > > > More specifically here are the following possibilities > > A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with > USE_COMPRESS_MODE the SA that compress payload (using EHC). The other SA * > *without** USE_COMPRESS_ MODE will not proceed to compression. In other > words, EHC is activated if and only if USE_COMPRESS_MODE is active for the > SA. > > B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes > compression is requested and one without EHC in which case no compression > is performed. > > > > During the last IETF we had a brief discussion in the meeting which we > would like to bring to the list now. > > We’re looking forward to any opinions or suggestions. > > > > Regards > > Tobias > > > > [1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 > > [2] > https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01 > > > > > > -- > > _ _ _ _ _ _ Tobias Guggemos M.Sc. > > |\/| |\ | |\/| Institut für Informatik / Dept. of CS > > | | | \| | | Ludwig-Maximilians-Universität München > > ======= TEAM ======= Oettingenstr.. 67, 80538 Munich, Germany > > Room E 010, Phone +49-89-2180-9209 > > Munich Network Management Team Email: [email protected] > > Muenchner Netz-Management Team http://www.nm.ifi.lmu.de/~guggemos > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
