> On Jan 11, 2016, at 8:19 AM, Tero Kivinen <kivi...@iki.fi> 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 > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
