understanding.rst
1 .. _understanding-main: 2 3 *********************** 4 Understanding Reticulum 5 *********************** 6 This chapter will briefly describe the overall purpose and operating principles of Reticulum. 7 It should give you an overview of how the stack works, and an understanding of how to 8 develop networked applications using Reticulum. 9 10 This chapter is not an exhaustive source of information on Reticulum, at least not yet. Currently, 11 the only complete repository, and final authority on how Reticulum actually functions, is the Python 12 reference implementation and API reference. That being said, this chapter is an essential resource in 13 understanding how Reticulum works from a high-level perspective, along with the general principles of 14 Reticulum, and how to apply them when creating your own networks or software. 15 16 After reading this document, you should be well-equipped to understand how a Reticulum network 17 operates, what it can achieve, and how you can use it yourself. If you want to help out with the 18 development, this is also the place to start, since it will provide a pretty clear overview of the 19 sentiments and the philosophy behind Reticulum, what problems it seeks to solve, and how it 20 approaches those solutions. 21 22 .. _understanding-motivation: 23 24 Motivation 25 ========== 26 27 The primary motivation for designing and implementing Reticulum has been the current lack of 28 reliable, functional and secure minimal-infrastructure modes of digital communication. It is my 29 belief that it is highly desirable to create a reliable and efficient way to set up long-range digital 30 communication networks that can securely allow exchange of information between people and 31 machines, with no central point of authority, control, censorship or barrier to entry. 32 33 Almost all of the various networking systems in use today share a common limitation: They 34 require large amounts of coordination and centralised trust and power to function. To join such networks, you need approval 35 of gatekeepers in control. This need for coordination and trust inevitably leads to an environment of 36 central control, where it's very easy for infrastructure operators or governments to control or alter 37 traffic, and censor or persecute unwanted actors. It also makes it completely impossible to freely deploy 38 and use networks at will, like one would use other common tools that enhance individual agency and freedom. 39 40 Reticulum aims to require as little coordination and trust as possible. It aims to make secure, 41 anonymous and permissionless networking and information exchange a tool that anyone can just pick up and use. 42 43 Since Reticulum is completely medium agnostic, it can be used to build networks on whatever is best 44 suited to the situation, or whatever you have available. In some cases, this might be packet radio 45 links over VHF frequencies, in other cases it might be a 2.4 GHz 46 network using off-the-shelf radios, or it might be using common LoRa development boards. 47 48 At the time of release of this document, the fastest and easiest setup for development and testing is using 49 LoRa radio modules with an open source firmware (see the section :ref:`Reference Setup<understanding-referencesystem>`), 50 connected to any kind of computer or mobile device that Reticulum can run on. 51 52 The ultimate aim of Reticulum is to allow anyone to be their own network operator, and to make it 53 cheap and easy to cover vast areas with a myriad of independent, interconnectable and autonomous networks. 54 Reticulum **is not** *one network*, it **is a tool** to build *thousands of networks*. Networks without 55 kill-switches, surveillance, censorship and control. Networks that can freely interoperate, associate and disassociate 56 with each other, and require no central oversight. Networks for human beings. *Networks for the people*. 57 58 .. _understanding-goals: 59 60 Goals 61 ===== 62 63 To be as widely usable and efficient to deploy as possible, the following goals have been used to 64 guide the design of Reticulum: 65 66 67 * **Fully useable as open source software stack** 68 Reticulum must be implemented with, and be able to run using only open source software. This is 69 critical to ensuring the availability, security and transparency of the system. 70 * **Hardware layer agnosticism** 71 Reticulum must be fully hardware agnostic, and shall be useable over a wide range of 72 physical networking layers, such as data radios, serial lines, modems, handheld transceivers, 73 wired Ethernet, WiFi, or anything else that can carry a digital data stream. Hardware made for 74 dedicated Reticulum use shall be as cheap as possible and use off-the-shelf components, so 75 it can be easily modified and replicated by anyone interested in doing so. 76 * **Very low bandwidth requirements** 77 Reticulum should be able to function reliably over links with a transmission capacity as low 78 as *5 bits per second*. 79 * **Encryption by default** 80 Reticulum must use strong encryption by default for all communication. 81 * **Initiator Anonymity** 82 It must be possible to communicate over a Reticulum network without revealing any identifying 83 information about oneself. 84 * **Unlicensed use** 85 Reticulum shall be functional over physical communication mediums that do not require any 86 form of license to use. Reticulum must be designed in a way, so it is usable over ISM radio 87 frequency bands, and can provide functional long distance links in such conditions, for example 88 by connecting a modem to a PMR or CB radio, or by using LoRa or WiFi modules. 89 * **Supplied software** 90 In addition to the core networking stack and API, that allows a developer to build 91 applications with Reticulum, a basic set of Reticulum-based communication tools must be 92 implemented and released along with Reticulum itself. These shall serve both as a 93 functional, basic communication suite, and as an example and learning resource to others wishing 94 to build applications with Reticulum. 95 * **Ease of use** 96 The reference implementation of Reticulum is written in Python, to make it easy to use 97 and understand. A programmer with only basic experience should be able to use 98 Reticulum to write networked applications. 99 * **Low cost** 100 It shall be as cheap as possible to deploy a communication system based on Reticulum. This 101 should be achieved by using cheap off-the-shelf hardware that potential users might already 102 own. The cost of setting up a functioning node should be less than $100 even if all parts 103 needs to be purchased. 104 105 .. _understanding-basicfunctionality: 106 107 Introduction & Basic Functionality 108 ================================== 109 110 Reticulum is a networking stack suited for high-latency, low-bandwidth links. Reticulum is at its 111 core a *message oriented* system. It is suited for both local point-to-point or point-to-multipoint 112 scenarios where all nodes are within range of each other, as well as scenarios where packets need 113 to be transported over multiple hops in a complex network to reach the recipient. 114 115 Reticulum does away with the idea of addresses and ports known from IP, TCP and UDP. Instead 116 Reticulum uses the singular concept of *destinations*. Any application using Reticulum as its 117 networking stack will need to create one or more destinations to receive data, and know the 118 destinations it needs to send data to. 119 120 All destinations in Reticulum are _represented_ as a 16 byte hash. This hash is derived from truncating a full 121 SHA-256 hash of identifying characteristics of the destination. To users, the destination addresses 122 will be displayed as 16 hexadecimal bytes, like this example: ``<13425ec15b621c1d928589718000d814>``. 123 124 The truncation size of 16 bytes (128 bits) for destinations has been chosen as a reasonable trade-off 125 between address space 126 and packet overhead. The address space accommodated by this size can support many billions of 127 simultaneously active devices on the same network, while keeping packet overhead low, which is 128 essential on low-bandwidth networks. In the very unlikely case that this address space nears 129 congestion, a one-line code change can upgrade the Reticulum address space all the way up to 256 130 bits, ensuring the Reticulum address space could potentially support galactic-scale networks. 131 This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should 132 be sufficient, even far into the future. 133 134 By default Reticulum encrypts all data using elliptic curve cryptography and AES. Any packet sent to a 135 destination is encrypted with a per-packet derived key. Reticulum can also set up an encrypted 136 channel to a destination, called a *Link*. Both data sent over Links and single packets offer 137 *Initiator Anonymity*. Links additionally offer *Forward Secrecy* by default, employing an Elliptic Curve 138 Diffie Hellman key exchange on Curve25519 to derive per-link ephemeral keys. Asymmetric, link-less 139 packet communication can also provide forward secrecy, with automatic key ratcheting, by enabling 140 ratchets on a per-destination basis. The multi-hop transport, coordination, verification and reliability 141 layers are fully autonomous and also based on elliptic curve cryptography. 142 143 Reticulum also offers symmetric key encryption for group-oriented communications, as well as 144 unencrypted packets for local broadcast purposes. 145 146 Reticulum can connect to a variety of interfaces such as radio modems, data radios and serial ports, 147 and offers the possibility to easily tunnel Reticulum traffic over IP links such as the Internet or 148 private IP networks. 149 150 .. _understanding-destinations: 151 152 Destinations 153 ------------ 154 155 To receive and send data with the Reticulum stack, an application needs to create one or more 156 destinations. Reticulum uses three different basic destination types, and one special: 157 158 159 * **Single** 160 The *single* destination type is the most common type in Reticulum, and should be used for 161 most purposes. It is always identified by a unique public key. Any data sent to this 162 destination will be encrypted using ephemeral keys derived from an ECDH key exchange, and will 163 only be readable by the creator of the destination, who holds the corresponding private key. 164 * **Plain** 165 A *plain* destination type is unencrypted, and suited for traffic that should be broadcast to a 166 number of users, or should be readable by anyone. Traffic to a *plain* destination is not encrypted. 167 Generally, *plain* destinations can be used for broadcast information intended to be public. 168 Plain destinations are only reachable directly, and packets addressed to plain destinations are 169 never transported over multiple hops in the network. To be transportable over multiple hops in Reticulum, information 170 *must* be encrypted, since Reticulum uses the per-packet encryption to verify routing paths and 171 keep them alive. 172 * **Group** 173 The *group* special destination type, that defines a symmetrically encrypted virtual destination. 174 Data sent to this destination will be encrypted with a symmetric key, and will be readable by 175 anyone in possession of the key, but as with the *plain* destination type, packets to this type 176 of destination are not currently transported over multiple hops, although a planned upgrade 177 to Reticulum will allow globally reachable *group* destinations. 178 * **Link** 179 A *link* is a special destination type, that serves as an abstract channel to a *single* 180 destination, directly connected or over multiple hops. The *link* also offers reliability and 181 more efficient encryption, forward secrecy, initiator anonymity, and as such can be useful even 182 when a node is directly reachable. It also offers a more capable API and allows easily carrying 183 out requests and responses, large data transfers and more. 184 185 .. _understanding-destinationnaming: 186 187 Destination Naming 188 ^^^^^^^^^^^^^^^^^^ 189 190 Destinations are created and named in an easy to understand dotted notation of *aspects*, and 191 represented on the network as a hash of this value. The hash is a SHA-256 truncated to 128 bits. The 192 top level aspect should always be a unique identifier for the application using the destination. 193 The next levels of aspects can be defined in any way by the creator of the application. 194 195 Aspects can be as long and as plentiful as required, and a resulting long destination name will not 196 impact efficiency, as names are always represented as truncated SHA-256 hashes on the network. 197 198 As an example, a destination for a environmental monitoring application could be made up of the 199 application name, a device type and measurement type, like this: 200 201 .. code-block:: text 202 203 app name : environmentlogger 204 aspects : remotesensor, temperature 205 206 full name : environmentlogger.remotesensor.temperature 207 hash : 4faf1b2e0a077e6a9d92fa051f256038 208 209 For the *single* destination, Reticulum will automatically append the associated public key as a 210 destination aspect before hashing. This is done to ensure only the correct destination is reached, 211 since anyone can listen to any destination name. Appending the public key ensures that a given 212 packet is only directed at the destination that holds the corresponding private key to decrypt the 213 packet. 214 215 **Take note!** There is a very important concept to understand here: 216 217 * Anyone can use the destination name ``environmentlogger.remotesensor.temperature`` 218 219 * Each destination that does so will still have a unique destination hash, and thus be uniquely 220 addressable, because their public keys will differ. 221 222 In actual use of *single* destination naming, it is advisable not to use any uniquely identifying 223 features in aspect naming. Aspect names should be general terms describing what kind of destination 224 is represented. The uniquely identifying aspect is always achieved by appending the public key, 225 which expands the destination into a uniquely identifiable one. Reticulum does this automatically. 226 227 Any destination on a Reticulum network can be addressed and reached simply by knowing its 228 destination hash (and public key, but if the public key is not known, it can be requested from the 229 network simply by knowing the destination hash). The use of app names and aspects makes it easy to 230 structure Reticulum programs and makes it possible to filter what information and data your program 231 receives. 232 233 To recap, the different destination types should be used in the following situations: 234 235 * **Single** 236 When private communication between two endpoints is needed. Supports multiple hops. 237 * **Group** 238 When private communication between two or more endpoints is needed. Supports multiple hops 239 indirectly, but must first be established through a *single* destination. 240 * **Plain** 241 When plain-text communication is desirable, for example when broadcasting information, or for local discovery purposes. 242 243 To communicate with a *single* destination, you need to know its public key. Any method for 244 obtaining the public key is valid, but Reticulum includes a simple mechanism for making other 245 nodes aware of your destinations public key, called the *announce*. It is also possible to request 246 an unknown public key from the network, as all transport instances serve as a distributed ledger 247 of public keys. 248 249 Note that public key information can be shared and verified in other ways than using the 250 built-in *announce* functionality, and that it is therefore not required to use the *announce* and *path request* 251 functionality to obtain public keys. It is by far the easiest though, and should definitely be used 252 if there is not a very good reason for doing it differently. 253 254 .. _understanding-keyannouncements: 255 256 Public Key Announcements 257 ------------------------ 258 259 An *announce* will send a special packet over any relevant interfaces, containing all needed 260 information about the destination hash and public key, and can also contain some additional, 261 application specific data. The entire packet is signed by the sender to ensure authenticity. It is not 262 required to use the announce functionality, but in many cases it will be the simplest way to share 263 public keys on the network. The announce mechanism also serves to establish end-to-end connectivity 264 to the announced destination, as the announce propagates through the network. 265 266 As an example, an announce in a simple messenger application might contain the following information: 267 268 269 * The announcers destination hash 270 * The announcers public key 271 * Application specific data, in this case the users nickname and availability status 272 * A random blob, making each new announce unique 273 * An Ed25519 signature of the above information, verifying authenticity 274 275 With this information, any Reticulum node that receives it will be able to reconstruct an outgoing 276 destination to securely communicate with that destination. You might have noticed that there is one 277 piece of information lacking to reconstruct full knowledge of the announced destination, and that is 278 the aspect names of the destination. These are intentionally left out to save bandwidth, since they 279 will be implicit in almost all cases. The receiving application will already know them. If a destination 280 name is not entirely implicit, information can be included in the application specific data part that 281 will allow the receiver to infer the naming. 282 283 It is important to note that announces will be forwarded throughout the network according to a 284 certain pattern. This will be detailed in the section 285 :ref:`The Announce Mechanism in Detail<understanding-announce>`. 286 287 In Reticulum, destinations are allowed to move around the network at will. This is very different from 288 protocols such as IP, where an address is always expected to stay within the network segment it was assigned in. 289 This limitation does not exist in Reticulum, and any destination is *completely portable* over the entire topography 290 of the network, and *can even be moved to other Reticulum networks* than the one it was created in, and 291 still become reachable. To update its reachability, a destination simply needs to send an announce on any 292 networks it is part of. After a short while, it will be globally reachable in the network. 293 294 Seeing how *single* destinations are always tied to a private/public key pair leads us to the next topic. 295 296 .. _understanding-identities: 297 298 Identities 299 ---------- 300 301 In Reticulum, an *identity* does not necessarily represent a personal identity, but is an abstraction that 302 can represent any kind of *verifiable entity*. This could very well be a person, but it could also be the 303 control interface of a machine, a program, robot, computer, sensor or something else entirely. In 304 general, any kind of agent that can act, or be acted upon, or store or manipulate information, can be 305 represented as an identity. An *identity* can be used to create any number of destinations. 306 307 A *single* destination will always have an *identity* tied to it, but not *plain* or *group* 308 destinations. Destinations and identities share a multilateral connection. You can create a 309 destination, and if it is not connected to an identity upon creation, it will just create a new one to use 310 automatically. This may be desirable in some situations, but often you will probably want to create 311 the identity first, and then use it to create new destinations. 312 313 As an example, we could use an identity to represent the user of a messaging application. 314 Destinations can then be created by this identity to allow communication to reach the user. 315 In all cases it is of great importance to store the private keys associated with any 316 Reticulum Identity securely and privately, since obtaining access to the identity keys equals 317 obtaining access and controlling reachability to any destinations created by that identity. 318 319 .. _understanding-gettingfurther: 320 321 Getting Further 322 --------------- 323 324 The above functions and principles form the core of Reticulum, and would suffice to create 325 functional networked applications in local clusters, for example over radio links where all interested 326 nodes can directly hear each other. But to be truly useful, we need a way to direct traffic over multiple 327 hops in the network. 328 329 In the following sections, two concepts that allow this will be introduced, *paths* and *links*. 330 331 .. _understanding-transport: 332 333 Reticulum Transport 334 =================== 335 336 The methods of routing used in traditional networks are fundamentally incompatible with the physical medium 337 types and circumstances that Reticulum was designed to handle. These mechanisms mostly assume trust at the physical layer, 338 and often needs a lot more bandwidth than Reticulum can assume is available. Since Reticulum is designed to 339 survive running over open radio spectrum, no such trust can be assumed, and bandwidth is often very limited. 340 341 To overcome such challenges, Reticulum’s *Transport* system uses asymmetric elliptic curve cryptography to 342 implement the concept of *paths* that allow discovery of how to get information closer to a certain 343 destination. It is important to note that no single node in a Reticulum network knows the complete 344 path to a destination. Every Transport node participating in a Reticulum network will only 345 know the most direct way to get a packet one hop closer to it's destination. 346 347 348 .. _understanding-nodetypes: 349 350 Node Types 351 ---------- 352 353 Currently, Reticulum distinguishes between two types of network nodes. All nodes on a Reticulum network 354 are *Reticulum Instances*, and some are also *Transport Nodes*. If a system running Reticulum is fixed in 355 one place, and is intended to be kept available most of the time, it is a good contender to be a *Transport Node*. 356 357 Any Reticulum Instance can become a Transport Node by enabling it in the configuration. 358 This distinction is made by the user configuring the node, and is used to determine what nodes on the 359 network will help forward traffic, and what nodes rely on other nodes for wider connectivity. 360 361 If a node is an *Instance* it should be given the configuration directive ``enable_transport = No``, which 362 is the default setting. 363 364 If it is a *Transport Node*, it should be given the configuration directive ``enable_transport = Yes``. 365 366 367 .. _understanding-announce: 368 369 The Announce Mechanism in Detail 370 -------------------------------- 371 372 When an *announce* for a destination is transmitted by a Reticulum instance, it will be forwarded by 373 any transport node receiving it, but according to some specific rules: 374 375 376 * | If this exact announce has already been received before, ignore it. 377 378 * | If not, record into a table which Transport Node the announce was received from, and how many times in 379 total it has been retransmitted to get here. 380 381 * | If the announce has been retransmitted *m+1* times, it will not be forwarded any more. By default, *m* is 382 set to 128. 383 384 * | After a randomised delay, the announce will be retransmitted on all interfaces that have bandwidth 385 available for processing announces. By default, the maximum bandwidth allocation for processing 386 announces is set at 2%, but can be configured on a per-interface basis. 387 388 * | If any given interface does not have enough bandwidth available for retransmitting the announce, 389 the announce will be assigned a priority inversely proportional to its hop count, and be inserted 390 into a queue managed by the interface. 391 392 * | When the interface has bandwidth available for processing an announce, it will prioritise announces 393 for destinations that are closest in terms of hops, thus prioritising reachability and connectivity 394 of local nodes, even on slow networks that connect to wider and faster networks. 395 396 * | After the announce has been re-transmitted, and if no other nodes are heard retransmitting the announce 397 with a greater hop count than when it left this node, transmitting it will be retried *r* times. By default, 398 *r* is set to 1. 399 400 * | If a newer announce from the same destination arrives, while an identical one is already waiting 401 to be transmitted, the newest announce is discarded. If the newest announce contains different 402 application specific data, it will replace the old announce. 403 404 Once an announce has reached a node in the network, any other node in direct contact with that 405 node will be able to reach the destination the announce originated from, simply by sending a packet 406 addressed to that destination. Any node with knowledge of the announce will be able to direct the 407 packet towards the destination by looking up the next node with the shortest amount of hops to the 408 destination. 409 410 According to these rules, an announce will propagate throughout the network in a predictable way, 411 and make the announced destination reachable in a short amount of time. Fast networks that have the 412 capacity to process many announces can reach full convergence very quickly, even when constantly adding 413 new destinations. Slower segments of such networks might take a bit longer to gain full knowledge about 414 the wide and fast networks they are connected to, but can still do so over time, while prioritising full 415 and quickly converging end-to-end connectivity for their local, slower segments. 416 417 In general, even extremely complex networks, that utilize the maximum 128 hops will converge to full 418 end-to-end connectivity in about one minute, given there is enough bandwidth available to process 419 the required amount of announces. 420 421 .. _understanding-paths: 422 423 Reaching the Destination 424 ------------------------ 425 426 In networks with changing topology and trustless connectivity, nodes need a way to establish 427 *verified connectivity* with each other. Since the network is assumed to be trustless, Reticulum 428 must provide a way to guarantee that the peer you are communicating with is actually who you 429 expect. Reticulum offers two ways to do this. 430 431 For exchanges of small amounts of information, Reticulum offers the *Packet* API, which works exactly like you would expect - on a per packet level. The following process is employed when sending a packet: 432 433 * | A packet is always created with an associated destination and some payload data. When the packet is sent 434 to a *single* destination type, Reticulum will automatically create an ephemeral encryption key, perform 435 an ECDH key exchange with the destination's public key (or ratchet key, if available), and encrypt the information. 436 437 * | It is important to note that this key exchange does not require any network traffic. The sender already 438 knows the public key of the destination from an earlier received *announce*, and can thus perform the ECDH 439 key exchange locally, before sending the packet. 440 441 * | The public part of the newly generated ephemeral key-pair is included with the encrypted token, and sent 442 along with the encrypted payload data in the packet. 443 444 * | When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the 445 packet. 446 447 * | A new ephemeral key is used for every packet sent in this way. 448 449 * | Once the packet has been received and decrypted by the addressed destination, that destination can opt 450 to *prove* its receipt of the packet. It does this by calculating the SHA-256 hash of the received packet, 451 and signing this hash with its Ed25519 signing key. Transport nodes in the network can then direct this 452 *proof* back to the packets origin, where the signature can be verified against the destination's known 453 public signing key. 454 455 * | In case the packet is addressed to a *group* destination type, the packet will be encrypted with the 456 pre-shared AES-256 key associated with the destination. In case the packet is addressed to a *plain* 457 destination type, the payload data will not be encrypted. Neither of these two destination types can offer 458 forward secrecy. In general, it is recommended to always use the *single* destination type, unless it is 459 strictly necessary to use one of the others. 460 461 462 For exchanges of larger amounts of data, or when longer sessions of bidirectional communication is desired, Reticulum offers the *Link* API. To establish a *link*, the following process is employed: 463 464 * | First, the node that wishes to establish a link will send out a special packet, that 465 traverses the network and locates the desired destination. Along the way, the Transport Nodes that 466 forward the packet will take note of this *link request*. 467 468 * | Second, if the destination accepts the *link request* , it will send back a packet that proves the 469 authenticity of its identity (and the receipt of the link request) to the initiating node. All 470 nodes that initially forwarded the packet will also be able to verify this proof, and thus 471 accept the validity of the *link* throughout the network. 472 473 * | When the validity of the *link* has been accepted by forwarding nodes, these nodes will 474 remember the *link* , and it can subsequently be used by referring to a hash representing it. 475 476 * | As a part of the *link request*, an Elliptic Curve Diffie-Hellman key exchange takes place, that sets up an 477 efficiently encrypted tunnel between the two nodes. As such, this mode of communication is preferred, 478 even for situations when nodes can directly communicate, when the amount of data to be exchanged numbers 479 in the tens of packets, or whenever the use of the more advanced API functions is desired. 480 481 * | When a *link* has been set up, it automatically provides message receipt functionality, through 482 the same *proof* mechanism discussed before, so the sending node can obtain verified confirmation 483 that the information reached the intended recipient. 484 485 * | Once the *link* has been set up, the initiator can remain anonymous, or choose to authenticate towards 486 the destination using a Reticulum Identity. This authentication is happening inside the encrypted 487 link, and is only revealed to the verified destination, and no intermediaries. 488 489 In a moment, we will discuss the details of how this methodology is 490 implemented, but let’s first recap what purposes this methodology serves. We 491 first ensure that the node answering our request is actually the one we want to 492 communicate with, and not a malicious actor pretending to be so. At the same 493 time we establish an efficient encrypted channel. The setup of this is 494 relatively cheap in terms of bandwidth, so it can be used just for a short 495 exchange, and then recreated as needed, which will also rotate encryption keys. 496 The link can also be kept alive for longer periods of time, if this is more 497 suitable to the application. The procedure also inserts the *link id* , a hash 498 calculated from the link request packet, into the memory of forwarding nodes, 499 which means that the communicating nodes can thereafter reach each other simply 500 by referring to this *link id*. 501 502 The combined bandwidth cost of setting up a link is 3 packets totalling 297 bytes (more info in the 503 :ref:`Binary Packet Format<understanding-packetformat>` section). The amount of bandwidth used on keeping 504 a link open is practically negligible, at 0.45 bits per second. Even on a slow 1200 bits per second packet 505 radio channel, 100 concurrent links will still leave 96% channel capacity for actual data. 506 507 508 Link Establishment in Detail 509 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 510 511 After exploring the basics of the announce mechanism, finding a path through the network, and an overview 512 of the link establishment procedure, this section will go into greater detail about the Reticulum link 513 establishment process. 514 515 The *link* in Reticulum terminology should not be viewed as a direct node-to-node link on the 516 physical layer, but as an abstract channel, that can be open for any amount of time, and can span 517 an arbitrary number of hops, where information will be exchanged between two nodes. 518 519 520 * | When a node in the network wants to establish verified connectivity with another node, it 521 will randomly generate a new X25519 private/public key pair. It then creates a *link request* 522 packet, and broadcast it. 523 | 524 | *It should be noted that the X25519 public/private keypair mentioned above is two separate keypairs: 525 An encryption key pair, used for derivation of a shared symmetric key, and a signing key pair, used 526 for signing and verifying messages on the link. They are sent together over the wire, and can be 527 considered as single public key for simplicity in this explanation.* 528 529 * | The *link request* is addressed to the destination hash of the desired destination, and 530 contains the following data: The newly generated X25519 public key *LKi*. 531 532 * | The broadcasted packet will be directed through the network according to the rules laid out 533 previously. 534 535 * | Any node that forwards the link request will store a *link id* in it’s *link table* , along with the 536 amount of hops the packet had taken when received. The link id is a hash of the entire link 537 request packet. If the link request packet is not *proven* by the addressed destination within some 538 set amount of time, the entry will be dropped from the *link table* again. 539 540 * | When the destination receives the link request packet, it will decide whether to accept the request. 541 If it is accepted, the destination will also generate a new X25519 private/public key pair, and 542 perform a Diffie Hellman Key Exchange, deriving a new symmetric key that will be used to encrypt the 543 channel, once it has been established. 544 545 * | A *link proof* packet is now constructed and transmitted over the network. This packet is 546 addressed to the *link id* of the *link*. It contains the following data: The newly generated X25519 547 public key *LKr* and an Ed25519 signature of the *link id* and *LKr* made by the *original signing key* of 548 the addressed destination. 549 550 * | By verifying this *link proof* packet, all nodes that originally transported the *link request* 551 packet to the destination from the originator can now verify that the intended destination received 552 the request and accepted it, and that the path they chose for forwarding the request was valid. 553 In successfully carrying out this verification, the transporting nodes marks the link as active. 554 An abstract bi-directional communication channel has now been established along a path in the network. 555 Packets can now be exchanged bi-directionally from either end of the link simply by adressing the 556 packets to the *link id* of the link. 557 558 * | When the source receives the *proof* , it will know unequivocally that a verified path has been 559 established to the destination. It can now also use the X25519 public key contained in the 560 *link proof* to perform it's own Diffie Hellman Key Exchange and derive the symmetric key 561 that is used to encrypt the channel. Information can now be exchanged reliably and securely. 562 563 564 It’s important to note that this methodology ensures that the source of the request does not need to 565 reveal any identifying information about itself. The link initiator remains completely anonymous. 566 567 When using *links*, Reticulum will automatically verify all data sent over the link, and can also 568 automate retransmissions if *Resources* are used. 569 570 .. _understanding-resources: 571 572 Resources 573 --------- 574 575 For exchanging small amounts of data over a Reticulum network, the :ref:`Packet<api-packet>` interface 576 is sufficient, but for exchanging data that would require many packets, an efficient way to coordinate 577 the transfer is needed. 578 579 This is the purpose of the Reticulum :ref:`Resource<api-resource>`. A *Resource* can automatically 580 handle the reliable transfer of an arbitrary amount of data over an established :ref:`Link<api-link>`. 581 Resources can auto-compress data, will handle breaking the data into individual packets, sequencing 582 the transfer, integrity verification and reassembling the data on the other end. 583 584 :ref:`Resources<api-resource>` are programmatically very simple to use, and only requires a few lines 585 of codes to reliably transfer any amount of data. They can be used to transfer data stored in memory, 586 or stream data directly from files. 587 588 .. _understanding-referencesystem: 589 590 Reference Setup 591 ====================== 592 593 This section will detail a recommended *Reference Setup* for Reticulum. It is important to 594 note that Reticulum is designed to be usable on more or less any computing device, and over more 595 or less any medium that allows you to send and receive data, which satisfies some very low 596 minimum requirements. 597 598 The communication channel must support at least half-duplex operation, and provide an average 599 throughput of 5 bits per second or greater, and supports a physical layer MTU of 500 bytes. The 600 Reticulum stack should be able to run on more or less any hardware that can provide a Python 3.x 601 runtime environment. 602 603 That being said, this reference setup has been outlined to provide a common platform for anyone 604 who wants to help in the development of Reticulum, and for everyone who wants to know a 605 recommended setup to get started experimenting. A reference system consists of three parts: 606 607 * **An Interface Device** 608 Which provides access to the physical medium whereupon the communication 609 takes place, for example a radio with an integrated modem. A setup with a separate modem 610 connected to a radio would also be an interface device. 611 * **A Host Device** 612 Some sort of computing device that can run the necessary software, communicate with the 613 interface device, and provide user interaction. 614 * **A Software Stack** 615 The software implementing the Reticulum protocol and applications using it. 616 617 The reference setup can be considered a relatively stable platform to develop on, and also to start 618 building networks or applications on. While details of the implementation might change at the current stage of 619 development, it is the goal to maintain hardware compatibility for as long as entirely possible, and 620 the current reference setup has been determined to provide a functional platform for many years 621 into the future. The current Reference System Setup is as follows: 622 623 624 * **Interface Device** 625 A data radio consisting of a LoRa radio module, and a microcontroller with open source 626 firmware, that can connect to host devices via USB. It operates in either the 430, 868 or 900 627 MHz frequency bands. More details can be found on the `RNode Page <https://unsigned.io/rnode>`_. 628 * **Host Device** 629 Any computer device running Linux and Python. A Raspberry Pi with a Debian based OS is 630 recommended. 631 * **Software Stack** 632 The most recently released Python Implementation of Reticulum, running on a Debian based 633 operating system. 634 635 To avoid confusion, it is very important to note, that the reference interface device **does not** 636 use the LoRaWAN standard, but uses a custom MAC layer on top of the plain LoRa modulation! As such, you will 637 need a plain LoRa radio module connected to an controller with the correct firmware. Full details on how to 638 get or make such a device is available on the `RNode Page <https://unsigned.io/rnode>`_. 639 640 With the current reference setup, it should be possible to get on a Reticulum network for around 100$ 641 even if you have none of the hardware already, and need to purchase everything. 642 643 This reference setup is of course just a recommendation for getting started easily, and you should 644 tailor it to your own specific needs, or whatever hardware you have available. 645 646 .. _understanding-protocolspecifics: 647 648 Protocol Specifics 649 ================== 650 651 This chapter will detail protocol specific information that is essential to the implementation of 652 Reticulum, but non critical in understanding how the protocol works on a general level. It should be 653 treated more as a reference than as essential reading. 654 655 656 Packet Prioritisation 657 --------------------- 658 659 Currently, Reticulum is completely priority-agnostic regarding general traffic. All traffic is handled 660 on a first-come, first-serve basis. Announce re-transmission are handled according to the re-transmission 661 times and priorities described earlier in this chapter. 662 663 664 Interface Access Codes 665 ---------------------- 666 667 Reticulum can create named virtual networks, and networks that are only accessible by knowing a preshared 668 passphrase. The configuration of this is detailed in the :ref:`Common Interface Options<interfaces-options>` 669 section. To implement these feature, Reticulum uses the concept of Interface Access Codes, that are calculated 670 and verified per packet. 671 672 An interface with a named virtual network or passphrase authentication enabled will derive a shared Ed25519 673 signing identity, and for every outbound packet generate a signature of the entire packet. This signature is 674 then inserted into the packet as an Interface Access Code before transmission. Depending on the speed and 675 capabilities of the interface, the IFAC can be the full 512-bit Ed25519 signature, or a truncated version. 676 Configured IFAC length can be inspected for all interfaces with the ``rnstatus`` utility. 677 678 Upon receipt, the interface will check that the signature matches the expected value, and drop the packet if it 679 does not. This ensures that only packets sent with the correct naming and/or passphrase parameters are allowed to 680 pass onto the network. 681 682 683 .. _understanding-packetformat: 684 685 Wire Format 686 ----------- 687 688 .. code-block:: text 689 690 == Reticulum Wire Format ====== 691 692 A Reticulum packet is composed of the following fields: 693 694 [HEADER 2 bytes] [ADDRESSES 16/32 bytes] [CONTEXT 1 byte] [DATA 0-465 bytes] 695 696 * The HEADER field is 2 bytes long. 697 * Byte 1: [IFAC Flag], [Header Type], [Context Flag], [Propagation Type], 698 [Destination Type] and [Packet Type] 699 * Byte 2: Number of hops 700 701 * Interface Access Code field if the IFAC flag was set. 702 * The length of the Interface Access Code can vary from 703 1 to 64 bytes according to physical interface 704 capabilities and configuration. 705 706 * The ADDRESSES field contains either 1 or 2 addresses. 707 * Each address is 16 bytes long. 708 * The Header Type flag in the HEADER field determines 709 whether the ADDRESSES field contains 1 or 2 addresses. 710 * Addresses are SHA-256 hashes truncated to 16 bytes. 711 712 * The CONTEXT field is 1 byte. 713 * It is used by Reticulum to determine packet context. 714 715 * The DATA field is between 0 and 465 bytes. 716 * It contains the packets data payload. 717 718 IFAC Flag 719 ----------------- 720 open 0 Packet for publically accessible interface 721 authenticated 1 Interface authentication is included in packet 722 723 724 Header Types 725 ----------------- 726 type 1 0 Two byte header, one 16 byte address field 727 type 2 1 Two byte header, two 16 byte address fields 728 729 730 Context Flag 731 ----------------- 732 unset 0 The context flag is used for various types 733 set 1 of signalling, depending on packet context 734 735 736 Propagation Types 737 ----------------- 738 broadcast 0 739 transport 1 740 741 742 Destination Types 743 ----------------- 744 single 00 745 group 01 746 plain 10 747 link 11 748 749 750 Packet Types 751 ----------------- 752 data 00 753 announce 01 754 link request 10 755 proof 11 756 757 758 +- Packet Example -+ 759 760 HEADER FIELD DESTINATION FIELDS CONTEXT FIELD DATA FIELD 761 _______|_______ ________________|________________ ________|______ __|_ 762 | | | | | | | | 763 01010000 00000100 [HASH1, 16 bytes] [HASH2, 16 bytes] [CONTEXT, 1 byte] [DATA] 764 || | | | | 765 || | | | +-- Hops = 4 766 || | | +------- Packet Type = DATA 767 || | +--------- Destination Type = SINGLE 768 || +----------- Propagation Type = TRANSPORT 769 |+------------- Header Type = HEADER_2 (two byte header, two address fields) 770 +-------------- Access Codes = DISABLED 771 772 773 +- Packet Example -+ 774 775 HEADER FIELD DESTINATION FIELD CONTEXT FIELD DATA FIELD 776 _______|_______ _______|_______ ________|______ __|_ 777 | | | | | | | | 778 00000000 00000111 [HASH1, 16 bytes] [CONTEXT, 1 byte] [DATA] 779 || | | | | 780 || | | | +-- Hops = 7 781 || | | +------- Packet Type = DATA 782 || | +--------- Destination Type = SINGLE 783 || +----------- Propagation Type = BROADCAST 784 |+------------- Header Type = HEADER_1 (two byte header, one address field) 785 +-------------- Access Codes = DISABLED 786 787 788 +- Packet Example -+ 789 790 HEADER FIELD IFAC FIELD DESTINATION FIELD CONTEXT FIELD DATA FIELD 791 _______|_______ ______|______ _______|_______ ________|______ __|_ 792 | | | | | | | | | | 793 10000000 00000111 [IFAC, N bytes] [HASH1, 16 bytes] [CONTEXT, 1 byte] [DATA] 794 || | | | | 795 || | | | +-- Hops = 7 796 || | | +------- Packet Type = DATA 797 || | +--------- Destination Type = SINGLE 798 || +----------- Propagation Type = BROADCAST 799 |+------------- Header Type = HEADER_1 (two byte header, one address field) 800 +-------------- Access Codes = ENABLED 801 802 803 Size examples of different packet types 804 --------------------------------------- 805 806 The following table lists example sizes of various 807 packet types. The size listed are the complete on- 808 wire size counting all fields including headers, 809 but excluding any interface access codes. 810 811 - Path Request : 51 bytes 812 - Announce : 167 bytes 813 - Link Request : 83 bytes 814 - Link Proof : 115 bytes 815 - Link RTT packet : 99 bytes 816 - Link keepalive : 20 bytes 817 818 819 .. _understanding-announcepropagation: 820 821 Announce Propagation Rules 822 -------------------------- 823 824 The following table illustrates the rules for automatically propagating announces 825 from one interface type to another, for all possible combinations. For the purpose 826 of announce propagation, the *Full* and *Gateway* modes are identical. 827 828 .. image:: graphics/if_mode_graph_b.png 829 830 See the :ref:`Interface Modes<interfaces-modes>` section for a conceptual overview 831 of the different interface modes, and how they are configured. 832 833 .. 834 (.. code-block:: text) 835 Full ────── ✓ ──┐ ┌── ✓ ── Full 836 AP ──────── ✓ ──┼───> Full >───┼── ✕ ── AP 837 Boundary ── ✓ ──┤ ├── ✓ ── Boundary 838 Roaming ─── ✓ ──┘ └── ✓ ── Roaming 839 840 Full ────── ✕ ──┐ ┌── ✓ ── Full 841 AP ──────── ✕ ──┼────> AP >────┼── ✕ ── AP 842 Boundary ── ✕ ──┤ ├── ✓ ── Boundary 843 Roaming ─── ✕ ──┘ └── ✓ ── Roaming 844 845 Full ────── ✓ ──┐ ┌── ✓ ── Full 846 AP ──────── ✓ ──┼─> Roaming >──┼── ✕ ── AP 847 Boundary ── ✕ ──┤ ├── ✕ ── Boundary 848 Roaming ─── ✕ ──┘ └── ✕ ── Roaming 849 850 Full ────── ✓ ──┐ ┌── ✓ ── Full 851 AP ──────── ✓ ──┼─> Boundary >─┼── ✕ ── AP 852 Boundary ── ✓ ──┤ ├── ✓ ── Boundary 853 Roaming ─── ✕ ──┘ └── ✕ ── Roaming 854 855 856 .. _understanding-primitives: 857 858 Cryptographic Primitives 859 ------------------------ 860 861 Reticulum uses a simple suite of efficient, strong and well-tested cryptographic 862 primitives, with widely available implementations that can be used both on 863 general-purpose CPUs and on microcontrollers. 864 865 One of the primary considerations for choosing this particular set of primitives is 866 that they can be implemented *safely* with relatively few pitfalls, on practically 867 all current computing platforms. 868 869 The primitives listed here **are authoritative**. Anything claiming to be Reticulum, 870 but not using these exact primitives **is not** Reticulum, and possibly an 871 intentionally compromised or weakened clone. The utilised primitives are: 872 873 * Ed25519 for signatures 874 875 * X25519 for ECDH key exchanges 876 877 * HKDF for key derivation 878 879 * Encrypted tokens are based on the Fernet spec 880 881 * Ephemeral keys derived from an ECDH key exchange on Curve25519 882 883 * AES-256 in CBC mode with PKCS7 padding 884 885 * HMAC using SHA256 for message authentication 886 887 * IVs must be generated through ``os.urandom()`` or better 888 889 * No Fernet version and timestamp metadata fields 890 891 * SHA-256 892 893 * SHA-512 894 895 In the default installation configuration, the ``X25519``, ``Ed25519`` and ``AES-256-CBC`` 896 primitives are provided by `OpenSSL <https://www.openssl.org/>`_ (via the `PyCA/cryptography <https://github.com/pyca/cryptography>`_ 897 package). The hashing functions ``SHA-256`` and ``SHA-512`` are provided by the standard 898 Python `hashlib <https://docs.python.org/3/library/hashlib.html>`_. The ``HKDF``, ``HMAC``, 899 ``Token`` primitives, and the ``PKCS7`` padding function are always provided by the 900 following internal implementations: 901 902 - ``RNS/Cryptography/HKDF.py`` 903 - ``RNS/Cryptography/HMAC.py`` 904 - ``RNS/Cryptography/Token.py`` 905 - ``RNS/Cryptography/PKCS7.py`` 906 907 908 Reticulum also includes a complete implementation of all necessary primitives in pure Python. 909 If OpenSSL & PyCA are not available on the system when Reticulum is started, Reticulum will 910 instead use the internal pure-python primitives. A trivial consequence of this is performance, 911 with the OpenSSL backend being *much* faster. The most important consequence however, is the 912 potential loss of security by using primitives that has not seen the same amount of scrutiny, 913 testing and review as those from OpenSSL. 914 915 .. warning:: 916 If you want to use the internal pure-python primitives, it is **highly advisable** that you 917 have a good understanding of the risks that this pose, and make an informed decision on whether 918 those risks are acceptable to you.