On Wed, 13 Jan 2016, Valery Smyslov wrote:
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.
This seems like a very unclear use case. More of a hypothetical use case.
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.
And that is a use case for something not even in the specification.
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.
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.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
