Hi Tobias,
unless I missed something, I think USE_COMPRESSED_MODE notify is superfluous and is not needed. As far as I understand, you negotiate EHC parameters per IPsec SA basis, so if they are negotiated successfully, then compression is used for this SA. If you need separate SA for the traffic that cannot be compressed, then negotiate it separately without EHC_STRATEGY_SUPPORTED notification. You may create as many IPsec SAs with the same Traffic Selectors as you like. Am I missing something? Regards, Valery. From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tobias Guggemos Sent: Thursday, October 18, 2018 1:57 PM To: IPsecME WG Subject: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC) 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: <mailto:gugge...@nm.ifi.lmu.de> gugge...@nm.ifi.lmu.de Muenchner Netz-Management Team http://www.nm.ifi.lmu.de/~guggemos
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
