Network-based consent contract using packet-level data indication

Abstract

Technologies for creating consent contracts for devices that indicate whether the device consents to receive network-based communications from other devices. Further, the technologies include enforcing the consent contracts such that network-based communications are allowed or disallowed in the network communication layer before the network communication reaches the device. Rather than simply allowing a device to communicate over a network with any other device, the technologies described herein include establishing consent for network-based communications, soliciting consent at one or more points in the communication process to make informed decisions about network-based traffic.

Description

[0001] Related applications This application claims priority to U.S. Patent Application No. 17 / 324,876, filed May 19, 2021, which is a partial continuation of U.S. Patent Application No. 17 / 183,825, filed February 24, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to inserting metadata into data packets to indicate to a receiving device that it agrees to receive network communication from a sending device. The metadata can be cryptographically verifiable, allowing the network device to verify the metadata and permit or deny communication at the network communication layer before the network communication reaches the receiving device. Background Technology

[0003] A computer network is typically a group of computers or other devices that are interconnected and communicate using a common set of communication protocols to exchange data and / or share resources. Nodes in a computer network can include various types of connected devices, such as client devices (e.g., laptops, desktops, smartphones, and tablets), networking devices (e.g., servers, routers, switches, etc.), and an ever-expanding array of Internet of Things (IoT) devices that can communicate with each other (e.g., cameras, door locks, doorbells, refrigerators, audio / video systems, thermostats, and various sensors). Various types of network architectures exist, such as Local Area Networks (LANs) located in a single physical location (e.g., a building), Wide Area Networks (WANs) extending over large geographical areas to connect individual users or LANs, enterprise networks built for large organizations, and Internet Service Provider (ISP) networks operating WANs to provide connectivity to individual users or businesses.

[0004] In these diverse network architectures, various types of devices can typically "connect" to or communicate with other devices on the network, for example, by using global routing tables. That is, a device can typically send communications—such as invitations, requests, or messages—to any other device over one or more networks using addresses assigned to the destination device (e.g., Internet Protocol (IP) addresses, Media Access Layer (MAC) addresses, etc.). While the advantage of this is that devices can communicate data more efficiently over the network and access the information and services they need, allowing devices to connect to all other devices on the network also has its disadvantages.

[0005] For example, a receiving device might end up receiving communication from a startup device it doesn't want to communicate with. While the receiving device can reject any communication request and thus refuse the communication session, the network will still deliver unwanted requests to it. The delivery of these unwanted requests can cause various problems for the network. For instance, the receiving device might be vulnerable to amplification and denial-of-service (DoS) attacks, where malicious devices send large amounts of traffic to it. Therefore, while enabling other devices in the network to connect to the receiving device is advantageous in some ways, it also forces the receiving device to reject communication it doesn't want to receive. Not only do receiving devices expend time and resources rejecting communication, but intermediate devices in the network also incur time and resources by unnecessarily forwarding communication that will ultimately be rejected by the receiving device. Attached Figure Description

[0006] The following is a detailed description with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which this reference numeral first appears. The same reference numerals are used in different drawings to indicate similar or identical items. The systems depicted in the drawings are not necessarily drawn to scale, and the components in the drawings may be drawn out of proportion to each other.

[0007] Figure 1A The diagram illustrates the system architecture of the consent-contract system, which creates consent contracts between client devices and servers. Figure 1A It further illustrates how network devices can enforce consent contracts by allowing or disallowing network-based communication.

[0008] Figure 1B The diagram illustrates the system architecture of the consent-contract system, which creates consent contracts between client devices and servers. Figure 1B It further illustrates how a consent-contract system uses a private key to create signed data provided to a sending device, and how a network device uses a public key to verify the signed data to allow or disallow network-based communication.

[0009] Figure 2 A component diagram of an example consent-contract system for creating, distributing, and / or executing network-based communication between devices is shown.

[0010] Figure 3A The diagram illustrates the system architecture of the consent-contract system, which creates consent contracts between client devices and servers.

[0011] Figure 3B The diagram illustrates the system architecture of an environment where a consent-contract system maps public keys to the addresses of destination devices (e.g., servers).

[0012] Figure 4 A flowchart illustrating an example method for client devices and servers to establish an agreement contract using an agreement-contract system is shown.

[0013] Figure 5 A flowchart illustrating an example method of an consent-contract system for determining whether a server is willing to establish a consent contract with a client device is shown.

[0014] Figure 6 A flowchart is shown illustrating an example method of the Domain Name System (DNS) creating and using consent contracts to allow or disallow network-based communication.

[0015] Figure 7 A flowchart illustrating an example method by which a Certificate Authority (CA) system creates and uses consent contracts to allow or disallow network-based communication is shown.

[0016] Figure 8 A flowchart is shown illustrating an example method for executing an agreement contract using sockets on the client device.

[0017] Figure 9 This diagram illustrates a system architecture of an environment where network devices execute consent contracts at the network layer to allow or disallow network-based communication.

[0018] Figure 10 A flowchart is shown as an example method for creating an agreement contract that can be used to allow or disallow network-based communication between devices.

[0019] Figure 11 A flowchart illustrates an example method for an agreement contract used to manage network-based communication between devices.

[0020] Figure 12 A flowchart is shown as an example method for executing an agreement contract to allow or disallow network-based communication between devices.

[0021] Figure 13 A flowchart illustrates an example method for a network device to verify a data packet by including consent data indicating that the destination device has agreed to receive the data packet.

[0022] Figure 14 The flowchart illustrates an example method of an agreement-contract system that determines that a destination device has agreed to receive network communications from a sending device and provides the sending device with signed data to be included in the data packets of the network communications.

[0023] Figure 15 This is a computer architecture diagram, illustrating an example computer architecture of a device capable of executing program components that can be used to implement various aspects of the various technologies described in this article.

[0024] Description of Example Implementations Overview Various aspects of the invention are set forth in the independent claims, and preferred features are set forth in the dependent claims. A feature of one aspect may be applied individually to each aspect or in combination with other aspects.

[0025] This disclosure generally relates to creating a consent contract for a device that indicates whether the device agrees to receive network communications from other devices, and executing the consent contract to allow or disallow network communications at the network communication layer before the network communications reach the device.

[0026] The first method described herein includes techniques for creating a network communication consent contract. The first method may include receiving consent data at a consent-contract system, the data instructing a first device to consent to receiving network communication from a sending device. Additionally, the first method may also include receiving request data at the consent-contract system, the data including a second device's request to communicate with the first device. Furthermore, the first method may include using the consent data and request data to determine that the first device consents to receiving network communication from the second device. Even further, the first method may include creating a consent contract instructing the first device to consent to receiving network communication from the second device.

[0027] The second method described herein includes techniques for managing network communication consent contracts. The second method may include storing consent contracts at a consent-contract system, wherein the consent contracts instruct a receiving device to consent to receiving network communication from a sending device. Additionally, the second method may also include receiving a request at the consent-contract system from a first device associated with communication between the second and third devices. Furthermore, the second method may also include using the consent contracts at the consent-contract system to determine whether the second device has consented to receiving network communication from the first device.

[0028] The third method described herein includes techniques for executing a network communication consent contract. The third method may include receiving a consent contract at a network device located in the network, the contract instructing a first device to consent to receiving network communication from a second device. Furthermore, the third method may also include receiving data packets to be transmitted over the network at the network device, and identifying from the data packets a first address of the first device to which the data packets are sent and a second address of the second device sending the data packets. Additionally, the third method may include using the first and second addresses to determine whether one of a plurality of consent contracts instructs the first device to consent to receiving data packets from the second device.

[0029] The fourth method includes receiving data packets destined for transmission over the network at a network device located within the network, wherein the data packets are sent from a sending device to a destination device. The fourth method may further include identifying consent data from the data packets indicating that the destination device has consented to receive data packets from the sending device. Furthermore, the fourth method may include determining whether the consent data was issued by a consent-contract system. The fourth method may include, in response to determining that the consent data was issued by a consent-contract system, sending the data packets to a next-hop network device in the network to transmit the data packets to the destination device. Alternatively, the fourth method may include discarding the data packets in response to determining that the consent data was issued by a consent-contract system.

[0030] In addition, the techniques of at least the first, second, third, and fourth methods, as well as any other techniques described herein, can be executed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform one or more of the methods described above.

[0031] Example Implementation This disclosure generally relates to techniques for creating consent contracts for devices that indicate whether a device agrees to receive network-based communications from other devices. Furthermore, the techniques include enforcing the consent contract to allow or disallow network-based communications at a network communication layer before the network communications reach the device. The techniques described herein do not simply allow a device to communicate with any other device over a network, but rather include: establishing consent for network-based communications, obtaining consent at one or more points during the communication process, and making informed decisions about network-based traffic.

[0032] In network architecture, devices are typically able to "reach" or communicate with other devices on the network. Taking the internet as an example, a device can address a data packet to any other device, and by default, this packet is sent to a router and routed across the network to the receiving device. This packet is usually routed throughout the network regardless of whether the receiving device actually wants to receive it. However, having a packet routed across the network and ultimately rejected wastes resources, as each device along the way must process the packet and pass it to the next hop. Furthermore, the receiving device may be forced to reject unwanted connections (which consumes resources), and / or entities associated with the receiving device may set up firewalls to block certain connections (this is also for optimization of server load, among other purposes).

[0033] Various techniques are used at the receiving end to prevent unwanted connections, such as using access control lists (ACLs) or firewalls to filter traffic based on source address. However, these ACLs or firewalls are often placed near the receiving device to ensure that all traffic destined for that device is inspected using the ACL or firewall. This approach has various inefficiencies, such as (i) unwanted packets traversing the entire network, including the Internet, which is inefficient; (ii) maintaining and updating large filtering tables; and (iii) vulnerability to attacks, such as denial-of-service (DoS) attacks.

[0034] To illustrate this conceptually, consider a telephone system where a person can provide their phone number to an entity. By doing so, the person effectively consents to receiving calls from that entity for any purpose. Furthermore, the person agrees to answer calls from anyone who shares the phone number with that entity. Answering these calls might be costly (both in terms of time and money), and by providing their phone number, the person has agreed to pay that cost. Thus, the person must either ignore phone calls (including those they need) or accept them (including those they don't need). However, if the person could establish a consent relationship with potential callers who have their phone number, then callers might only be able to call them with their consent, not just simply because they have the phone number.

[0035] This disclosure describes techniques and mechanisms for establishing consent between a sending device and a receiving device, thereby enabling the receiving device to receive only the necessary (or consented) network-based communications. Using the consent relationship techniques described herein (referred to as "consent contracts"), unwanted or unconsented network-based communications can be discarded or rejected at one or more points during the communication process. Generally, communications that can be managed using the consent contracts described herein can include Layer 2 and Layer 3 network communications, as well as higher-level communications (e.g., Layers 4 through 7).

[0036] The techniques described herein include creating consent contracts that represent relationships or agreements between devices that agree to communicate with each other. Generally, a centralized consent-contract system can be used to create, maintain, and potentially enforce consent contracts. In some cases, the consent-contract system may be a designated system for creating and facilitating the enforcement of consent contracts. In various examples, the consent-contract system may be implemented at or by various centralized vendors, such as Domain Name System (DNS) implementations, Certificate Authority (CA) implementations, network controller implementations, etc.

[0037] A consent-contract system is typically a trusted system used to create consent contracts between devices. Generally, devices can provide consent-contract systems with consent data indicating whether they consent to communicating with other devices or types of communication. For example, a device might simply provide the consent-contract system with a range of IP addresses it consents to communicate with (e.g., an "allowed" list). As another example, a device might provide the consent-contract system with a range of IP addresses it does not consent to communicate with (e.g., a "denied" list). In some cases, the consent-contract system can instruct whether a device consents to receive communication based on the type or purpose of the communication. Generally, consent can be specified by various entities (e.g., the receiving device itself, the network stack running on the receiving device, applications running on the receiving device, etc.). After receiving the consent data from the device, the consent-contract system can store the consent data for later use in determining whether the device consents to receiving communication from other devices.

[0038] To communicate with a receiving device, a sending device can request a consent-contract system to create a consent contract, enabling the sending device to send network-based communications to the receiving device. The consent-contract system can determine whether the receiving device has consented to receive communications from the sending device. For example, the consent-contract system can determine whether the sending device's IP address is included in the list of allowed IP addresses provided by the receiving device. If the consent-contract system determines that the receiving device has not consented to communicate with the sending device, the consent-contract system can reject the request (e.g., send a rejection to the sending device, preventing the establishment of a consent contract, etc.). However, the consent-contract system can create a consent contract in response to determining that the receiving device has consented to communicate with the sending device. Generally, a consent contract can indicate that the receiving device has consented to communicate with the sending device. The consent contract can indicate the addresses associated with the receiving and sending devices (e.g., IP addresses, MAC addresses, virtual IP addresses, etc.). Furthermore, the consent contract can also indicate the scope of the consented communications, such as the type of communications the receiving device has consented to receive from the sending device.

[0039] In some examples, other mechanisms (e.g., using permissions granted to an entity) can be used to establish consent. For example, permissions can be granted to devices with specific identities. Devices can be verified, authorized, and / or otherwise authenticated by a trusted party that issues the identity to the device (e.g., an identity provider or other trusted provider). Different authorizations can be granted to identities based on their identities. For example, some identities may have different permissions, similar to security levels, at which they are consented to communicate with more devices, fewer devices, different devices, and / or any combination thereof. Devices can provide consent to a consent-contract system to receive communications based on the identity issued to the requesting device. In this way, a device can contact the consent-contract system and provide its identity indication (or other permission indication), and the consent-contract system can determine whether the target receiving device of the communication consents to communicate with the identity or permissions of the requesting device. Therefore, the consent-contract system can use the indication of identity and / or other permissions to determine consent and create a consent contract.

[0040] After a consent contract is created, a consent-contract system can enforce it by allowing or disallowing communication. In some cases, a consent-contract system can enforce the consent contract by requiring the sending device to request consent before communicating with the receiving device. In one example, the consent-contract system could be a DNS server to which the sending device sends a DNS query or request to obtain the IP address associated with the receiving device. The DNS server (implemented as a consent-contract system) can determine whether the receiving device has consented to communicate with the sending device. If no consent is found, the DNS server can reject the DNS query; if consent is found, it can respond to the DNS query with the receiving device's IP address. As another example, a consent-contract system can be implemented as a Certificate Authority (CA). For instance, a CA server can receive requests from the sending device to verify a signed certificate associated with the receiving device. The CA server (implemented as a consent-contract system) can determine whether the receiving device has consented to communicate with the sending device. If no consent is found, the CA server can reject the verification request; if consent is found, the CA server can respond to the verification request, confirming the signed certificate. Therefore, consent contracts can be enforced by various types of centralized consent-contract systems.

[0041] In some cases, a consent contract can be executed using a socket on the sending device. For example, a receiving device can provide consent data to a consent-contract system, and a server can open a socket, bind a name to the socket for network access, and listen for connections that offer consent. Similarly, the sending device can open a socket to communicate with the receiving device, and the socket can be configured to perform consent verification when the sending device attempts to create the socket. For example, to bind a socket, the sending device can perform consent verification with the consent-contract system. If the consent-contract system determines that the receiving device has consented to receive communication from the sending device, the consent-contract system can verify the sending device's consent, and the socket on the sending device can connect to the socket on the receiving device to establish a connection. However, if the consent-contract system determines that the receiving device has not consented to communicate with the sending device, a connection may not be established.

[0042] In various examples, consent contracts can be provided to network devices positioned along the communication path between the sending and receiving devices. For instance, consent contracts can be provided to personal area network (PAN) routers, wide area network (WAN) routers, network switches, etc., associated with the sending device. The network device that receives the consent contract can then enforce it by verifying and allowing or disallowing traffic through the network based on the contract. For example, the consent contract can represent a mapping between the addresses of sending and receiving devices that have agreed to communicate with each other. The network device can identify the device's address from the data packet and, if the consent contract indicates that consent has been obtained, forward the packet to the next hop in the network. Conversely, if the network device cannot identify from the consent contract that the receiving device has agreed to receive communication, it can discard the data packet.

[0043] In various examples, the consent-contract system can provide the sending device with data that can be inserted into data packets to indicate consent, rather than actually providing the consent contract to the network device. The data can be metadata that can be inserted into data packets, allowing one or more data packets in a data stream through the network to include verifiable data instructing the destination device to consent to receiving the data packets. When the network device receives a data packet, it can analyze the metadata contained in one or more packets (e.g., in the packet header) to verify whether the destination device to which the data packet was sent has consented to receiving the data packet. The network device does not need to use a consent contract stored locally on the network device or that can be retrieved by the network device; it only needs to verify whether the metadata in the data packet has been published by the consent-contract system. After verifying that the metadata was indeed published by the consent-contract system, the network device can simply forward the data packet to the next-hop device in the network and then to the destination device.

[0044] Generally, the data provided by a consent-contract system can be any type of data that can be verified as being issued by the consent-contract system. For example, the data might simply be random number data that can be verified as being issued by a consent-contract system. If the random number data is verified as being issued by a consent-contract system, the network device can simply send the data packet to the next-hop device in the network and forward it to the destination device. In some cases, the data can be a data format used to express the consent contract, such as JavaScript Object Notation (JSON) data format, Java web tokens, and / or another data format that can be used to express the underlying consent contract. The data can provide the network device with various information, such as a simple indication that the destination device has consented to receive communication from the sending device. The network device can use this data to verify whether the destination device has been verified to receive communication from the sending device.

[0045] In some cases, data or metadata contained in a data packet can be cryptographically verified as being issued by a consent-contract system. For example, when providing data to a sending device, the consent-contract system can sign the data using its private key. For instance, the sending device may have previously established a consent contract with the destination device. When the sending device wants to send a data packet to the destination device, the consent-contract system can sign the data using its private key, allowing the signed data to be verified using its public key. For example, the consent-contract system can use its private key to generate a hash value for the data and provide the signed data to the sending device. Then, when network communication is sent to the destination device, the sending device can include the signed data in the data packet.

[0046] Network devices can receive data packets and recognize signed data as being included in the packets (e.g., options in the packet header). In some cases, only the first packet in a data stream may include signed data, while in other examples, more than one packet in a data stream may include signed data. Network devices can verify that the signed data was signed by a consent-contract system. The consent-contract system can send one or more public keys to the network device that can be used to verify the signature on the signed data. The network device can use the public key to verify the signature or hash value of the data. For example, the network device can use the public key to decrypt the signature to obtain the underlying data, which might simply be predefined random number data and / or an indication that the destination device agrees to receive data from the sending device. Therefore, since the public key can be used to decrypt the signature, the network device can determine that the signed data was indeed signed by a consent-contract system.

[0047] In some cases, consent-contract systems can use different private / public key pairs for different destination devices or groups of destination devices. For example, different address domains (e.g., different IP subnets) can be associated with specific private / public key pairs. Network devices can identify the destination address from the data packet and decrypt the signature using the appropriate public key to verify that the signed data was signed by the consent-contract system.

[0048] In this way, the consent contract formed between the sending and receiving devices can be executed by the network device using per-packet metadata. The per-packet metadata can be any type of data, and the network device can verify that this data was issued by the consent-contract system. For example, the data can be encrypted and verified, such as by decrypting a signature on the data using a public key provided by the consent-contract system, which was signed using the corresponding private key belonging to the consent-contract system. In this way, the network device does not need to store or maintain any consent contract; it only needs to verify that the data in the packet is signed by the consent-contract system and forward the packet along the network to the destination device.

[0049] In general, the techniques of this application improve the performance of various networks by reducing network-based communication or traffic sent over one or more networks but ultimately discarded or unwanted by the target device. Some of the techniques described herein involve a server agreeing (or disagreeing) to receive network-based communication from a client device. However, these techniques are generally applicable to any type of sending or receiving device. The agreement contracts described herein can be applied at any point in the communication process (e.g., socket layer, network layer, etc.) and to any device application receiving data packets in the network. In some cases, the closer a network device is to the sending device, the more advantageous it is for the network device to evaluate data packets based on the agreement contract, thereby discarding or allowing the data packets to continue being transmitted. In some cases, the agreement contract may expire after a period of time, and the sending device may need to interact with the agreement-contract system to create another agreement contract for the receiving device.

[0050] In some examples, the consent contract described herein can be distributed at the IP layer, thereby enabling the consent contract to be used with any protocol. That is, the consent contract described herein can be used to control communication with any communication protocol that can be used with IP-based communication. Network-based communication described herein can include low-level networking (e.g., Layer 2, Layer 3, etc.) and high-level communication (e.g., Layer 4 through Layer 7). For example, VoIP communication, social media application communication, and other communications can be controlled by the consent contract described herein.

[0051] In general, a consent contract represents a device's agreement to receive any data and fragments / or software from another device. A consent contract can specify which devices are allowed or denied, which types of communication are allowed or denied, and which communication purposes are allowed or denied, etc.

[0052] As described herein, network devices can include any type of component capable of evaluating data packets and consent contracts, including hardware-based components, software-based components, etc. For example, network devices or components can include hardware-based devices such as routers, network switches (e.g., leaf switches, spine switches, etc.), gateways, network interface cards (NICs), smart NICs, servers, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and / or any other hardware device capable of evaluating data packets and consent contracts. Network devices (or components) can also include software-based components such as virtual machines, containers, etc.

[0053] Certain embodiments and implementations of this disclosure will now be described more fully with reference to the accompanying drawings, which illustrate various aspects. However, aspects may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein. This disclosure includes variations of the embodiments described herein. The same numerals refer to the same elements.

[0054] Figure 1A The diagram illustrates the system architecture of the consent-contract system 102, which creates an consent contract between a client device and a server. Figure 1A It further illustrates how network devices can enforce consent contracts by allowing or disallowing network-based communication.

[0055] As shown in the figure, environment 102 includes client devices 104A-104N (where "N" is any integer greater than "0"). Client device 104 can be any type of computing device, such as a desktop computer, laptop or other portable computer, tablet, e-reader, smartphone, wearable device, or other computing device. In some cases, client device 104 can be an Internet of Things (IoT) device, such as a connected appliance, smart home device, autonomous vehicle or machine, factory equipment, sensor, and / or other IoT devices configured to communicate over one or more networks. In various examples, client device 104 can be various types of networking devices, such as a server, switch, router, hub, bridge, gateway, modem, repeater, access point, and / or any other type of computing device that can run any type of software and / or virtualization technology.

[0056] Client device 104 may decide to connect to one or more services 106A-106N for various purposes. Service 106 may include any type of service 106, such as cloud services (e.g., scalable computing services, memory services, storage services, networking services, etc.), applications (e.g., video applications, messaging applications, web applications, security applications, etc.), and / or any other type of service that may be at least partially hosted on one or more servers 110. However, service 106 may include any type of service 106 that can be used for any purpose and support any functionality.

[0057] Furthermore, although illustrated as server 110, server 110 can be any type of computing device capable of communicating with client device 104. That is, server 110 and client device 104 can be any type of computing device capable of communicating via one or more networks 112 for any purpose. One or more networks 112 can include devices housed in or located in one or more data centers and / or constituted therewith. One or more networks 112 can include one or more networks implemented by any feasible communication technology (e.g., wired and / or wireless modes and / or technologies). One or more networks 112 can include personal area networks (PANs), local area networks (LANs), campus LANs (CANs), metropolitan area networks (MANs), extranets, intranets, the Internet, short-range wireless communication networks (e.g., ZigBee, Bluetooth, etc.), wide area networks (WANs) – both centralized and / or distributed – and / or any combination, arrangement, and / or aggregation thereof. One or more networks 112 can include devices, virtual resources, or other nodes that forward data packets from one network segment to another via nodes in a computer network. One or more networks 112 may include multiple devices that utilize the network layer (and / or session layer, transport layer, etc.) and / or other layers in the OSI model used for packet forwarding. One or more networks 112 may include various hardware devices, such as routers, switches, gateways, smart NICs, NICs, ASICs, FPGAs, servers, and / or any other type of device. Furthermore, one or more networks 112 may include virtual resources, such as VMs, containers, and / or other virtual resources.

[0058] In some cases, one or more networks 112 and / or servers 110 may be located in one or more data centers. The one or more data centers may be physical facilities or buildings located in different geographical areas, designated for storing networked devices as part of one or more networks 112. Data centers may include a variety of networked devices, as well as redundant or backup components and infrastructure for power supply, data communication connectivity, environmental control, and various security devices. In some examples, data centers may include one or more virtual data centers, which are pools or collections of cloud infrastructure resources specifically designed to meet the needs of enterprises and / or cloud-based service providers. Generally, data centers (physical and / or virtual) can provide basic resources such as processors (CPUs), memory (RAM), storage (disks), and networking (bandwidth). However, in some examples, devices in one or more networks 112 may not be located in a explicitly defined data center, but may be located in other locations or buildings.

[0059] As shown in the figure, the consent-contract system 102 may include a consent-contract component 114, which includes logic and is configured to create, maintain, and / or execute consent contracts 118 stored in one or more consent databases 116. The consent-contract system 102 may be one or more devices configured as a centralized or distributed system for creating, managing, and potentially executing consent contracts. In some cases, the consent-contract system 102 may be a designated system for creating and facilitating the execution of consent contracts. In various examples, the consent-contract system 102 may be implemented at or by various centralized vendors, such as Domain Name System (DNS) implementations, Certificate Authority (CA) implementations, network controller implementations, etc.

[0060] Devices wishing to restrict received communications can create a consent contract 118 in conjunction with the consent contract system 102. Generally, the consent contract 118 represents a device's consent to receive data segments and / or software from another device (e.g., server 110 consents to receive data from client device 104). The consent contract 118 can specify which devices are allowed or denied, which types of communication are allowed or denied, and which communication purposes are allowed or denied.

[0061] exist Figure 1AIn the specific illustration, at point "1", service 106 and / or server 110 can register consent rules with consent-contract system 102. Consent rules can be registered by one or more of the following: server 110 itself, one or more network stacks on server 110 (e.g., kernel, userspace networking stack, etc.), and / or service 106 (e.g., an application) running on server 110. A consent rule might simply be a range of IP addresses that server 110 and / or service 106 agrees to communicate with (e.g., an "allow" list). As another example, server 110 and / or service 106 can provide consent-contract system 102 with a range of IP addresses that server 110 and / or service 106 does not agree to communicate with (e.g., a "deny" list). In some cases, server 110 and / or service 106 can indicate whether to consent to receive communication based on the type or purpose of communication. Upon receiving an instruction for consent data from a device, the consent-contract system 102 may store the consent data for later use in determining whether the server 110 and / or service 106 consent to receiving communications from other devices (e.g., client device 104).

[0062] At point “2”, at least one client device 104 may request consent to contract with service 106. For example, client device 104 may send a request to consent-contract system 102 indicating the address associated with server 110 and / or service 106 with which client device 104 wishes to communicate. Consent-contract system 102 may identify information associated with the request from client device 104. For example, the request may include or may be a data packet indicating the address of client device 104 (e.g., MAC address, IP address, etc.), and / or may include information about the type or purpose of communication that client device 104 wishes to communicate with server 110 and / or service 106.

[0063] At point “3”, the consent-contract system 102 can determine whether server 110 and / or service 106 consent to communicate with client device 104. For example, the consent-contract system 102 can determine whether the consent rules provided by server 110 and / or service 106 and the request data sent by client device 104 indicate that server 110 and / or service 106 consent to communicate with client device 104. This may include determining whether the address of client device 104 is included in the allowed or permitted address range indicated by server 110 and / or service 106. In some cases, this may include determining the type or purpose of communication consented to by server 110 and / or service 106.

[0064] At point “4”, the consent-contract component 114 can generate and distribute one or more consent contracts 118. Generally, a consent contract 118 indicates that two or more devices have agreed to communicate with each other (e.g., send and receive network-based communications). The consent-contract component 114 can send the consent contracts 118 to one or more network devices 114A-114N located in one or more networks 112. Network devices 114 can be any type of device configured to communicate data over one or more networks 112, such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, and / or any other type of computing device that can run any type of software and / or virtualization technology. In some cases, network device 114 may include or be associated with NICs and smart NICs, FPGAs, ASICs, virtual machines, containers, and / or any other type of hardware-based or software-based network components.

[0065] Network device 114 can be configured to analyze received network-based communications (e.g., data packets) and use an agreement contract 118 to determine whether the destination device of these data packets has agreed to receive them. For example, network device 114 can determine the address of the client device 104 that sent the data packet and the address of the destination server 110. In an illustrative example, client device 104A can send a data packet with a destination address corresponding to the IP address and port of server 110A, and client device 104N can send a data packet with a destination address corresponding to the IP address and port of server 110N. As shown, both data packets may arrive at network device 114A. Generally, it is more advantageous to position network device 114 near the sending device (e.g., client device 104) to evaluate data packets against the agreement contract 118 and to discard unwanted data packets early in one or more networks 112.

[0066] In this example, server 110A and / or service 106A may have agreed to receive communication from client device 104A, and consent-contract component 114 may have generated consent contract 118 for the device. However, server 110N and / or service 106N may not have agreed to receive communication from client device 104N. In such an example, network device 114A can use consent contract 118 to determine that server 110A and / or service 106A have agreed to receive data packets received from client device 104A and forward the data packets to next-hop network device 114B. However, network device 114A can also use consent contract 118 to determine that server 110N and / or service 106N have not agreed to receive data packets from client device 104N, and network device 114A may discard the data packets.

[0067] In this manner, network device 114 can execute consent contract 118 by discarding data packets that have not been received with the device's consent. However, in some examples, consent-contract system 102 can execute consent contract 118, which will be discussed later in this disclosure. In some cases, consent contract 118 may expire after a predefined period of time. In such examples, consent-contract system 102 and / or network device 114 may delete or remove consent contract 118 from memory, or otherwise indicate that consent contract 118 has expired. In such examples, the device may need to instruct consent to create a new consent contract 118.

[0068] The devices described herein can communicate with each other using any type of communication protocol and over any type of network. For example, client device 104 can attempt to communicate with the server using Transmission Control Protocol / Internet Protocol (TCP / IP), which is used to manage connections to and over the Internet. Figure 1A As shown in the figure, the data packet depicted can be a TCP synchronization packet (e.g., a SYN packet) used to request the establishment of a connection between client device 104 and server 110. However, as described herein, any type of protocol can be used.

[0069] In some cases, server 110 (and / or other receiving devices) may modify its address and / or create addresses as needed. For example, server 110 may continue to change its address, thereby causing old consent contracts 118 to expire and / or requiring the creation of new consent contracts 118.

[0070] In some cases, network device 114 (and / or any other intermediate device) can remap packets with the service address provided to client device 104 to the private addresses of the actual server 106 and / or server 110. For example, a service address or other address can be provided to client device 104 (and / or other initiating devices), which can be mapped by the intermediate device to the private addresses of the actual service 106 and / or server 110, instead of the actual addresses provided to service 106 and / or server 110. In this way, server 106 and / or server 110 do not need to modify or create new addresses, but the service address or random number address provided to client device 104 can be modified and remapped to the actual service 106 and / or server 110 addresses.

[0071] In some cases, Border Gateway Protocol (BGP) or other protocols used for routing and reachability information communication between autonomous systems can be configured to use the consent techniques described herein. For example, BGP reachability can be used when it is determined that consent has been established between devices (e.g., if an address is not currently used for consent contract 118, then there is no path selection for this address). In some cases, source routing extensions of the BGP protocol can be used to apply these techniques to enforce consent for BGP reachability.

[0072] Therefore, according to the techniques described herein, an address used for consenting connections may not be able to continue to be effectively used for non-consenting connections at a later time. Additionally, these techniques provide devices with the ability to grant different levels of consent to different connections originating from the same IP address.

[0073] Figure 1B The system architecture diagram of environment 100 is shown. In environment 100, the consent-contract system 102 uses a private key to create signed consent data provided to the sending device, and the network device uses a public key to verify the signed consent data to allow or disallow network-based communication.

[0074] As shown in the figure, the consent-contract system 102 can use or store one or more private keys 120. The consent-contract system 102 can use the private key 120 to create a digital signature, thereby encrypting the signature on the data. The consent-contract system 102 can use any type of encryption, such as Rivest-Shamir-Adleman (RSA) encryption, LastPass encryption, ECDSA, Advanced Encryption Standard (AES) encryption, Elliptic Curve Digital Signature Algorithm (ECDSA) encryption, Digital Signature Algorithm (DSA) encryption, and / or any other type of encryption technology. Generally, the private key 120, or key, is a cryptographic variable used together with an encryption algorithm to encrypt the data.

[0075] The consent-contract system 102 can use the private key 120 to create a hash value for the data, such as a one-way hash value, and encrypt the hash value. Therefore, the consent-contract system 102 generates a digital signature, i.e., the encrypted hash value, along with other information (e.g., the hash algorithm). In this way, the consent-contract system 102 can use the private key 120 to generate signed data or data with an encrypted signature.

[0076] like Figure 1AAs described, server 110A can register a consent rule at "1", and client device 104A can request consent at "2". Consent-contract system 102 can determine at "3" that server 110A has consented to receive communication with client device 104A. In such examples, consent-contract system 102 can sign the data with private key 120. The data may simply be predefined random number data known to network device 114. In some cases, the data signed with private key 120 indicates information associated with the underlying consent contract 118. For example, the data may simply indicate that the destination device (e.g., server 110A) has consented to receive communication from the sending device (e.g., client device 104A). In some cases, the data may include additional data, such as the scope of consent (e.g., what type of communication is consented to) and / or other information.

[0077] The consent-contract system 102 can sign data using private key 120 to generate signed data 124. The signed data 124 can have a signature, which can be a hash value of the underlying data signed using private key 120. The signed data 124 can be verified using the corresponding public key 122. The signed data 124 can be provided to the client device at position "5". Furthermore, the consent-contract system 102 can also distribute one or more public keys 122 to network device 114. Network device 114 can use the public key 122 to verify that the signed data 124 was signed by the consent-contract system 102 using the corresponding private key 120 of the consent-contract system 102.

[0078] Client device 104A may then send one or more data packets to destination device or server 110A at "6". The data packets may include a destination address corresponding to server 110A and may also include signed data 124. For example, signed data 124 may be included in options or extensions in the header of the data packet. In some cases, a single data packet in the data stream sent from client device 104A may include signed data 124 (e.g., the first data packet, the first data packet, and the last data packet, etc.). In other examples, each data packet may include signed data 124 in the data stream. Network device 114 may use a public key to verify the signature on the data packets in the data stream. For example, network device 114 may use public key 122 to decrypt the signature and obtain the underlying data (e.g., random number data, consent data indicating agreement contract 118, the scope of consent, etc.).

[0079] In some cases, network device 114 may have multiple public keys 122, and public keys 122 may be associated with different destination address ranges. For example, public key 122 may be used to verify signed data 124 for a destination IP address range (e.g., a Classless Inter-Domain Routing (CIDR) block, an IP subnet, etc.). Network device 114 can identify the destination address from one or more packets and determine which public key 122 is assigned to that destination address. Network device 114 can then use public key 122 to decrypt the signature on the signed data 124 contained in the packet to obtain the underlying data. Network device 114 can use public key 122 to confirm or verify the signature and to analyze the underlying data.

[0080] In the example where network device 114 cannot verify the signature using public key 122, network device 114 can determine that the signed data 124 was not signed by consent-contract system 102 and can discard the packet. In the example where network device 114 can verify the signature on the signed data 124 using public key 122, network device 114 can determine that the signed data 124 was signed by consent-contract system 102 and can forward (one or more) packets to the next-hop device (e.g., another network device 114, server 110A itself, etc.).

[0081] In this way, network device 114 can use data fragments contained in the data packet itself to verify that the destination device has agreed to receive the data packet. In some cases, the destination device itself can sign the data with its private key 120 instead of using the consent-contract system 102, and distribute the public key 122 to network device 114. Therefore, the public key 122 can be bound to the destination device's own private key 120 used to verify that the destination device agrees to receive the data packet containing the signed data 124.

[0082] Figure 2 A component diagram 200 illustrates an example consent-contract system 102 for creating, distributing, and / or executing consent contracts for network-based communication between devices. Generally, the consent-contract system 102 may include devices or device systems arranged in various ways, including centralized, distributed, and / or combinations thereof. In various examples, the consent-contract system 102 may be implemented at or by various entities or systems, such as Domain Name System (DNS) systems, Certificate Authority (CA) systems, network controller systems, etc.

[0083] As shown in the figure, the consent-contract system 102 may include one or more hardware processors 202 (processors), or one or more devices, configured to execute one or more stored instructions. The processors 202 may include one or more cores. Furthermore, the consent-contract system 102 may also include one or more network interfaces 204 configured to provide communication between the consent-contract system 102 and other devices (e.g., client device 104, network device 114, server 110, and / or other systems or devices). The network interface 204 may include devices configured to couple to a personal area network (PAN), wired and wireless local area network (LAN), wired and wireless wide area network (WAN), etc. For example, the network interface 204 may include various TCP / IP network interfaces.

[0084] The consent-contract system 102 may include memory 206, such as a computer-readable medium, for storing various executable components (e.g., software-based components, firmware-based components, etc.). Memory 206 may typically store components used to implement the functions described herein. Memory 206 may store an operating system 212 for controlling the operation of the various components of the consent-contract system 102. Furthermore, memory 206 may also store a communication component 214, which includes software (e.g., any protocol stack) enabling the consent-contract system 102 to communicate with other devices using one or more network interfaces 204.

[0085] In some cases, memory 210 may store consent-contract component 114, which includes logical or computer-readable instructions that, when executed, cause consent-contract component 114 to create, manage, and / or execute consent contract 118. For example, consent-contract component 114 may be configured to receive consent rules 240 from various devices utilizing consent-contract system 102. For example, consent-contract component 114 may receive consent rules from client device 104, server 110, and / or other devices that wish to refuse network communications they have not consented to. The consent rules 240 received by consent-contract component 114 may typically be any type of consent data instructing devices and / or receiving devices to consent to received communications.

[0086] For example, consent rule 240 might simply be a range of IP addresses that server 110 and / or service 106 agrees to communicate with (e.g., an "allow" list). As another example, consent rule 240 could be a range of IP addresses that a device does not agree to communicate with (e.g., a "deny" list). In some cases, consent rule 240 might indicate whether a device agrees to receive communication based on the type or purpose of the communication. After receiving an indication of consent rule 240 (or "consent data") from a device, consent-contract component 114 might store consent rule 240 for later use in determining whether a device agrees to receive communication from other devices. Generally, consent rule 240 might be stored in association with the device that provides consent rule 240 (e.g., a mapping between consent rule 240 and the device providing consent).

[0087] Furthermore, the consent-contract component 114 can also use consent rule 240 and requests from devices wishing to communicate with other devices to create consent contract 118. For example, consent-contract component 114 can receive a request from client device 104 and determine that the IP address (or other address) of client device 104 is within the list of allowed or consented IP addresses in consent rule 240 received from server 110 and / or service 106. As another example, consent-contract component 114 can receive a request from client device 104 to perform a specific type of communication and / or communication for a specific purpose. Consent-contract component 114 can determine that the communication type and / or purpose falls under the category of consented communication or purpose. After determining that consent rule 240 indicates that the receiving device has consented to receive communication from the requesting device, consent-contract component 114 can generate consent contract 118 indicating consent between devices and store consent contract 118 in consent database 116.

[0088] Memory 206 may further store network-topology component 216, which is configured to determine network-topology data 242 for one or more networks 112. For example, network-topology component 216 may act as or include a network controller configured to monitor communications in one or more networks 112, for example, by receiving control-plane and / or data-plane data indicating path selection, topology, and / or location of network devices 114 in one or more networks 112. Network-topology component 216 may generate network-topology data 242 and store the data in data storage 238.

[0089] In the example where consent contract 118 is distributed to and executed by network device 114, consent-contract component 114 can use network-topology data 242 to determine which network devices 114 should receive consent contract 118. For example, consent-contract component 114 can use network-topology data 242 to determine which network devices 114 are positioned between client device 104 and server 110, and receive the relevant consent contract 118 from these network devices 114.

[0090] The consent-contract system 102 may include one or more data stores 238 configured to store the various data and databases described herein. Data stores 238 may include any type of computer memory, including long-term memory (e.g., read-only memory (ROM), random access memory (RAM), cache, etc.). Data stores 228 may include at least consent rules 240, consent database 116, network-topology data 242, and / or any other data described herein.

[0091] The consent-contract system 102 may be or include DNS 226, which includes DNS consent logic 228 and a DNS resolver 230. DNS resolver 230 may include logic for resolving domain names to IP addresses. In some examples, DNS 226 may be used as a point of execution for consent contract 118. For example, the DNS server of DNS 226 may receive DNS requests from client device 104. Client device 104 may request the DNS server to resolve a domain name (e.g., a website address) to an IP address that makes the device associated with the domain name reachable. For example, the domain name may be associated with service 106A, and DNS resolver 230 may be configured to resolve the domain name to the IP address associated with server 110A and / or service 106A. However, DNS consent logic 228 may use consent contract 118 to determine whether server 110A and / or service 106A has consented to receive communication from client device 104. If DNS consent logic 228 determines that server 110A and / or service 106A has established consent contract 104 with client device 104A, and / or if consent rule 240 received from server 110A and / or service 106A indicates consent, then DNS resolver 230 can resolve the domain name to an IP address and return the IP address to client device 104A. Conversely, if DNS consent logic 228 determines that server 110A and / or service 106A does not consent to communicate with client device 104A, then DNS resolver 230 will not return an IP address to client device 104A. In this way, consent-contract system 102 may be or include DNS 226 that can be used to enforce consent contract 118 and / or consent rule 240.

[0092] In some examples, the consent-contract system 102 may be or include a CA system 232, which includes a issuing component 234 and a verification component 236. Generally, the issuing component 234 can issue a digital certificate that proves ownership of the public key through the subject named in the certificate. For example, the issuing component 234 can issue a digital certificate to server 110 containing the public key and server 110's identity as the owner. Therefore, server 110 can receive the signed digital certificate from the issuing component 234. In some cases, client device 104A may wish to contact server 110A and send a request to CA system 232 to verify server 110A's signed digital certificate. The verification component 236 can initially use the consent contract 118 to determine whether server 110A and / or service 106A have consented to receive communication from client device 104A. If verification component 236 determines that server 110A and / or service 106A has established an agreement contract 104 with client device 104A, and / or if the agreement rule 240 received from server 110A and / or service 106A indicates agreement, then verification component 236 may determine that the signed certificate is valid and notify client device 104A that the signed certificate is valid. Conversely, if verification component 236 determines that server 110A and / or service 106A does not agree to communicate with client device 104A, then verification component 236 will not return an indication that the signed certificate is valid.

[0093] As shown in the figure, the agreement-contract system may include a signature component 244, which is configured to sign data using a private key 120 to create signed data 124, and may distribute the corresponding public key 122 to network device 114. In some cases, data storage 238 may include an address-to-key database 246, which maps or associates destination addresses of the storage device with private key 120 and public key 122 pairs used to sign and verify data at these destination devices.

[0094] However, in some cases, the consent-contract system 102 may include or may be a network controller for managing some or all of the control plane activities of network(s) 112 and using one or more centralized control models to manage or monitor network status. Furthermore, the consent-contract system 102 may also include or may be an identity service provider that executes consent contracts 118 at the identity level (e.g., executing consent contracts 118 when a user provides identity instructions (e.g., username and password or other authentication mechanisms)).

[0095] Figure 3AThe diagram illustrates the system architecture of an environment 300 where the consent-contract system 102 creates a consent contract 118 between a client device 104 and a server 110 and / or service 106. However, the consent contract 118 can be established between any type of computing device or node.

[0096] like Figure 3A As shown, the consent-contract component 114 can create and manage consent contracts 118. For example, the consent-contract component 114 can be configured to receive consent data 304 representing consent rules 240 from various devices utilizing the consent-contract system 102. For example, the consent-contract component 114 can receive consent data 304 from client devices 104, servers 110, and / or other devices that wish to refuse to accept network communications they do not consent to. The consent data 304 received by the consent-contract component 114 can typically be any type of consent data 304 indicating that the device and / or receiving device consents to receive communications.

[0097] For example, consent data 304 might simply be a range of IP addresses that server 110 and / or service 106 agrees to communicate with (e.g., an "allow" list). As another example, consent data 304 could be a range of IP addresses that a device does not agree to communicate with (e.g., a "deny" list). In some cases, consent data 304 might indicate whether a device agrees to receive communication based on the type or purpose of the communication. Upon receiving the indication of consent data 304 from the device, the consent-contract component 114 might store a corresponding consent rule 240 for later determining whether the device agrees to receive communication from other devices. Generally, consent rule 240 might be stored in association with the device that provides consent rule 240 (e.g., a mapping between consent rule 240 and the device providing consent).

[0098] Furthermore, the consent-contract component 114 can use consent rule 240 and request data 302 from a device wishing to communicate with other devices to create a consent contract 118. For example, the consent-contract component 114 can receive request data 302 from client device 104 and determine if the IP address (or other address) of client device 104 is in the list of allowed or consented IP addresses received from server 110 and / or service 106 in consent rule 240. As another example, the consent-contract component 114 can receive request data 302 from client device 104 to perform a specific type of communication and / or communication for a specific purpose. The consent-contract component 114 can determine if the communication type and / or purpose falls under the category of consented communication or purpose. After determining that consent rule 240 indicates that the receiving device has consented to receive communication from the requesting device, the consent-contract component 114 can generate a consent contract 118 indicating consent between devices and store the consent contract 118 in the consent database 116.

[0099] Figure 3B The diagram illustrates the system architecture of an environment where a consent-contract system maps public keys to the addresses of destination devices (e.g., servers).

[0100] As shown in the figure, there is a mapping or association between the destination addresses of the address-to-key database 246 storage device and the private key 120 and public key 122 pairs used to sign and verify data for these destination devices. In some examples, when client device 104 sends request data 302 to consent-contract system 102, consent-contract component 114 can determine the destination device that client device 104 requests to communicate with. Consent-contract component 114 can determine that a consent contract 118 exists between client device 104 and server 110 (or any sending device and destination device). Next, consent-contract component 114 can identify the mapping between the destination address and the public / private key pair from address-to-key database 246. In some cases, there may be domains and / or other address ranges associated with a particular key pair 120 / 122. For example, an organization or domain may have an address range associated with a particular key pair 120 / 122, while different organizations or domains may have another address range associated with different particular key pairs 120 / 122. The agreement-contract component 114 can sign the data fragment using a private key 120 applicable to the destination address and provide the signed data 124 to the client device 104. If the corresponding public key 122 has not yet been distributed to the network device 114, the agreement-contract component 114 can also distribute the corresponding public key 122 to the network device 114 and indicate which destination addresses the public key 122 can use to verify the signed data 124.

[0101] Figure 4 A flowchart is shown of an example method 400 in which client device 104 and server 110 use consent-contract system 102 to establish consent contract 118.

[0102] At 402, when client device 104 joins the network and / or continuously joins the network through the hardware or software configuration of client device 104, an IP address "WXYZ" can be assigned to client device 104. Similarly, at 404, when server 110 joins the network and / or continuously joins the network through the hardware or software configuration of server 110, an IP address "ABCD" can be assigned to server 110.

[0103] At position 406, server 110 can register consent with consent-contract system 102 for devices originating from the IP range "WXYZ". That is, server 110 can send consent data 304 to consent-contract system 102, which instructs server 110 to consent to devices receiving communications.

[0104] At point 408, client device 104 may send a request to consent-contract system 102, requesting consent to communicate with the device with IP address "ABCD", i.e., server 110. Consent-contract system 102 may determine whether server 110 has consented to communicate with client device 104. For example, consent-contract system 102 may determine whether client device 104 and server 110 have created consent contract 118, and / or whether consent rule 240 received from server 110 indicates consent to communicate with client device 104.

[0105] At 410, the consent-contract system 102 can verify the request and create a consent contract 118. For example, the consent-contract system 102 can use request data 302 from client device 104 and consent rule 240 associated with server 110 to create consent contract 118.

[0106] At 412, the consent-contract system 102 can provide the client device 104 with an instruction to allow consent and permit the client device 104 to communicate with the server. Then, at 414, the client device 104 can establish a connection with the server 110 through one or more networks 112 (e.g., by establishing a TCP connection via a TCP handshake).

[0107] Figure 5 A flowchart is shown of an example method 500 for an consent-contract system 102 to determine whether server 110 wishes to establish consent contract 118 with client device 104.

[0108] At position 502, when client device 104 joins the network and / or continuously joins the network through the hardware or software configuration of client device 104, an IP address "WXYZ" can be assigned to client device 104. Similarly, at position 504, when server 110 joins the network and continuously joins the network through the hardware or software configuration of server 110, an IP address "ABCD" can be assigned to server 110.

[0109] At 506, client device 104 can send a request to consent-contract system 102, requesting consent to communicate with a device having IP address “ABCD”, which in this example is server 110.

[0110] At point 508, the consent-contract system 102 can determine that server 110 has not provided consent for client device 104 to communicate with server 110. For example, server 110 may not have provided consent data 304 instructing client device 104 to connect to server 110.

[0111] At point 510, the consent-contract system 102 may send a request to server 110 instructing server 110 whether it consents to communication with client device 104. This request may indicate the IP address of client device 104 and / or the purpose or type of communication. Server 110 may determine that it wishes to communicate with the client device, and at point 512, provides the consent-contract system 102 with an instruction to consent to communication between client device 104 and server 110.

[0112] At 514, the consent-contract system 102 can provide the client device 104 with an instruction to allow consent and permit the client device 104 to communicate with the server. Then, at 516, the client device 104 can establish a connection with the server 110 through one or more networks 112 (e.g., by establishing a TCP connection via a TCP handshake).

[0113] Figure 6 A flowchart is shown of an example method 600 for Domain Name System (DNS) 226 to create and use consent contract 118 to allow or disallow network-based communication.

[0114] At position 602, when client device 104 joins the network and / or continuously joins the network through the hardware or software configuration of client device 104, an IP address "WXYZ" can be assigned to client device 104. Similarly, at position 604, when server 110 joins the network and / or continuously joins the network through the hardware or software configuration of server 110, an IP address "ABCD" can be assigned to server 110.

[0115] At 606, server 110 can register with DNS 226 its consent to devices from the IP range "WXYZ". That is, server 110 can send consent data 304 to DNS 226 instructing server 110 to consent to devices receiving communication.

[0116] At 608, client device 104 may send a DNS request to DNS 226, requesting that the domain name “consent.com” be resolved to an address associated with this domain name. DNS 226 may determine whether server 110 has consented to communicate with client device 104. For example, DNS 226 may determine whether client device 104 and server 110 have created a consent contract 118, and / or whether consent rule 240 received from server 110 indicates consent to communicate with client device 104.

[0117] At 610, DNS 226 can verify the request and resolve “consent.com” to an IP address that can be used to reach the device associated with the domain name “consent.com”. For example, DNS 226 can use request data 302 from client device 104 and consent rule 240 associated with server 110 to create consent contract 118.

[0118] At 612, DNS 226 can provide client device 104 with an instruction to grant permission and the IP address of server 110, enabling client device 104 to communicate with server 110. Then, at 614, client device 104 can establish a connection with server 110 through one or more networks 112 (e.g., by establishing a TCP connection via a TCP handshake).

[0119] Figure 7 A flowchart is shown of an example method 700 in which a Certificate Authority (CA) system 232 creates and uses an agreement contract 118 to allow or disallow network-based communication.

[0120] At 702, when client device 104 joins the network and / or continuously joins the network through the hardware or software configuration of client device 104, an IP address "WXYZ" can be assigned to client device 104. Similarly, at 704, when server 110 joins the network and / or continuously joins the network through the hardware or software configuration of server 110, an IP address "ABCD" can be assigned to server 110.

[0121] At point 706, server 110 can request a signed digital certificate, and CA system 234 can issue a digital certificate to server 110. At point 708, server 110 can register with CA system 234 its consent to devices from the IP range "WXYZ". That is, server 110 can send consent data 304 to CA system 234 instructing server 110 to consent to devices receiving communication.

[0122] At 710, client device 104 may request a digital certificate from server 110, and server 110 may provide the digital certificate to client device. At 712, client device 104 may send a request to CA system 234 to verify server 110's digital certificate. CA system 234 may determine whether server 110 has consented to communicate with client device 104. For example, CA system 234 may determine whether client device 104 and server 110 have created a consent contract 118, and / or whether consent rule 240 received from server 110 indicates consent to communicate with client device 104.

[0123] At point 714, CA system 234 can verify the digital certificate and confirm that server 110 has provided consent to communicate with client device 104. For example, CA system 234 can use request data 302 from client device 104 and consent rule 240 associated with server 110 to create consent contract 118.

[0124] At 716, CA system 234 can provide client device 104 with instructions to grant permission and consent, as well as the IP address of server 110, enabling client device 104 to communicate with server 110. Then, at 718, client device 104 can establish a connection with server 110 through one or more networks 112 (e.g., establishing a TCP connection via a TCP handshake).

[0125] Figure 8 A flowchart is shown of an example method 800 for executing an agreement contract 118 using a socket on client device 104.

[0126] At 802, server 110 can open a socket, such as an Internet socket, to provide server 110 with access to the TCP / IP transport protocol. The socket can be a stream socket that allows programs to use TCP communication, a datagram socket that allows programs to use UDP communication, an ICMP socket, and / or any other type of socket.

[0127] At 804, server 110 can bind the socket to its address and port to receive data on the socket. At 806, server 110 can begin listening for traffic that will be received via the socket.

[0128] At 808, client device 104 can also open a socket (e.g., TCP, UDP, etc.). The socket opened on client device 104 can be a specific type of socket implemented by the operating system of client device 104, and when using this socket, a consent verification occurs when client device 104 attempts to create the socket. For example, at 810, client device 104 can attempt to obtain consent from consent-contract system 102. Therefore, consent is already built into the socket when it is opened on client device 104.

[0129] At 812, the consent-contract system 102 can accept the request (e.g., an indication that consent has been found), and since consent has been found, the client device 104 is permitted to connect to the socket on the server 110.

[0130] At 816, the client device can send data to the server 110 via one or more networks 112, for example, using TCP or UDP in the Internet example. At 818, the server 110 can receive data and respond at 820 by sending data to the client device. At 822, the client device can receive data and can continue to send and receive data with the server 110 (if needed).

[0131] At point 824, client device 104 can close the socket, and at point 826, server 110 can receive an instruction from client device 104 to close its socket. At point 828, server 110 can also close the socket, and the communication session can end.

[0132] Figure 9 This diagram illustrates a system architecture of an environment 900 in which network devices execute consent contracts at the network layer to allow or disallow network-based communication.

[0133] As shown in the figure, the consent-contract system 102 can generate consent contracts 118 and distribute them to network devices. In general, the consent-contract system 102 indicates that two or more devices have agreed to communicate with each other (e.g., send and receive network-based communications). The consent-contract system 102 can send consent contracts 118 to network devices, such as the PAN router 902 of client device 104, the WAN router 904 located in one or more networks 112, and / or the switch 906 located in one or more networks 112. However, network devices can be any type of device configured to communicate data over a network (e.g., servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points), and / or any other type of computing device that can run any type of software and / or virtualization technology. In some cases, network devices 902, 904, and 906 may include or be associated with NICs and smart NICs, FPGAs, ASICs, virtual machines, containers, and / or any other type of hardware-based or software-based network components.

[0134] Network devices can be configured to analyze received network-based communications, such as data packets, and use an agreement contract 118 to determine whether the destination device of these data packets has agreed to receive them. For example, network devices 902, 904, and / or 906 can determine the address of the client device 104 that sent the data packets and the address of the destination server 110. In an illustrative example, client device 104 can send data packets with a destination address corresponding to the IP address and port of server 110A, and client device 104 can also send data packets with a destination address corresponding to the IP address and port of server 110N. As shown, both data packets may arrive at PAN 902. Generally, it is more advantageous to place the network device enforcing the agreement contract 118 near the sending device (e.g., client device 104) to evaluate data packets against the agreement contract 118 and discard unwanted data packets early in the communication process.

[0135] In this example, server 110A may have agreed to receive communication from client device 104, and consent-contract system 102 may have generated consent contract 118 for the device. However, server 110N may not have agreed to receive communication from client device 104. In such an example, PAN router 902 can use consent contract 118 to determine that server 110A has agreed to receive data packet 910 from client device 104, and send data packet 910 to WAN router 904, switch 906, and finally to server 110A. However, PAN router 902 can use consent contract 118 to determine that server 110N has not agreed to receive data packet 912 from client device 104, and PAN router 902 can discard data packet 912.

[0136] Figures 10 to 14 Flowcharts for example methods 1000, 1100, 1200, 1300, and 1400 are shown, illustrating at least in part the methods described above. Figures 10 to 14 This document describes various aspects of the functions performed by the devices (e.g., client device 104, consent-contract system 102, network device 114, server 110, etc.). The document also discusses... Figures 10 to 14 The logical operations can be implemented as: (1) a sequence of behaviors or program modules implemented by a computer running on a computing system; and / or (2) as machine logic circuits or circuit modules interconnected within the computing system.

[0137] The implementation of the various components described herein depends on the choice of computing system performance and other requirements. Therefore, the logical operations described herein are referred to in various ways as operations, structural devices, behaviors, or modules. These operations, structural devices, behaviors, and modules can be implemented through software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that it is possible to perform operations that are more complex than those described herein. Figures 10 to 14 The operations shown and described herein may be more or fewer. These operations may also be performed in parallel or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically specified. Although the techniques described in this disclosure are directed to a particular component, in other examples, these techniques may be implemented by fewer components, more components, different components, or any component configuration.

[0138] In some cases, the steps of methods 1000, 1100, 1200, 1300 and / or 1400 may be performed by a device and / or a device system comprising one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by one or more processors, cause one or more processors to perform the operations of methods 1000, 1100, 1200, 1300 and / or 1400.

[0139] Figure 10 A flowchart is shown of an example method 1000 for creating an agreement contract 118 that can be used to allow or disallow network-based communication between devices.

[0140] At point 1002, the consent-contract system 102 can receive consent data instructing a first device to consent to receiving network communications from a sending device. For example, consent data 304 can instruct permission for client device 104 to communicate with server 110 and / or server 106.

[0141] At point 1004, the agreement-contract system 102 can receive request data 302, which includes a request from the second device to communicate with the first device. For example, the client device 104 can send request data 302 indicating a request to communicate with the server 110.

[0142] At point 1006, the consent-contract system 102 can use consent data and request data to determine that the first device consents to receive network communication from the second device. For example, the consent-contract system 102 can determine that the server 110 has consented to communicate with the client device 104 based on the address and / or communication type / purpose of the client device 104.

[0143] At point 1008, the consent-contract system 102 can create a consent contract 118 instructing the first device to consent to receiving network communications from the second device. The consent-contract system 102 can then locally store the consent contract 118 and / or distribute the consent contract 118 to the network device 114.

[0144] In some cases, method 1000 may also include sending an agreement contract to a network device located in the network where network communication is taking place, determining that a threshold period of time has elapsed since the agreement contract was created, and sending an indication to the network device that the agreement contract is invalid, at least in part, based on the fact that the threshold period of time has elapsed.

[0145] In some examples, other mechanisms can be used to establish consent, such as using permissions granted to an entity. For instance, permissions can be granted to devices with specific identities. Devices can be verified, authorized, and / or otherwise authenticated by a trusted party that issues the identity to the device (e.g., an identity provider or other trusted provider). Different authorizations can be granted to identities based on their identities. For example, some identities may have different permissions, similar to security levels, at which they are consented to communicate with more devices, fewer devices, different devices, and / or any combination thereof. Devices can provide consent to receive communications to a consent-contract system based on the identity issued to the requesting device. In this way, a device can contact the consent-contract system and provide its identity indication (or other permission indication), and the consent-contract system can determine whether the target receiving device of the communication has consented to communicate with the identity or permissions of the requesting device. Therefore, the consent-contract system can use identity and / or other permission indications to determine consent and create a consent contract.

[0146] In such an example, method 1000 may further include receiving first data from the second device indicating that a set of permissions is granted to the second device, and second data determining that the first device has provided indication that it agrees to receive network communications from a device having said set of permissions.

[0147] Figure 11 A flowchart is shown of an example method 1100 for a consent contract 118 used to manage network-based communication between devices.

[0148] At 1102, the consent-contract system 102 may store consent contract 118 in a storage location, and consent contract 118 typically instructs the receiving device to consent to receiving network communication from the sending device.

[0149] At 1104, the consent-contract system 102 can receive requests from a first device associated with communication with a second device. For example, the consent-contract system 102 can receive requests from client device 104 to communicate with server 110.

[0150] At 1106, the consent-contract system 102 can use consent contract 118 to determine whether the second device has consented to receive network communications from the first device.

[0151] In some cases, the consent-contract system is a DNS provider, and receiving requests from the first device includes receiving DNS requests to translate domain names into IP addresses associated with the second device. In other examples, the consent-contract system is a Certificate Authority (CA) system, and receiving requests from the first device includes receiving requests to verify signed certificates associated with the second device.

[0152] Figure 12 A flowchart is shown of an example method 1200 for executing an agreement contract 118 to allow or disallow network-based communication between devices.

[0153] At 1202, the network device may receive a consent contract instructing the first device to consent to receiving network communications from the second device. Network device 114 may include one or more of a network router, network switch, network modem, network hub, network gateway, or network access point. For example, network device 114 may receive a consent contract 118 from consent-contract system 102, and consent contract 118 may instruct server 110 whether it has consented to receiving network communications from client device 104 (however, these techniques are applicable to any communication device).

[0154] At 1204, network devices can receive data packets that will be sent over the network. For example, PAN router 902, WAN router 904, switch 906, and / or any other network device 114 can receive data packets from client device 104.

[0155] At 1206, the network device can identify from the data packet first data indicating that the data packet was sent to a first device and second data indicating that the data packet was sent to a second device. For example, network device 114 can identify the IP address of server 110 and the IP address of client device 104 from the data packet (although any type of address or indication can be used, such as a MAC address). In some cases, the first and second data can be other types of device indicators, such as device user identification, random numbers, signatures, and / or any other data that can be used to transmit device indications and / or device user indications.

[0156] At 1208, the network device can use the first data and the second data to determine whether one of the consent contracts indicates that the first device has agreed to receive data packets from the second device. For example, network device 114 can determine whether at least one of the consent contracts 118 indicates a mapping between IP addresses that instruct server 110 to agree to receive communication from client device 104.

[0157] In some cases, method 1200 includes determining that the consent contract indicates the first device has consented to receive data packets from the second device, and sending the data packets to a next-hop network device in the network, thereby transmitting the data packets to the first device. In other examples, method 1200 includes determining that the consent contract indicates the first device does not consent to receive data packets from the second device, and discarding the data packets.

[0158] In some cases, the data packets are synchronization packets that can be used to establish a Transmission Control Protocol (TCP) connection, and the network device is located in a wide area network (WAN). In some examples, an agreement contract 118 is received from a Domain Name System (DNS) provider configured to create an agreement contract or a Certificate Authority (CA) system configured to create an agreement contract.

[0159] Figure 13 A flowchart of an example method 1300 is shown, in which network device 114 verifies that a data packet includes consent data indicating that the destination device has agreed to receive the data packet.

[0160] At 1302, network device 114 can receive data packets that will be sent from the sending device to the destination device via network 112. For example, network device 114 can receive data packets that will be sent from a client device to server 110. In some cases, the data packet may be the first data packet in a data stream that will be sent to the destination device.

[0161] At 1304, network device 114 can identify consent data in the data packet that indicates the destination device has agreed to receive the data packet from the sending device. For example, network device 114 can determine that the header of the data packet includes options or extensions filled with signed data 124.

[0162] At 1306, network device 114 can determine whether the consent data was issued by the consent-contract system. For example, network device 114 can determine the destination address of the destination device and identify the public key 122 of this destination address. Network device 114 can determine which public key 122 is mapped to this destination address and / or request the consent-contract system 102 to provide the public key 122 of the specific destination address. Then, network device 114 can use the public key 122 of the specific destination address and determine whether the signed data 124 in the data packet has been signed using the corresponding private key 120.

[0163] In some examples, network device 114 determines that the consent data was issued by consent-contract system 102 (e.g., verifying the signature), and network device 114 may send the data packet (1308) to the next-hop network device in the network, thereby transmitting the data packet to the destination device (e.g., sending the data packet to another network device 114, the destination device itself, etc.).

[0164] In other examples, network device 114 determines that the consent data was not issued or signed by consent-contract system 102 (e.g., the signature is verified), and network device 114 may discard (1310) the data packet.

[0165] In some examples, network device 114 may receive an indication of a range of destination addresses associated with public key 122 from consent-contract system 102. Network device 114 may then store the association between public key 122 and the range of destination addresses and determine that the destination address is included within the range. In such examples, network device 114 may further receive a second data packet having a second destination address associated with a second destination device, and identify second consent data signed with private key 120 from the second data packet. Network device 114 may further determine that the second destination address is included within the range of destination addresses and select public key 122, at least in part, based on the association, to verify that the second consent data has been signed with private key 120.

[0166] Figure 14 A flowchart of an example method 1400 is shown, illustrating how an agreement-contract system 102 determines that a destination device has agreed to receive network communications from a sending device and provides the sending device with signed data to be included in a data packet of the network communications.

[0167] At 1402, the consent-contract system 102 can receive consent data instructing the destination device to consent to receiving network communications from the sending device. For example, consent data 304 can instruct permission for the client device 104 to communicate with server 110 and / or server 106.

[0168] At 1404, the agreement-contract system 102 can receive request data 302, which includes a request for the sending device to communicate with the destination device. For example, the client device 104 can send request data 302 indicating a request to communicate with the server 110.

[0169] At 1406, the consent-contract system 102 can use consent data and request data to determine that the destination device consents to receive network communication from the sending device. For example, the consent-contract system 102 can determine that the server 110 has consented to communicate with the client device 104 based on the address and / or communication type / purpose of the client device 104.

[0170] At 1408, the consent-contract system 102 can use private key 120 to sign data instructing the destination device to consent to receiving network communications. At 1410, the consent-contract system 102 can send the signed data to the sending device. In this way, the sending device (e.g., client device 104A) can insert the signed data 124 into the data packet destined for the destination device.

[0171] Figure 15 An example computer architecture is shown that is capable of executing program components for achieving the above-described functions. Figure 15The computer architecture shown illustrates any type of computer 1500, such as a conventional server computer, workstation, desktop computer, laptop computer, tablet computer, networked appliance, e-reader, smartphone, or other computing device, and can be used to execute any software components described herein. In some examples, computer 1500 may correspond to one or more devices including consent-contract system 102 and / or any other device described herein, and may include personal devices (e.g., smartphones, desks, wearable devices, laptop devices, etc.), networking devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, and / or any other type of computing device capable of running any type of software and / or virtualization technology.

[0172] Computer 1500 includes a baseboard 1502 or “motherboard,” which is a printed circuit board connected to various components or devices via a system bus or other electrical communication path. In one illustrative configuration, one or more central processing units (“CPUs”) 1504 operate in conjunction with a chipset 1506. The CPU 1504 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of computer 1500.

[0173] The CPU 1504 performs operations by transitioning from one discrete physical state to the next, where state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include electronic circuitry, such as flip-flops, that maintains one of two binary states, and electronic circuitry, such as logic gates, that provides the output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractor units, arithmetic logic units, floating-point units, and so on.

[0174] Chipset 1506 provides an interface between CPU 1504 and the remaining components and devices on substrate 1502. Chipset 1506 may provide an interface with RAM 1508, which serves as main memory in computer 1500. Chipset 1506 may further provide an interface with a computer-readable storage medium (e.g., read-only memory (“ROM”) 1510 or non-volatile RAM (“NVRAM”)) for storing basic routines that facilitate the startup of computer 1500 and the transfer of information between components and devices. ROM 1510 or NVRAM may also store other software components necessary for configuring and operating computer 1500 as described herein.

[0175] Computer 1500 can operate in a networked environment using a logical connection to remote computing devices and computer systems via a network (e.g., network 112). Chipset 1506 may include the ability to provide network connectivity via NIC 1512 (e.g., a Gigabit Ethernet adapter). NIC 1512 enables computer 1500 to connect to other computing devices via network 112. It should be understood that computer 1500 may have multiple NICs 1512 to connect the computer to other types of networks and remote computer systems.

[0176] Computer 1500 can be connected to storage device 1518, which provides non-volatile storage for the computer. Storage device 1518 can store operating system 1520, programs 1522, and data, which have been described in more detail herein. Storage device 1518 can be connected to computer 1500 via memory controller 1514 connected to chipset 1506. Storage device 1518 can consist of one or more physical storage units. Memory controller 1514 can interface with physical storage units via a Serial Attached SCSI (“SAS”) interface, a Serial Advanced Technology Attached (“SATA”) interface, a Fibre Channel (“FC”) interface, or other types of interfaces used for physically connecting and transferring data between the computer and physical storage units.

[0177] Computer 1500 can store data on storage device 1518 by changing the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific change of physical state depends on various factors. Examples of such factors include, but are not limited to, the technology used to implement the physical storage units, whether storage device 1518 is characterized as main memory or auxiliary memory, etc.

[0178] For example, computer 1500 can issue instructions via memory controller 1514 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location within an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component within a solid-state storage unit, thereby storing information in storage device 1518. Other transformations of the physical medium are also possible without departing from the scope and spirit of this specification; the examples provided above are merely for illustrative purposes. Computer 1500 can further read information from storage device 1518 by detecting the physical state or characteristics of one or more specific locations within the physical storage unit.

[0179] In addition to the aforementioned high-capacity storage device 1518, computer 1500 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that computer-readable storage media is any available medium that can provide non-transitory data storage and is accessible by computer 1500. In some examples, operations performed by consent-contract component 102, network device 114, and any components contained therein may be supported by one or more devices similar to computer 1500. In other words, some or all of the operations performed by consent-contract system 102 and / or network device 114 and any components contained therein may be performed by one or more computer devices 1500.

[0180] For example, and not as a limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (“EPROM”), electrically erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technologies, optical disc ROM (“CD-ROM”), digital versatile disk (“DVD”), high-definition DVD (“HD-DVD”), Blu-ray disc (BLU-RAY) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0181] As briefly described above, storage device 1518 may store operating system 1520 used to control the operation of computer 1500. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system includes a WINDOWS® SERVER operating system from MICROSOFT Corporation, located in Redmond, Washington. According to other embodiments, the operating system may include a UNIX operating system or a variant thereof. It should be understood that other operating systems may also be used. Storage device 1518 may store other systems or applications and data used by computer 1500.

[0182] In one embodiment, storage device 1518 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 1500, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 1500 by specifying how CPU 1504 transitions between different states. According to one embodiment, computer 1500 can access the computer-readable storage medium storing the computer-executable instructions, which, when executed, enable the execution of the above-described embodiments relating to Figures 1 to 1. Figure 14 The various processes described herein. Computer 1500 may also include a computer-readable storage medium having instructions stored thereon for performing any other computer-implemented operations described herein.

[0183] Computer 1500 may also include one or more input / output controllers 1516 for receiving and processing input from input devices such as keyboards, mice, touchpads, touchscreens, styluses, or other types of input devices. Similarly, input / output controllers 1516 may provide output to a display such as a computer monitor, flat panel display, digital projector, printer, or other types of output device. It is understood that computer 1500 may not include... Figure 2 All components shown may include Figure 15 Other components not explicitly shown, or those that may be used in conjunction with... Figure 15 The architecture shown is completely different.

[0184] As described herein, computer 1500 may include one or more of consent-contract system 102, network device 114, and / or any other device. Computer 1500 may include one or more hardware processors 1504 (processors) configured to execute one or more stored instructions. The processors 1504 may include one or more cores. Furthermore, computer 1500 may include one or more network interfaces configured to provide communication between computer 1500 and other devices, such as the communication performed herein by client device 104, consent-contract system 102, and / or network device 114. The network interface may include a device configured to couple to a personal area network (PAN), wired and wireless local area network (LAN), wired and wireless wide area network (WAN), etc. For example, the network interface may include a device compatible with Ethernet, Wi-Fi™, etc. Program 1522 may include any type of program or process for performing the techniques described in this disclosure.

[0185] In summary, technologies for creating consent contracts for devices indicate whether a device consents to receiving network-based communication from other devices. Furthermore, these technologies include enforcing consent contracts to allow or disallow network-based communication at the network communication layer before the network communication reaches the device. The technologies described herein do not simply allow a device to communicate with any other device over a network, but rather involve establishing consent for network-based communication, obtaining consent at one or more points during the communication process, to make informed decisions about network-based traffic.

[0186] While the invention has been described with reference to specific examples, it should be understood that the scope of the invention is not limited to these specific examples. Since other modifications and alterations made to suit specific operational requirements and environments will be apparent to those skilled in the art, the invention should not be considered limited to the examples chosen for disclosure purposes, and covers all variations and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0187] Although this application describes embodiments with specific structural features and / or methodological behaviors, it should be understood that the claims are not necessarily limited to the specific features or behaviors described. Rather, the specific features and behaviors are merely illustrative embodiments falling within the scope of the claims of this application.

Claims

1. A consent-contract system, comprising: One or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform operations including: Receive an instruction from the destination device located in the network indicating that the destination device has agreed to receive network communications from the sending device; Based at least in part on the instruction, a private key is distributed to the sending device, wherein the private key can be used to create a signature on consent data indicating that the destination device has consented to communicate with the sending device; Based at least in part on the instructions, a public key is distributed to network devices located in the network, wherein the public key can be used to verify the signature of consent data that has been signed using a private key, which is provided to the sending device with which the destination device has consented to communicate; At the network device, a data packet to be sent through the network is received, the data packet being sent from the sending device to the destination device; Consent data is identified from the data packet, indicating that the destination device has consented to receive the data packet from the sending device; Use the public key to verify that the consent data was signed using the private key; The destination device has agreed to receive the data packet from the sending device, based at least in part on the fact that the consent data was signed using the private key. as well as The data packet is sent to the next-hop network device in the network, so that the data packet is transmitted to the destination device.

2. The consent-contract system according to claim 1, further comprising: Identify the destination address associated with the destination device from the data packet; Receive a request from the network device for a specific public key associated with the destination address of the destination device; and The specific public key is sent from the consent-contract system to the network device.

3. The consent-contract system according to claim 1, further comprising: The consent data indicates that the destination device has consented to receive network communications from the sending device.

4. The consent-contract system according to claim 1, further comprising: Receive an indication of a range of destination addresses associated with the public key; Store the association between the public key and the destination address range; Determine that the destination address is included within the range of destination addresses; and The public key is selected at least in part based on the association to verify that the consent data was signed using the private key.

5. The consent-contract system according to claim 4, further comprising: The network device receives a second data packet having a second destination address associated with a second destination device. Identify the second consent data signed with the private key from the second data packet; It is determined that the second destination address is included within the range of said destination addresses; and The public key is selected at least in part based on the association to verify that the second consent data was signed using the private key.

6. The consent-contract system according to any one of claims 1 to 5, wherein, The network device includes at least one of the following: Network router; Network switch; Network modem; Network hub; Network gateway; or Network access point.

7. A communication method for identifying consent from a data packet indicating that a destination device has agreed to receive network communication, the communication method comprising: At the consent-contract system, the destination device receives an instruction from the network indicating that the destination device has consented to receive network communications from the sending device; Based at least in part on the instruction, the consent-contract system distributes a private key to the sending device, wherein the private key can be used to create a signature on consent data indicating that the destination device has consented to communicate with the sending device; Based at least in part on the instructions, the consent-contract system distributes a public key to network devices located in the network, wherein the public key can be used to verify the signature of consent data that has been signed using a private key, which is provided to the sending device with which the destination device has consented to communicate; At the network device, a data packet to be sent through the network is received, the data packet being sent from the sending device to the destination device; Consent data is identified from the data packet, indicating that the destination device has consented to receive the data packet from the sending device; Use the public key to determine whether the consent data was signed using the private key; as well as In response to determining that the consent data is signed using the private key, the data packet is sent to the next-hop network device in the network, so that the data packet is transmitted to the destination device; or The data packet is discarded in response to the determination that the consent data has not been signed with the private key.

8. The communication method according to claim 7, further comprising: Identify the destination address associated with the destination device from the data packet; Send a request for a specific public key to the consent-contract system, the specific public key being associated with the destination address of the destination device; and Receive the public key from the consent-contract system.

9. The communication method according to claim 7, further comprising: The consent data indicates that the destination device has consented to receive network communications from the sending device.

10. The communication method according to claim 7, further comprising: Receive an indication of the range of destination addresses associated with the public key from the consent-contract system; Store the association between the public key and the destination address range; Determine that the destination address is included within the range of destination addresses; and The public key is selected at least in part based on the association to verify that the consent data was signed using the private key.

11. The communication method according to claim 10, further comprising: Receive a second data packet having a second destination address associated with a second destination device; Identify the second consent data signed with the private key from the second data packet; It is determined that the second destination address is included within the range of said destination addresses; and The public key is selected at least in part based on the association to verify that the second consent data was signed using the private key.

12. The communication method according to claim 7, wherein, The network device includes at least one of the following: Network router; Network switch; Network modem; Network hub; Network gateway; or Network access point.

13. The communication method according to any one of claims 7 to 12, further comprising: The first data is received at the consent-contract system, indicating that the destination device consents to receiving the network communication from the sending device. The second data is received at the consent-contract system, the second data including the sending device's request to communicate with the destination device; The consent data indicating the destination device's consent is signed using the private key; as well as The consent data is sent to the sending device.

14. A communication method, comprising the following: At the consent-contract system, an instruction is received from the destination device in the network indicating that the destination device has consented to receive network communications from the sending device; Based at least in part on the instruction, the consent-contract system distributes a private key to the sending device, wherein the private key can be used to create a signature on consent data indicating that the destination device has consented to communicate with the sending device; Based at least in part on the instructions, the consent-contract system distributes a public key to network devices located in the network, wherein the public key can be used to verify the signature of consent data that has been signed using a private key, which is provided to the sending device with which the destination device has consented to communicate; At the network device, a data packet to be sent through the network is received, the data packet being sent from the sending device to the destination device; Consent data is identified from the data packet, indicating that the destination device has consented to receive the data packet from the sending device; Determine whether the consent data was issued by the consent-contract system based at least in part on the signature of the sending device on the consent data, wherein the consent-contract system manages consent contracts that indicate consent to network communication between devices; as well as In response to determining that the consent data was issued by the consent-contract system, the data packet is sent to the next-hop network device in the network, so that the data packet is transmitted to the destination device; or The data packet is discarded in response to the determination that the consent data was not published by the consent-contract system.

15. The communication method according to claim 14, further comprising: The consent data indicates that the destination device has consented to receive network communications from the sending device.

16. The communication method according to claim 14, wherein, Determining whether the consent data was published by the consent-contract system includes: The public key is used to determine that the consent data was signed using the private key, wherein the public key is provided to the network device from the consent-contract system.

17. The communication method according to claim 16, further comprising: Identify the destination address associated with the destination device from the data packet; Send a request for a specific public key to the consent-contract system, the specific public key being associated with the destination address of the destination device; and Receive the public key from the consent-contract system.

18. The communication method according to claim 16, further comprising: Receive an indication of the range of destination addresses associated with the public key from the consent-contract system; Store the association between the public key and the destination address range; Determine that the destination address is included within the range of destination addresses; and The public key is selected at least in part based on the association to verify that the consent data was signed using the private key.

19. The communication method according to claim 18, further comprising: Receive a second data packet having a second destination address associated with a second destination device; Identify the second consent data signed with the private key from the second data packet; It is determined that the second destination address is included within the range of said destination addresses; and The public key is selected at least in part based on the association to verify that the second consent data was signed using the private key.

20. The communication method according to any one of claims 16 to 19, further comprising: The first data is received at the consent-contract system, indicating that the destination device consents to receiving network communication from the sending device. The second data is received at the consent-contract system, the second data including the sending device's request to communicate with the destination device; The consent data indicating the destination device's consent is signed using the private key; as well as The consent data is sent to the sending device.

21. A communication apparatus for identifying consent from a data packet indicating that a destination device has agreed to receive network communications, the apparatus comprising: A means for receiving, at an agreement-contract system, an instruction from a destination device in a network indicating that the destination device has agreed to receive network communications from a sending device; A means for distributing a private key from the consent-contract system to the sending device, at least in part, based on the instruction, wherein the private key can be used to create a signature on consent data indicating that the destination device has consented to communicate with the sending device; A means for distributing a public key from the consent-contract system to network devices in the network, at least in part, based on the instruction, wherein the public key can be used to verify a signature of consent data signed using a private key, the private key being provided to a sending device with which the destination device has consented to communicate; A means for receiving, at the network device, a data packet to be transmitted over the network, the data packet being transmitted from the sending device to the destination device; A means for identifying consent data from the data packet, the consent data indicating that the destination device has consented to receive the data packet from the sending device; A means for using the public key to determine whether the consent data was signed using the private key; as well as Means for sending the data packet to a next-hop network device in the network to transmit the data packet to the destination device in response to determining that the consent data is signed using the private key; or A means for discarding the data packet in response to determining that the consent data has not been signed by the private key.

22. The communication device according to claim 21, further comprising: Apparatus for implementing the communication method according to any one of claims 8 to 13.

23. A communication device, comprising: A means for receiving, at an agreement-contract system, an instruction from a destination device in a network indicating that the destination device has agreed to receive network communications from a sending device; A means for distributing a private key from the consent-contract system to the sending device, at least in part, based on the instruction, wherein the private key can be used to create a signature on consent data indicating that the destination device has consented to communicate with the sending device; A means for distributing a public key from the consent-contract system to network devices in the network, at least in part, based on the instruction, wherein the public key can be used to verify a signature of consent data signed using a private key, the private key being provided to a sending device with which the destination device has consented to communicate; A means for receiving, at the network device, a data packet to be transmitted over the network, the data packet being transmitted from the sending device to the destination device; A means for identifying consent data from the data packet, the consent data indicating that the destination device has consented to receive the data packet from the sending device; A means for determining whether the consent data was issued by the consent-contract system based at least in part on the signature of the sending device on the consent data, wherein the consent-contract system manages consent contracts that indicate consent to network communication between devices; as well as Means for sending the data packet to a next-hop network device in the network to transmit the data packet to the destination device in response to determining that the consent data was issued by the consent-contract system; or A means for discarding the data packet in response to determining that the consent data was not published by the consent-contract system.

24. The communication device according to claim 23, further comprising: Apparatus for implementing the communication method according to any one of claims 15 to 20.

25. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the communication method according to any one of claims 7 to 20.

26. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the communication method according to any one of claims 7 to 20.

Images