torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2024-11-27 03:40:47 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

prop339: Fix couple typos

Browse Source 
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit is contained in:
David Goulet 2022-05-04 13:36:29 -04:00
parent 6c19c28090
commit 0b19ef1ba3
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
proposals/339-udp-over-tor.md
View File

@ -100,7 +100,7 @@ a while, to know when we can treat a stream as definitively gone-away.)
Optimistic traffic is permitted as with TCP streams: a client MAY send
`DATAGRAM` messages immediately after its `BIND_UDP` message, without
waiting for a `CONNECTED`. These are dropped if the `BIND` fails.
waiting for a `CONNECTED`. These are dropped if the `BIND_UDP` fails.
Clients and exits MAY drop incoming datagrams if their stream
or circuit buffers are too full. (Once a DATAGRAM message has been sent
@ -249,7 +249,7 @@ Because of security concerns I don't suggest that we support unconnected
sockets in the first version of this protocol. But _if we did_, here's how
I'd suggest we do it.
1. We would add a new "`FLAG_UNCONNECTED`" flag for `BIND_UDP` messaages.
1. We would add a new "`FLAG_UNCONNECTED`" flag for `BIND_UDP` messages.
2. We would designate the ANY addresses 0.0.0.0:0 and [::]:0 as permitted in
`BIND_UDP` messages, and as indicating unconnected sockets. These would
@ -278,7 +278,6 @@ p4u accept PortList
p6u accept PortList
```
(We need to include the policies in relay descriptors so that the
authorities can include them in the microdescriptors when voting.)
@ -293,7 +292,6 @@ would not necessarily mean that they permitted datagram streams, if
their exit policies did not say so.
# MTU notes and issues
Internet time. I might have this wrong.