diff options
| -rw-r--r-- | control-spec.txt | 29 | ||||
| -rw-r--r-- | proposals/000-index.txt | 2 | ||||
| -rw-r--r-- | proposals/338-netinfo-y2038.md | 79 | ||||
| -rw-r--r-- | proposals/BY_INDEX.md | 1 | ||||
| -rw-r--r-- | proposals/README.md | 1 | ||||
| -rw-r--r-- | pt-spec.txt | 3 |
6 files changed, 112 insertions, 3 deletions
diff --git a/control-spec.txt b/control-spec.txt index 0e2add3..af0368a 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -2425,6 +2425,14 @@ Table of Contents "DETACHED" / ; Detached from circuit; still retriable "CONTROLLER_WAIT" ; Waiting for controller to use ATTACHSTREAM ; (new in 0.4.5.1-alpha) + "XOFF_SENT" ; XOFF has been sent for this stream + ; (new in 0.4.7.5-alpha) + "XOFF_RECV" ; XOFF has been received for this stream + ; (new in 0.4.7.5-alpha) + "XON_SENT" ; XON has been sent for this stream + ; (new in 0.4.7.5-alpha) + "XON_RECV" ; XON has been received for this stream + ; (new in 0.4.7.5-alpha) Target = TargetAddress ":" Port Port = an integer from 0 to 65535 inclusive @@ -3430,14 +3438,21 @@ Table of Contents "WRITTEN=" BytesWritten SP "TIME=" Time SP "DELIVERED_READ=" DeliveredBytesRead SP "OVERHEAD_READ=" OverheadBytesRead SP - "DELIVERED_WRITTEN=" DeliveredBytesWritten CRLF + "DELIVERED_WRITTEN=" DeliveredBytesWritten SP "OVERHEAD_WRITTEN=" OverheadBytesWritten SP + "SS=" SlowStartState SP + "CWND=" CWNDCells SP + "RTT=" RTTMilliseconds SP + "MIN_RTT=" RTTMilliseconds CRLF BytesRead = 1*DIGIT BytesWritten = 1*DIGIT OverheadBytesRead = 1*DIGIT OverheadBytesWritten = 1*DIGIT DeliveredBytesRead = 1*DIGIT DeliveredBytesWritten = 1*DIGIT + SlowStartState = 0 or 1 + CWNDCells = 1*DIGIT + RTTMilliseconds= 1*DIGIT Time = ISOTime2Frac BytesRead and BytesWritten are the number of bytes read and written @@ -3465,6 +3480,16 @@ Table of Contents The Time field is provided only in versions 0.3.2.1-alpha and later. It records when Tor created the bandwidth event. + The SS, CWND, RTT, and MIN_RTT fields are present only if the circuit + has negotiated congestion control to an onion service or Exit hop (any + intermediate leaky pipe congestion control hops are not examined here). + SS provides an indication if the circuit is in slow start (1), or not (0). + CWND is the size of the congestion window in terms of number of cells. + RTT is the N_EWMA smoothed current RTT value, and MIN_RTT is the minimum + RTT value of the circuit. The SS and CWND fields apply only to the + upstream direction of the circuit. The slow start state and CWND values + of the other endpoint may be different. + These events are generated about once per second per circuit; no events are generated for circuits that had no attached stream writing or reading. @@ -3474,6 +3499,8 @@ Table of Contents [DELIVERED_READ, OVERHEAD_READ, DELIVERED_WRITTEN, and OVERHEAD_WRITTEN were added in Tor 0.3.4.0-alpha] + [SS, CWND, RTT, and MIN_RTT were added in Tor 0.4.7.5-alpha] + 4.1.23. Per-circuit cell stats The syntax is: diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 40152dd..c078e13 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -258,6 +258,7 @@ Proposals by number: 335 An authority-only design for MiddleOnly [CLOSED] 336 Randomized schedule for guard retries [OPEN] 337 A simpler way to decide, "Is this guard usable?" [OPEN] +338 Use an 8-byte timestamp in NETINFO cells [OPEN] Proposals by status: @@ -300,6 +301,7 @@ Proposals by status: 330 Modernizing authority contact entries 336 Randomized schedule for guard retries 337 A simpler way to decide, "Is this guard usable?" + 338 Use an 8-byte timestamp in NETINFO cells ACCEPTED: 265 Load Balancing with Overhead Parameters [for 0.2.9.x] 275 Stop including meaningful "published" time in microdescriptor consensus [for 0.3.1.x-alpha] diff --git a/proposals/338-netinfo-y2038.md b/proposals/338-netinfo-y2038.md new file mode 100644 index 0000000..a1a0385 --- /dev/null +++ b/proposals/338-netinfo-y2038.md @@ -0,0 +1,79 @@ +``` +Filename: 338-netinfo-y2038.md +Title: Use an 8-byte timestamp in NETINFO cells +Author: Nick Mathewson +Created: 2022-03-14 +Status: Open +``` + +# Introduction + +Currently Tor relays use a 4-byte timestamp (in seconds since the Unix +epoch) in their NETINFO cells. Notoriously, such a timestamp will +overflow on 19 January 2038. + +Let's get ahead of the problem and squash this issue now, by expanding +the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough +to outlast the Earth's sun.) + +# Proposed change + +I propose adding a new link protocol version. (The next one in +sequence, as of this writing, is version 6.) + +I propose that we change the text of tor-spec section 4.5 from: + +``` + TIME (Timestamp) [4 bytes] +``` + +to + +``` + TIME (Timestamp) [4 or 8 bytes *] +``` + +and specify that this field is 4 bytes wide on link protocols 1-5, but 8 +bytes wide on link protocols 6 and beyond. + +# Rejected alternatives + +Our protocol specifies that parties MUST ignore extra data at the end of +cells. Therefore we _could_ add additional data at the end of the +NETINFO cell, and use that to store the high 4 bytes of the timestamp +without having to increase the link protocol version number. I propose +that we don't do that: it's ugly. + +As another alternative, we could declare that parties must interpret the +timestamp such that its high 4 bytes place it as close as possible to +their current time. I'm rejecting this kludge because it would give +confusing results in the too-common case where clients have their clocks +mis-set to Jan 1, 1970. + +# Impacts on our implementations + +Arti won't be able to implement this change until it supports connection +padding (as required by link protocol 5), which is currently planned for +the next Arti milestone (1.0.0, scheduled for this fall). + +If we think that that's a problem, or if we want to have support for +implementations without connection padding in the future, we should +reconsider this plan so that connection padding support is independent +from 8-byte timestamps. + +# Other timestamps in Tor + +I've done a cursory search of our protocols to see if we have any other +instances of the Y2038 problem. + +There is a 4-byte timestamp in `cert-spec`, but that one is an unsigned +integer counting _hours_ since the Unix epoch, which will keep it from +wrapping around till 478756 C.E. (The rollover date of "10136 CE" +reported in `cert-spec` is wrong, and seems to be based on the +misapprehension that the counter is in *minutes*.) + +The v2 onion service protocol has 4-byte timestamps, but it is +thoroughly deprecated and unsupported. + +I couldn't find any other 4-byte timestamps, but that is no guarantee: +others should look for them too. diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md index e6bf782..484ad13 100644 --- a/proposals/BY_INDEX.md +++ b/proposals/BY_INDEX.md @@ -255,4 +255,5 @@ Below are a list of proposals sorted by their proposal number. See * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An authority-only design for MiddleOnly [CLOSED] * [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries [OPEN] * [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" [OPEN] +* [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells [OPEN] diff --git a/proposals/README.md b/proposals/README.md index 512ea26..8152d8b 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -42,6 +42,7 @@ for discussion. * [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries * [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries * [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" +* [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells ## ACCEPTED proposals: slated for implementation diff --git a/pt-spec.txt b/pt-spec.txt index 05421c1..45b4c31 100644 --- a/pt-spec.txt +++ b/pt-spec.txt @@ -1,4 +1,3 @@ - Pluggable Transport Specification (Version 1) Abstract @@ -668,7 +667,7 @@ Table of Contents The format of the message: - STATUS TRANSPORT=Transport <K_1>=<V_1> [<K_2>=<V_2>, ...] + STATUS TRANSPORT=Transport <K_1>=<V_1> [<K_2>=<V_2> ...] The TRANSPORT value indicates a hint on what the PT is such has the name or the protocol used for instance. As an example, obfs4proxy would use |