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
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.