0

NetInfo cells contain the fields Other OR's address [variable] and This OR's addresses [variable]. I was wondering what their usage is. In addition, its documented that the size is variable, but there's no length field that will allow to know the exact size of these fields. So how exactly their size is determined?

1 Answer 1

1

From tor-spec.txt

3. Cell Packet format
...
   The 'Command' field of a fixed-length cell holds one of the following
   values:
...
         8 -- NETINFO     (Time and address info)   (See Sec 4.5)
...
   VERSIONS and NETINFO cells are used to set up connections in link
   protocols v2 and higher; in link protocol v3 and higher, CERTS,
   AUTH_CHALLENGE, and AUTHENTICATE may also be used.  See section 4
   below.

4. Negotiating and initializing connections
...
   When the renegotiation handshake is used, both parties immediately
   send a VERSIONS cell (4.1 below), and after negotiating a link
   protocol version (which will be 2), each send a NETINFO cell (4.5
   below) to confirm their addresses and timestamps.  No other intervening
   cell types are allowed.

   When the in-protocol handshake is used, the initiator sends a
   VERSIONS cell to indicate that it will not be renegotiating.  The
   responder sends a VERSIONS cell, a CERTS cell (4.2 below) to give the
   initiator the certificates it needs to learn the responder's
   identity, an AUTH_CHALLENGE cell (4.3) that the initiator must include
   as part of its answer if it chooses to authenticate, and a NETINFO
   cell (4.5).  As soon as it gets the CERTS cell, the initiator knows
   whether the responder is correctly authenticated.  At this point the
   initiator behaves differently depending on whether it wants to
   authenticate or not. If it does not want to authenticate, it MUST
   send a NETINFO cell.  If it does want to authenticate, it MUST send a
   CERTS cell, an AUTHENTICATE cell (4.4), and a NETINFO.  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 VPADDING cells.

4.5. NETINFO cells

   If version 2 or higher is negotiated, each party sends the other a
   NETINFO cell.  The cell's payload is:

         Timestamp              [4 bytes]
         Other OR's address     [variable]
         Number of addresses    [1 byte]
         This OR's addresses    [variable]

   The address format is a type/length/value sequence as given in
   section 6.4 below, without the final TTL.  The timestamp is a
   big-endian unsigned integer number of seconds since the Unix epoch.

   Implementations MAY use the timestamp value to help decide if their
   clocks are skewed.  Initiators MAY use "other OR's address" to help
   learn which address their connections may be originating from, if they do
   not know it; and to learn whether the peer will treat the current
   connection as canonical.  Implementations SHOULD NOT trust these
   values unconditionally, especially when they come from non-authorities,
   since the other party can lie about the time or IP addresses it sees.

   Initiators SHOULD use "this OR's address" to make sure
   that they have connected to another OR at its canonical address.
   (See 5.3.1 below.)
...

6.4. Remote hostname lookup

...

       Type   (1 octet)
       Length (1 octet)
       Value  (variable-width)
       TTL    (4 octets)
   "Length" is the length of the Value field.
   "Type" is one of:
      0x00 -- Hostname
      0x04 -- IPv4 address
      0x06 -- IPv6 address
      0xF0 -- Error, transient
      0xF1 -- Error, nontransient

So the address value has a header of fixed length that includes the value length, a common pattern in network protocols (e.g. SOCKS).

All this information was found with ctrl+f -> NETINFO. I believe we've linked the specification to you multiple times in answers now, you might like to take the time to read it thoroughly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .