Re: Packet number encryption

[Kazuho Oku <[e-mail]>]

2018-02-05 6:31 GMT+09:00 Brian Trammell (IETF) <[e-mail]>:
> hi Jana,
>
>> On 3 Feb 2018, at 03:30, Jana Iyengar <[e-mail]> wrote:
>>
>> 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.
>
> After having worked my way through the PR again (and essentially rewriting it from the receiver's point of view, which I believe would be useful text to have in the final document, should we end up doing this), I buy this.
>
>> 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.
>
> Agree completely. Packet number jumps are a bad idea, and there seems to be a (not explicitly examined) consensus that attempting to make linkability difficult is worth the effort.
>
>> 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 an overgeneralization of experience from ossification of single static fields (as in the TLS greasing and GUIC flags cases) to functions over the time series of these fields which has not yet been shown to be valid IMO in the case of integrity-protected wire images -- will expand on this in my next message, replying to Roberto.
>
>> There's a win here in terms of implementation complexity and several implementers have said so.
>
> Compared to packet number jumps, absolutely. Compared to the state two revs of the draft ago, it's a *little* more complex but at least it doesn't add completely new operations at the sender or the receiver.
>
>> There's a win in terms of ossification and our experience says so.
>
> That experience is IMO overgeneralized.
>
>> There's a potential loss of manageability, in being able to detect reordering.
>
> Well, upstream loss and upstream reordering.
>
> As Christian suggested at the start of this thread, if we simultaneously add back a signal that would allow on-path loss and reordering detection, that would make this a usable-information-content-neutral change to the wire image, and everyone could leave the table happy.

+1

There are two parties with different interests. Endpoint developers
want something more straightforward to implement and also is safe from
ossification. Operators want a tool for diagnosis.

In TCP, both parties have used the same signal for their tasks.

In QUIC, we can split the signal into two, which can be tailored for
each use-case.

The split would help the protocol evolve (as fit from endpoint
developers' perspective). At the same time, it could also help
operators, since the signal they use can become more stable or evolve
in a different pace (since the changes to the encrypted part of the
protocol will not affect what the operators will see, or vice-versa).

Note also that even in the current unencrypted form, packet numbers of
QUIC is not as easy to use compared to TCP (from operators' viewpoint)
since the numbers monotonically increase and since ACKs are encrypted.
So there's a chance to make the signal more useful by splitting the
signals. Spin bit is a good example.

> The only problem with this is that the most obvious place to put this signal -- the four bits we get back from the short header type field (assuming we add the spin bit) aren't really enough to track the loss and reordering patterns we care about with a naive counter.
>
> There are lots of other options in this space (e.g. decide we care about latency more than reordering, and that we don't care about loss at all, and use a two-bit spin to protect the latency signal from reordering, and so on), but that seems like a third thread we should start.
>
> Cheers,
>
> Brian
>
>> 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
>>
>>
>



-- 
Kazuho Oku