Re: Packet number encryption

[Brian Trammell (IETF) <[e-mail]>]

hi Roberto, all,

(Trimming recipients)

Briefly: this is the approach under development with the IOAM work in the IPPM (and other) working groups; please come by if you‘d like to contribute there.

There are two serious drawbacks of an IOAM-only approach to measurability of encrypted transports.

First, they only allow measurement on the granularity of the tunnels carrying IOAM traffic. As you point out, sometimes that is exactly what you want. Often it isn’t. Requiring an operator to tunnel traffic differently in order to be able to get the measurement aggregates necessary for a given measurement task runs into a Heisenberg problem: you’ve changed the thing you want to measure in trying to measure it.

Second, they only measure the treatment of a traffic flow between tunnel endpoints. This implies that they're good for intranet diagnostics (of aggregates you generally already have) or for diagnostics for tunnel services provided to customers (assuming you ship IOAM-capable CPE for the customer end; this is indeed one of the reasons to standardize this approach). They're bad for diagnosing stuff within an end network (between the tunnel end and the endpoint) or for anything interdomain.

IOAM approaches are an important part of the measurement toolkit, but they're not a replacement for end-to-end signals for all tasks.

Cheers,

Brian


On 5 Feb 2018, at 08:16, Roberto Peon <[e-mail]> wrote:

> That depends.
> Arguably, all the network can know (or should know) is on the basis of a 5-tuple, thus the network could assign sequence numbers based on order of arrival of a 5-tuple.
> 
> However, one could do more useful and/or general things: If the intended egress node is known at the ingress point for a packet then, when applying the appropriate route, stamp the packet with a sequence number on/for that route. At that point you’re able to look at reordering across any/all flows within a route. This is a stronger ordering guarantee than is necessary, and thus is sufficient for any individual flow on that route. In my belief, this would be a superior metric for network health detection overall.
> 
> -=R
> 
> From: Roni Even <[e-mail]>
> Date: Sunday, February 4, 2018 at 8:58 PM
> To: Roberto Peon <[e-mail]>, "'Roni Even (A)'" <[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
> 
> Does not it mean that the network need to identify packets  that are from the same quic connection to make such wrapping?
> Roni
> 
> From: QUIC [mailto:[e-mail]] On Behalf Of Roberto Peon
> Sent: Monday, February 05, 2018 2:38 AM
> To: Roni Even (A); Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK)
> Cc: Gorry Fairhust; Eric Rescorla; Christian Huitema; Eggert, Lars; Brian Trammell; Mirja Kühlewind; QUIC WG; Martin Thomson
> Subject: Re: Packet number encryption
> 
> A network could carry whatever protocol it wished to, i.e. by wrapping any/all packets on ingress to the network, and then un-wrapping when forwarding to another network. This would allow a network to record and track whatever it wanted to without placing constraints on layers which should be above it.
> 
> If the network placed a sequence number on incoming packets, it could detect reordering across all flows. If it do so on a 5-tuple basis, it could detect reordering/duplication/loss across any 5-tuple.
> 
> -=R
> From: Roni Even (A) <[e-mail]>
> Sent: Saturday, February 3, 2018 11:47:06 PM
> To: Roberto Peon; 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
> 
> 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]] 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]] 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).
> 
> 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
> 
>