On Fri, 8 Jan 2016, Valery Smyslov wrote:
Third, I haven’t tested this myself, so I may be all wrong here, but I
question the value of compression on IKE.
IKE is a binary protocol with mostly compact binary payloads. Even the
list of supported CAs is a list of hashes in IKEv2.
How much can compression help?
It depends on the particular content of the messages. Those payloads that
contain
random (or randomly-looking) data like Nonce, KE, most VIDs are almost
uncompressable.
However the content of SA payload contains so many zeroes that it can be
compressed
of up to 90%. So, if your IKE_SA_INIT's SA payload contains only a couple of
transforms,
the saving is minimal - about few tens of bytes. However if it contains a
long list of transforms,
then you could make initial message 30% or even twice as small comparing to
no compression.
But IoT devices would likely only suggest one or at most two transforms
anyway? Not a long list?
And IKE_AUTH messages often contains a certificates, that is usually
compressable by 30%.
I thought IoT devices did not even have the memory to do X.509, which is
why raw public keys were added to TLS ?
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
