Subject: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC)

From: "Tobias Guggemos" <[email-masked]>
Date: Thu, 18 Oct 2018 12:56:44 +0200

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-masked] <mailto:[email-masked]>   

Muenchner Netz-Management Team   http://www.nm.ifi.lmu.de/~guggemos

---

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Oct 2018 08:48:16 -0400

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-masked]>
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..
>
>
>
> 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?
>
>
>
> 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.
>
>
>
> [2]
> https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01
>
>
>
>
>
> --
>
> Munich Network Management Team   Email: [email-masked]
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Wouters <[email-masked]>
Date: Sat, 20 Oct 2018 08:15:57 -0400 (EDT)

On Thu, 18 Oct 2018, Tobias Guggemos wrote:

> 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..

I really don't like either option. I was hoping we could get rid of
IPCOMP, not make it even more complex with other different kinds of
complicated compressions that take up more then a single IPsec SA.

> 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.
> 

I'm not sure I like either.

Tero, can be discuss this at the meeting?

Paul

---

From: "Tobias Guggemos" <[email-masked]>
Date: Tue, 23 Oct 2018 08:14:58 +0200

Hey Paul,
thanks for sharing your thoughts. 
The major issue behind is, what can we do if the sender recognizes something the receiver is not able to decompress.
One example of such are UDP options, which could appear without being "agreed" on during the IKE exchange. https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-05
The options basically use the UDP Length to indicate an UDP options trailer, so if we would compress the length field, we would lose the information about the size of the user data.

What we propose is a "regular" SA, which can either be agreed during the initial exchange or simply upon necessity (e.g. when the first uncompressible packet appears). 
This allows us to use the SPI as an identifier for compressed and uncompressed packets. 

Obviously, the "rude" option would be just to discard the outgoing packet as it mismatches the SA, but that seemed not to be a good way of handling it (maybe there are other opinions on that?)

In order to be efficient, EHC is meant to be used in settings where an SA is restricted to (in the best case) one specific connection (e.g. IP-address + ports set to be unique on both sides), this is why I anyway assume that there might be another SA for packets not fitting this particular use case which can be used as a fallback.

Any thoughts?

Tobias

> -----Ursprüngliche Nachricht-----
> Von: IPsec <[email-masked]> Im Auftrag von Paul Wouters
> Gesendet: Samstag, 20. Oktober 2018 14:16
> An: Tobias Guggemos <[email-masked]>
> Cc: IPsecME WG <[email-masked]>
> Betreff: Re: [IPsec] Proposals for IPsec Compression Mode for ESP Header
> Compression (EHC)
> 
> sender notifies the receiver by using a different SA and thus a different SPI.
> >
> I really don't like either option. I was hoping we could get rid of IPCOMP, not
> make it even more complex with other different kinds of complicated
> compressions that take up more then a single IPsec SA.
> 
> > 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.
> >
> compression is requested and one without EHC in which case no compression is
> performed.
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Oct 2018 11:42:05 +0300

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:[email-masked]] 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,

Regards

Tobias

 

-- 

Munich Network Management Team   Email:  <mailto:[email-masked]> [email-masked]

---

From: "Tobias Guggemos" <[email-masked]>
Date: Sat, 27 Oct 2018 11:31:48 +0200

Hey Valery,

Thanks for your thoughts.

The idea was to keep the notification of the support of compression separated from the notification how the compression is actually performed.

However, you’re perfectly right, it is not necessary and I’m perfectly fine with not defining this new notify payload for IKEv2.

Regards

Tobias

Von: Valery Smyslov <[email-masked]> 
Gesendet: Donnerstag, 25. Oktober 2018 10:42
An: 'Tobias Guggemos' <[email-masked]>; 'IPsecME WG' <[email-masked]>
Betreff: RE: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC)

Hi Tobias,

Regards,

Valery.

From: IPsec [mailto:[email-masked] <mailto:[email-masked]> ] 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,

Regards

Tobias

[1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 <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 <https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01> 

-- 

Muenchner Netz-Management Team   http://www.nm.ifi.lmu.de/~guggemos <http://www.nm.ifi.lmu.de/~guggemos>