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

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

You are right that there are other obstacles to prevent detection that just
RTT.

You can imagine an alternative DNS service and router system that send
traffic in one direction and then forwards traffic into the general
backbone. So you have a person in Asia connect to a US university that has
router that forwards packets out into the general internet without
terminating anything as a sort of extended NAT box. I might be missing
something here, but that is my train of thoughts. The latency is not hiding
the distance between the two continents but it can reveal detectable
anomalies in traffic. More generally, you could apply machine learning to
RTT - or to any other observable parameter.

I’m not really against the spin bit and I agree that there are often better
ways to achieve such attacks, but dropping the spin bit is a really easy
first line of defence. Hence, for the cases I listed you cannot expect
cooperation on the spin bit even if the attack is unlikely.


On 3 October 2018 at 09.58.12, Brian Trammell (IETF) ([e-mail])
wrote:

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.