Re: Getting to consensus on packet number encryption

[Ian Swett <[e-mail]>]

On Mon, Apr 9, 2018 at 4:36 AM Brian Trammell (IETF) <[e-mail]>
wrote:

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

Agreed.  It would only be non-identical in the case of 0 byte connection
IDs, which I don't believe anyone expects to be common from client to
server.

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