Re: Getting to consensus on packet number encryption

[Roberto Peon <[e-mail]>]

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