[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30704 [Circumvention/Snowflake]: Plan for snowflake update versioning and backwards compatability
#30704: Plan for snowflake update versioning and backwards compatability
-------------------------------------+------------------------
Reporter: cohosh | Owner: (none)
Type: task | Status: new
Priority: Medium | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------+------------------------
Old description:
> We have some upcoming changes that will change the way snowflake
> components talk to each other. We should decide (and possibly on a case-
> by-case basis) how to handle these updates.
> - Do we make sure changes are backwards compatible with clients/proxies
> that haven't updated yet?
> - Should we think about introducing some concept of versioning?
> - If we support older versions, how long until we no longer support them?
>
> Some examples of tickets that we'll need to think about this for:
> - 25429
> - 29206
> - #25985
New description:
We have some upcoming changes that will change the way snowflake
components talk to each other. We should decide (and possibly on a case-
by-case basis) how to handle these updates.
- Do we make sure changes are backwards compatible with clients/proxies
that haven't updated yet?
- Should we think about introducing some concept of versioning?
- If we support older versions, how long until we no longer support them?
Some examples of tickets that we'll need to think about this for:
- #25429
- #29206
- #25985
--
Comment (by dcf):
Ideally, we can keep the proxies as protocol-ignorant as possible, so that
they don't impede changes at the endpoints (end-to-end principle). #29206,
for example, likely won't require any changes in the proxy, which can
continue blindly forwarding anything it receives. Similarly, #25985
ideally only requires changes in the client and broker, not the proxy and
server. The exception to this principle is if we need to change something
about the WebRTC tunnel rather than the data tunnelled within it, for
example if we want to try an unreliable channel.
If we do need to upgrade proxies, my mental model is that proxies are easy
to upgrade (at least the web-based ones) because they
[https://gitweb.torproject.org/pluggable-
transports/snowflake.git/tree/proxy/static/embed.html?id=91255463c68c3ada6adc8718bf380cbd654fe9ef#n4
reboot themselves] once a day. Flash proxy had the same feature, and in
[https://www.bamsoftware.com/talks/ee380-flashproxy/index.html#s14 this
graph] you can see how quickly proxies upgraded when we had them
[[#7063|start sending a cookie]].
([[span(style=background:blanchedalmond;padding:0 0.5ex,--)]] is cookie-
naive; [[span(style=background:darkkhaki;padding:0 0.5ex,unset)]] and
[[span(style=color:white;background:#222222;padding:0 0.5ex,1)]] are
cookie-aware.)
Let's take #29206 as an example. It changes the format of the stream
between client and server to add framing. Here are a few potential ways to
handle it:
1. Flag day. Ignore backward compatibility. Push out an upgraded client
in Tor Browser and try to coordinate an upgrade of the server at roughly
the same time. This of course breaks all clients that do not upgrade, but
we can perhaps get away with that at this stage.
2. Backward-compatible protocol versioning. I think this is what cohosh
is suggesting in comment:13:ticket:29206. We know that the old protocol is
a raw TLS stream, so we can add a header of 00000000 or something to the
new protocol, anything that enables easy distinguishing from the old
protocol. The server peeks at the first few bytes to know what protocol is
in use, and then switches to raw-stream mode or framing mode as
appropriate. 00000000 could change to different numbers to represent
future upgrades. The downside here is code complexity, maintaining two or
more code paths.
3. Parallel deployment. We make a branch for the old protocol and merge
the new protocol into master. We deploy two instances of the server, one
speaking the old protocol and one speaking the new. These could be on
separate IP addresses/domain names, or could even be on the same host, say
!wss://snowflake.bamsoftware.com/ and !wss://snowflake.bamsoftware.com/v2,
with a reverse proxy diverting requests as appropriate. When a client
registers with the broker, it includes a signal that indicates which
protocol version the client supports. The proxy will need to know which
server to connect to, so either we have the have the broker ''tell'' the
proxy which server to connect to instead of having that information
hardcoded in the proxy (something like #25598), or else we maintain two
pools of proxies, one that uses the old server and one that uses the new.
Eventually we deactivate the old server. This way would put the code
complexity in the broker rather than the server, so it depends on the
nature of the code change whether the trade is worth it.
As for sending additional information (such as a version flag) from the
client to the broker, I would ideally like to see that bundled into the
registration blob. comment:16:ticket:29206 suggests using parallel
metadata such as a URL path or HTTP header, but that only works with HTTP-
based rendezvous, not for others that are proposed in #25594. Currently
the rendezvous blob is just the raw text of the [https://w3c.github.io
/webrtc-pc/#dom-rtcsessiondescription RTCSessionDescription] JSON:
{{{
{
"type": "offer",
"sdp": "v=0\r\no=...\r\n"
}
}}}
It would be better if there were another layer so that we could put other
metadata into the blob. Like:
{{{
{
"version": 1,
"foo": "bar",
"sessiondescription": {
"type": "offer",
"sdp": "v=0\r\no=...\r\n"
}
}
}}}
The benefit is that we can bundle all the later into e.g. a DNS request,
and in that way we make the rendezvous method independent of the contents
of the rendezvous method. We could adapt to the nested format in a
backward-compatible way by having the broker check whether there is a
`"sessiondescription"` key at the top level, and if not, synthesize a new
message that has the entire former message nested under that key. The
additional code complexity is not bad: just check for the old format and
convert it to the new format if needed before doing any other processing.
Something similar applies to the broker's response messages toward the
client and proxies. Currently the messages depend on HTTP metadata, namely
the status code (comment:2:ticket:29293). They look like this:
*
{{{
HTTP/2.0 200 OK
Content-Length: 742
{
"type":"answer",
"sdp":"v=0\r\no=...\r\n"
}
}}}
*
{{{
HTTP/2.0 504 Gateway Timeout
Content-Length: 0
}}}
It would be better if ''all'' the necessary information were in the HTTP
body, because that's something that can be easily bundled up into other
channels like DNS or AMP cache. Something like this:
*
{{{
HTTP/2.0 200 OK
Content-Length: 780
{
"status": 200,
{
"type":"answer",
"sdp":"v=0\r\no=...\r\n"
}
}
}}}
*
{{{
HTTP/2.0 504 Gateway Timeout
Content-Length: 21
{
"status": 504
}
}}}
Then we upgrade clients and proxies to only look at the HTTP body and
ignore the status code. We keep sending the old status codes for the
benefit of older clients. Now that I think of it, this is backward-
compatible for error responses, because old clients/proxies will only look
at the status code and ignore the body, but not backward compatible for
status 200, because the format of the body message will change. Maybe we
could keep the toplevel `"type"`/`"body"` as they are, to signify an
implicit status 200. Also, `"status": 504` is just an example; we may
prefer to represent that as a meaningful token like `"status": "no-
proxies"`.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30704#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs