diff options
Diffstat (limited to 'proposals/339-udp-over-tor.md')
| -rw-r--r-- | proposals/339-udp-over-tor.md | 87 |
1 files changed, 49 insertions, 38 deletions
diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md index 2dbe3b5..e5235d1 100644 --- a/proposals/339-udp-over-tor.md +++ b/proposals/339-udp-over-tor.md @@ -3,7 +3,7 @@ Filename: 339-udp-over-tor.md Title: UDP traffic over Tor Author: Nick Mathewson Created: 11 May 2020 -Status: Draft +Status: Accepted ``` # Introduction @@ -11,7 +11,7 @@ Status: Draft Tor currently only supports delivering two kinds of traffic to the internet: TCP data streams, and a certain limited subset of DNS requests. This proposal describes a plan to extend the Tor protocol so -that exit relays can also relay UDP traffic to the network?. +that exit relays can also relay UDP traffic to the network. Why would we want to do this? There are important protocols that use UDP, and in order to support users that rely on these protocols, we'll @@ -149,6 +149,42 @@ along with extensions to some older relay message types. We note in passing how we could extend these messages to support unconnected UDP sockets in the future. +### Common Format + +We define here a common format for an "address" that is used both in a +CONNECT_UDP and CONNECTED_UDP cell. + +#### Address + +Defines an IP or Hostname address along with its port. This can be seen as the +`ADDRPORT` of a `BEGIN` cell defined in tor-spec.txt but with a different +format. + +``` +/* Address types. + + Note that these are the same as in RESOLVED cells. +*/ +const T_HOSTNAME = 0x00; +const T_IPV4 = 0x04; +const T_IPV6 = 0x06; + +struct address { + u8 type IN [T_IPV4, T_IPV6, T_HOSTNAME]; + u8 len; + union addr[type] with length len { + T_IPV4: u32 ipv4; + T_IPV6: u8 ipv6[16]; + T_HOSTNAME: u8 hostname[]; + }; + u16 port; +} +``` + +The `hostname` follows the RFC1035 for its accepted length that is 63 +characters or less that is a `len` between 0 and 255 (bytes). It should +contain a sequence of nonzero octets as in any nul byte results in a malformed +cell. ### CONNECT_UDP @@ -161,26 +197,13 @@ sockets in the future. struct connect_udp_body { /* As in BEGIN cells. */ u32 flags; - /* Tag for union below. */ - u8 addr_type IN [T_HOSTNAME, T_IPV4, T_IPV6]; - /* Length of the following union */ - u8 addr_len; - /* The address to connect to. */ - union address[addr_type] with length addr_len { - T_IPV4: u32 ipv4; - T_IPV6: u8 ipv6[16]; - T_HOSTNAME: nulterm name - }; - u16 port; + /* Address to connect to. */ + struct address addr; // The rest is ignored. // TODO: Is "the rest is ignored" still a good idea? Look at Rochet's // research. } -/* Address types */ -const T_HOSTNAME = 0x01; -const T_IPV4 = 0x04; -const T_IPV6 = 0x06; /* As in BEGIN cells: these control how hostnames are interpreted. Clients MUST NOT send unrecognized flags; relays MUST ignore them. @@ -191,6 +214,10 @@ const FLAG_IPV4_NOT_OKAY = 0x02; const FLAG_IPV6_PREFERRED = 0x04; ``` +A "hostname" is a DNS hostname that can only contain ascii characters. It is +NOT following the large and broad DNS syntax. These behaves exacly like BEGIN +cell behave with regards to the hostname given. + ### CONNECTED_UDP A CONNECTED_UDP cell sent in response to a CONNECT_UDP cell has the following @@ -198,12 +225,6 @@ format. ``` struct udp_connected_body { - /* 5 bytes to distinguish from other CONNECTED_UDP cells. This is not - * strictly necessary, since we can distinguish by context, but - * it's nice to have a way to tell them apart at the parsing stage. - */ - u32 zero IN [0]; - u8 ff IN [0xFF]; /* The address that the relay has bound locally. This might not * be an address that is advertised in the relay's descriptor. */ struct address our_address; @@ -214,27 +235,17 @@ struct udp_connected_body { // TODO: Is "the rest is ignored" still a good idea? Look at Rochet's // research. } - -/* Note that this is a subset of the allowable address parts of a CONNECT_UDP - message */ -struct address { - u8 tag IN [T_IPV4, T_IPV6]; - u8 len; - union addr[tag] with length len { - T_IPV4: u32 ipv4; - T_IPV6: u8 ipv6[16]; - }; - u16 port; -} ``` +Both `our_address` and `their_address` MUST NOT be of type `T_HOSTNAME` else +the cell is considered malformed. + ### DATAGRAM ``` struct datagram_body { /* The datagram body is the entire body of the message. - This length is in the relay message header. - */ + * This length is in the relay message header. */ u8 body[..]; } ``` @@ -253,7 +264,7 @@ I'd suggest we do it. 1. We would add a new "`FLAG_UNCONNECTED`" flag for `CONNECT_UDP` messages. -2. We would designate the ANY addresses 0.0.0.0:0 and [::]:0 as permitted in +2. We would designate the ANY addresses 0.0.0.0:0 and \[::\]:0 as permitted in `CONNECT_UDP` messages, and as indicating unconnected sockets. These would be only permitted along with the `FLAG_UNCONNECTED` flag, and not permitted otherwise. |