CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This applications claims priority of U.S. Provisional Patent Application S/N 63/323,670 titled Serverless Mutual Authentication (Davis, et al.) filed March 25, 2022, the entire contents of which are hereby incorporated by reference.

BACKGROUND

[0002] This disclosure pertains to computer network operations and security. A fundamental decision in all forms of human communication involves choosing between openness and trust: should one be open to communication from every one, or only those they trust? This decision transcends communication modalities and profoundly influences the interactions between parties once the choice is made.

[0003] The Internet opted for openness. The Internet protocol stack, designed at ARPA and Stanford and transformed into a functional artifact at Berkeley in the late 1970s, was conceived with the notion that new nodes would continually join the Internet (while some existing nodes would temporarily or permanently disconnect due to hardware, communication failure, or organizational issues), and this should be managed with minimal friction. Authorization was expected to occur through an out-of-band mechanism, a reasonable assumption considering the technology' and time. When a $500,000 VAX 11/780 running Berkeley Unix was needed for Internet connection, it was reasonable to assume that inexperienced hackers would not pose a threat.

[0004] In other words, the Internet protocol stack was developed by researchers to facilitate the network's rapid expansion with minimal friction. Given the research-oriented nature of the early Internet and the size and cost of the computers involved, there was no advantage to formally incorporating security' measures. Moreover, the cryptographic operations required for validation and/or encryption were infeasible for those early machines. Although excluding all security concerns from the networking stack was a sensible decision at the time, it institutionalized an openness-first security model that persists today.

[0005] The Internet's design proved extraordinarily effective, considering the assumptions and objectives of the era. In 40 years, the Internet has grown by six orders of magnitude — from fewer than 1,000 nodes to over a billion — without significant alterations to its basic architecture. This remarkable achievement demonstrates the foresight and adaptability inherent in the Internet's fundamental architecture, as envisioned by those early pioneers.

SUMMARY

[0006] This disclosure describes a universal networking system called uNET which provides an alternative approach that enhances network security, automation, and govemability. uNet combines familiar features implemented in new ways, along with new features. These features include serverless mutual authentication, autonomous enforcement of group membership and privileges, automated and distributed infrastructure, and address portability.

[0007] uNet employs pre-distributed keys for serverless authentication between any two nodes prior to the exchange of network traffic, including control traffic. These keys are distributed out-of-band to participating nodes and used in a handshake protocol to establish authentication without generating or requiring additional network traffic.

BRIEF DESCRIPTION OF THE FIGURES

[0008] Figure 1 is a block diagram showing relationships between elements of the uNet Address Cert.

[0009] Figure 2 is a block diagram showing relationships between elements of the uNet Affiliate Membership Cert.

[0010] Figure 3 is a sequence diagram showing the uNet VPU Host handshake.

[0011] Figure 4 is a sequence diagram showing the uNet Available Physical

Connection (APC) process.

[0012] Figure 5 is a sequence diagram showing the uNet Register (R) process.

[0013] Figure 6 is a sequence diagram showing the uNet Route for Destination (RFD) process.

[0014] Figure 7 is a block diagram showing a uNet Prefix Provider creating an Address Cert for a uNet Address Provider.

[0015] Figure 8 is a block diagram showing a uNet Prefix Provider creating its own Address Cert.

[0016] Figure 9 is a block diagram showing a uNet Address Provider creating an Address Cert for a uNet Entity.

[0017] Figure 10 is the first in a series of block diagrams showing the creation of a uNet, showing 2 uNet Entities prior to any connection. [0018] Figure 11 is the second in a series of block diagrams showing the creation of a uNet, showing the APC handshake.

[0019] Figure 12 is the second in a series of block diagrams showing the creation of a uNet, showing the R handshake.

[0020] Figure 13 is the third in a series of block diagrams showing the creation of a uNet, showing the first stage of the RFD handshake.

[0021] Figure 14 is the fourth in a series of block diagrams showing the creation of a uNet, showing the second stage of the RFD handshake.

[0022] Figure 15 is the fifth in a series of block diagrams showing the creation of a uNet, showing the final state of two Entities having completed APC, R, and RFD handshakes. [0023] Figure 16 is the first in a series of block diagrams showing the creation of a uNet VPU, showing the initial out-of-band distribution of Membership Certificates.

[0024] Figure 17 is the second in a series of block diagrams showing the creation of a uNet VPU, showing that in this initial configuration, certain services remain unavailable.

[0025] Figure 18 is the third in a series of block diagrams showing the creation of a uNet VPU, showing that indirect routing is available in a VPU.

[0026] Figure 19 is the fourth in a series of block diagrams showing the creation of a uNet VPU, showing that in this configuration, certain services remain unavailable.

[0027] Figure 20 is the fifth in a series of block diagrams showing the creation of a uNet VPU, showing that the distribution of an Affiliate Membership Cert makes transitive service access available.

DETAILED DESCRIPTION

FOUNDATION

[0028] uNet is a networking system developed to address fundamental issues in modem IP networking. This alternative approach enhances security, automation, and govemability. uNet is a networking platform that combines familiar features, implemented in innovative ways, with original features. These features include serverless mutual authentication, autonomous enforcement of group membership and privileges, automated and distributed infrastructure, address portability.

[0029] uNet employs pre-distributed keys for serverless authentication between any two nodes prior to the exchange of network traffic, including control traffic. These keys are distributed out-of-band to participating nodes and used in a handshake protocol to establish authentication without generating or requiring additional network traffic. [0030] The analogy to cell phone networking is useful for understanding initial and subsequent connections in a uNet network. In a cell phone network, an issuing authority (the carrier) issues an address (the phone number) and a trust bundle (the SIM card and an association of the SIM Card with the IMEI) out-of-band. This typically occurs in the carriers' retail store when the phone is purchased. Once completed, the phone connects to the network by presenting its number, signed by the SIM card. Authentication is automatic because it is pre-bundled. The phone's location is rapidly propagated to the network root, making it instantly reachable from anywhere in the world.

[0031] Similarly, in a uNet network, the persistent uNet address and trust bundle (an SSL certificate, signed by the issuing authority) of a device are transmitted out-of-band and installed on the device in a manner that ensures the trust bundle can be used but not read.

[0032] In the first patent, addresses are tied to the "Roots" that issue them, making it impossible to move them from one root to another. This patent describes an innovation that builds upon the uNet Protocol to produce address portability.

[0033] The resulting system separates addresses from their roots and produces three new entity classes that enable the creation of a new type of virtual networking called Virtual Programmable uNETs (VPUs).

[0034] The three entity types in the VPU system are: uNet Prefix Provider, uNet Address Provider, and Virtual Programmable uNet Host (VPU Host).

[0035] A uNet Prefix Provider is a Certificate Authority that serves as the CA of all Certificate Signing Chains and is solely responsible for authorizing Address Providers. Address Providers may be limited to providing specific types of Addresses, including Public, Private, Translated, Non-Static, etc.

[0036] A uNet “Prefix” is the highest organizational layer of the uNet networking system. A uNet Prefix Provider need only be created when a new, completely isolated uNet network is desired. In general, to benefit from uNet’s autonomy and flexibility, creating an Address Provider is often the more appropriate organization layer.

[0037] A uNet Prefix Provider should not be directly connected to any network or infrastructure; instead, it should use "intermediate" authorities to issue Prefix Certificates.

[0038] Due to the extremely sensitive nature of Prefix issuance, we recommend that a qualified organization (such as ICANN) be empowered to serve this role. A uNet Prefix Provider does not possess an address. It is responsible for controlling the issuance of all prefixes and serves as the root of the certificate signing chain for every infrastructure. This provider stores all Certificate Signing Requests (CSRs) and their corresponding public keys for all issued prefixes. It establishes its own rules to determine the validity of a CSR.

[0039] Furthermore, the uNet Prefix Provider is not connected to any infrastructure. A uNet Address Provider is a Certificate Authority that is solely responsible for issuing Identities within a Prefix. Only Addresses that are signed by the Address Provider of the Prefix will be recognized as valid by other uNet Identities. Within their own specified limits (mandated by the Prefix Provider), an Address Provider may define rules and formats for Addresses they issue.

[0040] uNet Address Providers issue Address Certificates that can be used to prove that the holder of a specific private key is also the holder of a specific uNet Address.

[0041] Figure 1 shows important relationships among components of a uNet Address Certificate.

[0042] A uNet Address Provider is responsible for controlling the issuance of all addresses within a given prefix. Its own address should typically be the reserved "1" Identity within its own prefix. This provider stores all Certificate Signing Requests (CSRs) and their corresponding public keys for all issued addresses. Upon receiving a valid CSR, it responds with an address in the given prefix and the generated public key. The uNet Address Provider sets its own rules to determine the validity of a CSR. Moreover, it is not required to transmit CSRs, addresses, or keys through any specific medium.

[0043] A Virtual Programmable uNet Provider (VPU Host) is any valid Address that services requests to join a VPU and requests to receive VPU services (connectivity, routing, and bridging, etc.) from it. While possession of a valid Address is the only approval needed to make the Address into an VPU Host, a system will still be required to provide the service through any combination of public infrastructure, private infrastructure, or Affiliate Membership Certificates that allow inter-VPU routing.

[0044] Ownership of an address does not grant membership in a VPU. This is a significant change from our original patent. This means that addresses can be used for many different kinds of network tasks.

[0045] When a uNet device connects to a VPU or changes its registration, it sends a message to the VPU host using the underlying network layer for transport, sending authentication information in the initial packet. The VPU host then updates the routing information to the new node and sends an acknowledgment packet to the uNet node. If the uNet device wishes to connect to another uNet device, it sends the message toward the VPU host, relying on uNet's core routing to either discover the node along the way or be routed there by the VPU host or receive notice from the VPU host that the new device is offline. [0046] A VPU is similar to a VPN. A key difference is that VPUs are not siloed. They can be interconnected dynamically while maintaining privacy in a way not possible with IPbased VPNs. Furthermore, a VPU controls the entire infrastructure at all layers, in contrast to the leaf-orientation of VPNs. VPNs are effectively portals across existing networks, whereas VPUs encompass complete networks.

[0047] A VPU is a membership system. Membership in a VPU means members can "network" with other members according to the ad hoc rules of that VPU. These networking rules can cover anything related to connectivity, access control, routing, and bridging. Membership implicitly means agreeing to those rules. Members can join multiple VPUs and remain reachable at the same address across all joined VPUs, as there is only one addressing layer.

[0048] In relation to the original uNet patent, the VPU combines and supersedes the concepts of "Root addresses" and the "Account System" described therein.

[0049] VPU Hosts issue Membership Certificates which prove that an identity is a member of the VPU. These certificates have matching public keys with the Address Certificate of a requesting member. This allows other systems to validate that the real holder of the Address is also potentially allowed to receive network services if validated by the VPU Host. This validation can be either bespoke per device, based on a general set of distributed rules, or managed in some other way by the VPU Host. Note that from a cryptographic standpoint, VPU Hosts are not issuing new cryptographic materials, but rather they are crosssigning member certificates with their own certificates.

[0050] Figure 2 shows important relationships among components of a uNet Affiliate Membership Certificate.

[0051] VPUs can extend routing for its members on behalf of other VPUs, by producing “Affiliate Memberships”. VPU A can authorize VPU B to generate membership certificates that VPU A will honor. The Affiliate Membership allows routing and other VPU services to be transitive.

[0052] If a member of VPU A is granted an Affiliate Membership Certificate by VPU

Host on behalf of VPU Host B, that member will be authorized to request routing services through VPU B Host.

[0053] All members must still complete a required "RFDR" handshake with their own VPU Host, despite their entry point being through an affiliate VPU membership. [0054] A VPU Host can be any Address. The only approval required to convert an Address into a VPU Host is the possession of a valid Address. A VPU Host must either have a VPU Host that permits downstream VPU Hosts or be connected to any VPU Hosts that will be part of its intra-infrastructure network.

[0055] The VPU Host issues a new Membership Certificate for all Addresses, such as devices and users, which will be able to receive or provide routing through the VPU Host's infrastructure and any affiliated VPUs. New certificates can be issued through "virtual out-of- band" automation by requiring automatically issued Addresses to reference an already valid Address from an Address Provider. This approach ensures that the new issuance occurs over properly secured transmissions to already valid Addresses. Figure 3 illustrates this process.

[0056] The VPU Host enables complete Address portability from one VPU to another. It can issue Affiliate Membership Certificates, which allow other VPU Host’s Members to route through them. The VPU Host must announce or disconnect all Route for Destination Request(s) for all destination Addresses in their respective VPU. Approval means that the VPU Host can route for the requesting Address, provided that they are themselves allowed to be a router and they possess a valid Affiliate Membership Certificate. CHALLENGES AND ADVANTAGES

[0057] The growth of the Internet has come at a cost. Since trust was never embedded in the initial Internet architecture, trusted networking and computing have been added subsequently, necessitating layers of manual configuration and creating opportunities for errors and exploitation.

[0058] The architecture's openness has been crucial in enabling the tremendous growth and ubiquity of the Internet and connected devices over the past 40 years. However, it has also led to numerous and severe security issues we face today. To address this situation, uNet adopts the opposite approach — trust. Communication is only possible between mutually trusting parties who have verified their credentials through out-of-band mechanisms. This means that uNet prioritizes trust over promiscuity: it sacrifices rapid, ungovemed expansion for guaranteed trust.

[0059] The core insight underlying the uNet approach is that modem cryptography, when used correctly and with proper precautions against misconfiguration, possesses all the necessary tools for reliable counterparty identification and privacy assurance. However, implementing these cryptography -based tools to ensure counterparty identification and privacy with absolute reliability requires complex, multi-step protocols. These protocols are prone to errors in design, implementation, and configuration and are easy to get wrong. uNet's key innovation is the adoption of a protocol-wide standard for establishing security, rather than one negotiated for each connection.

[0060] U.S. Patent Publication US20160182350A1 describes a protocol for establishing connectivity which moves identity validation to the beginning of the process. No network traffic is permitted until the valid identity of each participating node has been established.

[0061] uNet does not support a protocol-based method for directly issuing identity. Instead, identity must be obtained and installed before any uNet connection is established. This identity should be stored in a protected form of storage or hardware. In other words, an "out-of-band" mechanism is necessary for transmitting the private cryptographic materials used in the protocol handshake sequences (discussed later). These materials should never be transported across the network they define. Once received or installed, each host entity should securely isolate them, as possessing these materials is essential for participating in a uNet network. Additionally, these materials should never be used for encrypting application layer data, whether at rest or in transit. They are reserved exclusively for identity validation within uNet protocols.

[0062] To make automatic decisions about routing and communication, a minimum level of confidence in network traffic identity is needed. uNef s stringent policy of preinstalling identity materials on all devices ensures that any two entities can securely exchange credentials and have confidence in each other's identity.

[0063] Being able to trust the source (though not necessarily the content) of traffic enables all participants in an infrastructure to gather data about the traffic, such as the identities encountered, their direction, timing, validity, and so on. This "network knowledge" permits connections to be fully automatic, secure, efficient, and self-healing.

[0064] uNet Addresses must be assigned by an Address Provider. Once assigned, the address is static and never changes, regardless of its location within an infrastructure, much like a phone number. While assignment does not prevent bad actors from obtaining addresses, it ensures they cannot mass-produce them and hide behind a constantly changing cloud of addresses.

[0065] Variable-length and mandatory assignment enable addresses to be encoded with useful information. An address could represent a domain name in utf-8, an email address, a person's name, a device name, a phone number, an IP address, and so on. Each Address Provider is responsible for defining and enforcing their own rules and formats for the addresses they provide. [0066] The decentralization of route and status information, combined with the VPU system, allows for the recentralization of governance and administration of membership within virtual network overlays. By adopting these principles, uNet aims to create a more secure and efficient networking environment, striking a balance between openness and trust. [0067] The introduction of multiple registered siblings (instead of a single “parent”) for each node enhances the network's adaptability and resilience. This approach allows nodes to register with multiple visible nodes, creating a more flexible and robust connection infrastructure. The collection of these nodes, or Active Physical Connections, enables nodes to select one or more paths to the VPU Host, known as portals, which further strengthens the network's ability to maintain secure and reliable communication.

[0068] It is important to note that uNet does not create security; rather, it implements modem security (SSL) using full automation to ensure that every connection has the highest level of security. This security is a prerequisite for each connection and is non-negotiable. [0069] uNet provides extensible systems that can be configured to interact with a variety of other protocols. Nearly any other addressing system (including full domains) can be represented in a uNet Address, and almost any packet structure can be emulated in a uNet Packet. This foundational layer of consistency allows for the gradual introduction of uNet-to- extemal protocol software that can provide translation, bridging, tunneling, and/or "network knowledge" to the external network.

[0070] In general, uNet processes that fail validation are not explicitly notified. Processes that fail to complete may be retried, with the frequency of retries determined by timeout settings.

[0071] The Keep Alive feature from the first patent provides a low-level system for detecting connectivity failures. Failure to deliver at the application layer requires the implementation of additional systems.

[0072] uNet's architecture can be thought of as a configuration of Secure Sockets Layer/Transport Layer Security (SSL/TLS), most commonly available as Open Secure Sockets Layer (Open SSL). Therefore, it offers the guarantees of correctly implemented SSL/TLS, along with significant extensions. SSL/TLS provides counterparty identification and strong privacy when used appropriately

[0073] The primary vulnerabilities of SSL/TLS lie in key exchange. Attacks on SSL/TLS-based systems can be grouped into four broad categories: key theft, timing attacks during key exchange, attacks that eventually yield enough information to guess a key (e.g., the Bleichenbacher CCA attack), and attacks that allow intruders to see memory in plaintext (e.g., Heartbleed).

[0074] All of these attacks exploit the fact that SSL/TLS is designed to operate in a plaintext world: parties must begin communication in plaintext to establish a cryptographically secured channel, agree on a cryptographic protocol, and exchange secrets. The Diffie-Hellman key exchange mechanism and RSA asymmetric key encryption were algonthms developed to securely exchange secrets in plaintext.

[0075] Despite the elegant algorithms for secure secret exchange, the implementations of negotiation and configuration offer multiple opportunities for attack. For example, Heartbeat was an extension to OpenS SL designed to keep connections alive while both parties were still present, motivated by the costly setup and teardown of TLS connections. Heartbeat requests were of the form (data, size of data in bytes), which the counterparty did not check, and the response was the data in the request, padded to ensure that the data size specified was met. So, in response to a Heartbeat message of (Hello, 1024 bytes), the counterparty would respond with "hello" followed by 1019 bytes taken from the counterparty's memory, which could be anything at all, including sensitive information.

[0076] POODLE was another (of many) configuration attacks. The "D" in POODLE stands for "Downgrade." TLS (and before it, SSL) began with a negotiation by the counterparties on which encryption algorithm to use; once this was agreed upon, secrets and a session key were exchanged, and then encrypted data was transmitted. POODLE forced a counterparty

[0077] to use a vulnerable, early version of SSL, which allowed the attacker to guess plaintext bytes in messages.

[0078] These are just two examples of many attacks. As Adi Shamir, the "S" in "RSA," observes: "Cryptography is typically bypassed, not penetrated," and the bypass primarily occurs in configuration. TLS has yet to be provably broken (excluding rumors about CIA backdoors in elliptic curve cryptography). uNet removes the ability to bypass the encryption.

[0079] The configuration in TLS (or any cryptographic protocol) generally involves a three-step process. First, one or both of the counterparties are authenticated, which is typically done on the web by presenting a signed, valid SSL certificate, an SSH key, or a password. Second, the counterparties reach an agreement on the cryptographic protocol to be used for the exchange. Finally, secrets are exchanged using the agreed-upon protocol. [0080] These steps do not need to follow this exact sequence. For example, in SSH, the server authenticates to the client by certificate presentation, the parties agree on the protocol, session secrets are exchanged using the server's key pair, and finally, the client authenticates to the server. However, for every variation, an attack will almost always occur in this configuration and setup exchange.

[0081] uNet requires that the complex, error-prone configuration and setup need only be done once, out-of-band, and afterward, parties could communicate securely, privately, and with complete trust in the other counterparty. This out-of-band configuration and authentication is reliable, verifiable, and checkable — unlike the in-band protocols used today. [0082] Each uNet node maintains a cache of routing infomiation for uNet nodes. This means that discovery is reactive. When a node moves, it informs the network of its new location. Nodes with existing connections find their routing tables automatically updated; new connections follow the standard process described above. This reduces the need for discovery protocols such as ARP.

[0083] A uNet edge node is a uNet device that connects to an underlying IP network and provides routing information within a uNet domain. A good example is an enterprise border switch. When two nodes (A and B) do not have direct connectivity on an underlying network, a third node, C, can act as a forwarding agent for both. In this case, C receives packets from A bound for B (as distinguished by uNet address) and forwards them according to its own routing table.

[0084] It is important to note that uNet can use any underlying network translation capabilities, and this overlay routing is simply an automated backup when underlying interdomain network routing is unavailable.

[0085] uNet can be implemented as an overlay or an underlay to current networks. In an overlay, the uNet packet is encapsulated in a standard IP packet, typically at the application layer (encapsulated within the transport header). This can be done using any of a number of tunneling protocols, such as Generic Routing Encapsulation (GRE). uNet encapsulation is hardware and network agnostic. In an underlay, the uNet header replaces the L3 IP header. Overlay use is suitable for wide-area networks, where pockets of uNet networks are connected over the standard internet; an underlay is suitable for local area networks, where the switching equipment uses only the L2 header (in basic switching) or uNet is encapsulated inside the L3 header in multi-layer switched networks.

[0086] Routing in uNet is designed to be robust and trustworthy at the expense of efficiency. The goal is not to produce an optimized routing system but rather to maintain an automatic system that can always be relied upon as a fallback and recovery point when more nuanced and heavily optimized routing strategies fail.

[0087] With respect to security, there are three major classes of network attack common to all networks: man-in-the-middle (MITM), spoofing, and resource exhaustion attacks, notably distributed denial-of-service (DDoS).

[0088] MITM attacks occur when a third party eavesdrops on and/or injects malicious traffic into the conversation. These attacks cannot occur in a properly configured encrypted conversation, which is the primary purpose of encryption. MITM attacks are the vast majority of attacks on TLS transmissions, always at the configuration level or on side-channel continuous-configuration messaging (e.g., the Heartbleed attack).

[0089] uNet eliminates configuration and side-channel MITM attacks through out-of- band configuration. Therefore, any in-band configuration is immediately recognized as an MITM attack since no legitimate counterparties will ever need, request, or offer configuration. Metadata attacks on the underlying TLS protocol are still possible, though these are both rare and rapidly patched by the underlying TLS protocol.

[0090] Spoofing attacks occur when a malicious third party appears to be a legitimate counterparty to the conversation. Since uNet identities are signed addresses with a matching trust bundle, spoofing attacks require the theft of a uNet address or trust bundle. This can only occur if there is improper distribution of uNet addresses and trust bundles or by theft of keys by a third party. If a uNet address is compromised through improper distribution or theft, the remedy is simple: when the key is stolen, change the lock, which in this case is achieved by canceling the affected address and issuing a new one.

[0091] Resource-denial attacks happen at multiple levels, some of which are beyond the scope of this background summary . For example, a wireless network can be jammed simply by broadcasting noise; a network can be attacked by a packet flood. However, the lower the level of the attack on the network, the fewer resources it consumes for the attacked party and the more resources it consumes for the attacker. A packet-flood attack requires launching enough packets to consume all traffic on the network, but the only resource it consumes on the attacked system is the network interface card. Serious resource-exhaustion attacks, therefore, focus on application-level resources, making requests that consume defender resources (memory, computation, storage). Once again, these attacks are impossible against a uNet-offered sendee, since requests from nonparticipants are from unauthorized senders and are discarded before they consume resources.

EXAMPLE HANDSHAKES [0092] The Available Physical Connection (APC) process involves discovering and validating direct links to other addresses. Both sides of each connection must initiate a handshake and complete validation. The initial message sent from an address is the Available Physical Connection Request (APCR), which discovers other available addresses with direct links. The APCR can be sent on an event, a timer to unresponsive links, in broadcast on wireless radios, or in multicast over IP. It includes the sender's public certificates and a unique nonce challenge. Before any other messages, the APCR must be sent to an unknown address connected directly to the sender

[0093] The Available Physical Connection Credential Request (APCCR) is a response to an APCR that indicates the receiver lacks the required certificates or chains to validate a certificate signature. In response, the Available Physical Connection Credential Announce (APCCA) provides all certificates required to validate the original APCR public certificate signatures. The APCCA can only be sent once per APCR. The Available Physical Connection Announce (APCA) responds to an APCR and indicates its validity. It includes an encrypted nonce challenge and can only be sent once per APCR. The Available Physical Connection Validation (APCV) is a response to an APCA that validates its reception and can only be sent once per APCA.

[0094] Figure 4 is a sequence diagram illustrating the APC process.

[0095] The Register (R) process involves registering for uNet communications with addresses. Nodes find out about others through the APC handshake and may decide not to communicate further. The Register Request (RR) indicates the sender's desire to communicate directly with the destination. It may be sent in response to an APCV or on a timer to unresponsive addresses that previously advertised route capacity. The Register Validation (RV) indicates that the sender is now registered for communication, allowing the nodes to communicate freely as uNet entities. The Register Capacity Announce (RCA) is a message sent to downstream entities with optional values for various routing metrics. The Register Disconnect (RD) may be sent to inform the other party of an inability to continue direct communications or a change in distributed settings from their VPU host.

[0096] Figure 5 is a sequence diagram illustrating the R process.

[0097] The Route for Destination (RFD) process involves applying for destination routing with a VPU host and all hops in-between. The Route for Destination Request (RFDR) is sent to the VPU host and inspected at each hop for validity. The Route for Destination Announce (RFD A) is sent as a response to indicate willingness to provide routing or to notify of a change in the sender's route selection. The Route for Destination Disconnect (RFDD) may be sent when all routes to an address have been disconnected or to arbitrarily remove a specific route. The Route for Destination Flush (RFDF) is sent to purge all route information from all systems regarding a particular destination.

[0098] Figure 6 is a sequence diagram illustrating the RFD process.

EXAMPLE CREATION OF A UNET NETWORK

[0099] Every uNet network starts with a single Prefix Provider. There can only be one per network. The Prefix Provider is not a connected network node - it is a designation applied to an organization or a person designated to act as Prefix Provider for the network. The Prefix Provider serves as a registrar for all the Address Providers that will make up the uNet network. In support of this role, it serves as a Certificate Authority responsible for the issuance of cryptographic materials, and for the safe storage of the private components used in the production of those materials.

[0100] As discussed above, all of the CSR interactions or transmissions of cryptographic materials between Prefix Providers and Address Providers are intentionally and crucially outside of the scope of the uNet system and specifications.

[0101] Once designated and having established storage and issuance procedures, the Prefix Provider’s first step is to issue to itself its own Address Cert, designating its own Address as “1 : 1”. This is illustrated in Figure 7.

[0102] Next, one or more Address Providers must be designated by the Prefix Provider. The private key components of each Addresses Provider’s Address Cert should be provisioned to the Address Provider out of band and stored by the Address Provider in a secure way. Like the Prefix Providers, Address Providers should never exchange or transmit cryptographic materials over network infrastructure. This step is illustrated in Figure 8.

Here the singular Prefix Provider designates a new Address Provider, which will be responsible for issuing new addresses within the “A” prefix. It grants the Provider with the Address Cert which it will use to sign all of its issued addresses, so that all the addresses within the prefix can successfully prove their shared Certificate provisioning ancestry through the cryptographic challenges presented during the uNet handshakes.

[0103] Note that these out-of-band exchanges are indicated in this and subsequent Figures by dashed lines. These lines do not represent network connections, they represent the chains of derivations and cross-signing required for the production of each entity’s Address Cert. See Figure 8.

[0104] Next, the “A” Address Provider issues a new Address for a new uNet entity.

In this Figure 9, “A:l” mints the new address “A: 142” and is responsible for transmitting the Address Cert for that address directly to the new entity, once again by an out-of-band modality.

[0105] Next the “A” Address Provider issues a second new Address (“A:216”) and we are left with two new uNet nodes in Figure 10. Here we are ready to begin the process of Connection Build-Up. Going forward in this series of figures, the Prefix and Address Providers are omitted for simplicity. It should be understood that any new Address Certs in subsequent Figures will have been issued in the same way.

[0106] A:235 begins process of joining the network. Its APC handshake with A:317 establishes mutual identity validation (visibility), so we can proceed. See Figure 11.

[0107] A:235 now begins the Register handshake with all visible Nodes. This establishes routability. See Figure 12.

[0108] A:235 will now begin the RouteForDestination handshake with A:317. Here we see that A:317 has already established a connection with the VPU Host. See Figure 13. [0109] A:235 has completed the RouteForDestination handshake with A:317. A:216 has replied with an RFDA. On its way back down the path, this RFDA gets stored as routing information by all intermediate nodes (in this case A: 317). This establishes VPU-wide routability. See Figure 14.

[0110] In Figure 15, uNet connectivity has been established.

[0111] The curved, solid lines in Figure 15 illustrate uNet connectivity. “A:142” and “A:215” are now “connected” and can send packets to each other bidirectionally. These packets (as with all uNet packets) are encrypted, but the shared cryptographic material in these two node’s Address Certs allows each node to decrypt packets from the other without any further handshaking, nonce-checking or negotiation.

[0112] Going forward in this series of figures, these double lines will represent the completion of this Connection Build-Up process between nodes.

[0113] Now we are ready to produce our first Virtual Programmable uNet (VPU). In Figure 16, “A:216” is now operating as a VPU Host. No new certificate or handshakes are required from a uNet entity to become a VPU Host. It merely needs to begin issuing Member Certs to other entities that together will comprise the VPU. Here in Figure 16, we see A:216 has issued a Member Cert to two new entities - “A:235” and “A:317”.

[0114] Note that in the Figure 16, these entities now carry a new “VM:” designation - this is an indication that they possess valid VPU Memberships for the VPU Host “A:216”. It should be noted that entities may hold more than one Member Certs at the same time. Because the static uNet addresses are embedded in the Certs, it is always apparent which Cert is relevant to handshakes and description on any VPU.

[0115] Now with a VPU formed, members of the VPU can use services provided by the VPU. There may be numerous services provided, in this example we examine the foundational service of VPU “routing”. Here VPU A:216 provides this service, which means member nodes may designate the A:216 as the address of their “routing network”. Any uNet packets they wish to send to a given destination address will be routed toward A:216 (the routing address) until they reach a node with routing info for that destination address.

[0116] In Figure 17 we see the simplest possible example of this idea. As members of VPU A:216, both A:235 and A:317 have completed their RFD handshakes, resulting in routing info for them being stored in A:216 (and in networks with more layers, in any intervening nodes). Now either can send packets to the other across the A:216 routing network.

[0117] In Figure 18 we rearrange the nodes to look at a different topology. Here we add an extra layer between A:216 and A:235. Here we see that when A:235 joined the network, it had a direct connection to A:317. A:235’s sent its outbound RFDR to A:317 and the returned RFD A response passed through A: 317 and A:317 made a routing entry for A: 235 as a result.

[0118] Figure 19 shows a different configuration. Here a new entity, A: 689, which is not a member of VPU Host A:216, cannot use A:317’s routing services into that VPU.

[0119] In Figure 20 VPU Host: A216 distributes an Affiliate Membership Cert to VPU Host B:87, B:87 subsequently distributes this to its members, including A:689, granting it an Affiliate Membership Designation, notated in his figures as AVM[A:216], This means that A:689 can now avail itself of the VPU A:216 routing services provided by A:317.