Opened 3 years ago

Closed 2 years ago

#22929 closed defect (fixed)

What cells can be sent before a VERSIONS cell, and what is their CIRCID_LEN?

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-spec, spec
Cc: Actual Points:
Parent ID: #18856 Points:
Reviewer: Sponsor:

Description

tor-spec.txt says:

   CIRCID_LEN is 2 for link protocol versions 1, 2, and 3.  CIRCID_LEN
   is 4 for link protocol version 4 or higher.  The VERSIONS cell itself
   always has CIRCID_LEN == 2 for backward compatibility.

But what is the CIRCID_LEN for early VPADDING, AUTHORIZE, or PADDING cells?

   When this handshake is in use, the first cell must
   be VERSIONS, VPADDING or AUTHORIZE, and no other cell type is allowed to
   intervene besides those specified, except for PADDING and VPADDING cells.

Is it valid to send VPADDING, then PADDING, then VERSIONS?
If so, what is their CIRCID_LEN?
Which sentence prevails, the one above, or the one below?

   Parties MUST NOT send any
   other cells on a connection until they have received a VERSIONS cell.

Child Tickets

Change History (5)

comment:1 Changed 3 years ago by teor

Parent ID: #18856

Re-parent spec issues found during to the stem ORPort task to that task

comment:2 in reply to:  description Changed 3 years ago by teor

Replying to teor:

tor-spec.txt says:

   CIRCID_LEN is 2 for link protocol versions 1, 2, and 3.  CIRCID_LEN
   is 4 for link protocol version 4 or higher.  The VERSIONS cell itself
   always has CIRCID_LEN == 2 for backward compatibility.

T1. This isn't strictly true: relays parse and drop duplicate VERSIONS cells, as long as those versions cells are formatted according to the *current* link version. In particular, relays will parse VERSIONS cells with CIRCID_LEN == 4 when link protocol 4 has been negotiated.
See #22931 for details.

But what is the CIRCID_LEN for early VPADDING, AUTHORIZE, or PADDING cells?

T2. PADDING cells are not allowed as the first cell, relays say:

[info] channel_tls_handle_cell: Received unexpected cell command 0 in chan state opening / conn state waiting for renegotiation or V3 handshake; closing the connection.

VPADDING cells are ignored, and the connection proceeds as normal.
It's possible to send any number of VPADDING cells.

   When this handshake is in use, the first cell must
   be VERSIONS, VPADDING or AUTHORIZE, and no other cell type is allowed to
   intervene besides those specified, except for PADDING and VPADDING cells.

Is it valid to send VPADDING, then PADDING, then VERSIONS?

T2. PADDING cells are not allowed before the VERSIONS cell, relays say:

[info] channel_tls_handle_cell: Received unexpected cell command 0 in chan state opening / conn state waiting for renegotiation or V3 handshake; closing the connection.

T3. In fact, PADDING cells don't seem to work after the VERSIONS cell, either. See #22934.

If so, what is their CIRCID_LEN?

T4. Before the first VERSIONS cell, 2. Afterwards, whatever was negotiated.

Which sentence prevails, the one above, or the one below?

   Parties MUST NOT send any
   other cells on a connection until they have received a VERSIONS cell.

T5. VPADDING works fine.

comment:3 Changed 2 years ago by nickm

Keywords: spec added

Add 'spec' keyword to items that are just spec fixes. These can land after the feature-freeze.

comment:4 Changed 2 years ago by teor

Status: newneeds_review

My branch bug22929 fixes #22929 and #22931.

comment:5 Changed 2 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged!

Note: See TracTickets for help on using tickets.