Re: [quicwg/base-drafts] What can change in a different version (#55)

[martinduke <[e-mail]>]

>
> On counterargument two: not sure I follow... is the argument here that we
> *want* it to be hard for middleboxes to "find" the connection ID? I
> personally think this counterargument perilously underestimates the human
> ingenuity (or, if you'd like a negative expression, "sheer unmitigated
> gall") of middlebox designers, as well as the flexibility of VHDL as a
> programming environment for expressing hardware packet inspection. We can
> force there to be a predictable processing cost for this information
> through an encoding, or by making the connection ID the answer to a puzzle,
> but doing this through random offsets simply increases middlebox designer
> annoyance while increasing the potential of hard-to-debug processing errors
> in middlebox implementations (i.e. operator annoyance) more.
>

I must not have been clear. The point is that option (1) means that the
connection ID (if 64 bits) is exactly one byte after the start of the UDP
payload. This is very simple. Option (2) means that middleboxes would have
to interpret the VERSION bit and the MORE_FLAGS bit to figure out how many
bytes of offset for the connection ID. It's a bit more complicated, and a
deviation for middleboxes that are already out there parsing QUIC in
exactly that way out there.

Again, I also favor (2), but for some reason I'm here making the
counterargument.


> This is probably purely ideological: I just don't see the point of
> deciding to expose a thing, then making it pointlessly difficult to use.
> There *may* be a discussion to be had about encoding information exposed
> in the wire image as puzzle solutions, in order to make targeted diagnostic
> usage of these fields possible while making mass usage of them (e.g. for
> all QUIC flows crossing a network border) costly. However, if we select the
> set of things to expose properly, and design the semantics of connection ID
> properly, such mass usage would tend to be useless for nefarious purposes
> (tracking, surveillance) while still being useful for less nefarious
> purposes (proactive detection and/or localization of network performance
> issues).
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/55#issuecomment-269744431>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AXRMERvRmxE5jUfrsJiANE0DhmjExj_Jks5rNL18gaJpZM4LCAfq>
> .
>


-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/55#issuecomment-269849716