Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

["Valery Smyslov" <[e-mail]>]

Hi Tommy,

>> In those environments the IKEv2 is used to negotiate link keys between
>> two devices. The payloads are already quite compacted, i.e. there will
>> not be several proposals for ciphers, only one, and all extra payloads
>> are omitted anyways.
>
> Tero’s comments seem to confirm the idea that constrained devices will generally
> be using a small set of proposals, and thus do not need compression.

Well, I'm not an expert in IoT devices. And it's true that with minimal set of transforms
and with reduced number of supported features the compression won't help much in IKEv2.
However, I'm a bit afraid of oversimplifying the whole picture. It seems to me that
there may be different kinds of constrained devices, and some of them would
be more advanced, then the most restricted ones. And I think that the IoT world
won't be isolated, so that at least some of the IoT devices would have to communicate
with the "big world" peers and thus would have to support more IKEv2 features and extensions,
that would make their messages larger. And for those devices the compression could be useful.

> The document referred to in the draft as IPSEC-IOT-REQS, draft-mglt-6lo-diet-esp-requirements-01,
> recommends essentially one algorithm for the Child SA algorithm (AES-CCM),
> so it may be safe to assume that IoT devices could converge to a small set of IKE SA algorithms
> to standardly use. And, while this document does recommend compression for ESP packets,
> I can see more of an argument being made for compressing ESP traffic (which may be many packets)
> than for compressing the IKE_SA_INIT packet, which is already a one-time-cost small packet.

The compression draft is not only about the IKE_SA_INIT messages. It also allows the subsequent
messages to be compressed. While the IKE_AUTH is also one-time message, I can imagine
that some restricted devices could use IKE SA to transmit application data (it can appear to be easier
than to implement ESP). In this case the compression would be useful too.

> Valery, do you have specific real-world examples of IKE_SA_INIT packets that are being used
> by IoT devices that get a benefit from this compression? Without this, it seems that adding
> compression to IKE would add a fair amount of complexity to optimize a packet that is already
> fairly inexpensive to send.

As I've already said I'm not an expert in the IoT world. And I still think that the compression can
also be used in a "big world". It would allow to keep the IKE_SA_INIT message size bounded
when more features are added into the protocol. And I don't see it as an alternative to
TCP encapsulation. As you wrote in the TCP encapsulation draft it has a number of issues
(for example TCP in TCP) and thus it should be considered as a "last resort". Compression
would make those occasions when TCP encapsulation is needed more rare,
when it is _really_ needed (e.g. when UDP traffic is blocked). Sure compression cannot
replace TCP encapsulation.

And here some data from my experiments with compression
of the IKEv2 messages using DEFLATE algorithm:

1. IKE_SA_INIT, single transform of each type:

HDR,
 SA[48]{
   P[44]{
    Encryption=AES-CBC {KeyLen=128},
    PRF=SHA1-HMAC,
    Integrity=SHA1-HMAC96,
    Group=MODP-1536}},
  NONCE[36],
  KE[200](MODP-1536),
  N[28](NAT_DETECTION_SOURCE_IP),
  N[28](NAT_DETECTION_DESTINATION_IP),
  N[8](IKEV2_FRAGMENTATION_SUPPORTED),
  N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512},
  N[8](REDIRECT_SUPPORTED),
  VID[26]

In this case using compression results in roughly the same message size
(you can save or loose a few bytes).

2. IKE_SA_INIT, multiple transforms of each type:

HDR,
  SA[264]{
   P[104]{
    Encryption=AES-CBC {KeyLen=256}, AES-CBC {KeyLen=128},
    PRF=SHA2.256-HMAC, SHA2.384-HMAC, SHA2.512-HMAC,
    Integrity=SHA2.256-HMAC128, SHA2.384-HMAC192, SHA2.512-HMAC256,
    Group=ECP-256, ECP-384, ECP-521},
   P[84]{
    Encryption=AES-CBC {KeyLen=128}, 3DES-CBC,
    PRF=SHA1-HMAC, SHA2.256-HMAC,
    Integrity=SHA1-HMAC96, SHA2.256-HMAC128,
    Group=MODP-1024, ECP-224, ECP-256},
   P[72]{
    Encryption=DES-CBC,
    PRF=SHA1-HMAC, MD5-HMAC,
    Integrity=SHA1-HMAC96, MD5-HMAC96,
    Group=MODP-1024, MODP-768, ECP-192}},
  NONCE[36],
  KE[72](ECP-256),
  N[28](NAT_DETECTION_SOURCE_IP),
  N[28](NAT_DETECTION_DESTINATION_IP),
  N[8](IKEV2_FRAGMENTATION_SUPPORTED),
  N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512},
  N[8](REDIRECT_SUPPORTED),
  VID[26]

In this case using compressions results in saving of ~150 bytes out of initial ~530 bytes (~30%).

3. IKE_AUTH with certificate, single proposal of each type, simple traffic selectors:

HDR,
 SK[1720]{
  IDi[63](DN),
  CERT[1167](X.509 Cert),
  CERTREQ[45](X.509 Cert),
  IDr[38](DN),
  AUTH[150](Sig){sha1RSA[13]},
  N[8](INITIAL_CONTACT),
  N[8](IKEV2_MESSAGE_ID_SYNC_SUPPORTED),
  N[12](SET_WINDOW_SIZE),
  CP[16](REQUEST),
  SA[44]{
   P[40]{
    Encryption=AES-CBC {KeyLen=128},
    Integrity=SHA1-HMAC96,
    ESN=Off}},
  TSi[40],
  TSr[40],
  N[8](ESP_TFC_PADDING_NOT_SUPPORTED),
  N[8](NON_FIRST_FRAGMENTS_ALSO),
  N[28](QCD_TOKEN),
  N[8](TICKET_REQUEST)}

In this case using compression results in saving ~350 bytes out of ~1750 (~20%).
In this particular example the resulting message would become ~1400 bytes, that
would avoid IP fragmentation in most cases (and thus avoid using IKE fragmentation).
Using compression here would be more effective if more transforms are included
in the SA payload, more attributes are requested in the CP payload or more complex
traffic selectors are included.

> Thanks,
> Tommy

Regards,
Valery.