]> Sandelman Software Works

mcr+ietf@sandelman.ca

vanderstok consultancy

stokcons@kpnmail.nl

Cisco Systems

pkampana@cisco.com

IoTconsultancy.nl

esko.dijk@iotconsultancy.nl

int anima This document extends the constrained Bootstrapping Remote Secure Key Infrastructures (cBRSKI) onboarding protocol by adding a new network function, the constrained Join Proxy. This function can be implemented on a constrained node. The goal of the Join Proxy is to help new constrained nodes ("Pledges") securely onboard into a new IP network using the cBRSKI protocol. It acts as a circuit proxy for User Datagram Protocol (UDP) packets that carry the onboarding messages. The solution is extensible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) based networks in which the onboarding authority server ("Registrar") may be multiple IP hops away from a Pledge. Despite this distance, the Pledge only needs to use link-local communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow different trade-offs regarding resource usage, implementation complexity and security. About This Document Status information for this document may be found at . Discussion of this document takes place on the anima Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol described in provides a solution for a secure zero-touch (automated) onboarding of new, unconfigured devices. In the context of BRSKI, new devices, called "Pledges", are equipped with a factory-installed Initial Device Identifier (IDevID) , and are enrolled into a network. BRSKI makes use of Enrollment over Secure Transport (EST) with signed vouchers to securely enroll devices. A Registrar provides the trust anchor of the network domain to which a Pledge enrolls. defines a version of BRSKI that is suitable for constrained nodes () and for operation on constrained networks () including Low-Power and Lossy Networks (LLN) . It uses Constrained Application Protocol (CoAP) messages secured by Datagram Transport Layer Security (DTLS) to implement the BRSKI functions defined by . In this document, cBRSKI is extended such that a cBRSKI Pledge can connect to a Registrar via a constrained Join Proxy. In particular, this solution is intended to support IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) mesh networks. 6TiSCH networks are not in scope of this document since these use the CoJP proxy mechanism. The Join Proxy as specified in this document is one of the Join Proxy options referred to in as future work. However, in IP networks that require node authentication, such as those using 6LoWPAN , data to and from the Pledge will not be routable over the IP network before it is properly authenticated to the network. A new Pledge can initially only use a link-local IPv6 address to communicate with a mesh neighbor until it receives the necessary network configuration parameters. Before it can receive these parameters, the Pledge needs to be authenticated and authorized to onboard the network. This is done in cBRSKI through an end-to-end encrypted DTLS session with a domain Registrar. When this Registrar is not a direct (link-local) neighbor of the Pledge but several hops away, the Pledge needs to discover a link-local neighbor that is operating as a constrained Join Proxy, which helps forward the DTLS messages of the session between Pledge and Registrar. Because the Join Proxy is a regular network node that has already been onboarded onto the network, it can send IP packets to the Registrar which are then routed over one or more hops over the mesh network -- and potentially over other IP networks too, before reaching the Registrar. Likewise, the Registrar sends its response IP packets which are routed back to the Join Proxy over the mesh network. Once a Pledge has enrolled onto the network in this manner, it can optionally be configured itself as a new constrained Join Proxy. In this role it can help other Pledges perform the cBRSKI onboarding process. Two modes of operation for a constrained Join Proxy are specified:

1. A stateful Join Proxy that locally stores UDP connection state per Pledge.
2. A stateless Join Proxy that does not locally store UDP connection state, but stores it in the header of a message that is exchanged between the Join Proxy and the Registrar.

Similar to the difference between storing and non-storing Modes of Operations (MOP) in RPL , the stateful and stateless modes differ in the way that they store the state required to forward return UDP packets from the Registrar back to the Pledge.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are defined in and , and are used identically in this document: artifact, Circuit Proxy, Join Proxy, domain, imprint, Registrar, Pledge, and Voucher. The term "installation" refers to all devices in the network and their interconnections, including Registrar, enrolled nodes (with and without constrained Join Proxy functionality) and Pledges (not yet enrolled). (Installation) IP addresses are assumed to be routable over the whole installation network, except for link-local IP addresses. The term "Join Proxy" is used in this document with the same definition as in . However, in this document it refers specifically to a Join Proxy that can support Pledges to onboard using a UDP-based protocol, such as the cBRSKI protocol . This protocol operates over an end-to-end secured DTLS session between a Pledge and a cBRSKI Registrar. The acronym "JPY" is used to refer to a new protocol and JPY message format defined by this document. The message can be seen as a "Join Proxy Yoke": connecting two data items and letting these travel together over a network. Because UDP does not have the notion of a connection, the term "UDP connection" in this document refers to a pseudo-connection, whose establishment on the Join Proxy is triggered by receipt of a first UDP packet from a new Pledge source. The term "endpoint" is used as defined in . The terms "6LoWPAN Router" (6LR), "6LoWPAN Border Router" (6LBR) and "6LoWPAN link" are used as defined in . Details of the IP address and port notation used in the Join Proxy specification are provided in .

Join Proxy Problem Statement and Solution

Problem Statement As depicted in , the Pledge (P), in a network such as a 6LoWPAN mesh network can be more than one hop away from the Registrar (R) and it is not yet authenticated to the network. Also, the Pledge does not possess any key material to encrypt or decrypt link-layer data transmissions. In this situation, the Pledge can only communicate one-hop to its neighbors, such as the constrained Join Proxy (J), using link-local IPv6 addresses and using no link-layer encryption. However, the Pledge needs to communicate with end-to-end security with a Registrar to authenticate and obtain its domain identity/credentials. In the case of cBRSKI, the domain identity is an X.509 certificate. Domain credentials may include key material for network access.

Multi-hop cBRSKI onboarding scenario in a 6LoWPAN mesh network

So one problem is that there is no IP routability between the Pledge and the Registrar, via intermediate nodes such as 6LoWPAN Routers (6LRs), despite the need for an end-to-end secured session between both. Furthermore, the Pledge is not be able to discover the IP address of the Registrar because it is not yet allowed onto the network.

Solution To overcome these problems, the constrained Join Proxy is introduced. This is specific functionality that all, or a specific subset of, authenticated nodes in an IP network can implement. When the Join Proxy functionality is enabled in a node, it can help a neighboring Pledge securely onboard the network. The Join Proxy performs relaying of UDP packets from the Pledge to the intended Registrar, and relaying of the subsequent return packets. An authenticated Join Proxy can either be configured with the routable IP address of the Registrar, or it can discover this address as specified in this document. Other methods of Registrar discovery (not yet specified in this document) can also be easily added. The Join Proxy acts as a packet-by-packet proxy for UDP packets between Pledge and Registrar. The cBRSKI protocol between Pledge and Registrar which this Join Proxy supports uses UDP messages with DTLS-encrypted CoAP payloads, but the Join Proxy as described here is unaware of these payloads. The Join Proxy solution can therefore be easily extended to work for other UDP-based protocols, as long as these protocols are agnostic to (or can be made to work with) the change of the IP and UDP headers performed by the Join Proxy. In summary, the following steps are typically taken for the onboarding process of a Pledge:

1. Join Proxies in the network learn the IP address and UDP port of the Registrar.
2. A new Pledge arrives: it discovers one or more Join Proxies and selects one.
3. The Pledge sends a link-local UDP message to the selected Join Proxy.
4. The Join Proxy relays the message to the Registrar (and port) of step 1.
5. The Registrar sends a response UDP message back to the Join Proxy.
6. The Join Proxy relays the message back to the Pledge.
7. Step 3 to 6 repeat as needed, for multiple messages, to complete the onboarding protocol.
8. The Pledge uses its obtained domain identity/credentials to join the domain network.

To reach the Registrar in step 4, the Join Proxy needs to be either configured with a Registrar address or needs to dynamically discover a Registrar as detailed in . This configuration/discovery is specified here as step 1. Alternatively, in case of automated discovery it can also happen on-demand in step 4, at the moment that the Join Proxy has data to send to the Registrar.

Solution for Multiple Registrars The solution description in assumes there is only one Registrar service configured or discovered by a Join Proxy, defined by a single IP address and single UDP port. However, there may be multiple Registrars present in a network deployment. There may be multiple Registrars supporting the exact same onboarding protocol, or multiple Registrars supporting different onboarding protocols, or a combination of both. Such cases are all supported by this specification, to enable redundancy, backward-compatibility, and introduction of new variants of onboarding protocols over time. Further information about the "BRSKI variants" concept can be found in . See for the specific requirements on the Join Proxy for supporting multiple Registrars or multiple onboarding protocol variants.

Forming 6LoWPAN Mesh Networks with cBRSKI The Join Proxy has been specifically designed to set up an entire 6LoWPAN mesh network using cBRSKI onboarding. This section outlines how this process works and highlights the role that the Join Proxy plays in forming the mesh network. Typically, the first node to be set up is a 6LoWPAN Border Router (6LBR) which will form the new mesh network and decide on the network's configuration. The 6LBR may be configured using for example one of the below methods. Note that multiple methods may be used within the scope of a single installation.

1. Manual administrative configuration
2. Use non-constrained BRSKI to automatically onboard over its high-speed network interface when it gets powered on.
3. Use cBRSKI to automatically onboard over its high-speed network interface when it gets powered on.

Once the 6LBR is enabled, it requires an active Registrar reachable via IP communication to onboard any Pledges. Once cBRSKI onboarding is enabled (either administratively, or automatically) on the 6BLR, it can support the onboarding of 6LoWPAN-enabled Pledges, via its 6LoWPAN network interface. This 6LBR may host the cBRSKI Registrar itself, but the Registrar may also be hosted elsewhere on the installation network. At the time the Registrar and the 6LBR are enabled, there may be zero Pledges, or there may be already one or more installed and powered Pledges waiting - periodically attempting to discover a Join Proxy over their 6LoWPAN network interface. A Registrar hosted on the 6LBR will, per , make itself discoverable as a Join Proxy so that Pledges can use it for cBRSKI onboarding over a 6LoWPAN link (one hop). Note that only some of Pledges waiting to onboard may be direct neighbors of the Registrar/6LBR. Other Pledges would need their traffic to be relayed by Join Proxies across one or more enrolled mesh devices (6LR, see ) in order to reach the Registrar/6LBR. For this purpose, all or a subset of the enrolled Pledges start to act as Join Proxies themselves. Which subset is selected, and when the Join Proxy function is enabled by a node, is out of scope of this document. The desired end state of the installation includes a network with a Registrar and all Pledges successfully enrolled in the network domain and connected to one of the 6LoWPAN mesh networks that are part of the installation. New Pledges may also be added by future network maintenance work on the installation. Pledges employ link-local communication until they are enrolled, at which point they stop being a "Pledge". A Pledge will periodically try to discover a Join Proxy using for example link-local discovery requests, as defined in . Pledges that are neighbors of the Registrar will discover the Registrar itself (which is posing as a Join Proxy) and will be enrolled first, using cBRSKI. The Pledges that are not a neighbor of the Registrar will at first fail to find a Join Proxy. Later on, they will eventually discover a Join Proxy so that they can be enrolled with cBRSKI too. While this continues, more and more Join Proxies with a larger hop distance to the Registrar will emerge. The mesh network auto-configures in this way, such that at the end of the onboarding process, all Pledges are enrolled into the network domain and connected to the mesh network.

Join Proxy Specification A Join Proxy can operate in two modes:

1. Stateful mode
2. Stateless mode

The advantages and disadvantages of the two modes are presented in .

Mode Implementation and Configuration Requirements For a Join Proxy implementation on a node, there are three possible scenarios:

1. Both stateful and stateless modes are implemented. The Join Proxy can switch between these modes, depending on configuration and/or auto-discovery of Registrar(s) for each option.
2. Only stateful mode is implemented.
3. Only stateless mode is implemented.

Option 2 and 3 have the advantage of reducing code size, testing efforts and deployment complexity, but requires all devices in the deployment to standardize on the same choice. A standard for a network-wide application or ecosystem profile, that integrates the Join Proxy functionality as defined in this document, MAY specify the use of any of these three options. It is expected that most deployments of constrained Join Proxies will be in the context of such standards and that these standards will be able to pick either option 2 or 3 based on considerations such as those in . A Join Proxy that is not adhering to such an additional standard MUST implement both modes (option 1). A Join Proxy or Registrar not adhering to such additional standards is called "generic". If a Join Proxy implements both modes but does not implement methods to discover available Registrars (for either method), then it MUST use only the mode that is currently configured for the network, or configured individually for the device. The method or profile that defines such a configuration is outside the scope of this document. If the mode is not configured and also can not be discovered automatically, then the device MUST NOT operate as a Join Proxy. For a Join Proxy to be operational, the node on which it is running has to be able to communicate with a Registrar (that is, exchange UDP messages with it). Establishing this connectivity can happen fully automatically if the Join Proxy node first enrolls itself as a Pledge, and then discovers the Registrar IP address/port, and if applicable its desired mode of operation (stateful or stateless), through a discovery mechanism (see ). Other methods, such as provisioning the Join Proxy are out of scope for this document but equally feasible. Such methods would typically be defined by a standard or ecosystem profile that integrates Join Proxy functionality. Such provisioning can also be fully automated, for example if the Registrar IP address/port are included in the network configuration parameters that are disseminated to each trusted network node. Independent of the mode of the Join Proxy or its discovery/configuration methods, the Pledge first discovers (see ) and selects the most appropriate Join Proxy. From the discovery result, the Pledge learns a Join Proxy's link-local IP address and UDP join-port. Details of this discovery are defined by the onboarding protocol and are not in scope of this document. For cBRSKI, this is defined in . A generic cBRSKI Registrar by design necessarily implements the stateful mode, and it SHOULD implement support for Join Proxies operating in the stateless mode. Support for only the stateless mode is considered not to bring significant simplifications to a generic cBRSKI Registrar implementation. However, the generic cBRSKI Registrar MAY offer a configuration option to disable either the stateful or stateless mode, which can be useful in a particular deployment. A cBRSKI Registrar that is only implemented to support an aforementioned network-wide application or ecosystem profile MAY implement either stateful and/or stateless mode.

Notation The following notation is used in this section in both text and figures:

• The colon (:) separates IP address and port number (<IP>:<port>).
• IP_P denotes the link-local IP address of the Pledge. For simplicity, it is assumed here that the Pledge only has one network interface.
• IP_R denotes the routable IP address of the Registrar.
• IP_Jl denotes the link-local IP address of the Join Proxy on the interface that connects it to the Pledge.
• IP_Jr denotes the routable IP address of the Join Proxy.
• p_P denotes the UDP port used by the Pledge for its onboarding/joining protocol, which may be cBRSKI. The Pledge acts in a UDP client role, specifically as a DTLS client for the case of cBRSKI.
• p_Jl denotes the join-port of the Join Proxy.
• p_Jr denotes the client port of the Join Proxy that it uses to forward packets to the Registrar.
• p_R denotes the server port of the Registrar on which it serves the onboarding protocol, such as cBRSKI.
• p_Rj denotes the server port of the Registrar on which it serves the JPY protocol.
• JPY[H( ),C( )] denotes a JPY message, as defined by the JPY protocol, with header H and content C indicated in between the parentheses.

Stateful Join Proxy In stateful mode, the Join Proxy acts as a UDP circuit proxy that does not change the UDP payload (called "data octets" in ) but only rewrites the IP and UDP headers of each UDP packet it forwards between a Pledge and a Registrar. The UDP flow mapping state maintained by the Join Proxy can be represented as a list of tuples, one for each active Pledge, as follows: (IP_Jr:p_Jr, IP_R:p_R) (Exp-timer) ]]> In case a Join Proxy has multiple network interfaces that accept Pledges, an interface identifier needs to be added on the leftmost tuple component. If a Join Proxy has multiple network interfaces to connect to (one or more) Registrars, an interface identifier needs to be added to the rightmost tuple component. Both of these are not shown further in this section, for better readability. The establishment of the UDP connection state on the Join Proxy is solely triggered by receipt of a UDP packet from a Pledge with an IP_P:p_P link-local source and IP_Jl:p_Jl link-local destination for which no mapping state exists, and that is terminated by a connection expiry timer. depicts an example DTLS session via the Join Proxy, to show how this state is used in practice. In this case the Join Proxy knows the IP address of the Registrar (IP_R) and the default CoAPS port (P_R = 5684) on the Registrar is used to access cBRSKI resources.

Example of the message flow of a DTLS session via a stateful Join Proxy. | IP_P:p_P | IP_Jl:p_Jl | | ---ClientHello--> | IP_Jr:p_Jr| IP_R:5684 | | | | | | <--ServerHello--- | IP_R:5684 | IP_Jr:p_Jr | | : | | | | <--ServerHello--- : | IP_Jl:p_Jl| IP_P:p_P | | : : | : | : | | [DTLS messages] | : | : | | : : | : | : | | ---Finished--> : | IP_P:p_P | IP_Jl:p_Jl | | ---Finished--> | IP_Jr:p_Jr| IP_R:5684 | | | | | | <--Finished--- | IP_R:5684 | IP_Jr:p_Jr | | <--Finished--- | IP_Jl:p_Jl| IP_P:p_P | | : : | : | : | +---------------------------------------+-------------+------------+ ]]>

The Join Proxy MUST allocate a unique IP_Jr:p_Jr for every unique Pledge that it serves. This is typically done by selecting a unique available port P_Jr for each Pledge. Doing so enables the Join Proxy to correctly map the UDP packets received from the Registrar back to the corresponding Pledges. Also, it enables the Registrar to correctly distinguish multiple DTLS clients by means of IP address/port tuples. The default timeout for clearing the state for a Pledge MUST be 30 seconds after the last relayed packet was sent on a UDP connection associated to that Pledge, in either direction. The default timeout MAY be overridden by another value that is either configured, or discovered in some way out of scope of this document. When a Join Proxy receives an ICMP / ICMPv6 error from the Registrar, this may signal a permanent change of the Registrar's IP address and/or port, or it may signal a temporary disruption of the network. In such case, the Join Proxy SHOULD send an equivalent ICMP error message (with same Type and Code) to the Pledge. The specific Pledge can be determined from the IP/UDP header information that is contained in the ICMP error message body, if included. In case the ICMP message body is empty, or insufficient information is included there, the Join Proxy does not send the ICMP error message to the Pledge because the intended recipient cannot be determined. To protect itself and the Registrar against malfunctioning Pledges and/or denial of service (DoS) attacks, the Join Proxy SHOULD limit the number of simultaneous state tuples for a given IP_p to at most 2, and it SHOULD limit the number of simultaneous state tuples per network interface to at most 10. When a new Pledge connection is received and the Join Proxy is unable to build new mapping state for it, for example due to the above limits, the Join Proxy SHOULD return an ICMP Type 1 "Destination Unreachable" error message with Code 1, "Communication with destination administratively prohibited".

Stateless Join Proxy Stateless Join Proxy operation eliminates the need and complexity to maintain per-Pledge UDP connection mapping state on the proxy and the machinery to build, maintain and remove this mapping state. It also removes the need to protect this mapping state against DoS attacks and may also reduce memory and CPU requirements on the proxy. Stateless Join Proxy operations work by introducing a new JPY message used in communication between Proxy and Registrar. This message will store the state "in the network". It consists of two parts:

• Header (H) field: contains state information about the Pledge (P) such as the link-local IP address and UDP port.
• Contents (C) field: the original UDP payload (data octets according to ) received from the Pledge, or destined to the Pledge.

When the join proxy receives a UDP message from a Pledge, it encodes the Pledge's link-local IP address, interface ID and UDP (source) port of the UDP packet into the Header field and the UDP payload into the Contents field and sends the packet to the Registrar from a fixed source UDP port. When the Registrar sends packets for the Pledge, it MUST return the Header field unchanged, so that the join proxy can decode the Header to reconstruct the Pledge's link-local IP address, interace and UDP (destination) port for the return UDP packet. shows this per-packet mapping on the join proxy for a DTLS session. The Registrar transiently stores the Header field information. The Registrar uses the Contents field to execute the Registrar functionality. When the Registrar replies, it wraps its DTLS message in a JPY message and sends it back to the Join Proxy. The Registrar SHOULD NOT assume that it can decode the Header Field of a received JPY message, it MUST simply replicate it when responding. The Header of a reply JPY message contains the original source link-local address and port of the Pledge from the transient state stored earlier and the Contents field contains the DTLS payload created by the Registrar. On receiving the JPY message, the Join Proxy retrieves the two parts. It uses the Header field information to send a link-local UDP message containing the (DTLS) payload retrieved from the Contents field to a particular Pledge. When the Registrar receives such a JPY message, it MUST treat the Header H as a single additional opaque identifier of all packets associated to a UDP connection with a Pledge. Whereas in the stateful proxy case, all packets with the same 4-tuple (IP_Jr:p_Jr, IP_R:p_R) belong to a single Pledge's UDP connection, in the stateless proxy case only the packets with the same 5-tuple (IP_Jr:p_Jr, IP_R:p_Rj, H) belong to a single Pledge's UDP connection. The JPY message Contents field contains the UDP payload of the packet for that Pledge's UDP connection. Packets with different header H belong to different Pledge's UDP connections. In the stateless mode, the Registrar MUST offer the JPY protocol on a discoverable UDP port (p_Rj). There is no default port number available for the JPY protocol, unlike in the stateful mode where the Registrar can host all its services on the CoAPS default port (5684).

Example of the message flow of a DTLS session via a stateless Join Proxy. | IP_P:p_P |IP_Jl:p_Jl | | ---JPY[H(IP_P:p_P), --> | IP_Jr:p_Jr|IP_R:p_Rj | | C(ClientHello)] | | | | <--JPY[H(IP_P:p_P), --- | IP_R:p_Rj |IP_Jr:p_Jr | | C(ServerHello)] | | | | <---ServerHello--- | IP_Jl:p_Jl|IP_P:p_P | | : | : | : | | [ DTLS messages ] | : | : | | : | : | : | | ---Finished---> | IP_P:p_P |IP_Jr:p_Jr | | ---JPY[H(IP_P:p_P), --> | IP_Jl:p_Jl|IP_R:p_Rj | | C(Finished)] | | | | <--JPY[H(IP_P:p_P), --- | IP_R:p_Rj |IP_Jr:p_Jr | | C(Finished)] | | | | <---Finished-- | IP_Jl:p_Jl|IP_P:p_P | | : | : | : | +-------------------------------------------+-----------+-----------+ ]]>

When a Join Proxy receives an ICMP / ICMPv6 error from the Registrar, this may signal a permanent change of the Registrar's IP address and/or port, or it may signal a temporary disruption of the network. Unlike a stateful Join Proxy, the stateless Join Proxy cannot determine the Pledge to which this ICMP error should be mapped, because the JPY header containing this information is not included in the ICMP error message. Therefore, it cannot inform the Pledge of the specific error that occurred.

JPY Protocol and Messages JPY messages are used by a stateless Join Proxy to carry required state information in the relayed UDP messages, such that it does not need to store this state in memory. JPY messages are carried directly over the UDP layer. So, there is no CoAP or DTLS layer used between the JPY messages and the UDP layer. A Registrar that supports the JPY protocol also uses JPY message to return relayed UDP messages to the stateless Join Proxy, including the state information that it needs.

JPY Message Structure Each JPY message consists of one CBOR array with 2 elements:

1. The Header (H) with the Join Proxy's per-message state data: wrapped in a CBOR byte string. The state data SHOULD be at most 32 bytes.
2. The Content (C) field: the binary (DTLS) payload being relayed, wrapped in a CBOR byte string. The payload is encrypted. The Join Proxy cannot decrypt it and therefore has no knowledge of any transported (CoAP) messages, or the URI paths or media types within the CoAP messages.

Using CDDL , the CBOR array that constitutes the JPY message can be formally defined as:

CDDL representation of a JPY message

The jpy_header state data is to be reflected (unmodified) by the Registrar when sending return JPY messages to the Join Proxy. The header's internal representation is not standardized: it can be constructed by the Join Proxy in whatever way. It is to be used by the Join Proxy to record state for the included jpy_content field, which includes the information which Pledge the data in jpy_content came from. This state data stored in the JPY message is similar to the "state object" mechanism described in . However, since the CoAP protocol layer (if any) is inside the DTLS layer, so end-to-end encrypted between the Pledge and the Registrar, it is not possible for the Join Proxy to act as a CoAP proxy per . Detailed examples of a complete JPY message are shown in .

JPY Message Port Usage For the JPY messages sent to the Registrar, the Join Proxy SHOULD use the same UDP source port and IP source address for the JPY messages sent on behalf of all Pledges. Although a Join Proxy MAY vary the UDP source port, doing so creates more local state. A Join Proxy with multiple CPUs (unlikely in a constrained system, but possible) could, for instance, use different UDP source port numbers to demultiplex connections across CPUs.

JPY Message Overhead and MTU Size The use of the JPY message CBOR encoding adds a 3-6 byte overhead on top of the data carried within the Header and Contents fields. The Header state data itself (up to 32 bytes) also adds an overhead on each UDP message exchanged between Join Proxy and Registrar. Therefore, a protocol using the stateless Join Proxy MUST use (UDP) payloads that are bounded in size, such that the maximum payload length used minus the maximum overhead size (38 bytes) stays below the MTU size of the network. cBRSKI is designed to work even for the minimum IPv6 MTU of 1280 bytes, by configuring the DTLS maximum fragment length and using CoAP blockwise transfer for large resource transfers . At the CoAP level, using the cBRSKI and the EST-CoAPS protocols, the CoAP blockwise options are often used to split large payloads into multiple data blocks. The Registrar and the Pledge MUST select a block size that would allow the addition of the JPY message structure without violating MTU sizes.

JPY Message Security Application or ecosystem standards adopting the stateless Join Proxy need to determine if there is the potential for attacks originating from the trusted network side of the Join Proxy. Such attacks would involve senders other than a trustworthy Registrar sending packets to the Join Proxy, impersonating the trusted Registrar by using its source address and port. In many well-designed solutions, this attack vector can be excluded because IP source addresses are verified. For example, in Autonomic Networking Infrastructure (ANI) networks, the Autonomic Control Plane (ACP) () ensures that only trustworthy nodes can communicate amongst each other. In an ACP, compromising an ACP node may be as hard as compromising the Registrar itself. Likewise, in many Wi-Fi mesh networks and 6LoWPAN mesh networks, link-layer security is applied and claimed to achieve similar levels of secure and trusted communication within the scope of the mesh. For stateless Join Proxies that only operate in such secured network environments, it can be sufficient to only accept JPY messages originating from a Registrar's IP address and port, and not use any additional encryption or integrity protection of the JPY header. The Registrar's IP address and port are configured on the Join Proxy, or discovered by the Join Proxy, for sending JPY messages. Generic stateless Join Proxies on the other hand can not assume any such additional security measures for the network that connects the Proxy to the Registrar. For example, a generic Join Proxy's network connection to a Registrar may pass through a lightly protected enterprise network, such as a university or campus network, without additional security. Therefore, a generic stateless Join Proxy SHOULD encrypt and integrity-protect the state data prior to wrapping it in a CBOR byte string in jpy_header. It SHOULD be encrypted with a symmetric key known only to the Join Proxy itself. When the Join Proxy attempts to decrypt a receiver jpy_header byte string, and either the decryption or the integrity check fails, it MUST silently discard the JPY message. The symmetric key need not persist on a long-term basis, and MAY be changed periodically. Because a key change during an onboarding attempt of a Pledge could lead to DTLS retransmissions, or even failure of the onboarding attempt, it is RECOMMENDED to change the key infrequently: for example every 24 hours.

Example Format for JPY Header Data A typical JPY message header format, prior to encryption, could be constructed using the following binary data structure (expressed in C style notation): 0 uint8_t iid[8]; uint32_t zero; // Only valid == 0 }; ]]> This is illustrative only: the format of the data inside jpy_header is not subject to standardization and may vary across Pledges. It may for example use a CBOR array encoding, formally defined and constrained using CDDL . The data structure stores the Pledge's UDP source port (srcport), the IID bits of the Pledge's originating IPv6 link-Local address (iid), the IPv4/IPv6 family (as a uint8 value 0 or 1) and an interface index (ifindex) to provide the link-local scope for the case that the Join Proxy has multiple network interfaces. The zero field is both for integrity protection and padding. It is always value zero (before encryption) on sending and MUST be zero after decryption on reception. The resulting plaintext size is 16 bytes. This size fits into a single AES128 CBC block for instance, resulting in a 16 byte block of encrypted state data, jpy_header_ciphertext. Due to the way that CBC encryption mixes all the contents of a block together, an attacker that modifies any bit of this block will most likely change one of the zero bits in the family and/or zero fields as well. This jpy_header_ciphertext data is then wrapped in a CBOR byte string to form the jpy_header element. This results in a jpy_header CBOR element of 17 bytes which includes a 1-byte overhead to encode the data as a CBOR byte string of length 16. Note: when IPv6 is used only the lower 64-bits of the source IPv6 address need to be recorded, because they must be by design all IPv6 link-Local addresses, so the upper 64-bits are just "fe80::" and can be elided. For IPv4, a link-Local IPv4 address would be used, and it would always fit into the 64 bits of the iid field. On link types where the Interface IDentifier (IID) is not 64-bits, a different field size for iid will be necessary. Replay protection is not included in this example security solution, because the regular transport layers of cBRSKI and BRSKI, respectively UDP and TCP, also do not provide replay protection. Rather, replay protection is handled by the higher layer protocol, respectively DTLS and TLS. If replay attack protection is desired, AES with GCM SHOULD be used. Detailed examples of a complete JPY message are shown in .

Processing by Registrar On reception of a JPY message by the Registrar, the Registrar MUST verify that the number of CBOR array elements is 2 or more. To implement this specification, only the first two elements are used. The data in the jpy_content field must be provided as input to a DTLS library , which along with the 5-tuple defined in provides enough information for the Registrar to pick an appropriate (active) client context. Note that the same UDP socket will need to be used for multiple DTLS flows, which is atypical for how DTLS usually uses sockets. The jpy_context field can be used to select an appropriate DTLS context, as DTLS headers do not contain any kind of per-session context. The jpy_context field needs to be linked to the DTLS context, and when a DTLS message need to be sent back to the client, the jpy_context needs to be included in a JPY message along with the DTLS message in the jpy_content field.

Handling Multiple Registrars In a network deployment there MAY be multiple Registrar hosts present, each host operating one or more Registrar service(s). Regardless of the number of (physical or logical) hosts, each of these Registrar services is considered a separate Registrar. One or more of these Registrars MAY be configured in a Join Proxy, by a method out of scope of this specification. Also one or more of these Registrars MAY be found by a Join Proxy using its discovery method(s). The Join Proxy is not necessarily aware of all onboarding protocol variants that are enabled in its network. Specifically, it may not be aware of the expected communication timing characteristics for the onboarding protocol that it is providing its proxy function for. Therefore, the final selection of onboarding protocol and Registrar is left to the Pledge and not to the Join Proxy. Also the determination of "onboarding progress" and whether the Registrar is considered responsive or not is left to the Pledge performing the onboarding protocol. This is consistent with which defines how a BRSKI Pledge attempts onboarding via multiple Join Proxies and defines the related retry and switching behaviors. If a Join Proxy discovers more Registrars than it can simultaneously offer to Pledges, given its resource limits or implementation-defined limits, then the Join Proxy MUST select from the discovered Registrars in an implementation-defined manner. Future work such as may define a selection process for this case. As an example, a network deployment might include a single Registrar host that offers two Registrar services: cBRSKI and a hypothetical "future BRSKI" (fuBRSKI). Both services are hosted on different UDP ports. Each Join Proxy is configured with these two Registrar services, and when a Pledge is sending CoAP discovery requests each Join Proxy in range will respond with both services in a CoAP discovery response. The Join Proxy is able to distinguish the properties of the two Registrar services by the differences in the CoRE Link Format parameters included in the two responded onboarding service descriptions.

Discovery

Join Proxy Discovers Registrar In order to accommodate automatic configuration of the Join Proxy, it MUST discover the location and capabilities of the Registrar, in case this information is not configured already. In BRSKI the GeneRic Autonomic Signaling Protocol (GRASP) protocol is supported for discovery of a BRSKI Registrar in an Autonomic Control Plane (ACP). However, this document does not target the ACP context of use. Therefore, the definition of how to use GRASP for discovering a cBRSKI Registrar in an ACP is left to future work such as . Although multiple discovery methods can be supported in principle by a single Join Proxy, this document only defines one default method for a Join Proxy to discover a Registrar: using CoAP resource discovery queries . The CoAP discovery query to use depends on the intended mode of operation of the Join Proxy: stateless or stateful. A stateless Join Proxy needs to discover a UDP endpoint (address and port) that can accept JPY messages, supporting the coaps+jpy scheme. On the other hand, a stateful Join Proxy needs to discover a single CoAPS endpoint supporting the coaps scheme that offers the full set of cBRSKI Registrar resources.

Stateless Case The stateless Join Proxy can discover the JPY protocol endpoint of the Registrar by sending a multicast CoAP GET discovery query to the "/.well-known/core" resource including a resource type (rt) query parameter "brski.rjp". The latter CoAP resource type is defined in . Upon success, the return payload will contain the port of the Registrar on which the JPY protocol handler is hosted. This exchange is shown below: ;rt=brski.rjp ]]> In this case, the multicast CoAP request is sent to the site-local "All CoAP Nodes" multicast IPv6 address ff05::fd. In some deployments, a smaller scope than site-local is more appropriate to reduce the network load due to this CoAP discovery traffic. For example, in a 6LoWPAN mesh network where a JPY protocol endpoint is always hosted on a 6LoWPAN Border Router (6LBR), the realm-local scope "All CoAP Nodes" address ff03::fd can be used. The reason that the IPv6 address (field ipv6_address) is always included in the link-format result is that in the link format, and per , the authority component cannot include only a port number but has to include also the IP address. The returned port is expected to process the encapsulated JPY messages described in . The scheme is coaps+jpy, described in , and not regular coaps because the JPY messages effectively form a new protocol that encapsulates CoAPS.

Stateful Case The stateful Join Proxy can discover the Registrar's cBRSKI resource set by sending a multicast CoAP GET discovery query to the "/.well-known/core" resource including a resource type (rt) query parameter "brski". The latter CoAP resource type is defined in . Upon success, the return payload will contain the URI path and port of the Registrar on which the cBRSKI resources are hosted. This exchange is shown below: ;rt=brski ]]> The port field and its preceding colon are optionally included: if elided, the default CoAPS port 5684 is implied. The uri_path field may be a single CoAP URI path resource label, or it may be a hierarchy of resources. For efficiency, it is RECOMMENDED for the Registrar to configure the URI path as short as possible, for example b. Note that the Join Proxy does not use the returned uri_path information, while it uses the ipv6_address and port information for its relaying operations.

Examples A Registrar with address 2001:db8:0:abcd::52, with the JPY protocol hosted on port 7634, and the CoAPS resources hosted on default port 5684 could for example reply to a multicast CoAP query of a stateful Join Proxy as follows: ;rt=brski ]]> The same Registrar could for example reply to a multicast CoAP query of a stateless Join Proxy as follows: ;rt=brski.rjp ]]> In these examples, the Join Proxy in a specific mode of operation (stateful or stateless) only queries for those cBRSKI services that it minimally needs to perform the Join Proxy function in that mode. For this reason, wildcard queries (such as rt=brski*) are not sent.

Pledge Discovers Join Proxy Regardless of whether the Join Proxy operates in stateful or stateless mode, it is discovered by the Pledge identically. defines the details of the CoAP discovery request sent by the Pledge. A Join Proxy implementation by default MUST support this discovery method. If there is another method configured, by some means outside of the scope of this document, the default method MAY be deactivated. The join-port of the Join Proxy is discovered by sending a multicast GET request to "/.well-known/core" including a resource type (rt) parameter with the value "brski.jp". This value is defined in . Upon success, the return payload will contain the join-port. The meta-example below shows the discovery of the join-port (field join_port) of the Join Proxy: ;rt=brski.jp ]]> In actual examples based on this, the field IP_address would contain the link-local IP address of the Join Proxy and the field join_port would contain the join-port value as a decimal number. Note that the join_port field and preceding colon MAY be absent in the discovery response: this indicates that the join-port is the default CoAPS port 5684. In the returned CoRE link format document, discoverable port numbers are usually returned for the Join Proxy resource in the <URI-Reference> of the link (see for details).

Pledge Discovers Multiple Join Ports A Pledge MUST be able to handle multiple join-ports being returned in a discovery response sent by a Join Proxy. This can happen if the network supports multiple Registrars and/or multiple Registrar-services as defined in . Then, each Registrar gets assigned its own join-port (up to a limit imposed by Join Proxy implementation) so that a Pledge is enabled to failover to another Registrar if a prior onboarding attempt fails. How the Pledge selects between the onboarding services matching its query, is implementation-specific and out of scope of this document. Discovery of multiple Registrars works in the same way as discovery of a single Registrar as defined in , except that multiple links are returned in the CoRE Link Format document. The meta-example below shows the discovery of two join-ports (fields join_port1 and join_port2) on a Join Proxy, each associated to a different cBRSKI protocol variant, defined by two CoRE Link Format links: ;rt=brski.jp, ;rt=brski.jp; param1=value1;param2=value2 ]]> In actual examples based on this, the field IP_address would contain the link-local IP address of the Join Proxy and the fields join_port1 and join_port2 would contain distinct decimal port number values. The parameter values (param1 and param2) are included for illustrative purposes. In a real example, these would contain Link Format parameters specifically defined for the brski.jp resource type. Such parameters may be defined in future work (). These parameters, if understood by the Pledge, help in selecting the optimal matching onboarding protocol variant of cBRSKI. If the Pledge does not understand these parameters, it can select any one of the two join-ports for cBRSKI onboarding. If the attempt subsequently fails, the Pledge repeats the attempt using the other discovered join-port as defined by .

Comparison of Stateless and Stateful Modes The stateful and stateless mode of operation for the Join Proxy each have their advantages and disadvantages. This section helps operators and/or profile-specifiers to make a choice between the two modes based on the available device resources and network bandwidth. Stateful mode introduces the complexity of maintaining per-connection state, which can increase processing and memory requirements on the proxy compared to the stateless mode under ideal conditions. Additionally, it opens up a wider range of potential implementation challenges in the presence of misbehaving or malicious Pledges. For example: How can state be effectively limited? How can malicious Pledges be detected—or at least prevented from negatively impacting non-malicious nodes? And so on. If the proxy is deployed on nodes that support frequent and reliable software updates, then tailoring software enhancements based on the observed attack profile(s) in the deployment scenario is an effective way to improve and harden the implementation. However, many constrained devices either lack this software agility or intentionally avoid it. In such environments, stateless mode becomes advantageous, as it offloads most of the complex hardening responsibilities to the Registrar, allowing the proxy implementation to remain as lightweight as possible. Ultimately, a stateless proxy requires no more protective mechanisms than a basic packet-forwarding router. The main concern for a stateless Join Proxy is the risk of forwarding an excessive number of packets to the Registrar, particularly over low-bandwidth connections such as 6LoWPAN links. Rate-limiting forwarded packets is the primary defense mechanism in such cases. All other Pledge-specific protections can be delegated to the Registrar, which is expected to have the necessary software agility to handle these. The following table summarizes more comparison details. Comparison between stateful and stateless Join Proxy mode

Properties	Stateful mode	Stateless mode
State Information	The Join Proxy needs additional storage to maintain mappings between the address and port number of the Pledge and those of the Registrar.	No information is maintained by the Join Proxy. Registrar transiently stores the JPY message header.
Packet size	The size of a relayed message is the same as the original message.	Size of a relayed message is up to 38 bytes larger than the original: due to additional context data.
Technical complexity	The Join Proxy needs additional functions to maintain state information, and specify the source and destination addresses and ports of relayed messages.	Requires new JPY message structure (CBOR) in Join Proxy. The Registrar requires a function to process JPY messages.
Join Proxy Ports	Join Proxy needs discoverable join-port	Join Proxy needs discoverable join-port
Registrar Ports	Registrar can host on a single UDP port.	Registrar must host on two UDP ports: one for DTLS, one for JPY messages.

Security Considerations For a Pledge using a Join Proxy, all the security considerations and requirements in apply. While doing discovery of Join Proxies, the Pledge can be deceived by malicious Join Proxy announcements. The subsequent communication of a Pledge with a Registrar that flows via the Join Proxy is end-to-end protected by DTLS. A malicious Join Proxy has a number of relay/routing options for messages sent by a Pledge:

• It relays messages to a malicious Registrar. This is the same case as the presence of a "malicious Registrar" discussed in .
• It does not relay messages, or does not return the responses from the Registrar to the Pledge. This is equivalent to the case of a non-responding Registrar discussed in and .
• It uses the returned responses of the Registrar for its own (attack) purposes. This is very unlikely due to the DTLS security.
• It uses the request from the Pledge to take the Pledge certificate and impersonate the Pledge. This is very unlikely because that requires it to acquire the private key of the Pledge, for an attack to be effective.

A malicious Pledge may also craft and send messages to a Join Proxy:

• It can construct an invalid DTLS or UDP message and send it to the open join-port of the Join Proxy. A Join Proxy will accept the message and relay to the Registrar without checking the payload. The Registrar will now parse the invalid message as DTLS protocol payload. Due to the security properties of DTLS, it is highly unlikely that this malicious payload will lead to message acceptance or to the Registrar's malfunctioning. The Registrar of course MUST be prepared to receive invalid and/or non-DTLS payloads in this way. If the Pledge uses large UDP payloads, the attacker is able to misuse network resources. This way, a DoS attack could be performed by using multiple malicious Pledges, or using a single device posing as multiple Pledges.

For a malicious node that is either a neighbor of a Join Proxy, or is a router on the network path to the Registrar, and the node is part of the trusted network:

• It may sniff the messages routed by the Join Proxy. It is very unlikely that the malicious node can decrypt the DTLS payload. The malicious node may be able to read the inner data structure in the JPY Header field, if that is not encrypted. This does expose some information about the Pledge attempting to join, but this can be mitigated by the Pledge using a new (random) link-local address for each onboarding attempt.

In case the JPY Header is not encrypted, a malicious node has a number of options to craft a JPY message and send it to a stateless Join Proxy:

• It can craft a JPY message with header fields of its choice based on earlier observed contents of JPY messages sent by a stateless Join Proxy. In that case, the Join Proxy would accept the message and send the Content field data to a Pledge as a UDP message. Such a message could disrupt an ongoing DTLS session. It could also allow the attacker to access an unsecured UDP port that a Pledge may have exposed. For this reason, a Pledge MUST NOT accept messages on other UDP ports than its port used for onboarding while an onboarding attempt is ongoing.

It should be noted here that the JPY message CBOR array and the JPY Header field are not DTLS protected. When the communication between stateless Join Proxy and Registrar passes over an unsecure network, an attacker can change the CBOR array, and change the Header field if no encryption is used there. These concerns are also expressed in . It is also pointed out here that the encryption by the source of the JPY Header, the Join Proxy, is a local matter. Similar to , the use of AES-CCM with a 64-bit tag is recommended, combined with a sequence number and a replay window. A "malicious Registrar" (see ) may also be unknowingly selected by a genuine (non-compromised) Join Proxy. This may happen when the malicious Registrar either modifies the network's Registrar address configuration or presents itself as a Registrar using the discovery method used in the network. If the discovery of Registrars is performed in an unsecured manner within the trusted network, it would allow the malicious Registrar to present itself as a Registrar candidate. CoAP discovery defined in ) is, for example, defined without any transport-layer or application-layer security. A trusted Join Proxy may therefore relay a Pledge's messages to it. It is the responsibility of a Pledge to monitor if an onboarding attempt with the selected Join Proxy and selected join-port on this Proxy (in case of multiple) is proceeding sufficiently quickly. If this is not the case, the Pledge needs to switch to another join-port and/or another Join Proxy to retry its onboarding attempt. See for specification details on this. In some installations, layer 2 (link layer) security is provided between all node pairs of a mesh network. In such an environment, in case all mesh nodes are trusted, and the Registrar is also located on the mesh network, and on-mesh attackers are not considered, then encryption of the JPY Header field as specified in this document is not necessary because the layer 2 security already protects it.

IANA Considerations

Resource Type Attributes Registry This specification registers two new Resource Type (rt=) Link Target Attributes in the "Resource Type (rt=) Link Target Attribute Values" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group, per the procedure.

coaps+jpy Scheme Registration This specification registers a new URI scheme per under the IANA "Uniform Resource Identifier (URI) Schemes" registry. The scheme specification is provided below.

• Scheme syntax: identical to the "coaps" scheme defined in .
• Scheme semantics: identical to the "coaps" scheme, except that the JPY message encapsulation mechanism described in of [This RFC] is used to transport each CoAPS UDP datagram.
• Encoding considerations: identical to the "coaps" scheme.
• Interoperability considerations: identical to the "coaps" scheme.
• Security considerations: all of the security considerations of the "coaps" scheme apply. Users of this scheme should be aware that as part of the intended use, a UDP message that was formed using the "coaps" scheme is embedded by a Join Proxy as defined by [This RFC] into a UDP message conforming to the "coaps+jpy" scheme without the Join Proxy being able to parse/decode which CoAPS URI was originally used by the sender, since that information is stored as DTLS-protected data. The receiving server can transform the "coaps+jpy" scheme back to the original "coaps" scheme by decoding the JPY message payload. However, any CoAP-related information not stored in the DTLS-protected data (such as in the UDP/IP headers) may be changed by these scheme transforms.

Service Name and Transport Protocol Port Number Registry This specification registers two service names under the IANA "Service Name and Transport Protocol Port Number" registry. Contact: IESG Description: Bootstrapping Remote Secure Key Infrastructure constrained Join Proxy Reference: [This RFC] Service Name: brski-rjp Transport Protocol(s): udp Assignee: IESG Contact: IESG Description: Bootstrapping Remote Secure Key Infrastructure Registrar join-port, supporting the coaps+jpy scheme, used by stateless constrained Join Proxy Reference: [This RFC] ]]>

References Normative References This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK] This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] Watsen Networks Sandelman Software Cisco Systems Futurewei Technologies Inc. Huawei This document defines a strategy to securely assign a Pledge to an owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, includes a number of desired extensions into the YANG. The voucher request defined in RFC8995 is also now included in this document, as well as other YANG extensions needed for variants of BRSKI/RFC8995. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES). To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK] This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK] This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration. The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. This document provides considerations for alleviating Constrained Application Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header. This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. Futurewei USA IoTconsultancy.nl This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators, especially in the face of variations in the protocols that can introduce non-interoperability when not equally supported by both responder and initiator. Philips Research University of Glasgow Singapore Philips Research The 6LoWPAN and CoAP standards defined for resource-constrained devices are fast emerging as the de-facto protocols for enabling the Internet-of-Things (IoTs). Security is an important concern in IoTs and the DTLS protocol has been chosen as the preferred method for securing CoAP messages. DTLS is a point-to-point protocol relying on IP routing to deliver messages between the client and the server. However in some low-power lossy networks (LLNs) with multi-hop, a new "joining" device may not be initially IP-routable. Moreover, it exists in a separate, unauthenticated domain at the point of first contact and therefore cannot be initially trusted. This puts limitations on the ability to use DTLS as an authentication and confidentiality protocol at this stage. These devices being Resource-constrained often cannot accommodate more than one security protocol in their code memory. To overcome this problem we suggest DTLS as the single protocol and therefore, we present a DTLS Relay solution for the non-IP routable "joining" device to enable it to establish a secure DTLS connection with a DTLS Server. Furthermore we present a stateful and stateless mode of operation for the DTLS Relay. Sandelman Software Works This document explores a number of issues affecting the decision to use a stateful or stateless forwarding mechanism by the join router (aka join assistant) during the bootstrap process for ANIMA. IEEE Standards Association

Stateless Join Proxy JPY Message Examples This appendix shows an example of a JPY message, sent by a stateless Join Proxy to a Registrar, and an example of the return JPY message sent by the Registrar. The DTLS payload itself, carried in the Content (C) field of the JPY message, is not shown in detail but abbreviated. First, assume that a Pledge creates a CoAP request to a Join Proxy that it has just discovered and selected for performing onboarding. This request may be a Pledge Voucher Request (PVR) as follows: ]]> Because a DTLS session is not yet established at this point, the first step for the client is to send the DTLS Client Hello message to the Join Proxy's join-port 45965. When the Join Proxy receives this UDP packet, it creates a JPY message with the following UDP payload: ]]> The same JPY message written in CBOR diagnostic notation is: Above, the ellipsis ("...") notation in a CBOR diagnostic byte string denotes a further sequence of bytes that is not shown for brevity. The first CBOR byte string wraps the 16 bytes of encrypted state information of the Header (H) field. The second CBOR byte string wraps the 427 bytes of the received DTLS message. After the Registrar has processed the received JPY message, it sends a DTLS 1.2 Hello Verify Request in response to the received Client Hello message. This Hello Verify Request is wrapped in a new JPY message that it sends back to the Join Proxy: ]]> The same JPY message in CBOR diagnostic notation is:

Acknowledgements outlined the various options for building a constrained Join Proxy. Many thanks for the comments by , , , , , , , , , , , and . This document is very much inspired by text published earlier in . , , and are the co-authors of this document. Their draft text has served as a basis for this document.

Changelog -16 to -17 -15 to -16 -13 to -15 -12 to -13 -11 to -12 -10 to -11 -09 to -10 -07 to -09 -06 to -07 -05 to -06 -04 to -05 -03 to -04 -02 to -03 -01 to -02 -00 to -01 -00 to -00