node to node protocol redesign

[majestrate]

⚠️ please note ⚠️

these are NOT a part of the node to node protocol, nor are they a proposal. these are brain dumps of my thoughts while reviewing feedback on #2168

preface

our current wire protocol "works" except when it doesn't, it's very NIH and we want to replace it yada yada tech debt tirade goes here. we have decided it will go and be replaced by quic tls/1.3 which is an improvement. that being said, now we have a chance to redo inter node messages. i'll have to start with a quick rundown on what the requirements, responsibility and limitations are.

this is a thread for discussing the upgraded node to node protocol, specifically WHAT is in the messages we send between nodes, not how. the design decisions on it that we talked in our internal voice chat i tend to forget a lot of it so i wanted to write this down so it's not forgotten and to have it accessible outside my head.

it also provides a place where we can iterate on it and provide a record of what we thought up and eliminated in our design phase.

high level requirements

the messages sent between nodes would provide the following generic functionality.

• we need to be able to do path builds, see Update Documentation #2127 for some of the details on how some of that works now.
• we need to handle RC gossip, see Gossip protocol for router snode propagation #1055 on what that is and why it was added.
• we need to handle onion encryption at each hop on paths built.
• we need to query the network for things like introsets, service descriptors and router contacts.
• probably a few other things i forgot when writing this.

current thoughts and the previous attempts and their pitfalls

these few things that i did not originally notice:

path builds

we can make path build and path confirm messages "guaranteed" by using a sub stream. this makes it so that path build messages can be bigger if we wanted.

we can also use this sub stream to send control messages on this path.

use cases of control messages include but are not limited to:

• modify some kind of setiting per hop, like qos, or user specified constant delays.
• tear down the path early.
• extend the lifetime of a path,
• rekey the path at each or some hops,
• partially rewrite which hops are used (like if we know a middle hop is dead we could partially rebuild around it, this would require some more thoughts like how we can authenticate this to snodes that didnt die, we also need to think about infinite path extensions and how to prevent them if we do partial hop rewrites).

we could build multiple sub streams in the path build too that would apply onion encryption that we can use to onion route a stream to the snode at the other end so we can request things ons namehash, introset, RCs, etc via those. this would de-duplicate responsibilities that are currently stuck up across multiple parts of the protocol right now.

fragmentation

i know right now we fragment node to node messages for onion routed data but we dont HAVE to. if we make the onion routed data messages drop tolerant we can do reassembly at each end of the path.

putting fragmentation out of the link layer has 2 dimensions of complexity:

• we could propagate congestion/drop related hints on these new node to node messages but right now the mechanism for that is not currently explored much. also what kind of info would we add? how is it authenticated? can it be authenticated? these must be addressed to avoid tagging attacks.
• how many fragments would we allow? this is the packing problem, and splitting things into max of 2 fragments seems simple enough but i feel like this could be explored more. also the actual sizes of these would need to be fully calculated and decided on to get the maximum bang for buck.

we dont have a DHT anymore

we have a hash ring, thus we dont really recurse in any of our lookups, given that we can basically omit DHT messages and this makes it so that all the inter node messages for that are revisited as well. thank god, no more SLV (single letter variables)

[majestrate]

cc @jagerman @tewinget @dr7ana

[Pantyhose-X]

Exit node DGA spoofing

user ---> Exit node ---> DGA ---> Internet

This reduces the risk of node address exposed.