Patent Description:
A computer network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between the nodes (e.g., computing devices), such as servers, routers, endpoints, and hosts. An administrator may desire to ensure that the network to which a host computing device is joining is an intended network. Likewise, a number of routers and servers within the network may seek to authenticate the host to ensure the host is authentic and that the host computing device is the device the host computing device asserts it to be.

Neighbor discovery (ND) protocols are protocols in the Internet protocol suite used with Internet protocol version <NUM> (IPv6). ND protocols operate at the link layer of the <NUM> Internet model and are responsible for gathering various information required for Internet communication. The information required for Internet communication may include the configuration of local connections and the domain name servers and gateways used to communicate with more distant systems. ND protocols may include registration extensions for IPv6 over a low-power wireless personal area network (6LoWPAN). RFC <NUM> is a host computing device to router interface that enables the host computing device to request routing services. RFC <NUM> is referenced by a revision to the IEEE <NUM> protocols as the interface for IPv6 ND proxy and for host route injection in a routing protocol for low-power and lossy (RPL) networks. Further, in the case of cloud networking, the RFC <NUM> defines a host to router interface to the Internet Engineering Task Force (IETF) routing protocol for cloud underlay referred to as routing in fat trees (RIFT). However, RFC <NUM> is not self-secured and relies on lower layer security. Under these and other current protocols, the host computing device is not protected against a router being a rogue routing device that may impersonate the network the host computing device seeks or intends to join. Further, these and other current protocols, do not ensure that the network devices such as routers, registrars, and servers are able to confirm that the host computing device is, in fact, the computing device the host computing device purports to be.

<NPL>",updates the 6LoWPAN Neighbor Discovery (ND) protocol defined in RFC <NUM> and RFC <NUM>. The new extension is called Address Protected Neighbor Discovery (AP-ND) and it protects the owner of an address against address theft and impersonation attacks in a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID) and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof-of-ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.

The methods and protocols described in RFC <NUM> include descriptions regarding a host to router interface that enable the host to request routing services. However, RFC <NUM> does not describe the methods the host may use to prove to a router device and/or server device that the host is the owner of an address (e.g., an intemet protocol (IP) address and/or a media access control (MAC) address) and to prove to the host and/or other networked devices (e.g., the router device and/or the server device) that the host has joined the right network.

RFC <NUM> updates RFC <NUM> titled Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs), to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the routing registrars performing routing for host routes and/or proxy neighbor discovery (ND) in a low-power network. RFC <NUM> and RFC <NUM> are incorporated herein in their entireties.

IPv6 Low-Power and Lossy Networks (LLNs) support star and mesh network topologies, and 6LoWPAN ND provides a registration mechanism and a central IPv6 ND registrar to ensure unique addresses. The 6LoWPAN ND mechanism reduces the dependency of the IPv6 ND protocol on network-layer multicast and link-layer broadcast operations. RFC <NUM> simplifies and generalizes registration in 6LoWPAN Routers (6LRs) by modifying and extending the behavior and protocol elements of 6LoWPAN ND to simplify the registration flow for link-local addresses, enable verification for the registration, using a registration ownership verifier (ROVR), and enable registration to an IPv6 ND proxy such as, for example, a routing registrar.

Within an RFC <NUM> registration flow, a neighbor solicitation (NS) message nay be utilized that includes an extended address registration option (EARO) that registers the address of the host computing device (e.g., a 6LoWPAN Node (6LN) to a router (e.g., a 6LoWPAN Backbone Router (6BBR). A duplicate address detection (DAD) process may be unicast such that the router checks that the address is unique with a central network registrar (e.g., 6LoWPAN border router (6LBR)). This process may be utilized in the cloud in association with, for example, a locator identification separation protocol (LISP) map server (MS)/map resolver (MR).

In one example, an extension referred to as address protected neighbor discovery (AP-ND) may be used within an LLN to protect an owner of an address against address theft and impersonation attacks. AP-ND is an update or extension to the 6LoWPAN ND protocol defined in RFC <NUM> and RFC <NUM>. A host computing device that supports the extension may compute a cryptographic identifier (crypto-ID) and use it with a registered address. The crypto-ID identifies the owner of the registered address and may be used to provide proof of ownership of the registered addresses. Once an address is registered with the crypto-ID and a proof-of-ownership is provided, the owner of that address may modify the registration information, thereby enforcing source address validation. The cryptographic method including its algorithms, curves, encodings, etc., may be signaled by a crypto-type. The parameters of the cryptographic method including at least one of a public or private key of a public key infrastructure (PKI) key pair may be passed via a network crypto-identification parameters option (CIPO) defining the cryptographic identifier (crypto-ID), the crypto-ID being derived from the public key of the PKI key pair. Further, under AP-ND, at least two separate nonces may be passed between a host computing device and a router; the router passing a first nonce and the host computing device passing a second nonce in response. The present systems and methods utilize a crypto-ID identifying the network <NUM> to which the host computing device <NUM> seeks to join. This network crypto-ID may be provisioned or pre-provisioned by a network registrar <NUM> to the host computing device <NUM> for the purpose of authenticating to the host computing device <NUM> that the network <NUM> is the network the host computing device <NUM> is intending to join. The network crypto-ID may be a hash of a public key that authenticates the network to which the host computing device seeks to join. The associated private key is used by a network registrar to sign the CIPO via a neighbor discovery protocol signature option (NDPSO).

In AP-ND, a neighbor discovery protocol signature option (NDPSO) may be passed from the host computing device to the router. The NDPSO carries the signature that proves the address ownership (e.g., the crypto-ID passed by the host computing device). The crypto-ID may be derived from the public key and a modifier in a format that includes a hash function used internally by the signature scheme indicated by the crypto-type that is applied to the CIPO and leftmost bits of the resulting hash, up to the desired size, that are used as the crypto-ID.

AP-ND adds a validation phase to the methods and protocols described in RFC <NUM> whereby the router checks that the host computing device is the owner of the crypto-ID that is associated with the address in a first registration instance, and allows the use of the address to source packets or inject routes. AP-ND protects the address of the host. However, AP-ND does not provide a guarantee that the host computing device has joined an intended (e.g., the right network). Given that computer networking is ubiquitous including virtual networking and overlay networking, it may prove easy to connect to an incorrect network or communicatively connect two computing devices together. Thus, the systems and methods described herein provide an additional service to a host computing device that confirms to the host computing device that it has joined the intended network.

Examples described herein provide a method including sending, to a network registrar, an extended duplicate address request (EDAR) message including a host nonce (e.g., NonceH) generated by a host computing device, and receiving, from the network registrar, an extended duplicate address confirmation (EDAC) message including a network nonce (e.g., NonceL) generated by the network registrar, the pair of nonces (e.g., NonceH and NonceL) being signed by the network registrar via a private key of a first public key infrastructure (PKI) key pair of the network registrar via a first signature. The method further includes sending a neighbor advertisement (NA) message from a router to the host computing device including at least the second nonce (e.g., NonceL). The second nonce (e.g., NonceL) and the public key of the network registrar verifies the first signature from the network registrar, the verification of the first signature indicating that the router is not impersonating the network.

The NA message from the router and based on the EDAC message from the network registrar includes a network crypto-identification parameters option (CIPO) containing the public key of a first PKI key pair, an arbitrary modifier and an indication of the size of a network cryptographic identifier (crypto-ID) to be generated. The network crypto-ID is obtained as a truncated hash of the network CIPO, and, thus, is derived from a public key of the first PKI key pair. The method may further include pre-provisioning the host computing device with the network crypto-ID as an identification of the network that the host computing device is to join. The method may further include sending the NA message from the router and based on the EDAC message from the network registrar to the host computing device with the network CIPO. Thus, the method includes sending to the host computing device material to validate that the public key corresponds to the network crypto-ID, and that the first signature corresponds with the private key that forms the first PKI key pair with the public key. The first signature signs the network crypto-ID via a neighbor discovery protocol signature option (NDPSO).

Preliminary to the above processes, the host computing device may communicate with the router to allow the router to validate the host computing device. Thus, the method further includes receiving, at the router, a first neighbor solicitation (NS) message from the host computing device, the first NS message including an address of the host computing device, and a public key of a second PKI key pair of the host computing device. The method further includes sending, from the router to the host computing device, a neighbor advertisement (NA) message including a challenge to the address of the host computing device, and a third nonce generated by the router, and receiving, at the router, a second NS message from the host computing device including the first nonce, the first nonce being signed by the host computing device via a second signature. The method further includes verifying the host computing device based at least in part on the first nonce and the public key of the host computing device to verify the second signature, the verification of the second signature indicating that the host computing device is authentic.

The address of the host computing device includes at least one of an internet protocol (IP) address of the host computing device, and a media access control address (MAC) address of the host computing device. The first NS message includes an extended address registration option (EARO), the EARO including a registration ownership verifier (ROVR), the ROVR including a host crypto-ID. The host crypto-ID may be a hash of a CIPO generated by the host computing device. The second NS message from the host computing device to the router includes a CIPO including the public key. The host crypto-ID may be included within the host CIPO. The host nonce (e.g., Nonce H) may be included in a nonce option of the EARO. The host CIPO may be signed by an NDPSO. The NDPSO carries the first signature proving ownership of the host crypto-ID.

Systems and apparatus for implementing the methods described herein, including network nodes, computer programs, computer program products, computer readable media and logic encoded on tangible media for implementing the methods are also described.

Examples described herein also provide a non-transitory computer-readable medium storing instructions that, when executed, cause one or more processors to perform operations including sending, to a network registrar, an extended duplicate address request (EDAR) message including a host nonce (e.g., NonceH) generated by a host computing device, and receiving, from the network registrar, an extended duplicate address confirmation (EDAC) message including a network nonce (e.g., NonceL) generated by the network registrar, the pair of nonces (e.g., NonceH and NonceL) being signed by the network registrar via a private key of a first public key infrastructure (PKI) key pair of the network registrar via a first signature. Although on nonce is sent in any given message (because each party knows its own nonce), both nonces are used in the signed content of the messages. The operations further include sending a neighbor advertisement (NA) message from a router to the host computing device including at least the second nonce (e.g., NonceL). The second nonce (e.g., NonceL) and the public key of the network registrar verifies the first signature from the network registrar, the verification of the first signature indicating that the router is not impersonating the network.

The NA message from the router and based on the EDAC message from the network registrar includes a network crypto-identification parameters option (CIPO) containing the public key of a first PKI key pair, an arbitrary modifier and an indication of the size of a network cryptographic identifier (crypto-ID) to be generated. The network crypto-ID is obtained as a truncated hash of the network CIPO, and, thus, is derived from a public key of the first PKI key pair. The method may further include pre-provisioning the host computing device with the network crypto-ID as an identification of the network that the host computing device is to join. The method may further include sending the NA message from the router and based on the EDAC message from the network registrar to the host computing device with the network CIPO thus includes sending to the host computing device material to validate that the public key corresponds to the network crypto-ID, and that the first signature corresponds with the private key that forms the first PKI key pair with the public key. The first signature signs the network crypto-ID via a neighbor discovery protocol signature option (NDPSO).

Preliminary to the above operations, the host computing device may communicate with the router to allow the router to validate the host computing device. Thus, the operations further include receiving, at the router, a first neighbor solicitation (NS) message from the host computing device, the first NS message including an address of the host computing device, and a public key of a second PKI key pair of the host computing device. The operations further include sending, from the router to the host computing device, a neighbor advertisement (NA) message including a challenge to the address of the host computing device, and a third nonce generated by the router, and receiving, at the router, a second NS message from the host computing device including the first nonce, the first nonce being signed by the host computing device via a second signature. The operations further include verifying the host computing device based at least in part on the first nonce and the public key of the host computing device to verify the second signature, the verification of the second signature indicating that the host computing device is authentic.

The address of the host computing device includes at least one of an internet protocol (IP) address of the host computing device, and a media access control address (MAC) address of the host computing device. The first NS message includes an extended address registration option (EARO), the EARO including a registration ownership verifier (ROVR), the ROVR including a host crypto-ID. The host crypto-ID may be a hash of a CIPO generated by the host computing device. The second NS message from the host computing device to the router includes a CIPO including the host crypto-ID. The host nonce (e.g., Nonce H) may be included in a nonce option of the EARO. The host CIPO may be signed by an NDPSO. The NDPSO carries the first signature proving ownership of the host crypto-ID.

Examples described herein also provide a system including a router, and a network registrar communicatively coupled to the router. The router includes one or more processors, and one or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including sending, to a network registrar, an extended duplicate address request (EDAR) message including a host nonce (e.g., NonceH) generated by a host computing device, and receiving, from the network registrar, an extended duplicate address confirmation (EDAC) message including a network nonce (e.g., NonceL) generated by the network registrar, the pair of nonces (e.g., NonceH and NonceL) being signed by the network registrar via a private key of a first public key infrastructure (PKI) key pair of the network registrar via a first signature. The operations further include sending a neighbor advertisement (NA) message from a router to the host computing device including at least the second nonce (e.g., NonceL). The second nonce (e.g., NonceL) and the public key of the network registrar verifies the first signature from the network registrar, the verification of the first signature indicating that the router is not impersonating the network.

Preliminary to the above operations, the host computing device may communicate with the router to allow the router to validate the host computing device. Thus, the operations further include operations further include receiving, at the router, a first neighbor solicitation (NS) message from the host computing device, the first NS message including an address of the host computing device, and a public key of a second PKI key pair of the host computing device. The operations further include sending, from the router to the host computing device, a neighbor advertisement (NA) message including a challenge to the address of the host computing device, and a third nonce generated by the router, and receiving, at the router, a second NS message from the host computing device including the first nonce, the first nonce being signed by the host computing device via a second signature. The operations further include verifying the host computing device based at least in part on the first nonce and the public key of the host computing device to verify the second signature, the verification of the second signature indicating that the host computing device is authentic.

Additionally, the techniques described in this disclosure may be performed as a method and/or by a system having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the techniques described above.

<FIG> schematically illustrates a system-architecture diagram of network <NUM> for host and network verification, according to an example of the principles described herein. The network <NUM> may include a number of router(s) <NUM> communicatively coupled to a number of server(s) <NUM>. The router <NUM> may include any type of computing device capable of transmitting data between computing devices within the network <NUM> and/or capable of transmitting data between networks. The router <NUM> may include a leaf router within a cloud network, an edge router, and an access point router, among other types of routers within a myriad of different types of networks.

A number of network registrar(s) <NUM> may be included within the network <NUM>. The network registrar <NUM> maintains a list of addresses in order to establish connectivity for the host computing device <NUM> to the network <NUM>. The network registrar <NUM> may include any computing device that can process a registration in either NS(EARO) or EDAR messages and consequently respond with an NA or EDAC message containing the EARO and appropriate status for the registration. Thus, the network registrar <NUM> supports EDAR and EDAC messages. The router <NUM>, network registrar <NUM>, server(s) <NUM> may be capable of utilizing and operating under the IPv6 communications protocol to provide identification and location data for computing devices within the network and to router traffic within the network.

The network <NUM> may include a cloud network <NUM> as depicted in <FIG>. Further, the network <NUM> may include a low-power and lossy network (LLN), an Internet of Things (IoT) network, a routing protocol for low-power and lossy (RPL) network, an overlay network, other types and forms of network and aspects thereof.

The host computing device <NUM> may be a workstation, a desktop computer, a laptop, a tablet, a network appliance, an e-reader, a smartphone, a server, a switch, a router, a hub, a bridge, a gateway, a modem, a repeater, an access point, a virtual machine, or other computing devices and virtual (e.g., emulated) machines seeking insertion into the network <NUM> and requesting routing services. In the examples described herein, the host computing device may be a 6LoWPAN-enabled computing device capable of transmitting neighbor solicitation (NS) messages. The NS messages may include an extended address registration option (EARO) that registers the address of the host computing device <NUM> to the router <NUM> using a registration ownership verifier (ROVR) included within the EARO in order to carry different types of information, such as, for example, cryptographic information of variable size (e.g., a crypto-ID). Further, the NS messages may include a crypto-identification parameters option (CIPO) defining the cryptographic identifier (crypto-ID), the crypto-ID being derived from a public key of a PKI key pair. The CIPO contains the parameters that are necessary for the proof. The EARO further includes a nonce option, and a neighbor discovery protocol signature option (NDPSO). Still further, the NS messages may include a nonce option and a neighborhood discovery protocol signature option (NDPSO).

In the examples described herein where a CIPO is employed (e.g., at <NUM> and <NUM>), the CIPO carries the parameters used to form a crypto-ID (e.g., the host crypto-ID generated by the host computing device <NUM>, and the network crypto-ID generated by the network registrar <NUM>). Further, the NDPSO, as described herein at, for example, <NUM> and <NUM> (NDPSO and network NDPSO, respectively) carries the signature that proves the ownership of the respective crypto-ID. The NDPSO does not include a key hash field, but, instead, the leftmost <NUM> bits of the ROVR field in the EARO at <NUM> are used as hash to retrieve the CIPO that contains the key material used for signature verification, and may be left-padded if necessary.

The router <NUM> may include any routing device including an edge router, an intemal router, a border router, a backbone router, or other routing device that may assist in verifying the host computing device <NUM> and verifying for the host computing device <NUM> that the network <NUM> is the intended network the host computing device <NUM> seeks to. In the examples described herein, the router <NUM> may be a 6LoWPAN router (6LR), a 6LoWPAN border router (6LBR), a 6LoWPAN backbone router (6BBR), or other 6LoWPAN-enabled routing devices capable of transmitting neighbor advertisement (NA) messages. The NA messages may include an EARO challenge. The host computing device <NUM>, as a registering node, is challenged for owning a registered address or for being an acceptable proxy for the registration. The router <NUM> challenges the crypto-ID sent by the host computing device <NUM> in an NS message. The host computing device <NUM> places a cryptographic token, the host crypto-ID, in the ROVR that is associated with the address at the first registration, enabling the router <NUM> to later challenge the host crypto-ID to verify that the host computing device <NUM> is the original registering node. The ROVR field within the EARO provides proof of ownership of an IP address via the inclusion of the host crypto-ID. The host crypto-ID is derived from a public key of a key pair generated by the host computing device <NUM> at the time the host computing device <NUM> boots up or otherwise before access to the network is requested. The host computing device <NUM> retains the private key of the key pair. The host computing device <NUM> also generates an IP address independent from the crypto-ID. The IP address generated by the host computing device <NUM> is an IP address that does not exist within the network <NUM>.

The router <NUM> challenges the host computing device <NUM> when the ROVR is received in the EARO from the host computing device <NUM> and when a new registration attempts to change a parameter that identifies the host computing device <NUM>, for example the IP address, and/or the MAC address of the host computing device. This verification protects against a rogue routing device that would steal an address and attract the traffic of the host computing device <NUM> or use the address as a source address. Further, the router <NUM> also challenges the host computing device <NUM> if the network registrar <NUM> directly signals to do so, using an extended duplicate address confirmation (EDAC) message with a "validation requested" status. An extended duplicate address request (EDAR) message may be echoed by the router <NUM> in the NA (EARO) back to the host computing device <NUM> (e.g., the registering node).

The network registrar <NUM> may include any computing device including a router, a border router, a controller, a processing device, or other device capable of receiving the EDAR message from the router <NUM>, send the EDAC message to the router <NUM>, and participate in the validation of the intended network to which the host computing device <NUM> is to be joined. In one example, the network register <NUM> may include a 6LoWPAN border router (6LBR) or a locator identification separation protocol (LISP) map server/map resolver (MS/MR).

Once joined as part of the network <NUM>, the host computing device <NUM> may communicate with a server <NUM> or other computing device to utilize services provided by the server <NUM>. The server <NUM> may provide a myriad of different types of computing resources including, for example, data storage services, mail services, printing services, web services, gaming services, and application services.

The manner in which the host computing device <NUM> joins the network <NUM> will now be described in connection with <FIG> schematically illustrates example call flows <NUM> for verification of a host computing device <NUM> to a network <NUM> and the network <NUM> to the host computing device <NUM>, according to an example of the principles described herein. As a summary of the call flows <NUM> depicted in <FIG>, the host computing device <NUM> and the network registrar <NUM> generate their own respective crypto-identification parameters option (CIPO) messages (e.g., a host CIPO and network CIPO, respectively) which contain their respective public keys, and a crypto-ID that is a hash of that CIPO. By some means, a network crypto-ID is provisioned in the host computing device <NUM>. The call flow <NUM> includes the host computing device <NUM> advertising its address as target in a first neighbor solicitation (NS) message at <NUM>. The first NS message indicates a registration ownership verifier (ROVR) that contains a host crypto-ID, which is a provable identity. The router <NUM>, at <NUM>, sends back a challenge in a first neighbor advertisement (NA) message in response to the first NS message. The challenge is indicated by a status and a nonce (e.g., NonceR) generated by the router <NUM>. In response to the challenge presented in the NA message from the router <NUM>, the host computing device <NUM>, at <NUM>, provides proof in response to the challenge via a second NS message containing its nonce (e.g., NonceH), a CIPO, and a neighbor discovery protocol signature option (NDPSO) that match the host crypto-ID. At that point (e.g., at <NUM>), the router <NUM> validates the host computing device <NUM>, but the host computing device <NUM> has not yet validated the network <NUM>.

In order to begin the process of validating the network <NUM> as to the host computing device <NUM>, the router <NUM> sends an extended duplicate address request (EDAR) message to the network registrar <NUM> similar to an AP-ND process, with the host nonce (e.g., NonceH) being passed to the network registrar <NUM> at <NUM>. The network registrar <NUM> generates a nonce (e.g., NonceL), and generates an extended duplicate address confirmation (EDAC) message at <NUM> in response to the EDAR message from the router <NUM>. The network registrar <NUM> generates a signature within the EDAC that contains the host nonce (e.g., NonceH) and the network registrar nonce (e.g., NonceL). The network registrar <NUM> also generates a network CIPO (e.g. Net-CIPO). The network registrar <NUM> signs the network CIPO via a network NDPSO (e.g., Net-NDPSO). The network registrar <NUM> sends the EDAC message to the router <NUM> at <NUM> as similarly performed in an AP-ND process, but with the network registrar nonce (e.g., NonceL), the network CIPO (e.g., Net-CIPO), and the network NDPSO (e.g., Net-NDPSO) as added by the network registrar <NUM>. The router <NUM> replies to the second NS message sent by the host computing device <NUM> at <NUM> with a second NA message as similarly performed in AP-ND processing, but with the network registrar nonce (e.g., NonceL), the network CIPO (e.g., Net-CIPO), and the network NDPSO (e.g., Net-NDPSO) as added by the router <NUM> based on the EDAC message received from the network registrar <NUM> at <NUM>. The host computing device validates the network <NUM> based on the validation of the network crypto-ID (e.g., Net-Crypto-ID). Having summarized the call flow <NUM> of <FIG>, details for each of the individual call flows will now be described.

As depicted in <FIG>, the host computing device <NUM> may send a first NS message to the router <NUM>, and the router <NUM> receives the first NS message from the host computing device <NUM> at <NUM>. The first NS message includes an address of the host computing device <NUM> and a public key of a first PKI key pair of the host computing device <NUM>. More specifically, the first NS message includes an extended address registration option (EARO) message. The EARO message includes a registration ownership verifier (ROVR) including a crypto-ID of the host computing device <NUM>.

The host crypto-ID identifies the host and is a hash of the host CIPO included in the EARO message. The address of the host computing device <NUM> may include at least one of an internet protocol (IP) address and/or a media access control address (MAC) address of the host computing device <NUM>. As described herein, a host computing device <NUM> supporting the AP-ND extension computes a cryptographic identifier (crypto-ID) and uses it with one or more of their registered addresses (e.g., the IP address, and/or the MAC address). The crypto-ID identifies may be used to provide proof of ownership of the registered address. Once an address is registered with the crypto-ID and a proof-of-ownership is provided or established, only the owner of that address can modify the registration information, thereby enforcing source address validation. The host computing device <NUM> (acting as a 6LN) generates the host crypto-ID and places it in the ROVR field of the EARO of the NS message at <NUM> during the registration of one or more of its addresses with the router <NUM> (acting as a 6LR). Proof of ownership of the crypto-ID is passed with the first registration exchange such as a first NS message to the new router <NUM> and enforced at the router <NUM>. The router validates ownership of the crypto-ID before it creates any new registration state or changes existing information.

The crypto-ID is derived from a public key and a modifier as follows. The hash function used internally by the signature scheme indicated by a crypto-type is applied to a CIPO. In one example, all the reserved and padding bits are set to zero. The leftmost bits of the resulting hash, up to the desired size, are used as the crypto-ID. In one example, a minimal size for the crypto-ID of <NUM> bits is used unless backward compatibility is needed.

A first neighbor advertisement (NA) message is generated by and sent from the router <NUM> to the host computing device <NUM> in response to the first NS message at <NUM>. The challenge is indicated by the EARO including a status and a nonce (e.g., NonceR) generated by the router <NUM>. The status included in the EARO may be, for example, "validation requested. " The NA message thus includes an EARO challenge to the address of the host computing device <NUM>, and a first nonce (e.g., NonceR) generated by the router <NUM>. Further, the challenge to the address of the host computing device <NUM> includes a nonce option. The nonce option contains a nonce value (e.g., "NonceR") that, to the extent possible for the implementation, was never employed in association with the key pair used to generate the crypto-ID. A cryptographic nonce is an arbitrary number that can be used just once in a cryptographic communication. A nonce may be a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. Thus, the host computing device <NUM>, the router <NUM>, and/or the network registrar <NUM> may generate their respective nonces for authentication or validation purposes described herein.

The host computing device <NUM> receives the NA message including the EARO challenge, and in response to the NA message, the host computing device <NUM> generates and sends to the router <NUM> a second NS message at <NUM>. The second NS message includes a second nonce (e.g., "NonceH") generated by the host computing device <NUM>. The host computing device <NUM> provides proof in response to the challenge via a second NS message containing its nonce (e.g., NonceH), a CIPO, and a neighbor discovery protocol signature option (NDPSO) that match the host crypto-ID. The second nonce (e.g., NonceH) is included in the second NS message at <NUM>, and the nonce pair including the first nonce (e.g., NonceR) and the second nonce (e.g., NonceH) is signed by the host computing device <NUM> via a signature. The signature generated by the host computing device <NUM> provides proof-of-ownership of the private-key of the host computing device <NUM> and is carried in a host neighbor discovery protocol signature option (NDPSO). In the examples described herein including at <NUM> and <NUM>, though only one nonce (e.g., NonceH or NonceL, respectively) is transmitted in the messages since each party knows its own nonce, both nonces are used in the signed content. Thus, at <NUM>, both the nonce (e.g., NonceR) from the router <NUM> and the nonce (e.g., NonceH) from the host computing device <NUM> are used to sign the NS message via, for example, the CIPO and the NDPSO that match the host crypto-ID.

In one example, the host NDPSO is generated by the host computing device <NUM> by concatenating byte-strings in the following order: (<NUM>) a <NUM>-bit message type tag (in network byte order); (<NUM>) the CIPO; (<NUM>) a <NUM>-byte target address (in network byte order) sent in the first NS message (e.g., the address which the host computing device <NUM> is registering with the router <NUM> and the network registrar <NUM>); (<NUM>) the NonceR received from the router <NUM> (in network byte order) in the NA message (the nonce may be at least <NUM> bytes long); (<NUM>) the NonceH sent from the host computing device <NUM> in network byte order (the nonce may be at least <NUM> bytes long); and (<NUM>) <NUM>-byte option length of the EARO containing the host crypto-ID. The signature algorithm specified by the crypto-type is applied using the private key.

The router <NUM>, upon receiving the NDPSO and CIPO options may validate the host computing device <NUM>. In one example, the router <NUM> checks that the EARO length in the CIPO matches the length of the EARO. If so, it regenerates the host crypto-ID based on the CIPO to make sure that the leftmost bits up to the size of the ROVR match. The router <NUM> attempts to verify the signature in the NDPSO option based at least in part on the check being successful. In one example, the check may be processed by forming the message to be verified, by concatenating the following byte-strings in the order listed: (<NUM>) the <NUM>-bit message type tag (in network byte order); (<NUM>) the CIPO; (<NUM>) the <NUM>-byte target address (in network byte order) received in the first NS) message (the target address is the address which the host computing device <NUM> is registering with the router <NUM> and the network registrar <NUM>); (<NUM>) the NonceR sent in the NA message from the router <NUM> (the NonceR may be at least <NUM> bytes long); (<NUM>) NonceH received from the host computing device <NUM> (in network byte order) in the second NS message (the nonce is at least <NUM> bytes long); and (<NUM>) <NUM>-byte EARO length received in the CIPO. The router <NUM> verifies the signature on the second NS message with the public key in the CIPO and the locally computed values using the signature algorithm specified by the crypto-type.

The router <NUM> propagates the information to the network registrar <NUM> based at least in part on the verification succeeding, using an EDAR/EDAC flow as describe below in connection with call flows <NUM>, <NUM>, and <NUM>. In one example, due to the first-come/first-serve nature of the registration, if the address is not registered to the network registrar <NUM>, then flow succeeds and both the router <NUM> and network registrar <NUM> add the state information about the host crypto-ID and target address of the host computing device <NUM> being registered to their respective databases. In this manner, the host computing device <NUM> is verified by the router <NUM> based at least in part on the second NS message. The verification of the second signature indicates that the host is authentic.

The first NS message at <NUM> includes an extended address registration option (EARO). The EARO includes the registration ownership verifier (ROVR). The ROVR may be derived from the MAC address of the host computing device <NUM> (e.g., using the <NUM>-bit Extended Unique Identifier EUI-<NUM> address format specified by IEEE). However, the EUI-<NUM> can be spoofed, and therefore, any node connected to the subnet and aware of a registered-address-to-ROVR mapping could effectively fake the ROVR. This would allow an attacker to steal the address and redirect traffic for that address. In the systems and methods described herein, the host computing device <NUM> generates the host crypto-ID and places the host crypto-ID in the ROVR field during the registration of one (or more) of its addresses with the router <NUM>. Proof of ownership of the host crypto-ID is passed with the first registration exchange at, for example, <NUM>, to the router <NUM>, and enforced at the router <NUM>. The router <NUM> validates ownership of the host crypto-ID before it creates any new registration state or changes existing information.

The ROVR includes the host crypto-ID. Further, the router <NUM> stores the host crypto-ID, one or more addresses of the host computing device <NUM>, and any public and/or private key of a first PKI key pair of the host computing device <NUM> as router registration data (<FIG>, <NUM>) of a data store (<FIG>, <NUM>) in order to allow for the host computing device <NUM> to be recognized in any subsequent registration to the network <NUM>.

The second NS message at <NUM> from the host computing device <NUM> includes a CIPO including the network crypto-ID, the nonce (e.g., NonceH), and the NDPSO. The NDPSO verifies the host computing device <NUM> has ownership of the network crypto-ID to the router <NUM>. Having described the manner in which the router <NUM> verifies the host computing device <NUM>, the manner in which the host computing device <NUM> validates the network <NUM> (e.g., how the host computing device <NUM> verifies that the network <NUM> is the network the host computing device <NUM> intends to join) will now be described in connection with call flows <NUM> through <NUM>.

Thus, as depicted in <FIG>, the router <NUM> sends, to the network registrar <NUM>, an extended duplicate address request (EDAR) message at <NUM>. Specifically, the router <NUM> sends the EDAR message to the network registrar <NUM> similar to an AP-ND process, but with the host nonce (e.g., NonceH) being passed to the network registrar <NUM>. The router <NUM> and the network registrar <NUM> may communicate using ICMPv6 Extended Duplicate Address Request (EDAR) and Extended Duplicate Address Confirmation (EDAC) messages. In the examples described herein, the EDAR and EDAC messages are extended to carry a cryptographically generated ROVR. The assumption is that the router <NUM> and the network registrar <NUM> maintain a security association to authenticate and protect the integrity of the EDAR and EDAC messages, so there is no need to propagate the proof of ownership to the network registrar <NUM>. The network registrar <NUM> implicitly trusts that the router <NUM> performs the verification when the network registrar <NUM> requires it, and if there is no further exchange from the router <NUM> to remove the state, that the verification succeeded.

The EDAR message includes the nonce (e.g., NonceH) generated and provided by the host computing device <NUM>. The network registrar <NUM>, within the network <NUM>, is the central repository of all the registered addresses in its domain. Further, the network registrar <NUM> maintains a registration state for all devices in its attached network <NUM>. Together with the router <NUM>, the network registrar <NUM> assures uniqueness and grants ownership of an IPv6 address before it can be used in the network <NUM>. In one example, the network links between the router <NUM> and the network registrar <NUM> are protected so that a packet that was validated by the router <NUM> may be safely routed by other on-path routers to the network registrar <NUM>.

Thus, in order to begin the process of validating the network <NUM> as to the host computing device <NUM>, the router <NUM> sends the EDAR message to the network registrar <NUM> at <NUM> similar to an AP-ND process, with the host nonce (e.g., NonceH) being passed to the network registrar <NUM>. The network registrar <NUM> receives the EDAR at <NUM> and stores data relating to the host crypto-ID of the host computing device <NUM>, one or more addresses of the host computing device <NUM>, and any public and/or private key of a first PKI key pair of the host computing device <NUM> as network registration data (<FIG>, <NUM>) of a data store <NUM> in order to allow for the host computing device <NUM> to be recognized in any subsequent registration to the network <NUM>.

At <NUM>, the router <NUM> receives, from the network registrar <NUM>, an extended duplicate address confirmation (EDAC) message including a third nonce (e.g., "NonceL"). The EDAC message is signed by the network registrar <NUM> via a private key of a second public key infrastructure (PKI) key pair of the network registrar <NUM> via a second signature. The second signature may be generated by the network registrar <NUM> to provide proof-of-ownership of the private-key and may be carried in the network NDPSO (e.g., Net-NDPSO). The network NDPSO is generated by the network registrar <NUM>. The network registrar <NUM> generates the nonce (e.g., NonceL), and generates the EDAC message at <NUM> in response to the EDAR message from the router <NUM>. The network registrar <NUM> generates a signature within the EDAC that contains the host nonce (e.g., NonceH) and the network registrar nonce (e.g., NonceL). Like at <NUM> in connection with the nonce pair including the first nonce (e.g., NonceR) and the second nonce (e.g., NonceH), the nonce pair including the second nonce (e.g., NonceH) and the third nonce (e.g., NonceL) is signed by the network registrar via a signature. The network registrar <NUM> also generates a network CIPO (e.g. Net-CIPO). The network registrar <NUM> signs the network CIPO via a network NDPSO (e.g., Net-NDPSO). In one example, the value used in the signature may have a size that is equal to the size of a network token, placed in the network CIPO by the network registrar <NUM> before signature and based on its prior knowledge of it, as opposed to an option length of an EARO such as the EARO sent at <NUM> by the router <NUM>. The network registrar <NUM> sends the EDAC message to the router <NUM> at <NUM> as similarly performed in an AP-ND process, but with the network registrar nonce (e.g., NonceL), the network CIPO (e.g., Net-CIPO), and the network NDPSO (e.g., Net-NDPSO) as added by the network registrar <NUM>.

In the above examples, the network crypto ID is not passed on in the EARO and/or the EDAR due to the assumption that there is only one network crypto-ID and both the host computing device <NUM> and the network registrar <NUM> know and have stored the network crypto-ID in memory. Thus, although the network crypto-ID is not included in the above examples such as in the EARO at <NUM> or the EDAR at <NUM>, in one example, the value of including a network crypto-ID in the EARO at <NUM> or the EDAR at <NUM> may allow the network <NUM> to have multiple crypto IDs. Thus, the network crypto-ID, in this example, may be added to the NS message at <NUM> and the EDAR message at <NUM> as a message option. In this example, a same public address may be used to generate different tokens by changing a modifier in the CIPO or by changing the length that impacts the NDPSO generation and verification as described above. With this, a plurality of network crypto tokens may be generated. Those network crypto tokens may be associated in groups, to which access rights may be assigned. Provisioning different crypto-IDs to different host computing devices may allow the grouping of the crypto-IDs. In this example, the network registrar <NUM> may match a respective network crypto-ID with one of possibly multiple CIPOs generated by the network registrar <NUM>. The matched CIPO may contain the length of the crypto token (in a length field of the EARO) and the modifier so that any changes in those values means a different CIPO including a different token since the CIPO carries the parameters used to form a crypto-ID. Further, the length of the network crypto-ID passed by the host computing device <NUM> may be the value used in the NDPSO generation and verification. Thus, multiple net crypto-IDs may be enabled for the same network where different modifiers and/or different keys with different security levels may be employed such as in connection with IoT devices. The host computing device <NUM> is provisioned with one of the crypto-IDs, and that crypto-ID is passed through the NS message at <NUM> and the EDAR at <NUM> to the network registrar <NUM>. The network registrar <NUM> chooses the CIPO that matches. Thus, this example utilizes the modifier field in the CIPO above as a group ID or an indicator of the group of the user.

Turning again to the example of <FIG>, the network CIPO defines the network crypto-ID. The network crypto-ID is derived from a public key (e.g., a network public key) of the PKI key pair provided by the network registrar <NUM>. In one example, one network registrar <NUM> may be responsible for the network <NUM> and the router(s) <NUM> have a secured channel to talk to the network registrar <NUM>.

The router <NUM> sends an extended duplicate address request (EDAR) message to the network registrar <NUM> similar to an AP-ND process, with the host nonce (e.g., NonceH) being passed to the network registrar <NUM> at <NUM>. The network registrar <NUM> generates a nonce (e.g., NonceL), and generates an extended duplicate address confirmation (EDAC) message at <NUM> in response to the EDAR message from the router <NUM>. As noted above, the network registrar <NUM> generates a signature within the EDAC that signs the host nonce (e.g., NonceH) and the network registrar nonce (e.g., NonceL) as a nonce pair. Further, the network registrar <NUM> generates a network CIPO (e.g. Net-CIPO). The network registrar <NUM> signs these items via a network NDPSO (e.g., Net-NDPSO). The NDPSO signs the pair of nonces (e.g., NonceH and NonceL).

The network registrar <NUM> sends the EDAC message to the router <NUM> at <NUM> as similarly performed in an AP-ND process, but with the network registrar nonce (e.g., NonceL), the network CIPO (e.g., Net-CIPO), and the network NDPSO (e.g., Net-NDPSO) as added by the network registrar <NUM>. The exchange of the EDAR message at <NUM> and the EDAC message at <NUM> between the router <NUM> and the network registrar <NUM> ensures that an address is unique across the domain covered by the network registrar <NUM>. As to the EDAC message at <NUM>, the second nonce (e.g., NonceH), the third nonce (e.g., NonceL), and the private key of the network registrar <NUM> verifies the first signature from the network registrar <NUM>, the verification of the first signature indicating that the router <NUM> is not impersonating the network <NUM> and is not a rogue router. The pair of nonces (e.g., the second nonce (e.g., NonceH) and the third nonce NonceL) is different from the nonces in the AP-ND flow (call flows <NUM>, <NUM>, and <NUM>) since the nonce in the challenge by the router <NUM> at <NUM> is coming from the router <NUM> and is independent from the network registrar <NUM>.

The EDAC message at <NUM> includes the network crypto-identification parameters option (CIPO) defining the network crypto-ID. The network crypto-ID is derived from the public key of the PKI key pair. Further, as mentioned above, the host computing device <NUM> is pre-provisioned with the network crypto-ID as an identification of the network that the host is to join.

As described above, the network crypto-ID may be included in the EARO at <NUM> and/or the EDAR at <NUM>, and the network <NUM> may use multiple network crypto-IDs for the same network where different modifiers and/or different keys with different security levels are employed. The network crypto tokens in this example may be associated in groups, to which access rights and other security privileges may be assigned or granted. In one example, this may be used to signal the service that the network <NUM> will provide to the host computing device <NUM>. In this example, the router <NUM> may check the signature within the EDAC message at <NUM> received from the network registrar <NUM> as a confirmation that a service and/or security privileges may be granted to the host computing device <NUM>. Further, the modifier that signals the service level that this host computing device <NUM> may receive may be found in the CIPO of the EDAC message. The router <NUM> may enforce that service, or tag the packet sent at <NUM> to the host computing device <NUM> with an identifier that signals to the rest of the network <NUM> what service level the host computing device <NUM> is granted. In one example, this may be performed via the Identity Services Engine (ISE) developed by Cisco Systems, Inc. ISE enables a dynamic and automated approach to policy enforcement that simplifies the delivery of highly secure network access control and empowers software-defined access and automates network segmentation. The router <NUM> may also enforce the services and/or security privileges granted to the host computing device <NUM> based on the service and/or security privileges identified by the network crypto-ID and its assigned security level.

At <NUM>, a second NA message is sent to the host computing device <NUM>. Sending the second NA message to the host computing device <NUM> includes sending to the host computing device <NUM> the public key to validate that the public key corresponds to the network crypto-ID, and that the second signature corresponds with the private key that forms the PKI key pair with the public key. The first signature at <NUM> and the second signature at <NUM> sign their respective CIPOs (e.g., CIPO at <NUM> and Net-CIPO at <NUM>) via a neighbor discovery protocol signature option (NDPSO) (e.g., the NDPSO at <NUM> and Net-NDPSO at <NUM>). In this manner, the router <NUM> replies to the second NS message sent by the host computing device <NUM> at <NUM> with a second NA message as similarly performed in AP-ND processing, but with the network registrar nonce (e.g., NonceL), the network CIPO (e.g., Net-CIPO), and the network NDPSO (e.g., Net-NDPSO) as added by the router <NUM> based on the EDAC message received from the network registrar <NUM> at <NUM>. The host computing device validates the network <NUM> based on the validation of the network crypto-ID (e.g., Net-Crypto-ID).

Following the validation of the host computing device <NUM> as to the router <NUM> and network registrar <NUM> and validating the network <NUM> as to the host computing device <NUM>, the host computing device <NUM> may then freely communicate with other computing devices within the network <NUM> including, for example a number of servers <NUM>. The server(s) <NUM> may provide a myriad of different types of computing resources to or for the host computing device <NUM> including, for example, data storage services, mail services, printing services, web services, gaming services, and application services. In one example, at <NUM>, a number of routes may be injected to the host computing device <NUM> such as, for example, with a routing protocol for low power and lossy networks (RPL) destination advertisement object (DAO) message.

The systems and methods described herein ensure that the host computing device <NUM> joins an expected network. Further, the systems and methods described herein enables a host computing device <NUM> to ensure that it has joined an appropriate network <NUM> using the same flow that the network <NUM> ensures to trust the host computing device <NUM>. This technique protects the host computing device <NUM> from joining an incorrect network <NUM> due to a rogue router.

Further, the systems and methods described herein extend the method that the host computing device <NUM>, the router <NUM>, and the network registrar <NUM> use to prove that the host computing device <NUM> is the owner of an address and to prove to the host computing device that it has joined the right network. Thus, the systems and methods described herein may be easily added to an IPv6 stack and provides an additional zero-trust guarantee. The call flow may be reversed while reusing the host computing device <NUM> nonce in a fashion that proves the network <NUM> to be the expected or intended network with minimal addition to the processing and network infrastructure. In other words, the present systems and methods allow the router <NUM> to validate the host computing device <NUM> as well as allow the host computing device <NUM> to validate the network <NUM> to which the host computing device <NUM> seeks to join. Having described the topology of the network <NUM> and the call flows within the network <NUM>, the host computing device <NUM>, the router <NUM>, and the network registrar <NUM> and their respective elements will now be described.

<FIG> is a component diagram <NUM> of example components of a host computing device <NUM> within the network of <FIG>, according to an example of the principles described herein. As illustrated, the host computing device <NUM> may include one or more hardware processor(s) <NUM> configured to execute one or more stored instructions. The processor(s) <NUM> may comprise one or more cores. Further, the host computing device <NUM> may include one or more network interfaces <NUM> configured to provide communications between the host computing device <NUM> and other devices, such as the router <NUM>, the network registrar <NUM>, and/or the server(s) <NUM>. The network interface(s) <NUM> may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth. For example, the network interfaces <NUM> may include devices compatible with the wired and/or wireless communication technologies and protocols described herein.

The host computing device <NUM> may also include computer-readable media <NUM> that stores various executable components (e.g., software-based components, firmware-based components, etc.). In addition to various components discussed herein, the computer-readable media <NUM> may further store components to implement functionality described herein. While not illustrated, the computer-readable media <NUM> may store one or more operating systems utilized to control the operation of the one or more devices that comprise the host computing device <NUM>. According to one example, the operating system comprises the LINUX operating system. According to another example, the operating system(s) comprise the WINDOWS SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further examples, the operating system(s) may comprise the UNIX operating system or one of its variants. It may be appreciated that other operating systems may also be utilized.

Additionally, the host computing device <NUM> may include a data store <NUM> which may comprise one, or multiple, repositories or other storage locations for persistently storing and managing collections of data such as databases, simple files, binary, and/or any other data. The data store <NUM> may include one or more storage locations that may be managed by one or more database management systems. The data store <NUM> may store, for example, data packets <NUM> for transmission to the router <NUM>, the network registrar <NUM>, and/or the server(s) <NUM>, among other networked computing devices. The data packets <NUM> may include data sent via the host computing device <NUM> in a data session and within a data flow as described herein.

Further, the data store <NUM> may store a number of address(es) <NUM>. The address(es) <NUM> may include any data defining an address of the host computing device <NUM> that may be used to validate the host computing device <NUM> to the router <NUM> and the network <NUM> as described herein.

The data store <NUM> may also store crypto-ID data <NUM> used in the validation of the host computing device <NUM> as to the router <NUM> and network registrar <NUM>, and the validation of the network <NUM> as to the host computing device <NUM>. The crypto-ID data <NUM> may include crypto-IDs generated by the host computing device <NUM> or the network registrar <NUM> based on a hash of their respective CIPOs as described herein. The crypto-ID data <NUM> may include a host crypto-ID generated by, for example, the registration services <NUM> of the computer readable media <NUM>. In one example, the crypto-ID data <NUM> may include a network crypto-ID provisioned or pre-provisioned by the network registrar <NUM> that identities the network <NUM> that the host computing device <NUM> is intending to join and may be provided to the host computing device <NUM> by the network registrar <NUM> or other computing device that can confirm the authenticity of the network <NUM>.

The computer-readable media <NUM> may store portions, or components, of registration services <NUM> described herein. For example, the registration services <NUM> of the computer-readable media <NUM> may include a neighbor solicitation (NS) component <NUM> to, when executed by the processor(s) <NUM>, send a number of NS messages to the router <NUM>. The NS component <NUM> may include within the NS messages an EARO, a ROVR, a CIPO, a nonce (e.g., NonceH), a NDPSO, and PKI key pairs, among other types of data.

In conjunction with the NS component <NUM>, the registration services <NUM> may further include a cryptography component <NUM>. The cryptography component <NUM> derives and provides the host crypto-ID for the host computing device <NUM>. Further, the cryptography component <NUM> may receive and process data related to the crypto-ID of the host computing device and/or the network crypto-ID of the network registrar <NUM> in order to validate the host computing device <NUM> as to the router <NUM> and network registrar <NUM>, and validate the network <NUM> as to the host computing device <NUM>.

<FIG> is a component diagram <NUM> of example components of a router <NUM> within the network <NUM> of <FIG>, according to an example of the principles described herein. As illustrated, the router <NUM> may include one or more hardware processor(s) <NUM> configured to execute one or more stored instructions. The processor(s) <NUM> may comprise one or more cores. Further, the router <NUM> may include one or more network interfaces <NUM> configured to provide communications between the router <NUM> and other devices, such as the host computing device <NUM>, the network registrar <NUM>, and/or the server(s) <NUM>. The network interface(s) <NUM> may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth. For example, the network interfaces <NUM> may include devices compatible with the wired and/or wireless communication technologies and protocols described herein.

The router <NUM> may also include computer-readable media <NUM> that stores various executable components (e.g., software-based components, firmware-based components, etc.). In addition to various components discussed herein, the computer-readable media <NUM> may further store components to implement functionality described herein. While not illustrated, the computer-readable media <NUM> may store one or more operating systems utilized to control the operation of the one or more devices that comprise the router <NUM>. According to one example, the operating system comprises the LINUX operating system. According to another example, the operating system(s) comprise the WINDOWS SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further examples, the operating system(s) may comprise the UNIX operating system or one of its variants. It may be appreciated that other operating systems may also be utilized.

Additionally, the router <NUM> may include a data store <NUM> which may comprise one, or multiple, repositories or other storage locations for persistently storing and managing collections of data such as databases, simple files, binary, and/or any other data. The data store <NUM> may include one or more storage locations that may be managed by one or more database management systems. The data store <NUM> may store, for example, data packets <NUM> for transmission to the host computing device <NUM>, the network registrar <NUM>, and/or the server(s) <NUM>, among other networked computing devices. The data packets <NUM> may include data sent in a data session and within a data flow as described herein.

Further, the data store <NUM> may store a number of address(es) <NUM>. The address(es) <NUM> may include any data defining an address of the host computing device <NUM> that may be used to validate the host computing device <NUM> to the router <NUM> and the network <NUM> as described herein. The router <NUM> may store the address(es) for validating and re-validating the host computing device <NUM>. The address(es) <NUM> may also include a neighbor cache that stores a MAC address of the host computing device <NUM> and maps associated IP address to the MAC address. In this manner, the router <NUM> may use the neighbor cache stored in the address(es) of the data store <NUM> in order to initiate communication with the host computing device <NUM> as well as confirm that the host computing device <NUM> is the host computing device it states that it is in any subsequent communications and/or during any subsequent attempts by the host computing device <NUM> to join the network <NUM>.

The data store <NUM> may also store router registration data <NUM> that includes registration data related to the registration of the host computing device <NUM> and other computing devices seeking to join the network <NUM>. The router registration data <NUM> may also include any data associated with the nonces passed to and from the host computing device <NUM>, the EARO, the EDAR, the EDAC, and/or PKI key pairs, as described herein.

The computer-readable media <NUM> may store portions, or components, of registration services <NUM> described herein. For example, the registration services <NUM> of the computer-readable media <NUM> may include a neighbor advertisement (NA) component <NUM> to, when executed by the processor(s) <NUM>, send a number of NA messages to the host computing device <NUM>. The NA component <NUM> may include within the NA messages an EARO challenge, a nonce (e.g., NonceR and/or NonceL), a CIPO, a network CIPO, and NDPSO, and a network NDPSO, among other types of data as described herein.

In conjunction with the NA component <NUM>, the registration services <NUM> may further include a cryptography component <NUM>. The cryptography component <NUM> may receive and process data related to the host crypto-ID of the host computing device <NUM> and a network crypto-ID of the network registrar <NUM> in order to validate the host computing device <NUM> as to the router <NUM> and network registrar <NUM>, and validate the network <NUM> as to the host computing device. As described herein, the network crypto-ID belongs to the network registrar <NUM> and is derived from the public key of the network registrar <NUM> (e.g., the network public key). The network crypto-ID is provisioned or pre-provisioned in the host computing device <NUM> so that the host computing device <NUM> can check that the network public key is the expected one, and then, based on the NDPSO sent from the network registrar <NUM> at <NUM>, that the network registrar <NUM> has the network private key that goes with the network public key.

Further, the registration services <NUM> may include an EDAR/EDAC component <NUM>. The EDAR/EDAC component <NUM>, when executed by the processor(s) <NUM>, passes EDAR and EDAC messages as described herein.

<FIG> is a component diagram <NUM> of example components of a network registrar <NUM> within the network <NUM> of <FIG>, according to an example of the principles described herein. As illustrated, the network registrar <NUM> may include one or more hardware processor(s) <NUM>, one or more devices, configured to execute one or more stored instructions. The processor(s) <NUM> may comprise one or more cores. Further, the network registrar <NUM> may include one or more network interfaces <NUM> configured to provide communications between the network registrar <NUM> and other devices, such as the host computing device <NUM>, the network registrar <NUM>, and/or the server(s) <NUM>. The network interface(s) <NUM> may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth. For example, the network interfaces <NUM> may include devices compatible with the wired and/or wireless communication technologies and protocols described herein.

The network registrar <NUM> may also include computer-readable media <NUM> that stores various executable components (e.g., software-based components, firmware-based components, etc.). In addition to various components discussed herein, the computer-readable media <NUM> may further store components to implement functionality described herein. While not illustrated, the computer-readable media <NUM> may store one or more operating systems utilized to control the operation of the one or more devices that comprise the network registrar <NUM>. According to one example, the operating system comprises the LINUX operating system. According to another example, the operating system(s) comprise the WINDOWS SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further examples, the operating system(s) may comprise the UNIX operating system or one of its variants. It may be appreciated that other operating systems may also be utilized.

Additionally, the network registrar <NUM> may include a data store <NUM> which may comprise one, or multiple, repositories or other storage locations for persistently storing and managing collections of data such as databases, simple files, binary, and/or any other data. The data store <NUM> may include one or more storage locations that may be managed by one or more database management systems. The data store <NUM> may store, for example, data packets <NUM> for transmission to the host computing device <NUM>, the router <NUM>, and/or the server(s) <NUM>, among other networked computing devices. The data packets <NUM> may include data sent in a data session and within a data flow as described herein.

Further, the data store <NUM> may store network data <NUM>. The network data <NUM> may include any data that defines the topology of the network <NUM> and data defining the router(s) <NUM> and the host computing device <NUM>. In one example, the network data <NUM> may include data defining the topology of the network <NUM>, the nonce (e.g., NonceL) of the network registrar <NUM>, the network crypto-ID, registration information defining the validation of the host computing device <NUM> within the network <NUM>, among other data. Further, the data store <NUM> may store network registration data <NUM>. The network registration data <NUM> may include the network crypto-ID of the network <NUM> that is used by the host computing device <NUM> to authenticate the network <NUM>. Further, in one example, the network registration data <NUM> may include a number of address(es) defining the address(es) of the host computing device <NUM>, crypto-IDs of the host computing device <NUM>, a number of nonces (e.g., NonceR, NonceH, Nonce L), a EDAR messages, EDAC messages, and PKI key pairs, among other types of data related to the registration of the host computing device <NUM> within the network <NUM>.

The computer-readable media <NUM> may store portions, or components, of registration services <NUM> described herein. For example, the registration services <NUM> of the computer-readable media <NUM> may include a an EDAR/EDAC component <NUM>. The EDAR/EDAC component <NUM>, when executed by the processor(s) <NUM>, passes EDAR and EDAC messages as described herein.

In conjunction with the EDAR/EDAC component <NUM>, the registration services <NUM> may further include a cryptography component <NUM>. The cryptography component <NUM> may provide the network crypto-ID to the host computing device <NUM> such that the host computing device <NUM> may provision or pre-provision the network crypto-ID to the host computing device <NUM>. In the examples described herein, the network crypto-ID may be provided to the host computing device <NUM> from the network registrar <NUM> in any manner such that the host computing device <NUM> may use the network crypto-ID to validate the network <NUM> as to the host computing device <NUM>. The cryptography component <NUM> may also receive and process data related to the host nonce (e.g., NonceH) received from the host computing device <NUM> in order to validate the network <NUM> as to the host computing device <NUM>.

<FIG> illustrates a flow diagram of an example method <NUM> of validating a network as to a host computing device <NUM>, according to an example of the principles described herein. The method may include, at <NUM>, sending, to a network registrar, an extended duplicate address request (EDAR) message including a nonce (e.g., NonceH) generated by the router <NUM> based on the second NS message sent by the host computing device <NUM> at <NUM> of <FIG>. At <NUM>, the router <NUM> receives, from the network registrar, an extended duplicate address confirmation (EDAC) message including a nonce (e.g., NonceL) generated by the network registrar <NUM>. The nonce pair including the second nonce and the third nonce (e.g., NonceH and NonceL) is signed by the network registrar <NUM> via a private key of a public key infrastructure (PKI) key pair of the network registrar <NUM> via a net-NDPSO. The EDAC message may be sent to the router <NUM>. The router <NUM> obtains the nonce (e.g., NonceL) of the network registrar, the CIPO containing the public key, and the NDPSO containing the signature from the EDAC, and includes these elements in an NA message sent to the host computing device <NUM> at <NUM>. The verification of the first signature indicates that the router <NUM> is not impersonating the network <NUM>. In this manner, the host computing device <NUM> receives signed content that includes the nonce (e.g., NonceL) of the network registrar <NUM> for verification purposes. The host computing device <NUM> verifies the NA message and its contents using the public key when the host computing device <NUM> receives the NA message.

<FIG> illustrates a flow diagram of an example method <NUM> of validating a host computing device <NUM> as to a network <NUM> and validating the network <NUM> as to the host computing device <NUM>, according to an example of the principles described herein. The method of <FIG> may include pre-provisioning the host computing device <NUM> with the network crypto-ID at <NUM>. The network crypto-ID is used to validate to the host computing device <NUM> that it is joining an intended network. The network crypto-ID may include a hash of the public key from the network registrar <NUM> that authenticates the network <NUM>. Further, the network crypto-ID servs to verify that the public key in the CIPO included within the NA message is the expected public key. The associated private key of the PKI key pair from the network registrar <NUM> is used in the signature by the network registrar <NUM>. That private key is not shared.

At <NUM>, the method <NUM> may include receiving, at the router <NUM>, a first neighbor solicitation (NS) message from the host computing device <NUM>. The first NS message includes an address of the host computing device <NUM> and a public key of a PKI key pair of the host computing device <NUM>. In one example, the first NS message may include an EARO including a registration ownership verifier (ROVR). The ROVR may include a host crypto-ID, the host crypto-ID verify that the host computing device <NUM> is the original registering node as described herein.

At <NUM>, a first neighbor advertisement (NA) message may be sent from the router <NUM> to the host computing device <NUM>. The first NA message may include a challenge to the address of the host computing device <NUM> and a nonce (e.g., NonceR) generated by the router <NUM>.

The method at <NUM> may also include receiving, at the router <NUM>, a second NS message from the host computing device <NUM> including the nonce (e.g., NonceH) generated by the host computing device <NUM>. The host nonce (e.g., NonceH) is transmitted to the router <NUM>. However, the pair of nonces (e.g., NonceR and NonceH) is signed. The signature by the host computing device <NUM> of the host nonce (e.g., NonceH) serves to ensure that the aggregate result of the pair of nonces (e.g., NonceR and NonceH) has never been previously used. In this manner, the host computing device <NUM> is in agreement with cryptographic processes where signature of distinct elements within a message may or should only be performed once.

The nonce (e.g., NonceH) generated by the host computing device <NUM> may be carried by a nonce option and signed by the host computing device <NUM> via a signature (e.g., an NDPSO). In the examples described herein, the network crypto-ID transmitted to the router <NUM> from the host computing device (the network crypto-ID being pre-provisioned to the host computing device <NUM>) servs to verify that the public key in the CIPO in the NA message from the router <NUM> is the expected one. The NDPSO incudes the signature of the nonce pair (e.g., NonceH and NonceL). The nonce (e.g., NonceL) generated by the network registrar <NUM> may be carried in a nonce option. The other signature parameters including the public key are included in the CIPO. The public key is used to verify that the NA message was signed with the associated private key. This process proves that the host computing device <NUM> is joining the correct or intended network.

At <NUM>, the method includes verifying the host computing device <NUM> based at least in part on the nonce (e.g., NonceH) and the public key of the host computing device <NUM> in order to verify the signature. The verification of the second signature indicates that the host computing device <NUM> is authentic. As mentioned above, the address of the host computing device <NUM> may include at least one of an intemet protocol (IP) address of the host computing device <NUM>, and a media access control address (MAC) address of the host computing device <NUM>. The first NS message includes an extended address registration option (EARO), the EARO including a registration ownership verifier (ROVR), the ROVR including a host crypto-ID, the host crypto-ID verify that the host computing device <NUM> is the original registering node. The second NS message from the host computing device includes a CIPO including the network crypto-ID, the first nonce, and an NDPSO, the NDPSO carrying the first signature proving ownership of the network crypto-ID.

At <NUM>, the method includes sending, to the network registrar <NUM>, an extended duplicate address request (EDAR) message including a first nonce generated by the host computing device <NUM>. The EDAR includes the host nonce (e.g., NonceH) generated by the host computing device <NUM>. At <NUM>, the method my include receiving, from the network registrar <NUM>, the EDAC message including a third nonce (NonceL). The third nonce is generated by the network registrar <NUM>. The EDAC message is signed by the network registrar <NUM> via a private key of a first public key infrastructure (PKI) key pair of the registrar via a network NDPSO (e.g., net-NDPSO). The network registrar includes its nonce (e.g., NonceL) in the EDAC and signs the pair of nonces (e.g., NonceH and NonceL). Pair of nonces is signed because this signature serves as the challenge from the router <NUM> to the host computing device <NUM>. The signature by the host computing device <NUM> of NonceH at <NUM> serves to ensure that the aggregate result of the pair of nonces (e.g., NonceH and NonceR) has never been used previously. When the network registrar <NUM> signs the pair of nonces (e.g., NonceH and NonceL), the role of NonceH changes as it becomes the challenge from the host to the network.

At <NUM>, the router <NUM> may send the NA message to the host computing device <NUM>. The NA message may include the nonce (e.g., NonceL) generated by the network registrar <NUM>, and the public key of the registrar to verify the signature from the network registrar <NUM>. The verification of the signature indicates to the host computing device <NUM> that the router <NUM> is not impersonating the network <NUM>.

<FIG> illustrates a computing system diagram illustrating a configuration for a data center <NUM> that can be utilized to implement aspects of the technologies disclosed herein. The example data center <NUM> shown in <FIG> includes several server computers 802A-802F (which might be referred to herein singularly as "a server computer <NUM>" or in the plural as "the server computers <NUM>) for providing computing resources. In some examples, the resources and/or server computers <NUM> may include, or correspond to, the any type of networked device described herein. Although described as servers, the server computers <NUM> may comprise any type of networked device, such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc..

The server computers <NUM> can be standard tower, rack-mount, or blade server computers configured appropriately for providing computing resources. In some examples, the server computers <NUM> may provide computing resources <NUM> including data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, virtual private networks (VPNs), and others. Some of the servers <NUM> can also be configured to execute a resource manager <NUM> capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager <NUM> can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer <NUM>. Server computers <NUM> in the data center <NUM> can also be configured to provide network services and other types of services.

In the example data center <NUM> shown in <FIG>, an appropriate LAN <NUM> is also utilized to interconnect the server computers 802A-802F. It may be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between data centers <NUM>, between each of the server computers 802A-802F in each data center <NUM>, and, potentially, between computing resources in each of the server computers <NUM>. It may be appreciated that the configuration of the data center <NUM> described with reference to <FIG> is merely illustrative and that other implementations can be utilized.

In some examples, the server computers <NUM> and or the computing resources <NUM> may each execute/host one or more tenant containers and/or virtual machines to perform techniques described herein.

In some instances, the data center <NUM> may provide computing resources, like tenant containers, VM instances, VPN instances, and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources provided by a cloud computing network may be utilized to implement the various services and techniques described above. The computing resources <NUM> provided by the cloud computing network can include various types of computing resources, such as data processing resources like tenant containers and VM instances, data storage resources, networking resources, data communication resources, network services, VPN instances, and the like.

Each type of computing resource <NUM> provided by the cloud computing network can be general-purpose or can be available in a number of specific configurations. For example, data processing resources can be available as physical computers or VM instances in a number of different configurations. The VM instances can be configured to execute applications, including web servers, application servers, media servers, database servers, some or all of the network services described above, and/or other types of programs. Data storage resources can include file storage devices, block storage devices, and the like. The cloud computing network can also be configured to provide other types of computing resources <NUM> not mentioned specifically herein.

The computing resources <NUM> provided by a cloud computing network may be enabled in one example by one or more data centers <NUM> (which might be referred to herein singularly as "a data center <NUM>" or in the plural as "the data centers <NUM>). The data centers <NUM> are facilities utilized to house and operate computer systems and associated components. The data centers <NUM> may include redundant and backup power, communications, cooling, and security systems. The data centers <NUM> can also be located in geographically disparate locations. One illustrative example for a data center <NUM> that can be utilized to implement the technologies disclosed herein will be described below with regard to <FIG>.

<FIG> illustrates a computer architecture diagram showing an example computer hardware architecture <NUM> for implementing a computing device that can be utilized to implement aspects of the various technologies presented herein. The computer hardware architecture <NUM> shown in <FIG> illustrates a server computer <NUM>, network device (e.g., host computing device <NUM>, router <NUM>, network registrar <NUM>, server(s) <NUM>, data store, etc.), workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The computer <NUM> may, in some examples, correspond to a network device (e.g., the host computing device <NUM>, router <NUM>, network registrar <NUM>, server(s) <NUM> described herein, and may comprise networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc..

The computer <NUM> includes a baseboard <NUM>, or "motherboard," which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (CPUs) <NUM> operate in conjunction with a chipset <NUM>. The CPUs <NUM> can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer <NUM>.

The chipset <NUM> provides an interface between the CPUs <NUM> and the remainder of the components and devices on the baseboard <NUM>. The chipset <NUM> can provide an interface to a RAM <NUM>, used as the main memory in the computer <NUM>. The chipset <NUM> can further provide an interface to a computer-readable storage medium such as a read-only memory (ROM) <NUM> or non-volatile RAM (NVRAM) for storing basic routines that help to startup the computer <NUM> and to transfer information between the various components and devices. The ROM <NUM> or NVRAM can also store other software components necessary for the operation of the computer <NUM> in accordance with the configurations described herein.

The computer <NUM> can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network <NUM>. The chipset <NUM> can include functionality for providing network connectivity through a Network Interface Controller (NIC) <NUM>, such as a gigabit Ethernet adapter. The NIC <NUM> is capable of connecting the computer <NUM> to other computing devices over the network <NUM>. It may be appreciated that multiple NICs <NUM> can be present in the computer <NUM>, connecting the computer to other types of networks and remote computer systems. In some examples, the NIC <NUM> may be configured to perform at least some of the techniques described herein, such as packet redirects and/or other techniques described herein.

The computer <NUM> can be connected to a storage device <NUM> that provides non-volatile storage for the computer. The storage device <NUM> can store an operating system <NUM>, programs <NUM>, and data, which have been described in greater detail herein. The storage device <NUM> can be connected to the computer <NUM> through a storage controller <NUM> connected to the chipset <NUM>. The storage device <NUM> can consist of one or more physical storage units. The storage controller <NUM> can interface with the physical storage units through a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computer <NUM> can store data on the storage device <NUM> by transforming the physical state of the physical storage units to reflect the information being stored. The specific transfonnation of physical state can depend on various factors, in different examples of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device <NUM> is characterized as primary or secondary storage, and the like.

For example, the computer <NUM> can store information to the storage device <NUM> by issuing instructions through the storage controller <NUM> to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. The computer <NUM> can further read information from the storage device <NUM> by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the storage device <NUM> described above, the computer <NUM> can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It may be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the nontransitory storage of data and that can be accessed by the computer <NUM>. In some examples, the operations performed by the network <NUM> and or any components included therein, may be supported by one or more devices similar to computer <NUM>. Stated otherwise, some or all of the operations performed by the network <NUM>, and or any components included therein, may be performed by one or more computer devices <NUM> operating in a cloud-based arrangement.

By way of example, and not 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 includes, but is not limited to, RAM, ROM, erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory or other solid-state memory technology, compact disc ROM (CDROM), digital versatile disk (DVD), high definition DVD (HD-DVD), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.

As mentioned briefly above, the storage device <NUM> can store an operating system <NUM> utilized to control the operation of the computer <NUM>. According to one example, the operating system <NUM> comprises the LINUX operating system. According to another example, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further examples, the operating system can comprise the UNIX operating system or one of its variants. It may be appreciated that other operating systems can also be utilized. The storage device <NUM> can store other system or application programs and data utilized by the computer <NUM>.

In one example, the storage device <NUM> or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer <NUM>, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the examples described herein. These computer-executable instructions transform the computer <NUM> by specifying how the CPUs <NUM> transition between states, as described above. According to one example, the computer <NUM> has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer <NUM>, perform the various processes described above with regard to <FIG>. The computer <NUM> can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

As described herein, the computer <NUM> may comprise one or more of a host computing device <NUM>, router(s) <NUM>, a network registrar <NUM>, server(s) <NUM>, or a network device (e.g., server computer <NUM>, computing resource, router, etc.). The computer <NUM> may include one or more hardware processor(s) such as the CPUs <NUM> configured to execute one or more stored instructions. The CPUs <NUM> may comprise one or more cores. Further, the computer <NUM> may include one or more network interfaces configured to provide communications between the computer <NUM> and other devices, such as the communications described herein as being performed by the host computing device <NUM>, router(s) <NUM>, a network registrar <NUM>, server(s) <NUM>, or a network device, or other computing device. The network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth. For example, the network interfaces may include devices compatible with Ethernet, Wi-Fi™, and so forth.

The programs <NUM> may comprise any type of programs or processes to perform the techniques described in this disclosure for validating a host computing device <NUM> relative to a router <NUM>, and validating to the host computing device that it has joined an intended network. The programs <NUM> may enable the host computing device <NUM>, router(s) <NUM>, a network registrar <NUM>, server(s) <NUM>, and/or a network device to perform various operations.

In summary, systems and methods may include sending, to a network registrar, an extended duplicate address request (EDAR) message including a first nonce generated by a host computing device, and receiving, from the network registrar, an extended duplicate address confirmation (EDAC) message including a second nonce, the second nonce being signed by the network registrar via a private key of a first public key infrastructure (PKI) key pair of the network registrar via a first signature. The method further includes sending a first neighbor advertisement (NA) message to the host computing device including the second nonce. The second nonce and the private key of the network registrar verifies the first signature from the network registrar, the verification of the first signature indicating that the router is not impersonating the network.

Claim 1:
A method carried out by an Internet protocol version <NUM>, IPv6, over a low-power wireless personal area network, 6LoWPAN, enabled routing device, the method comprising:
receiving, from a 6LoWPAN-enabled host computing device (<NUM>), a first nonce generated by the 6LoWPAN-enabled host computing device (<NUM>);
sending (<NUM>) to a network registrar (<NUM>) included within a network (<NUM>) to which the 6LoWPAN-enabled host computing device (<NUM>) seeks to join, an extended duplicate address request, EDAR, message (<NUM>) including the first nonce;
receiving (<NUM>) from the network registrar (<NUM>), an extended duplicate address confirmation, EDAC, message (<NUM>) including;
a second nonce and a first signature,
wherein the first signature has been derived by the network registrar (<NUM>) by signing a first nonce pair including the first nonce and the second nonce via a private key of a first public key infrastructure, PKI, key pair of the network registrar (<NUM>) comprising the private key and a public key; and
sending (<NUM>) a first neighbor advertisement, NA, message (<NUM>) to the 6LoWPAN-enabled host computing device (<NUM>) including the second nonce and the first signature,
such that the 6LoWPAN-enabled host computing device (<NUM>) can verify that the 6LoWPAN-enabled routing device (<NUM>) is not impersonating the network (<NUM>) by verifying the first signature using the second nonce and the public key of the first PKI key pair.