On Fri, 17 Jun 2022 12:48:02 -0700, Christian Huitema wrote: > On 6/17/2022 6:08 AM, Michael Eriksson wrote: > > On Thu, 16 Jun 2022 18:21:38 -0700, Christian Huitema wrote: > > [...] > > > > Here we definitely disagree. Why go for a solution that has obvious > > fundamental problems when they can be easily avoided by choosing > > another solution? > > There are no "obvious fundamental problems" with the single PN > solution. [...]
There is an obvious fundamental problem with a single PN space and hardware offload, namely expanding compressed packet numbers when there are unavoidable holes in the packet number sequence. You claim that this problem can be worked around. I would say that the problem is far from fully understood, and that a generic solution is probably at least "non-trivial" and/or costly. In any case, it seems unwise to design a new protocol with a problem that is not fully understood. > > > With the single space solution, the same encryption logic is > > > used regardless of whether the connection supports multipath or > > > not. I think that makes implementation of crypto offload > > > simpler. The same encryption key and IV are used for all paths, > > > and that too makes encryption offload simpler, especially when > > > handling key rotations. > > > > In Rebecka Alfredsson's prototype, the exact same encryption logic > > is used regardless of whether the connection supports multipath or > > not. The single path of a unipath connection has the ID zero and > > it just works. > > That may be true in your case, but it is not true in general. Per > RFC 9000, the CID changes after path migration. It can also change > in an arbitrary way if the clients decides to do it, maybe for > privacy reasons. And it will definitely have to change if the TTL of > the CID expires and the server issues "retire CID" requests. I don't understand what your point is here. The exact same encryption logic can be used regardless of whether the connection supports multipath or not. For unipath connections the path ID is always set to zero when the nonce is computed. As you know from your own draft, setting the path ID to zero will create the very same nonce as RFC 9001 specifies for unipath connections, where these 32 bits are always zero from zero padding. > > [...] > > > > Don't forget that the unified solution is also unable to handle ECN on > > path's with zero-length connection IDs. ECN is needed for L4S, which > > Apple has now made available as a beta in iOS 16 and macOS Ventura. > > > > https://developer.apple.com/videos/play/wwdc2022/10078/ > > Correct. There is also text to that effect in the PR, with proposed > mitigations. It could be fixed quite simply, see comment above about > the need of a PATH REPORT frame. Hmm, interesting... Can you please explain in detail how a receiver with zero-length connection IDs identify over which path packets arrive to be able to collect and report ECN counts? > > To be honest, it's really hard to understand why you hold on to a > > solution that has obvious problems. I have shown how they can be > > avoided, in a way that also has much lower complexity. > > Not true. The management of path identifiers and PN does increase > complexity quite a bit if you cannot rely on CID. I don't understand what your point is here. For multipath connections, I suggest a very clear mapping between connection IDs and path identifier, namely to use the server's connection ID sequence number as path identifier in both directions. With explicit path setup signaling, as I suggested in a separate mail, path identifiers could probably be more stable and not change when the connection ID changes. /me
