Hi Yoav,
First, the problem of IKE having too large packets in certain environments is a
real problem.
We’ve already addressed it with fragmentation, and the TCP encapsulation draft
proposes yet another way.
I don't think that compression is an alternative to TCP encapsulation. TCP encapsulation
is a "last resort"
and compression would just make the necessity to use this "last resort" less
frequent.
I think either of those can solve most of the bad router and noisy line issues. I also think that IKE is quite
low-volume
so the savings in number of bytes sent from, say, a mobile phone are not an issue. So the only scenario where
compression
may have value is for an IoT device working on a battery and/or using a
particularly slow network.
I think it could be useful even in "big world" (see above), but I agree that in "IoT world" the benefit would be more
substantial.
Second, as I understand it, those battery-powered devices tend to use 802.15.4
networks with 127-byte frames.
There’s 6LoWPAN to provide fragmentation support, but that’s similar to using
IKE’s fragmentation for the same issue.
Can anything be done at all with 127-byte frames, that include the (IPv6?)
headers, the 8-byte UDP header,
the 20-byte IKEv2 header in addition to all the payload headers? If we need fragmentation anyway, I don’t know if
compression matters.
I'm not familiar with 6LoWPAN, but isn't IKE independent from the transport?
I mean that IKE messages would be composed (and compressed) regardless of how
they are fragmented
by the lower level, wouldn't them?
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.
And IKE_AUTH messages often contains a certificates, that is usually
compressable by 30%.
Since certificates are large, you can save few hundreds of bytes even with a
short list
of transforms in IKE_AUTH messages.
I can provide more detailed information on next week.
Yoav
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
