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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
