Re: Structuring the BKK spin bit discussion

[Christian Huitema <[e-mail]>]

On 10/31/2018 10:16 AM, Brian Trammell (IETF) wrote:

> In the case that...
>
> - ...an end-to-end connection actually terminates at a location different than the apparent location in the endpoint IP address, because the endpoint IP address is a VPN tunnel endpoint
> - ...the "hidden" endpoint is very far (> ~3000-5000km) from the apparent location
> - ...that VPN tunnel exists solely to make the end-to-end association appear to originate from at or near the VPN tunnel endpoint (e.g., anti-geofencing)

The actual scenario relates to UDP/QUIC proxies, and how they would
compare to TCP/TLS proxies.

Today, I can build a TCP/TLS proxy that accepts connections at port 443,
examines the (possibly encrypted) SNI in the client Hello, establishes a
TCP connection to the hidden destination, and relays TLS packets between
the 2 connections. TCP is hop by hop, TLS is end to end, examining TCP
sequence numbers and ACKs does not reveal the hidden leg of the service.

Suppose that I build a QUIC proxy that accepts UDP packets at port 4433,
and then does pretty much the same job as load balancer: look for the
(possibly encrypted) SNI inside the client hello for initial packets;
look for the destination connection ID in other packets; forward the UDP
packets to the hidden server based on that, and vice versa in the other
direction. This is sort of equivalent to the TCP/TLS proxy scenario: UDP
is hop by hop; QUIC and TLS is end to end. The QUIC messages are
encrypted and don't reveal much, but the spin bit will reveal the
end-to-end RTT.

Of course, examining the content and timing of packets might in both
cases reveal the end-to-end RTT, but layering makes a difference. The
application may be able to implement end-to-end measures to counter the
analysis of end-to-end traffic, but the application cannot easily
influence the spin bit.

-- Christian Huitema