RE: Packet number encryption

[Mikkel Fahnøe Jørgensen <[e-mail]>]

If you need to troubleshoot a network, what prevents you from injecting
probe packets with random content on the same route? The more opaque QUIC
is, the more likely it is that probe packets would behave the same.

For that matter, QUIC could define stateless probe packets that must route
the same as real connections.

Mikkel


On 4 February 2018 at 18.19.16, Lubashev, Igor ([e-mail]) wrote:

The need to troubleshoot networks (at a minimum, to detect packet loss and
reordering) is real.  I would assume that every network would need to have
an ability to do so.  Ability to quickly troubleshoot and fix networks is
not only “nice” for the networks themselves, but it is also very beneficial
to QUIC users.



Having networks wrap and unwrap packets at their boundaries is a
possibility, though it has real costs and downsides.  First, while networks
could setup such wrapping for UDP port 443 traffic, what about QUIC traffic
using other ports?  Would networks need to wrap all UDP traffic?  Second,
this does reduce MTU for end users, reducing available bandwidth.  Third,
this would allow networks to only answer questions like: “Is my network the
culprit of the problem?” instead of “Is the problem in my network, upstream
from me, or downstream from me?”.



Would it be considered outrageous to suggest that packet number encryption
be an option negotiated during connection handshake?  An end user client in
“Privacy-Enhanced” mode would negotiate this, while end users not
particularly concerned with connection migration linkability issues would
leave this off?



- Igor





*From:* Roni Even (A) [mailto:[e-mail]]
*Sent:* Sunday, February 04, 2018 2:47 AM
*To:* Roberto Peon <[e-mail]>; Piotr Galecki <
[e-mail]>; Jana Iyengar <[e-mail]>;
Fossati, Thomas (Nokia - GB/Cambridge, UK) <[e-mail]>
*Cc:* Gorry Fairhust <[e-mail]>; Eric Rescorla <[e-mail]>;
Christian Huitema <[e-mail]>; Eggert, Lars <[e-mail]>;
Brian Trammell <[e-mail]>; Mirja Kühlewind <
[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <
[e-mail]>
*Subject:* RE: Packet number encryption



Hi,

Network monitoring:

Networks may always wrap the packet(s) they have received with whatever
data they wish, and unwrap before forwarding. This can allow any network to
understand ordering,  loss, etc within its boundaries.



RE- so you are saying that we can for example  leverage  RTP and define RTP
payload for QUIC that will carry QUIC packets, we will just need to resolve
the MTU size.

Roni





*From:* QUIC [mailto:[e-mail] <[e-mail]>] *On
Behalf Of *Roberto Peon
*Sent:* Saturday, February 03, 2018 8:38 PM
*To:* Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge,
UK)
*Cc:* Gorry Fairhust; Eric Rescorla; Mirja Kühlewind; Eggert, Lars; Brian
Trammell; Christian Huitema; QUIC WG; Martin Thomson
*Subject:* Re: Packet number encryption



Ossification:

In the past tcp middleboxes expected in-order, monotonically increasing
offsets and tried to fix reordering before forwarding. This middlebox
behavior, predicated on observable flows, prevented deployment of things
which would have made tcp more efficient.



 This is the kind of non-theoretical ossification that drove the creation
of QUIC in the first place.



Network monitoring:

Networks may always wrap the packet(s) they have received with whatever
data they wish, and unwrap before forwarding. This can allow any network to
understand ordering,  loss, etc within its boundaries.



Debugging:

Debugging of flows can still happen for flows that wish to be debugged--
the QUIC connection's key material(s) can be shared manually and used by
the debugging tool. This is how one debugs http2, https, etc. already today.



-=R







-------- Original message --------

From: Piotr Galecki <[e-mail]>

Date: 2/2/18 7:00 PM (GMT-08:00)

To: Jana Iyengar <[e-mail]>, "Fossati, Thomas (Nokia - GB/Cambridge,
UK)" <[e-mail]>

Cc: Gorry Fairhust <[e-mail]>, Eric Rescorla <[e-mail]>,
Christian Huitema <[e-mail]>, "Eggert, Lars" <[e-mail]>,
Brian Trammell <[e-mail]>, Mirja Kühlewind <
[e-mail]>, QUIC WG <[e-mail]>, Martin Thomson <
[e-mail]>

Subject: RE: Packet number encryption



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

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] <[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://urldefense.proofpoint.com/v2/url?u=https-3A__static.googleusercontent.com_media_research.google.com_en_pubs_archive_46403.pdf&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=SY87I4v_IqTCGOds-j5NCOwkQ0cJcYHGyKdXmMIVn6I&s=U9o6dI-dwzKwvXHvvmv7WtVm84puvxhaP0cN2of3VvA&e=>
).



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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.symmetrymagazine.org_article_the-2Ddeconstructed-2Dstandard-2Dmodel-2Dequation&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=SY87I4v_IqTCGOds-j5NCOwkQ0cJcYHGyKdXmMIVn6I&s=etIO0AUHiJm8zucsWaTgo-XULFisCMoG2iDvwC69s9Q&e=>