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.
I thought Tommy had data that showed that IKE fragmentation is not
an issue. If UDP flows then IKE fragmentation works too. It is only
when udp is blocked that TCP was needed.
The IKE_SA_INIT message size is an issue here. If it is too long
then IKE fragmentation won't help (it starts working from the IKE_AUTH).
In this case if crippled NAT box is in between the peers would
be unable to complete the IKE_SA_INIT exchange and would
switch to TCP encapsulation. If the IKE_SA_INITmessage
were smaller, they could have completed the IKE_SA_INIT
and then would have communicated using UDP without suffering
from TCP encapsulation issues.
I'm still not really convinced this is much of a gain compared to the
added complexity on the protocol.
The only real use case I've heard so far is "less bytes is less
battery", but still find it weak as the newly setup IPsec tunnel
is going to get used and send more bytes.
IPsec tunnels can use IPcomp too, as recommended for the
low-power consumption devices.
Paul
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
