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

2016-01-13 Thread 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 I

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

2016-01-13 Thread 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

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

2016-01-13 Thread 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 t

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

2016-01-13 Thread 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 cons

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

2016-01-12 Thread 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

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

2016-01-11 Thread 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 fr

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

2016-01-09 Thread 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

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

2016-01-09 Thread 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

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

2016-01-08 Thread 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

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

2016-01-08 Thread 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 encapsula

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

2016-01-08 Thread 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 dis

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

2016-01-05 Thread Yoav Nir
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 th

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

2016-01-05 Thread 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 t

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

2016-01-05 Thread 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 yo