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

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 5 Jan 2016 13:58:39 +0300

Hi Paul, 

thank you for your comments.

> This draft makes me nervous, as compression has been removed from
> encryption specifications in the last few years. 

As far as I know IPcomp isn't deprecated, is it?

If you mean TLS, then as far as I understand the compression-related attacks
on TLS rely on an ability for an attacker to insert specific data into the
encrypted (and compressed) stream that contains secret information
(e.g. password). I don't think it's relevant to IKE and it is discussed
in the Security Considerations section.

> I find the security
> considerations also weak on this. It basically says "if you think
> compression might be security issue, don't use it". Which isn't helpful
> at all to implementors.

Not really. It says that basically using compression in IKE should be safe.
However, IF you transfer secret information inside an IKE SA and 
IF some part of the IKE messages originates outside IKE,
then you are probably at risk. This could happen in case of 
EAP authentication using weak EAP methods that transfer 
passwords in clear. Note, that RFC 7296 strongly discourage
using such methods.

Note, that this is -00 draft and the security considerations
are currently very basic. What do you think should be added there?

> I am also worried about the security of maliciously compressed payloads,
> eg a zillion 0's, and other corner cases such as AUTH-NULL clients.

In this case either the decompressor or the message parser will return an error.
Note that malicious peer could send zillion 0's even without using compression.
A robust implementation should handle such cases.

But I think it's a good idea to mention this in the security considerations.

> I'm also not yet very convinced about the use case. For instance, the
> mentioned explosion of algorithms supported causing big IKE_INIT packets
> seems very unlikely for IoT devices which most likely only support 1 or
> 2 algorithms anyway.

These are two different use cases. For IoT devices the primary benefit 
is the decrease of the power consumption. For the others the primary
benefit is avoiding of an IP fragmentation of the IKE_SA_INIT messages
and making IKE Fragmentation less likeky for the rest messages.

> Note I'm not strongly against it. I just need more convincing.

I'm trying to convince :-)

> Paul

Regards,
Valery.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 05 Jan 2016 09:16:53 -0800

> As far as I know IPcomp isn't deprecated, is it?

No, but that's not what PaulW said.

> in the Security Considerations section.

No one considered it relevant to TLS until researchers discovered the 
problems there. I think that's PaulW's point, and one that I agree with.

> However, IF you transfer secret information inside an IKE SA and IF 
> some part of the IKE messages originates outside IKE,
> then you are probably at risk. This could happen in case of EAP 
> authentication using weak EAP methods that transfer passwords in 
> clear. Note, that RFC 7296 strongly discourage
> using such methods.
>

That seems like a premature question. We haven't even decided if the 
idea of compressing IKE would give the benefits listed, whether the 
computational cost match the space benefits, and thus should be 
considered at all.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Jan 2016 12:48:07 -0500 (EST)

> No, but that's not what PaulW said.

Indeed, although I would like to deprecate it. It is basically never
used by our users that I'm aware of and it adds code complexity.

> problems there. I think that's PaulW's point, and one that I agree with.

Yes. Which is why I wanted to hear more convincing arguments to justify it.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jan 2016 22:08:03 +0200

Hi, Valery.

Thank you for this draft. Having read it, I have some comments.

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 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.

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.

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?

Yoav

> On 25 Dec 2015, at 2:18 PM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi,
> 
> I've posted a new draft on using compression in IKEv2.
> Comments, thoughts, criticism are very very welcome.
> 
> Regards,
> Valery Smyslov.
> 
> 
>> A new version of I-D, draft-smyslov-ipsecme-ikev2-compression-00.txt
>> has been successfully submitted by Valery Smyslov and posted to the
>> IETF repository.
>> Name: draft-smyslov-ipsecme-ikev2-compression
>> Revision: 00
>> Title: Compression in the Internet Key Exchange Protocol Version 2 (IKEv2)
>> Document date: 2015-12-25
>> Group: Individual Submission
>> Pages: 17
>> URL:            https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-compression-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compression/
>> Htmlized:       https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-compression-00
>> Abstract:
>>  This document describes a method for reducing the size of IKEv2
>>  messages by means of lossless compression.  Making IKEv2 messages
>>  smaller is desirable for low power consumption battery powered IoT
>>  devices.  It also helps avoid IP fragmentation of IKEv2 messages.
>>  This document describes how compression is negotiated maintaining
>>  backward compatibility and how it is used in IKEv2.
>>                                                                                 Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 8 Jan 2016 13:01:57 +0300

Hi Paul, 

> problems there. I think that's PaulW's point, and one that I agree with.

IETF develops standards based on the best current knowledge.
For example today AES is considered secure, but there is a non-zero
probability that it'll be broken tomorrow. Shouldn't then we use it today?

Coming back to compression. As far as I understand compression per se was not a problem
in TLS. The problem was that TLS mixed up secret information with user-provided
data and compressed it all together. The decision was to remove compression
from TLS (transport) and to move it to application level, because application does know
what is safe to compress and what is not. 

In case of IKE, IKE *is* an application. It shouldn't transfer any data that was
originated outside IKE. It does know what kind of data it transfers.
Moreover, no secret information is transferred in IKE SA. Some of information
is sensitive (like peers identities), but no passwords or keys are transferred.

Taking all these into considerations I think it is possible to use compression
in IKE without degrading its security. Of course there is no gurantee that 
tomorrow all these consideration become wrong, but this could happen
with almost any security primitive IKE uses today.

> computational cost match the space benefits, and thus should be 

We couldn't decide if this idea is worth to use if we don't analyse
its security as deep as we can. I think that any new text in the 
security considerations section will help us to make a right decision.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 8 Jan 2016 13:56:22 +0300

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.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Jan 2016 10:29:58 -0500 (EST)

On Fri, 8 Jan 2016, Valery Smyslov wrote:

>>  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.

But IoT devices would likely only suggest one or at most two transforms
anyway? Not a long list?

> And IKE_AUTH messages often contains a certificates, that is usually 

I thought IoT devices did not even have the memory to do X.509, which is
why raw public keys were added to TLS ?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 9 Jan 2016 12:27:16 +0300

> But IoT devices would likely only suggest one or at most two transforms

As far as I understand for some lower power consumption systems even small reduction 
of message is significant. For example see the following: 
https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY

> why raw public keys were added to TLS ?

I don't think raw public keys cover all use cases. The IoT device could present
its own certificate even if it cannot process the peer's one. And even without
certificates the IKE_AUTH messages contain some redundancy to compress.

Regards,
Valery.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 09 Jan 2016 08:58:28 -0800

<co-chair hat on>

This seems like a lot of guessing about what IoT devices want, 
specifically how they would handle tradeoffs of code complexity, CPU 
usage, and message size. If this WG offers an extension that is "for 
IoT", there will be a tendency to use it even in places where it might 
actually make things worse, so we really should be careful about 
deciding whether or not to pursue this.

How can we determine if the IoT community (as compared to IPsec 
developers) have a need for IKE compression?

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 Jan 2016 18:19:04 +0200

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. 
-- 
[email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 12 Jan 2016 08:27:30 -0800

> On Jan 11, 2016, at 8:19 AM, Tero Kivinen <[email-masked]> wrote:
> 
> Yoav Nir writes:

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 13 Jan 2016 18:09:26 +0300

Hi Tommy,

> 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.

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.

> 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.

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.

> 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.

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.

And here some data from my experiments with compression
of the IKEv2 messages using DEFLATE algorithm:

1. IKE_SA_INIT, single transform of each type:

HDR,
 SA[48]{
   P[44]{
    Encryption=AES-CBC {KeyLen=128},
    PRF=SHA1-HMAC,
    Integrity=SHA1-HMAC96,
    Group=MODP-1536}},
  NONCE[36],
  KE[200](MODP-1536),
  N[28](NAT_DETECTION_SOURCE_IP),
  N[28](NAT_DETECTION_DESTINATION_IP),
  N[8](IKEV2_FRAGMENTATION_SUPPORTED),
  N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512},
  N[8](REDIRECT_SUPPORTED),
  VID[26]

In this case using compression results in roughly the same message size
(you can save or loose a few bytes).

2. IKE_SA_INIT, multiple transforms of each type:

HDR,
  SA[264]{
   P[104]{
    Encryption=AES-CBC {KeyLen=256}, AES-CBC {KeyLen=128},
    PRF=SHA2.256-HMAC, SHA2.384-HMAC, SHA2.512-HMAC,
    Integrity=SHA2.256-HMAC128, SHA2.384-HMAC192, SHA2.512-HMAC256,
    Group=ECP-256, ECP-384, ECP-521},
   P[84]{
    Encryption=AES-CBC {KeyLen=128}, 3DES-CBC,
    PRF=SHA1-HMAC, SHA2.256-HMAC,
    Integrity=SHA1-HMAC96, SHA2.256-HMAC128,
    Group=MODP-1024, ECP-224, ECP-256},
   P[72]{
    Encryption=DES-CBC,
    PRF=SHA1-HMAC, MD5-HMAC,
    Integrity=SHA1-HMAC96, MD5-HMAC96,
    Group=MODP-1024, MODP-768, ECP-192}},
  NONCE[36],
  KE[72](ECP-256),
  N[28](NAT_DETECTION_SOURCE_IP),
  N[28](NAT_DETECTION_DESTINATION_IP),
  N[8](IKEV2_FRAGMENTATION_SUPPORTED),
  N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512},
  N[8](REDIRECT_SUPPORTED),
  VID[26]

In this case using compressions results in saving of ~150 bytes out of initial ~530 bytes (~30%).

3. IKE_AUTH with certificate, single proposal of each type, simple traffic selectors:

HDR,
 SK[1720]{
  IDi[63](DN),
  CERT[1167](X.509 Cert),
  CERTREQ[45](X.509 Cert),
  IDr[38](DN),
  AUTH[150](Sig){sha1RSA[13]},
  N[8](INITIAL_CONTACT),
  N[8](IKEV2_MESSAGE_ID_SYNC_SUPPORTED),
  N[12](SET_WINDOW_SIZE),
  CP[16](REQUEST),
  SA[44]{
   P[40]{
    Encryption=AES-CBC {KeyLen=128},
    Integrity=SHA1-HMAC96,
    ESN=Off}},
  TSi[40],
  TSr[40],
  N[8](ESP_TFC_PADDING_NOT_SUPPORTED),
  N[8](NON_FIRST_FRAGMENTS_ALSO),
  N[28](QCD_TOKEN),
  N[8](TICKET_REQUEST)}

In this case using compression results in saving ~350 bytes out of ~1750 (~20%).
In this particular example the resulting message would become ~1400 bytes, that
would avoid IP fragmentation in most cases (and thus avoid using IKE fragmentation).
Using compression here would be more effective if more transforms are included
in the SA payload, more attributes are requested in the CP payload or more complex
traffic selectors are included.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Jan 2016 10:21:10 -0500 (EST)

> that would make their messages larger. And for those devices the compression 

This seems like a very unclear use case. More of a hypothetical use case.

> 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.

> 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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 13 Jan 2016 18:35:11 +0300

> 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.

> is going to get used and send more bytes.

IPsec tunnels can use IPcomp too, as recommended for the 
low-power consumption devices.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Jan 2016 10:48:27 -0500 (EST)

> then IKE fragmentation won't help (it starts working from the IKE_AUTH).

Ah right. That's a fair point.

> IPsec tunnels can use IPcomp too, as recommended for the low-power 
> consumption devices.

Did anyone actually meassure battery costs of this versus not using it?
Is burning main CPU cheaper than burning a bit more in the transmission
chip?

Paul