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

[Valery Smyslov]

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

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

[Paul Wouters]

On Wed, 13 Jan 2016, Valery Smyslov wrote:


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


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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Tommy,


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.


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],
 

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

[Paul Wouters]

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

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

[Tommy Pauly]

> On Jan 11, 2016, at 8:19 AM, Tero Kivinen  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

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

[Tero Kivinen]

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. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Hoffman]

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

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.


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


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


And IKE_AUTH messages often contains a certificates, that is usually 
compressable by 30%.


I thought IoT devices did not even have the memory to do X.509, which is
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.


Paul


Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

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.


Yoav


Regards,
Valery. 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Paul, 

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.


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.


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.


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


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.


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.



--Paul Hoffman


Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

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


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 
compressable by 30%.


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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Hoffman]

On 5 Jan 2016, at 2:58, Valery Smyslov wrote:


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?


No, but that's not what PaulW said.

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.


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.





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?


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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

On Tue, 5 Jan 2016, Paul Hoffman wrote:


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


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.

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.


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

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec