Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

[Tommy Pauly <[e-mail]>]

> On Jan 11, 2016, at 8:19 AM, Tero Kivinen <[e-mail]> wrote:
> 
> Yoav Nir writes:
>> 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. 
> 
> 802.15.4 networks also have 802.15.9, which will provide its own
> fragmentation and reassembly for the IKEv2 frames (not including IP or
> UDP headers, as those are not used, this is raw IKEv2 frames over raw
> 802.15.4 frames).
> 
> 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. 

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.

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.

Thanks,
Tommy

> -- 
> [e-mail]
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec