Re: Getting to consensus on packet number encryption

["Brian Trammell (IETF)" <[e-mail]>]

hi Mark, all,

> On 9 Apr 2018, at 04:54, Mark Nottingham <[e-mail]> wrote:
> 
> Praveen,
> 
> In previous discussions, there's been strong interest in including connection migration -- in a limited form (for the "parking lot" use case) -- in QUICv1 (discussed in Melbourne in some detail; see <https://github.com/quicwg/wg-materials/blob/master/interim-18-01/minutes.md#connection-migration>).
> 
> It looks like the discussion in <https://github.com/quicwg/base-drafts/issues/1271> about making it optional and how that gets indicated / negotiated is going nicely. Thanks for opening an issue.
> 
> AFAICT, (at least) two assumptions need to be proven to have that help the PNE issue:
> 
> a) There isn't a linkability issue during NAT rebinding

Isn't the question we should be asking here "does QUIC with connection migration disabled (and no PNE) have similar linkability characteristics to QUIC with connection migration enabled (and PNE)?"?

I'm still confused as to how PNE is supposed to mitigate linkability across a NAT rebinding that occurs without client knowledge in the presence of a server-supplied CID, which seems to me to be the most common NAT rebinding event type. If it indeed does not, then the linkability characteristics seem identical to me.

> 
> b) Having two packet number schemes is acceptable to implementers (given the probable popularity of migration)
> 
> I haven't yet seen much discussion of either of these specific aspects.
> 
> As an aside -- the other threads about modifications to PNE to make them single-pass seem extremely promising; I'd encourage folks there to continue discussions and make a PR.

+1. Making the design of PNE less problematic for offload and other future optimizations won't solve the underlying requirements problem (i.e. we are both treating linkability among 5-tuple flows by a specific on-path device, the LB, as a requirement to support via CID, as well as a requirement to mitigate linkability among 5-tuple flows by a all generic on-path devices via PNE, which is inherently contradictory  without a very precise definition of under which circumstances which requirement takes precedence). But it will reduce the cost from "probably mostly harmless" to "almost definitely mostly harmless", which should make the decision easier.

Cheers,

Brian


> 
> Cheers,
> 
> 
> 
>> On 6 Apr 2018, at 2:41 am, Praveen Balasubramanian <pravb=[e-mail]> wrote:
>> 
>> Love this idea. Expanding it a bit further I don’t think we need to make PN transform a transport parameter but rather connection migration itself. We could also simply use QUIC versioning for this.
>> 
>> 1. Ship QUIC v1 with no support for connection migration. Servers behind load balancers that are not QUIC aware will only advertise this version. I expect this to be a large fraction of servers especially those hosted in AWS, Azure, GCP. *This is important - I want the group to acknowledge that servers needs to be able to advertise support for connection migration*.
>> 2. Ship QUIC v2 with support for connection migration. If a client and server use this version they MUST do PNE as per #1079. If we find a more efficient scheme before November then we use that instead.
>> 
>> Eventually we will ship QUIV vN which has support for multi-path and we can revisit if PNE is needed or multiple PN spaces will work. Until then I can live with higher CPU cost for the fraction of connections that will migrate.
>> 
>> Now there is the ossification problem in QUIC v1 as referred to above. We already require a random starting PN. The next problem is one that Kazuho brought up where middleboxes will start seeing strict increasing PN and try to reorder. I was thinking about short random jumps to fix this problem but the monotonic increase will remain. While I think sane middleboxes will not do any reordering, there might be a few crazy outliers like with TCP. I think we can solve this by making the in clear PN jump both forward and back within a "reordering degree". I am thinking about some ideas here and will reply back if I find a simple scheme.
>> 
>>>> FWIW, what I got from the info that Praveen and Ian have shared is that there are enough problems to solve with UDP that worrying about the performance hit from encryption is premature
>> Martin, we have plans to make UDP screaming fast in software. But the real advantage for TCP comes from the batch offloads (see email with subject " Impact of hardware offloads on network stack performance"). Batch offloads for QUIC are impossible to do without crypto offload. I would be happy to explain more on this front. I think we will exhaust software optimizations soon and then get blocked on crypto offload.
>> 
>> 
>> -----Original Message-----
>> From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
>> Sent: Wednesday, April 4, 2018 9:36 PM
>> To: Kazuho Oku <[e-mail]>
>> Cc: Lars Eggert <[e-mail]>; Mark Nottingham <[e-mail]>; IETF QUIC WG <[e-mail]>; Patrick McManus <[e-mail]>
>> Subject: Re: Getting to consensus on packet number encryption
>> 
>> On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku <[e-mail]> wrote:
>>> It is true that #1079 has issues with hardware crypto offload. I am
>>> happy to support switching to a better encryption scheme (if we find
>>> one) at any moment; e.g., during the standardization of QUICv1, or as
>>> an extension to v1, or part of vX.
>> 
>> Until this came up, I hadn't considered the use of an extension/transport parameter to negotiate a new scheme, but it's obvious.  This fits best with my view of things.
>> 
>> If that means that we get the DC-QUIC option that turns the packet number encryption function into identity or some cheaper function, then I think that's an OK outcome.  We should stop pretending that one size fits all is achievable; it's not been the case for years already.
>> 
>> FWIW, what I got from the info that Praveen and Ian have shared is that there are enough problems to solve with UDP that worrying about the performance hit from encryption is premature.
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>