RE: a proposed way forward was Re: Spin bit decision

[Lucas Pardue <[e-mail]>]

Nice summary Brian.

Thinking about tunneling QUIC in QUIC and proxy chains, we might end up with multiple layered QUIC security contexts, with the innermost layer being the end-to-end QUIC connection that is used for an actual application layer. Do you think this would benefit from multiple spin bits? Is that covered by the cases you already set out?

Lucas
________________________________________
From: QUIC [[e-mail]] on behalf of Brian Trammell (IETF) [[e-mail]]
Sent: 03 October 2018 08:58
To: Mikkel Fahnøe Jørgensen
Cc: [e-mail]; Mike Bishop; Ian Swett; Lars Eggert; IETF QUIC WG; Kazuho Oku
Subject: Re: a proposed way forward was Re: Spin bit decision

hi Mikkel,

I think we're having trouble with the many meanings of the word "proxy" here. It can mean at least three things in this context, each of which has different implications for RTT measurement:

(1) Web proxying. The web proxy terminates transport connections, and as such the spin bit would only expose the RTT on the segment between the proxy and its Internet-side peer. Since the whole point of the proxy from a privacy standpoint is to make traffic look like it's coming from the proxy, exposing this RTT is not an issue.

(2) Transport-terminating proxying. Here the proxying happens at the stream, as opposed to the request level. For spin bit measurement, this is equivalent to (1) above. (Note that this is widely deployed for TCP in the form of transparent back-to-back proxies, which won't work in QUIC since the security association protecting the transport is end-to-end.)

(3) Proxy-via-NAT. Here the proxy simply rewrites UDP addresses; in this case, since the transport association is not terminated, the spin bit will expose full end-to-end RTT. Indeed, in this case, endpoints may want to disable RTT measurement.

> On 3 Oct 2018, at 09:45, Mikkel Fahnøe Jørgensen <[e-mail]> wrote:
>
>>
>> At last a concrete argument, thanks ;)
>> But why would exposing the RTT be harmful in a NAT/UDP-proxy scenario ?
> Great firewall censorship.

Say more here? I don't see the relevance.

> VPN proxy to bypass streaming restrictions by country.

AFAIK most/all of these are of type (1) and (2), so not relevant to the discussion.

> Hackers that proxy traffic via a legitimate cooperation.

For web traffic, at least, this would probably be of type (1).

> Internet access providers prioritising local traffic.

This can and always will be done via other identifiers, so even if RTT is exposed here, it is of limited utility/threat (depending on which team you're rooting for).

> High latency onion routing traffic.

Necessarily always terminates transport. However, the fundamental design properties of circuit-based anonymity systems do mean that if you're doing something like running a VPN tunnel over ToR (for.. some reason?), then you should turn off the spin bit for traffic within that tunnel. Client opt-outs seem to be mostly sufficient for this, though.

Cheers,

Brian


>
>>
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------