[tor-bugs] #27325 [Core Tor/Tor]: Rework NETINFO cell parsing and generation with trunnel

[Tor Bug Tracker & Wiki]

#27325: Rework NETINFO cell parsing and generation with trunnel
-------------------------------------------------+-------------------------
 Reporter:  rl1987                               |          Owner:  rl1987
     Type:  enhancement                          |         Status:
                                                 |  needs_information
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.0.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  trunnel wireformat heartbleed-       |  Actual Points:
  safety security parsing                        |
Parent ID:  #27143                               |         Points:
 Reviewer:  dgoulet                              |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 Replying to [comment:9 rl1987]:
 > Replying to [comment:8 dgoulet]:
 > > This is my main worry right now:
 https://github.com/torproject/tor/pull/370#pullrequestreview-167479209
 > >
 >
 > In RELAY_RESOLVED there's also TTL value, which NETINFO does not have. I
 suppose we could define an object consisting of type-length-value sequence
 and use it in both cells. That would require to either: 1) Implement file
 include feature in trunnel (AFAIK it doesn't support that) or 2) have both
 RELAY_RESOLVED and NETINFO cells defined in the same trunnel file (e.g.
 cells.trunnel or handshake.trunnel or something).

 Hmmm so I think the `TTL` field is specific to the `RELAY_RESOLVED` cell
 so in theory we could do a trunnel definition (thus obj) that would
 represent an "address" as section 6.4 specifies *without* the TTL.

 Then we would use that object with `RELAY_RESOLVED` and explicitly add the
 TTL field. Sorta makes sense?

 >
 > Or we could explicitly decouple wire formats of the two cells and decide
 that they are independently defined. RELAY_RESOLVED addresses can have one
 of the five types (hostname, IPv4, IPv6, transient error, non-transient
 error), but does the same apply for NETINFO? Does it make sense to ever
 send hostname in NETINFO cell during handshake? Error conditions can
 always happen, but does Tor protocol specify a way to signal them when
 NETINFO cell is needed?
 >
 > My code takes second path, but I think we need to take a step back and
 do a little bit of design work here and possibly a patch to tor-spec
 regarding how addresses are represented in Tor cells and whether or not
 there is/should be a dependency between common part of wire format in
 different cells.

 The problem with changing the format is backward compatibility so changing
 what those cells contain is a big endeavor tbh.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27325#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online