Re: Packet number encryption

[Patrick McManus <[e-mail]>]

On Fri, Feb 2, 2018 at 9:59 PM, Piotr Galecki <
[e-mail]> wrote:

> What is the group’s proposal for allowing network monitoring tools to
> detect packet retransmission or packet reordering ?
>

quic retransmits data, it does not retransmit packets. I'm not trying to be
pedantic - that's the answer to your question because obviously data needs
keys. Cooperating parties need to cooperate to share keying material...
this is something wireshark and tls have worked out in the past.



> These metrics are pretty straightforward to measure for TCP flows.
>
> Tools like Wireshark can analyze packets and spot issues.
>
> How can the network tools perform this kind of measurements for QUIC flows
> if PN field is encrypted?
>
>
>
>
>
> *From:* QUIC [mailto:[e-mail]] *On Behalf Of *Jana Iyengar
> *Sent:* Friday, February 02, 2018 9:31 PM
> *To:* Fossati, Thomas (Nokia - GB/Cambridge, UK) <[e-mail]
> >
> *Cc:* Gorry Fairhust <[e-mail]>; Eric Rescorla <[e-mail]>;
> Mirja Kühlewind <[e-mail]>; Christian Huitema <
> [e-mail]>; Brian Trammell <[e-mail]>; Eggert, Lars <
> [e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <
> [e-mail]>
> *Subject:* Re: Packet number encryption
>
>
>
> A few points as I catch up on this thread.
>
>
>
> First, I'll remind folks that QUIC is an encrypted transport. I say this
> because the cost of this operation is trivial in the context of encrypting
> every packet. The cost is borne at the servers and not at middleboxes, so
> the additional crypto cost is basically trivial.
>
>
>
> Second, this simplifies and increases robustness of implementation.
> Avoiding random PN jumps, as Kazuho points out, makes special-casing of
> code unnecessary. Special code that is exercised occasionally is a strong
> bug attractor, and I would strongly argue for as few of those as possible
> in implementation.
>
>
>
> Third, yes, ossification is a real concern. A simple example: using
> increasing packet numbers as a signature for detecting QUIC. Even if you
> argue against this example, there are innovative ways in which ossification
> will happen. This is based on a true story: We had no idea how GQUIC's
> flags field could get ossified, the value that was being used commonly
> became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM
> QUIC paper
> <https://static.googleusercontent.com/media/research.google.com/en/pubs/archive/46403.pdf>
> ).
>
>
>
> There's a win here in terms of implementation complexity and several
> implementers have said so. There's a win in terms of ossification and our
> experience says so. There's a potential loss of manageability, in being
> able to detect reordering. This is the trade-off, and I am still in favor
> of encrypting packet numbers.
>
>
>
> On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK)
> <[e-mail]> wrote:
>
> On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" <
> [e-mail] on behalf of [e-mail]> wrote:
> > On 2018-1-31, at 10:52, Gorry Fairhurst <[e-mail]> wrote:
> > > +1 - Simply: This *is* complicated and seems to add little.
> >
> > So as an implementor (chair hat off), this adds very little to the
> > overall complexity of the protocol.
>
> This doesn't sound great.  It's a bit like saying that adding the Higgs
> mechanism to the standard model's lagrangian doesn't make it much more
> complicate :-)  (*)
>
> More seriously though, I'd like to point out that it is not just about
> implementation complexity, it's also the energy cost per packet that is
> quite crucial.  I haven't done the math but ISTM that bringing in
> another batch of non-optional crypto computation on a per packet basis
> is not going to move the needle in the right direction for stacks that
> run on low power (IoT).
>
> This is not a catastrophe - we have CoAP and a (D)TLS profile - but
> neither it's ideal, since cutting off the small things from the wider
> ecosystem creates an artificial gap which then will need a middlebox to
> bridge.  (Sure, we have specified the behaviour of a similar box
> already, but it'd be really better if the extra translation logic could
> be avoided in the first place.)
>
> I guess what I'm saying is that PN encryption being a core mechanism
> that can't be negotiated at handshake time reduces our ability to later
> profile QUIC for the IoT, which would be a bit unlucky.
>
> So the question is: would it be possible to make this property a
> configurable knob instead?
>
> (*) https://www.symmetrymagazine.org/article/the-deconstructed-
> standard-model-equation
>
>
>