Re: Getting to consensus on packet number encryption

[Christian Huitema <[e-mail]>]

Since you all want to read more text, I wrote a summary of the various
proposals in the QUIC Wiki:
https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives.


Of course, that summary reflects my own modest understanding. But then
it's a wiki, so you can easily correct me.


-- Christian Huitema



On 4/16/2018 12:56 PM, Roberto Peon wrote:
>
> Paraphrasing:
>
> > PN insufficient to fix ossification, why is that difficult/expensive?
>
> As described in the other subthread, you'd have to emulate the same
> ordering of the previously-ossified PN while also doing whatever
> newness you want with the new PN.
> That sounds fabulously complex. You'd end up running two different
> implementations simultaneously.
>
> > Ossification/invariant without encryption:
> Encryption solves it, sounds like we agree on that 😊
>
>
> -=R
>
> ------------------------------------------------------------------------
> *From:* QUIC <[e-mail]> on behalf of Mirja Kühlewind
> <[e-mail]>
> *Sent:* Friday, April 13, 2018 4:06:40 AM
> *To:* Roberto Peon
> *Cc:* [e-mail]; Christian Huitema
> *Subject:* Re: Getting to consensus on packet number encryption
>  
> Hi Roberto,
>
> see below.
>
> > Am 10.04.2018 um 03:04 schrieb Roberto Peon <[e-mail]>:
> >
> > Adding another PN would probably not be sufficient-- one would need
> to ensure that the ossified PN was presented with the right sequencing
> as well, which might be difficult, or expensive.
>
> Yes, that is easy. Why do you think that is difficult or expensive?
>
> > Ossification is surprisingly difficult to work around once it sets
> in, as even figuring out how it is impacting you can be substantial work.
>
> That is true for a protocol like TCP very the invariant is large and
> non of the bits are encrypted. For QUIC we have a completely different
> situation.
>
> Mirja
>
>
> >
> > -=R
> >
> > On 4/5/18, 2:27 AM, "QUIC on behalf of Mirja Kühlewind"
> <[e-mail] on behalf of [e-mail]>
> wrote:
> >
> >    Let me repeat another position then as well:
> >
> >> Am 05.04.2018 um 02:44 schrieb Christian Huitema <[e-mail]>:
> >>
> >> If we are in the business of repeating our positions, so be it. I
> am pretty much on the same line as Patrick and others:
> >>
> >> 1) Privacy is not optional. And yes, removing "linkability through
> PN" is important, because when the connection ID and the source
> address also change, the only other cue for linkability is timing.
> Timing can be addressed by having overlapping connections.
> >>
> >    Timing doesn’t help here either because you still have the same
> destination IP, both port numbers and the fact that a migrated
> connection does not have a handshake. If we want to address the
> linkability problem, we would need to do much more, probably baring
> more hits on performance.
> >
> >    I thought we discussed this already endlessly and concluded that
> PNE does not help linkability.
> >
> >    Then an argument for ossification was broad up. However, we
> really cannot compare the situation here with TCP. With TCP everything
> is in the clear incl. also the retransmissions. In case of MPTCP this
> was rather the problem the the seq# because if you’d use the same seq#
> number space on both connections it would like loss but without a
> retransmission. Further boxes that reorder, usually do that in
> situation where packets were transmitted for a known reason out-of
> order previously, e.g. when multiple paths are used in the network.
> The recommendation we still give in the IETF transport area is that in
> such a situation the scheduling should not be done on a per-packet
> level but per-flow. However, those scheme that do per-packet
> scheduling usually also apply mechanism to re-order afterwards. They
> can just use the TCP seq# for that but for non-TCP they would simply
> add their own encapsulation with a seq#…
> >
> >    Please keep in mind that even if an (unencrypted) PN gets
> ossified by the network,
> >    in case of QUIC that does not mean that we can’t change the
> transport machinery anymore. Currently the exposed PN is also used for
> congestion control and retransmission, however, we can still add
> another PN in the encrypted part and resolved the fact that the
> current PN is overloaded for different functions.
> >
> >    Currently, I really still don’t see the benefit of PNE but only
> additional complexity and known performance degradation.
> >
> >    Mirja
> >
> >
> >
> >
> >
>