1RTT is 1RTT :)
", "time": "2022-11-09T15:01:04Z"}, {"author": "Mohamed Boucadair", "text": "@Chairs: draft-ietf-ipsecme-add-ike is in WGLC since 2022-08-09. Is there a plan to conclude the call?
", "time": "2022-11-09T15:03:13Z"}, {"author": "Paul Wouters", "text": "\"after this meeting\" i think that implies \"today\" :P not \"in 10 years\" :P
", "time": "2022-11-09T15:11:10Z"}, {"author": "Yoav Nir", "text": "@meetecho: is it possible to turn the camera to the speaker?
", "time": "2022-11-09T15:11:20Z"}, {"author": "Mohamed Boucadair", "text": "@Paul: https://datatracker.ietf.org/doc/html/draft-farrel-soon-07
", "time": "2022-11-09T15:16:59Z"}, {"author": "Tero Kivinen", "text": "Paul Wouters said:
\n\n\n\"after this meeting\" i think that implies \"today\" :P not \"in 10 years\" :P
\n
Done.
", "time": "2022-11-09T15:18:07Z"}, {"author": "Yoav Nir", "text": "That doesn't really fall under the definition of \"after this meeting\"
", "time": "2022-11-09T15:19:08Z"}, {"author": "Yoav Nir", "text": "Isn't IPComp in practice almost deprecated?
", "time": "2022-11-09T15:19:43Z"}, {"author": "Dan Harkins", "text": "@Yoav, that was my thought. Who uses this today?
", "time": "2022-11-09T15:20:00Z"}, {"author": "Yoav Nir", "text": "We didn't have an attack demonstrated on stage like in TLS, but from what I remember we kind of hid it.
", "time": "2022-11-09T15:21:17Z"}, {"author": "Dan Harkins", "text": "And I don't believe it was ever intended to stand-alone (i.e. just do IPcomp not ESP+IPcomp).
", "time": "2022-11-09T15:21:29Z"}, {"author": "Valery Smyslov", "text": "@Dan: this my impression too
", "time": "2022-11-09T15:22:07Z"}, {"author": "\u00c9ric Vyncke", "text": "You may also have a look at draft-ietf-intarea-schc-ip-protocol-number (running LPWAN SCHC directly over IP layer)
", "time": "2022-11-09T15:23:19Z"}, {"author": "Benjamin Schwartz", "text": "Does IPComp even measurably help on the modern internet? Everything is incompressible.
", "time": "2022-11-09T15:24:32Z"}, {"author": "Dan Harkins", "text": "@Benjamin, not really. That's why it wasn't used. Compression is good when it's stateful but in practice the state got flushed with each packet and the result was meh.
", "time": "2022-11-09T15:25:39Z"}, {"author": "Yoav Nir", "text": "@Benjamin: it depends. If you're using IPsec (and IPcomp) to compress HTTPS streams, than obviously you're not gaining much. If you are compressing some unencrypted FTP stream, maybe you are.
", "time": "2022-11-09T15:26:17Z"}, {"author": "Yoav Nir", "text": "@Dan: we (CP) stopped recommending it because the acceleration didn't support it, and it wasn't worth the effort making the acceleration support it.
", "time": "2022-11-09T15:27:12Z"}, {"author": "Benjamin Schwartz", "text": "@Yoav Nir Even FTP supports DEFLATE, which will work much better
", "time": "2022-11-09T15:27:37Z"}, {"author": "Tero Kivinen", "text": "And most of the files you move are already compressed.
", "time": "2022-11-09T15:27:59Z"}, {"author": "Yoav Nir", "text": "Need a big payload to transfer the entire organization network in a CP payload. And then again in a TSr payload.
", "time": "2022-11-09T15:28:21Z"}, {"author": "Benjamin Schwartz", "text": "Could this be fixed by defining a simple auto-retry heuristic?
", "time": "2022-11-09T15:47:50Z"}, {"author": "Dan Harkins", "text": "it seems unwise for authentication to succeed if the peers don't agree on what the cookies are.
", "time": "2022-11-09T15:48:42Z"}, {"author": "Benjamin Schwartz", "text": "It seems like \"retry up to N times on authentication failure\" would solve this without a protocol change.
", "time": "2022-11-09T15:49:30Z"}, {"author": "Yoav Nir", "text": "@Benjamin: Yes, but if you get a bad AUTH payload (think digital signature) from the responder, it looks like a bad security issue that the initiator needs to alert about.
", "time": "2022-11-09T15:49:51Z"}, {"author": "Yoav Nir", "text": "There's no \"good\" reason for a bad AUTH payload
", "time": "2022-11-09T15:50:04Z"}, {"author": "Benjamin Schwartz", "text": "Also, what about diversifying the source ports?
", "time": "2022-11-09T15:51:21Z"}, {"author": "Yoav Nir", "text": "*** Take it to the list
", "time": "2022-11-09T15:54:19Z"}, {"author": "Tobias Brunner", "text": "You could also just let the CHILD_SA negotiation fail, you end up with a childless IKE_SA
", "time": "2022-11-09T16:12:40Z"}, {"author": "Valery Smyslov", "text": "What about NO_ADDITIONAL_SAS ?
", "time": "2022-11-09T16:14:11Z"}, {"author": "Valery Smyslov", "text": "It's a standard notify that Child SA cannot be created.
", "time": "2022-11-09T16:14:50Z"}, {"author": "Valery Smyslov", "text": "Permanently.
", "time": "2022-11-09T16:14:59Z"}, {"author": "Yoav Nir", "text": "Permanently until the next IKE SA.
", "time": "2022-11-09T16:15:35Z"}, {"author": "Benjamin Schwartz", "text": "@Valery Smyslov Interesting, thanks!
", "time": "2022-11-09T16:15:42Z"}, {"author": "Valery Smyslov", "text": "Sure
", "time": "2022-11-09T16:15:44Z"}, {"author": "Benjamin Schwartz", "text": "@Tobias Brunner Is that true? Or do you end up with a child SA automatically from the AUTH exchange?
", "time": "2022-11-09T16:16:27Z"}, {"author": "Yoav Nir", "text": "@meetecho: please point the camera at the speaker
", "time": "2022-11-09T16:16:45Z"}, {"author": "Yoav Nir", "text": "If the IPsec part of the IKE_AUTH fails (like disagreeing on crypto methods) you remain with a valid IKE SA but no IPsec SA
", "time": "2022-11-09T16:17:54Z"}, {"author": "Benjamin Schwartz", "text": "@Yoav Nir Yes, but that's an unauthenticated failure mode that could be an attack. We are looking for a way to produce an authenticated declaration that means \"Actually let's not use IPsec\".
", "time": "2022-11-09T16:19:00Z"}, {"author": "Tobias Brunner", "text": "The SA is still fully authenticated
", "time": "2022-11-09T16:19:19Z"}, {"author": "Benjamin Schwartz", "text": "(or can be interpreted that way in this context)
", "time": "2022-11-09T16:19:25Z"}, {"author": "Yoav Nir", "text": "The child part of the IKE_AUTH is authenticated
", "time": "2022-11-09T16:19:35Z"}, {"author": "Benjamin Schwartz", "text": "OK, thanks
", "time": "2022-11-09T16:19:52Z"}, {"author": "Yoav Nir", "text": "The motivation for CHILDLESS was to avoid these situations - to make the child SA negotiations separate. The use case then was VPN clients - separate the user-initiated \"connect\" operation from the traffic-initiated \"child SA setup\"
", "time": "2022-11-09T16:20:53Z"}, {"author": "Tobias Brunner", "text": "It also allows using independent key exchanges for every CHILD_SA and not have the first CHILD_SA have keys derived from the key exchange already used for the IKE_SA
", "time": "2022-11-09T16:22:28Z"}, {"author": "Yoav Nir", "text": "Wasn't there a big discussion in TLS and CFRG a few years back with the conclusion that you needed to replace AES-GCM keys far more often?
", "time": "2022-11-09T16:26:51Z"}]