| < draft-ietf-anima-constrained-join-proxy-09.txt | draft-ietf-anima-constrained-join-proxy-10.txt > | |||
|---|---|---|---|---|
| anima Working Group M. Richardson | anima Working Group M. Richardson | |||
| Internet-Draft Sandelman Software Works | Internet-Draft Sandelman Software Works | |||
| Intended status: Standards Track P. van der Stok | Intended status: Standards Track P. van der Stok | |||
| Expires: 26 September 2022 vanderstok consultancy | Expires: 16 October 2022 vanderstok consultancy | |||
| P. Kampanakis | P. Kampanakis | |||
| Cisco Systems | Cisco Systems | |||
| 25 March 2022 | 14 April 2022 | |||
| Constrained Join Proxy for Bootstrapping Protocols | Constrained Join Proxy for Bootstrapping Protocols | |||
| draft-ietf-anima-constrained-join-proxy-09 | draft-ietf-anima-constrained-join-proxy-10 | |||
| Abstract | Abstract | |||
| This document extends the work of Bootstrapping Remote Secure Key | ||||
| Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge | ||||
| and Registrar by a stateless/stateful constrained Join Proxy. The | ||||
| constrained Join Proxy is a mesh neighbor of the Pledge and can relay | ||||
| a DTLS session originating from a Pledge with only link-local | ||||
| addresses to a Registrar which is not a mesh neighbor of the Pledge. | ||||
| This document defines a protocol to securely assign a Pledge to a | This document defines a protocol to securely assign a Pledge to a | |||
| domain, represented by a Registrar, using an intermediary node | domain, represented by a Registrar, using an intermediary node | |||
| between Pledge and Registrar. This intermediary node is known as a | between Pledge and Registrar. This intermediary node is known as a | |||
| "constrained Join Proxy". An enrolled Pledge can act as a | "constrained Join Proxy". An enrolled Pledge can act as a | |||
| constrained Join Proxy. | constrained Join Proxy. | |||
| This document extends the work of Bootstrapping Remote Secure Key | ||||
| Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge | ||||
| and Registrar by a stateless/stateful constrained Join Proxy. It | ||||
| relays join traffic from the Pledge to the Registrar. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 26 September 2022. | This Internet-Draft will expire on 16 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 | 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Join Proxy functionality . . . . . . . . . . . . . . . . . . 5 | 4. constrained Join Proxy functionality . . . . . . . . . . . . 5 | |||
| 5. Join Proxy specification . . . . . . . . . . . . . . . . . . 5 | 5. constrained Join Proxy specification . . . . . . . . . . . . 7 | |||
| 5.1. Stateful Join Proxy . . . . . . . . . . . . . . . . . . . 6 | 5.1. Stateful Join Proxy . . . . . . . . . . . . . . . . . . . 7 | |||
| 5.2. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 7 | 5.2. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 8 | |||
| 5.3. Stateless Message structure . . . . . . . . . . . . . . . 9 | 5.3. Stateless Message structure . . . . . . . . . . . . . . . 10 | |||
| 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.1. Join Proxy discovers Registrar . . . . . . . . . . . . . 11 | 6.1. Join Proxy discovers Registrar . . . . . . . . . . . . . 12 | |||
| 6.1.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 12 | 6.1.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 12 | 6.1.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 12 | 6.1.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 13 | |||
| 6.2. Pledge discovers Registrar . . . . . . . . . . . . . . . 12 | 6.2. Pledge discovers Registrar . . . . . . . . . . . . . . . 13 | |||
| 6.2.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 12 | 6.2.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.2.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 13 | 6.2.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.2.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 13 | 6.2.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 14 | |||
| 6.3. Pledge discovers Join Proxy . . . . . . . . . . . . . . . 13 | 6.3. Pledge discovers Join Proxy . . . . . . . . . . . . . . . 14 | |||
| 6.3.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 | 6.3.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.3.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 14 | 6.3.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 15 | |||
| 6.3.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 14 | 6.3.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 15 | |||
| 7. Comparison of stateless and stateful modes . . . . . . . . . 14 | 7. Comparison of stateless and stateful modes . . . . . . . . . 15 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 9.1. Resource Type Attributes registry . . . . . . . . . . . . 15 | 9.1. Resource Type Attributes registry . . . . . . . . . . . . 17 | |||
| 9.2. service name and port number registry . . . . . . . . . . 15 | 9.2. service name and port number registry . . . . . . . . . . 17 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 | 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 12.1. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 16 | 12.1. 10 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 12.2. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 16 | 12.2. 09 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 12.3. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 16 | 12.3. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 12.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12.4. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12.5. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12.6. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12.6. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12.7. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12.7. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12.8. 00 to 00 . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12.8. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12.9. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12.10. 00 to 00 . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . 18 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 | |||
| Appendix A. Stateless Proxy payload examples . . . . . . . . . . 20 | 13.2. Informative References . . . . . . . . . . . . . . . . . 21 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | Appendix A. Stateless Proxy payload examples . . . . . . . . . . 23 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
| 1. Introduction | 1. Introduction | |||
| The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol | The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol | |||
| described in [RFC8995] provides a solution for a secure zero-touch | described in [RFC8995] provides a solution for a secure zero-touch | |||
| (automated) bootstrap of new (unconfigured) devices. In the context | (automated) bootstrap of new (unconfigured) devices. In the context | |||
| of BRSKI, new devices, called "Pledges", are equipped with a factory- | of BRSKI, new devices, called "Pledges", are equipped with a factory- | |||
| installed Initial Device Identifier (IDevID) (see [ieee802-1AR]), and | installed Initial Device Identifier (IDevID) (see [ieee802-1AR]), and | |||
| are enrolled into a network. BRSKI makes use of Enrollment over | are enrolled into a network. BRSKI makes use of Enrollment over | |||
| Secure Transport (EST) [RFC7030] with [RFC8366] vouchers to securely | Secure Transport (EST) [RFC7030] with [RFC8366] vouchers to securely | |||
| enroll devices. A Registrar provides the security anchor of the | enroll devices. A Registrar provides the security anchor of the | |||
| network to which a Pledge enrolls. In this document, BRSKI is | network to which a Pledge enrolls. In this document, BRSKI is | |||
| extended such that a Pledge connects to "Registrars" via a Join | extended such that a Pledge connects to "Registrars" via a | |||
| Proxy. | constrained Join Proxy. In particular, the underlying IP network is | |||
| assumed to be a mesh newtork as described in [RFC4944], although | ||||
| other IP-over-foo networks are not excluded. | ||||
| A complete specification of the terminology is pointed at in | A complete specification of the terminology is pointed at in | |||
| Section 2. | Section 2. | |||
| The specified solutions in [RFC8995] and [RFC7030] are based on POST | The specified solutions in [RFC8995] and [RFC7030] are based on POST | |||
| or GET requests to the EST resources (/cacerts, /simpleenroll, | or GET requests to the EST resources (/cacerts, /simpleenroll, | |||
| /simplereenroll, /serverkeygen, and /csrattrs), and the brski | /simplereenroll, /serverkeygen, and /csrattrs), and the brski | |||
| resources (/requestvoucher, /voucher_status, and /enrollstatus). | resources (/requestvoucher, /voucher_status, and /enrollstatus). | |||
| These requests use https and may be too large in terms of code space | These requests use https and may be too large in terms of code space | |||
| or bandwidth required for constrained devices. Constrained devices | or bandwidth required for constrained devices. Constrained devices | |||
| skipping to change at page 3, line 49 ¶ | skipping to change at page 4, line 7 ¶ | |||
| CoAP can be run with the Datagram Transport Layer Security (DTLS) | CoAP can be run with the Datagram Transport Layer Security (DTLS) | |||
| [RFC6347] as a security protocol for authenticity and confidentiality | [RFC6347] as a security protocol for authenticity and confidentiality | |||
| of the messages. This is known as the "coaps" scheme. A constrained | of the messages. This is known as the "coaps" scheme. A constrained | |||
| version of EST, using Coap and DTLS, is described in | version of EST, using Coap and DTLS, is described in | |||
| [I-D.ietf-ace-coap-est]. The [I-D.ietf-anima-constrained-voucher] | [I-D.ietf-ace-coap-est]. The [I-D.ietf-anima-constrained-voucher] | |||
| extends [I-D.ietf-ace-coap-est] with BRSKI artifacts such as voucher, | extends [I-D.ietf-ace-coap-est] with BRSKI artifacts such as voucher, | |||
| request voucher, and the protocol extensions for constrained Pledges. | request voucher, and the protocol extensions for constrained Pledges. | |||
| DTLS is a client-server protocol relying on the underlying IP layer | DTLS is a client-server protocol relying on the underlying IP layer | |||
| to perform the routing between the DTLS Client and the DTLS Server. | to perform the routing between the DTLS Client and the DTLS Server. | |||
| However, the Pledge will not be IP routable until it is authenticated | However, the Pledge will not be IP routable over the mesh network | |||
| to the network. A new Pledge can only initially use a link-local | until it is authenticated to the mesh network. A new Pledge can only | |||
| IPv6 address to communicate with a neighbor on the same link | initially use a link-local IPv6 address to communicate with a mesh | |||
| [RFC6775] until it receives the necessary network configuration | neighbor [RFC6775] until it receives the necessary network | |||
| parameters. However, before the Pledge can receive these | configuration parameters. The Pledge receives these configuration | |||
| configuration parameters, it needs to authenticate itself to the | parameters from the Registrar. When the Registrar is not a direct | |||
| network to which it connects. | neighbor of the Registrar but several hops away, the Pledge discovers | |||
| a neighbor constrained Join Proxy, which transmits the DTLS protected | ||||
| request coming from the Pledge to the Registrar. The constrained | ||||
| Join Proxy must be enrolled previously such that the message from | ||||
| constrained Join Proxy to Registrar can be routed over one or more | ||||
| hops. | ||||
| During enrollment, a DTLS connection is required between Pledge and | During enrollment, a DTLS connection is required between Pledge and | |||
| Registrar. | Registrar. | |||
| Once a Pledge is enrolled, it can act as Join Proxy between other | Once a Pledge is enrolled, it can act as constrained Join Proxy | |||
| Pledges and the enrolling Registrar. | between other Pledges and the enrolling Registrar. | |||
| This document specifies a new form of Join Proxy and protocol to act | This document specifies a new form of constrained Join Proxy and | |||
| as intermediary between Pledge and Registrar to relay DTLS messages | protocol to act as intermediary between Pledge and Registrar to relay | |||
| between Pledge and Registrar. Two versions of the Join Proxy are | DTLS messages between Pledge and Registrar. Two modes of the | |||
| specified: | constrained Join Proxy are specified: | |||
| 1 A stateful Join Proxy that locally stores IP addresses | 1 A stateful Join Proxy that locally stores IP addresses | |||
| during the connection. | during the connection. | |||
| 2 A stateless Join Proxy that where the connection state | 2 A stateless Join Proxy that where the connection state | |||
| is stored in the messages. | is stored in the messages. | |||
| This document is very much inspired by text published earlier in | This document is very much inspired by text published earlier in | |||
| [I-D.kumar-dice-dtls-relay]. | [I-D.kumar-dice-dtls-relay]. | |||
| [I-D.richardson-anima-state-for-joinrouter] outlined the various | [I-D.richardson-anima-state-for-joinrouter] outlined the various | |||
| options for building a Join Proxy. [RFC8995] adopted only the | options for building a constrained Join Proxy. [RFC8995] adopted | |||
| Circuit Proxy method (1), leaving the other methods as future work. | only the Circuit Proxy method (1), leaving the other methods as | |||
| This document standardizes the CoAP/DTLS (method 4). | future work. | |||
| The stateful and stateless modes differ in the way that they store | ||||
| the state required to forward the return packet to the pledge. | ||||
| Similar to the difference between storing and non_storing Modes of | ||||
| Operations (MOP) in RPL [RFC6550]. In the stateful method, the | ||||
| return forward state is stored in the join proxy. In the stateless | ||||
| method, the return forward state is stored in the network. | ||||
| 2. Terminology | 2. Terminology | |||
| The following terms are defined in [RFC8366], and are used | The following terms are defined in [RFC8366], and are used | |||
| identically as in that document: artifact, imprint, domain, Join | identically as in that document: artifact, imprint, domain, Join | |||
| Registrar/Coordinator (JRC), Manufacturer Authorized Signing | Registrar/Coordinator (JRC), Pledge, and Voucher. | |||
| Authority (MASA), Pledge, Trust of First Use (TOFU), and Voucher. | ||||
| In this document, the term "Registrar" is used throughout instead of | ||||
| "Join Registrar/Coordinator (JRC)". | ||||
| The term "installation network" refers to all devices in the | The term "installation network" refers to all devices in the | |||
| installation and the network connections between them. The term | installation and the network connections between them. The term | |||
| "installation IP_address" refers to an address out of the set of | "installation IP_address" refers to an address out of the set of | |||
| addresses which are routable over the whole installation network. | addresses which are routable over the whole installation network. | |||
| The "Constrained Join Proxy" enables a pledge that is multiple hops | ||||
| away from the Registrar, to securely execute the BRSKI protocol | ||||
| [RFC8995] over a secure channel. | ||||
| The term "join Proxy" is used interchangeably with the term | ||||
| "constrained Join Proxy" throughout this document. | ||||
| 3. Requirements Language | 3. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 4. Join Proxy functionality | 4. constrained Join Proxy functionality | |||
| As depicted in the Figure 1, the Pledge (P), in a Low-Power and Lossy | As depicted in the Figure 1, the Pledge (P), in a Low-Power and Lossy | |||
| Network (LLN) mesh [RFC7102] can be more than one hop away from the | Network (LLN) mesh [RFC7102] can be more than one hop away from the | |||
| Registrar (R) and not yet authenticated into the network. | Registrar (R) and not yet authenticated into the network. | |||
| In this situation, the Pledge can only communicate one-hop to its | In this situation, the Pledge can only communicate one-hop to its | |||
| nearest neighbor, the Join Proxy (J) using their link-local IPv6 | nearest neighbor, the constrained Join Proxy (J) using their link- | |||
| addresses. However, the Pledge (P) needs to communicate with end-to- | local IPv6 addresses. However, the Pledge (P) needs to communicate | |||
| end security with a Registrar to authenticate and get the relevant | with end-to-end security with a Registrar to authenticate and get the | |||
| system/network parameters. If the Pledge (P), knowing the IP-address | relevant system/network parameters. If the Pledge (P), knowing the | |||
| of the Registrar, initiates a DTLS connection to the Registrar, then | IP-address of the Registrar, initiates a DTLS connection to the | |||
| the packets are dropped at the Join Proxy (J) since the Pledge (P) is | Registrar, then the packets are dropped at the constrained Join Proxy | |||
| not yet admitted to the network or there is no IP routability to | (J) since the Pledge (P) is not yet admitted to the network or there | |||
| Pledge (P) for any returned messages from the Registrar. | is no IP routability to Pledge (P) for any returned messages from the | |||
| Registrar. | ||||
| ++++ multi-hop | ++++ multi-hop | |||
| |R |---- mesh +--+ +--+ | |R |---- mesh +--+ +--+ | |||
| | | \ |J |........|P | | | | \ |J |........|P | | |||
| ++++ \-----| | | | | ++++ \-----| | | | | |||
| +--+ +--+ | +--+ +--+ | |||
| Registrar Join Proxy Pledge | Registrar Join Proxy Pledge | |||
| Figure 1: multi-hop enrollment. | Figure 1: multi-hop enrollment. | |||
| Without routing the Pledge (P) cannot establish a secure connection | Without routing the Pledge (P) cannot establish a secure connection | |||
| to the Registrar (R) over multiple hops in the network. | to the Registrar (R) over multiple hops in the network. | |||
| Furthermore, the Pledge (P) cannot discover the IP address of the | Furthermore, the Pledge (P) cannot discover the IP address of the | |||
| Registrar (R) over multiple hops to initiate a DTLS connection and | Registrar (R) over multiple hops to initiate a DTLS connection and | |||
| perform authentication. | perform authentication. | |||
| To overcome the problems with non-routability of DTLS packets and/or | To overcome the problems with non-routability of DTLS packets and/or | |||
| discovery of the destination address of the Registrar, the Join Proxy | discovery of the destination address of the Registrar, the | |||
| is introduced. This Join Proxy functionality is configured into all | constrained Join Proxy is introduced. This constrained Join Proxy | |||
| authenticated devices in the network which may act as a Join Proxy | functionality is configured into all authenticated devices in the | |||
| for Pledges. The Join Proxy allows for routing of the packets from | network which may act as a constrained Join Proxy for Pledges. The | |||
| the Pledge using IP routing to the intended Registrar. An | constrained Join Proxy allows for routing of the packets from the | |||
| authenticated Join Proxy can discover the routable IP address of the | Pledge using IP routing to the intended Registrar. An authenticated | |||
| constrained Join Proxy can discover the routable IP address of the | ||||
| Registrar over multiple hops. The following Section 5 specifies the | Registrar over multiple hops. The following Section 5 specifies the | |||
| two Join Proxy modes. A comparison is presented in Section 7. | two constrained Join Proxy modes. A comparison is presented in | |||
| Section 7. | ||||
| 5. Join Proxy specification | When a mesh network is set up, it consists of a Registrar and a set | |||
| of connected pledges. No constrained Join Proxies are present. The | ||||
| wanted end-state is a network with a Registrar and a set of enrolled | ||||
| devices. Some of these enrolled devices can act as constrained Join | ||||
| Proxies. Pledges can only employ link-local communication untill | ||||
| they are enrolled. A Pledge will regularly try to discover a | ||||
| constrained Join Proxy or a Registrar with link-local discovery | ||||
| requests. The Pledges which are neigbors of the Registrar will | ||||
| discover the Registrar and be enrolled following the BRSKI protocol. | ||||
| An enrolled device can act as constrained Join Proxy. The Pledges | ||||
| which are not a neighbor of the Registrar will eventually discover a | ||||
| constrained Join Proxy and follow the BRSKI protocol to be enrolled. | ||||
| While this goes on, more and more constrained Join Proxies with a | ||||
| larger hop distance to the Registrar will emerge. The network should | ||||
| be configured such that at the end of the enrollment process, all | ||||
| pledges have discovered a neigboring constrained Join Proxy or the | ||||
| Registrar, and all "legal" Pledges are enrolled. | ||||
| 5. constrained Join Proxy specification | ||||
| A Join Proxy can operate in two modes: | A Join Proxy can operate in two modes: | |||
| * Stateful mode | * Stateful mode | |||
| * Stateless mode | * Stateless mode | |||
| A Join Proxy MUST implement one of the two modes. A Join Proxy MAY | A Join Proxy MAY implement both. A mechanism to switch between modes | |||
| implement both, with an unspecified mechanism to switch between the | is out of scope of this document. It is recommended that a Join | |||
| two modes. | Proxy uses only one of these modes at any given moment during an | |||
| installation lifetime. | ||||
| 5.1. Stateful Join Proxy | 5.1. Stateful Join Proxy | |||
| In stateful mode, the Join Proxy forwards the DTLS messages to the | In stateful mode, the Join Proxy forwards the DTLS messages to the | |||
| Registrar. | Registrar. | |||
| Assume that the Pledge does not know the IP address of the Registrar | Assume that the Pledge does not know the IP address of the Registrar | |||
| it needs to contact. The Join Proxy has been enrolled via the | it needs to contact. The Join Proxy has been enrolled via the | |||
| Registrar and learns the IP address and port of the Registrar, for | Registrar and learns the IP address and port of the Registrar, for | |||
| example by using the discovery mechanism described in Section 6. The | example by using the discovery mechanism described in Section 6. The | |||
| Pledge first discovers (see Section 6) and selects the most | Pledge first discovers (see Section 6) and selects the most | |||
| appropriate Join Proxy. (Discovery can also be based upon [RFC8995] | appropriate Join Proxy. (Discovery can also be based upon [RFC8995] | |||
| section 4.1). For service discovery via DNS-SD [RFC6763], this | section 4.1). For service discovery via DNS-SD [RFC6763], this | |||
| document specifies the service names in Section 9.2. The Pledge | document specifies the service names in Section 9.2. The Pledge | |||
| initiates its request as if the Join Proxy is the intended Registrar. | initiates its request as if the Join Proxy is the intended Registrar. | |||
| The Join Proxy receives the message at a discoverable join-port. The | The Join Proxy receives the message at a discoverable join-port. The | |||
| Join Proxy constructs an IP packet by copying the DTLS payload from | Join Proxy constructs an IP packet by copying the DTLS payload from | |||
| the message received from the Pledge, and provides source and | the message received from the Pledge, and provides source and | |||
| destination addresses to forward the message to the intended | destination addresses to forward the message to the intended | |||
| Registrar. The Join Proxy maintains a 4-tuple array to translate the | Registrar. The Join Proxy stores the 4-tuple array of the messages | |||
| DTLS messages received from the Registrar and forwards it back to the | received from the Registrar and copies it back to the header of the | |||
| Pledge. | message returned to the Pledge. | |||
| In Figure 2 the various steps of the message flow are shown, with | In Figure 2 the various steps of the message flow are shown, with | |||
| 5684 being the standard coaps port: | 5684 being the standard coaps port: | |||
| +------------+------------+-------------+--------------------------+ | +------------+------------+-------------+--------------------------+ | |||
| | Pledge | Join Proxy | Registrar | Message | | | Pledge | Join Proxy | Registrar | Message | | |||
| | (P) | (J) | (R) | Src_IP:port | Dst_IP:port| | | (P) | (J) | (R) | Src_IP:port | Dst_IP:port| | |||
| +------------+------------+-------------+-------------+------------+ | +------------+------------+-------------+-------------+------------+ | |||
| | --ClientHello--> | IP_P:p_P | IP_Jl:p_Jl | | | --ClientHello--> | IP_P:p_P | IP_Jl:p_Jl | | |||
| | --ClientHello--> | IP_Jr:p_Jr| IP_R:5684 | | | --ClientHello--> | IP_Jr:p_Jr| IP_R:5684 | | |||
| skipping to change at page 10, line 36 ¶ | skipping to change at page 11, line 36 ¶ | |||
| On reception by the Registrar, the Registrar MUST verify that the | On reception by the Registrar, the Registrar MUST verify that the | |||
| number of array elements is larger than or equal to 5, and reject the | number of array elements is larger than or equal to 5, and reject the | |||
| message when the number of array elements is smaller than 5. After | message when the number of array elements is smaller than 5. After | |||
| replacing the 5th "content" element with the DTLS payload of the | replacing the 5th "content" element with the DTLS payload of the | |||
| response message and leaving all other array elements unchanged, the | response message and leaving all other array elements unchanged, the | |||
| Registrar returns the response message. | Registrar returns the response message. | |||
| Examples are shown in Appendix A. | Examples are shown in Appendix A. | |||
| When additions are added to the array in later versions of this | The header field is completely opaque to the receiver. A Registrar | |||
| protocol, any additional array elements (i.e., not specified by | MUST copy the header and return it unmodified in the return message. | |||
| current document) MUST be ignored by a receiver if it doesn't know | ||||
| these elements. This approach allows evolution of the protocol while | ||||
| maintaining backwards-compatibility. A version number isn't needed; | ||||
| that number is defined by the length of the array. However, this | ||||
| means that message elements are consistently added to earlier defined | ||||
| elements to avoid ambiguities. | ||||
| 6. Discovery | 6. Discovery | |||
| It is assumed that Join Proxy seamlessly provides a coaps connection | It is assumed that Join Proxy seamlessly provides a coaps connection | |||
| between Pledge and Registrar. In particular this section extends | between Pledge and Registrar. In particular this section extends | |||
| section 4.1 of [RFC8995] for the constrained case. | section 4.1 of [RFC8995] for the constrained case. | |||
| The discovery follows two steps with two alternatives for step 1: | The discovery follows two steps with two alternatives for step 1: | |||
| * Step 1. Two alternatives exist (near and remote): | * Step 1. Two alternatives exist (near and remote): | |||
| skipping to change at page 11, line 23 ¶ | skipping to change at page 12, line 21 ¶ | |||
| - Remote: the Pledge is more than one hop away from a relevant | - Remote: the Pledge is more than one hop away from a relevant | |||
| Registrar, and discovers the link-local address and join-port | Registrar, and discovers the link-local address and join-port | |||
| of a Join Proxy. The Pledge then follows the BRSKI procedure | of a Join Proxy. The Pledge then follows the BRSKI procedure | |||
| using the link-local address of the Join Proxy. | using the link-local address of the Join Proxy. | |||
| * Step 2. The enrolled Join Proxy discovers the join-port of the | * Step 2. The enrolled Join Proxy discovers the join-port of the | |||
| Registrar. | Registrar. | |||
| The order in which the two alternatives of step 1 are tried is | The order in which the two alternatives of step 1 are tried is | |||
| installation dependent. The trigger for discovery in Step 2 in | installation dependent. The trigger for discovery in Step 2 is | |||
| implementation dependent. | implementation dependent. | |||
| Once a Pledge is enrolled, it may function as Join Proxy. The Join | Once a Pledge is enrolled, it may function as Join Proxy. The Join | |||
| Proxy functions are advertised as described below. In principle, the | Proxy functions are advertised as described below. In principle, the | |||
| Join Proxy functions are offered via a join-port, and not the | Join Proxy functions are offered via a join-port, and not the | |||
| standard coaps port. Also, the Registrar offers a join-port to which | standard coaps port. Also, the Registrar offers a join-port to which | |||
| the stateless Join Proxy sends the JPY message. The Join Proxy and | the stateless Join Proxy sends the JPY message. The Join Proxy and | |||
| Registrar show the extra join-port number when responding to a | Registrar show the extra join-port number when responding to a | |||
| /.well-known/core discovery request addressed to the standard coap/ | /.well-known/core discovery request addressed to the standard coap/ | |||
| coaps port. | coaps port. | |||
| Three discovery cases are discussed: Join Proxy discovers Registrar, | Three discovery cases are discussed: Join Proxy discovers Registrar, | |||
| Pledge discovers Registrar, and Pledge discovers Join Proxy. Each | Pledge discovers Registrar, and Pledge discovers Join Proxy. Each | |||
| discovery case considers three alternatives: CoAP based discovery, | discovery case considers three alternatives: CoAP based discovery, | |||
| GRASP Based discovery, and 6tisch based discovery. The choice of | GRASP Based discovery, and 6tisch based discovery. The choice of | |||
| discovery mechanism depends on the type of installation, and | discovery mechanism depends on the type of installation, and | |||
| manufacturers can provide the pledge/join-proxy with support for more | manufacturers can provide the pledge/Join Proxy with support for more | |||
| than one discovery mechanism. The pledge/join-proxy can be designed | than one discovery mechanism. The pledge/Join Proxy can be designed | |||
| to dynamically try different discovery mechanisms until a successful | to dynamically try different discovery mechanisms until a successful | |||
| discovery mechanism is found, or the choice of discovery mechanism | discovery mechanism is found, or the choice of discovery mechanism | |||
| could be configured during device installation. | could be configured during device installation. | |||
| 6.1. Join Proxy discovers Registrar | 6.1. Join Proxy discovers Registrar | |||
| In this section, the Join Proxy and Registrar are assumed to | In this section, the Join Proxy and Registrar are assumed to | |||
| communicate via Link-Local addresses. This section describes the | communicate via Link-Local addresses. This section describes the | |||
| discovery of the Registrar by the Join Proxy. | discovery of the Registrar by the Join Proxy. | |||
| skipping to change at page 15, line 13 ¶ | skipping to change at page 16, line 13 ¶ | |||
| Figure 5: Comparison between stateful and stateless mode | Figure 5: Comparison between stateful and stateless mode | |||
| 8. Security Considerations | 8. Security Considerations | |||
| All the concerns in [RFC8995] section 4.1 apply. The Pledge can be | All the concerns in [RFC8995] section 4.1 apply. The Pledge can be | |||
| deceived by malicious Join Proxy announcements. The Pledge will only | deceived by malicious Join Proxy announcements. The Pledge will only | |||
| join a network to which it receives a valid [RFC8366] voucher | join a network to which it receives a valid [RFC8366] voucher | |||
| [I-D.ietf-anima-constrained-voucher]. Once the Pledge joined, the | [I-D.ietf-anima-constrained-voucher]. Once the Pledge joined, the | |||
| payload between Pledge and Registrar is protected by DTLS. | payload between Pledge and Registrar is protected by DTLS. | |||
| It should be noted here that the contents of the CBOR map used to | A malicious constrained Join Proxy has a number of routing | |||
| possibilities: | ||||
| * It sends the message on to a malicious Registrar. This is the | ||||
| same case as the presence of a malicious Registrar discussed in | ||||
| RFC 8995. | ||||
| * It does not send on the request or does not return the response | ||||
| from the Registrar. This is the case of the not responding or | ||||
| crashing Registrar discussed in RFC 8995. | ||||
| * It uses the returned response of the Registrar to enroll itself in | ||||
| the network. With very low probability it can decrypt the | ||||
| response. Successful enrollment is deemed too unlikely. | ||||
| * It uses the request from the pledge to appropriate the pledge | ||||
| certificate, but then it still needs to acquire the private key of | ||||
| the pledge. Also this is assumed to be highly unlikely. | ||||
| * A malicious node can construct an invalid Join Proxy message. | ||||
| Suppose, the destination port is the coaps port. In that case, a | ||||
| Join Proxy can accept the message and add the routing addresses | ||||
| without checking the payload. The Join Proxy then routes it to | ||||
| the Registrar. In all cases, the Registrar needs to receive the | ||||
| message at the join-port, checks that the message consists of two | ||||
| parts and uses the DTLS payload to start the BRSKI procedure. It | ||||
| is highly unlikely that this malicious payload will lead to node | ||||
| acceptance. | ||||
| * A malicious node can sniff the messages routed by the constrained | ||||
| Join Proxy. It is very unlikely that the malicious node can | ||||
| decrypt the DTLS payload. A malicious node can read the header | ||||
| field of the message sent by the stateless Join Proxy. This | ||||
| ability does not yield much more information than the visible | ||||
| addresses transported in the network packets. | ||||
| It should be noted here that the contents of the CBOR array used to | ||||
| convey return address information is not DTLS protected. When the | convey return address information is not DTLS protected. When the | |||
| communication between JOIN Proxy and Registrar passes over an | communication between JOIN Proxy and Registrar passes over an | |||
| unsecure network, an attacker can change the CBOR array, causing the | unsecure network, an attacker can change the CBOR array, causing the | |||
| Registrar to deviate traffic from the intended Pledge. If such | Registrar to deviate traffic from the intended Pledge. These | |||
| scenario needs to be avoided, then it is reasonable for the Join | concerns are also expressed in [RFC8974]. It is also pointed out | |||
| Proxy to encrypt the CBOR array using a locally generated symmetric | that the encryption in the source is a local matter. Similarly to | |||
| key. The Registrar would not be able to examine the result, but it | [RFC8974], the use of AES-CCM [RFC3610] with a 64-bit tag is | |||
| does not need to do so. This is a topic for future work. | recommended, combined with a sequence number and a replay window. | |||
| In some installations, level 2 protection is provided between all | If such scenario needs to be avoided, the constrained Join Proxy MUST | |||
| encrypt the CBOR array using a locally generated symmetric key. The | ||||
| Registrar is not able to examine the encrypted result, but does not | ||||
| need to. The Registrar stores the encrypted header in the return | ||||
| packet without modifications. The constrained Join Proxy can decrypt | ||||
| the contents to route the message to the right destination. | ||||
| In some installations, layer 2 protection is provided between all | ||||
| member pairs of the mesh. In such an enviroment encryption of the | member pairs of the mesh. In such an enviroment encryption of the | |||
| CBOR array is unnecessay because the level 2 protection already | CBOR array is unnecessay because the layer 2 protection already | |||
| provide it. | provide it. | |||
| 9. IANA Considerations | 9. IANA Considerations | |||
| 9.1. Resource Type Attributes registry | 9.1. Resource Type Attributes registry | |||
| This specification registers two new Resource Type (rt=) Link Target | This specification registers two new Resource Type (rt=) Link Target | |||
| Attributes in the "Resource Type (rt=) Link Target Attribute Values" | Attributes in the "Resource Type (rt=) Link Target Attribute Values" | |||
| subregistry under the "Constrained RESTful Environments (CoRE) | subregistry under the "Constrained RESTful Environments (CoRE) | |||
| Parameters" registry per the [RFC6690] procedure. | Parameters" registry per the [RFC6690] procedure. | |||
| Attribute Value: brski.jp | Attribute Value: brski.jp | |||
| Description: This BRSKI resource type is used to query and return the | Description: This BRSKI resource type is used to query and return | |||
| supported BRSKI (CoAP over DTLS) port of the constrained | the supported BRSKI resources of the constrained | |||
| Join Proxy. | Join Proxy. | |||
| Reference: [this document] | Reference: [this document] | |||
| Attribute Value: brski.rjp | Attribute Value: brski.rjp | |||
| Description: This BRSKI resource type is used to query and return the | Description: This BRSKI resource type is used for the constrained | |||
| supported BRSKI JPY protocol port of the Registrar. | Join Proxy to query and return Join Proxy specific | |||
| BRSKI resources of a Registrar. | ||||
| Reference: [this document] | Reference: [this document] | |||
| 9.2. service name and port number registry | 9.2. service name and port number registry | |||
| This specification registers two service names under the "Service | This specification registers two service names under the "Service | |||
| Name and Transport Protocol Port Number" registry. | Name and Transport Protocol Port Number" registry. | |||
| Service Name: brski-jp | Service Name: brski-jp | |||
| Transport Protocol(s): udp | Transport Protocol(s): udp | |||
| Assignee: IESG <iesg@ietf.org> | Assignee: IESG <iesg@ietf.org> | |||
| skipping to change at page 16, line 24 ¶ | skipping to change at page 18, line 24 ¶ | |||
| Transport Protocol(s): udp | Transport Protocol(s): udp | |||
| Assignee: IESG <iesg@ietf.org> | Assignee: IESG <iesg@ietf.org> | |||
| Contact: IESG <iesg@ietf.org> | Contact: IESG <iesg@ietf.org> | |||
| Description: Bootstrapping Remote Secure Key Infrastructure | Description: Bootstrapping Remote Secure Key Infrastructure | |||
| Registrar join-port used by stateless constrained | Registrar join-port used by stateless constrained | |||
| Join Proxy | Join Proxy | |||
| Reference: [this document] | Reference: [this document] | |||
| 10. Acknowledgements | 10. Acknowledgements | |||
| Many thanks for the comments by Brian Carpenter, Esko Dijk, Russ | Many thanks for the comments by Cartsen, Bormann, Brian Carpenter, | |||
| Housley, and Rob Wilton. | Esko Dijk, Toerless Eckert, Russ Housley, Ines Robles, Juergen | |||
| Schoenwaelder, Malisa Vučinić, and Rob Wilton. | ||||
| 11. Contributors | 11. Contributors | |||
| Sandeep Kumar, Sye loong Keoh, and Oscar Garcia-Morchon are the co- | Sandeep Kumar, Sye loong Keoh, and Oscar Garcia-Morchon are the co- | |||
| authors of the draft-kumar-dice-dtls-relay-02. Their draft has | authors of the draft-kumar-dice-dtls-relay-02. Their draft has | |||
| served as a basis for this document. Much text from their draft is | served as a basis for this document. Much text from their draft is | |||
| copied over to this draft. | copied over to this draft. | |||
| 12. Changelog | 12. Changelog | |||
| 12.1. 06 to 07 | 12.1. 10 to 09 | |||
| * OPSDIR review | ||||
| * IANA review | ||||
| * SECDIR review | ||||
| * GENART review | ||||
| 12.2. 09 to 07 | ||||
| * typos | ||||
| 12.3. 06 to 07 | ||||
| * AD review changes | * AD review changes | |||
| 12.2. 05 to 06 | 12.4. 05 to 06 | |||
| * RT value change to brski.jp and brski.rjp | * RT value change to brski.jp and brski.rjp | |||
| * new registry values for IANA | * new registry values for IANA | |||
| * improved handling of jpy header array | * improved handling of jpy header array | |||
| 12.3. 04 to 05 | 12.5. 04 to 05 | |||
| * Join Proxy and join-port consistent spelling | * Join Proxy and join-port consistent spelling | |||
| * some nits removed | * some nits removed | |||
| * restructured discovery | * restructured discovery | |||
| * section | * section | |||
| * rephrased parts of security section | * rephrased parts of security section | |||
| 12.4. 03 to 04 | 12.6. 03 to 04 | |||
| * mail address and reference | * mail address and reference | |||
| 12.5. 02 to 03 | 12.7. 02 to 03 | |||
| * Terminology updated | * Terminology updated | |||
| * Several clarifications on discovery and routability | * Several clarifications on discovery and routability | |||
| * DTLS payload introduced | * DTLS payload introduced | |||
| 12.6. 01 to 02 | 12.8. 01 to 02 | |||
| * Discovery of Join Proxy and Registrar ports | * Discovery of Join Proxy and Registrar ports | |||
| 12.7. 00 to 01 | 12.9. 00 to 01 | |||
| * Registrar used throughout instead of EST server | * Registrar used throughout instead of EST server | |||
| * Emphasized additional Join Proxy port for Join Proxy and Registrar | * Emphasized additional Join Proxy port for Join Proxy and Registrar | |||
| * updated discovery accordingly | * updated discovery accordingly | |||
| * updated stateless Join Proxy JPY header | * updated stateless Join Proxy JPY header | |||
| * JPY header described with CDDL | * JPY header described with CDDL | |||
| * Example simplified and corrected | * Example simplified and corrected | |||
| 12.8. 00 to 00 | 12.10. 00 to 00 | |||
| * copied from vanderstok-anima-constrained-join-proxy-05 | * copied from vanderstok-anima-constrained-join-proxy-05 | |||
| 13. References | 13. References | |||
| 13.1. Normative References | 13.1. Normative References | |||
| [family] "Address Family Numbers", 19 October 2021, | [family] "Address Family Numbers", 19 October 2021, | |||
| <https://www.iana.org/assignments/address-family-numbers/ | <https://www.iana.org/assignments/address-family-numbers/ | |||
| address-family-numbers.xhtml>. | address-family-numbers.xhtml>. | |||
| [I-D.ietf-ace-coap-est] | [I-D.ietf-ace-coap-est] | |||
| Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. | Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. | |||
| Raza, "EST over secure CoAP (EST-coaps)", Work in | Raza, "EST over secure CoAP (EST-coaps)", Work in | |||
| Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 | Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 | |||
| January 2020, <https://www.ietf.org/archive/id/draft-ietf- | January 2020, <https://www.ietf.org/archive/id/draft-ietf- | |||
| ace-coap-est-18.txt>. | ace-coap-est-18.txt>. | |||
| [I-D.ietf-anima-constrained-voucher] | [I-D.ietf-anima-constrained-voucher] | |||
| Richardson, M., Stok, P. V. D., Kampanakis, P., and E. | Richardson, M., Stok, P. V. D., Kampanakis, P., and E. | |||
| Dijk, "Constrained Bootstrapping Remote Secure Key | Dijk, "Constrained Bootstrapping Remote Secure Key | |||
| Infrastructure (BRSKI)", Work in Progress, Internet-Draft, | Infrastructure (BRSKI)", Work in Progress, Internet-Draft, | |||
| draft-ietf-anima-constrained-voucher-16, 14 February 2022, | draft-ietf-anima-constrained-voucher-17, 7 April 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-anima- | <https://www.ietf.org/archive/id/draft-ietf-anima- | |||
| constrained-voucher-16.txt>. | constrained-voucher-17.txt>. | |||
| [ieee802-1AR] | [ieee802-1AR] | |||
| "IEEE 802.1AR Secure Device Identifier", 2009, | "IEEE 802.1AR Secure Device Identifier", 2009, | |||
| <https://standards.ieee.org/standard/802.1AR-2009.html>. | <https://standards.ieee.org/standard/802.1AR-2009.html>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| skipping to change at page 19, line 28 ¶ | skipping to change at page 21, line 40 ¶ | |||
| dtls-relay-02.txt>. | dtls-relay-02.txt>. | |||
| [I-D.richardson-anima-state-for-joinrouter] | [I-D.richardson-anima-state-for-joinrouter] | |||
| Richardson, M. C., "Considerations for stateful vs | Richardson, M. C., "Considerations for stateful vs | |||
| stateless join router in ANIMA bootstrap", Work in | stateless join router in ANIMA bootstrap", Work in | |||
| Progress, Internet-Draft, draft-richardson-anima-state- | Progress, Internet-Draft, draft-richardson-anima-state- | |||
| for-joinrouter-03, 22 September 2020, | for-joinrouter-03, 22 September 2020, | |||
| <https://www.ietf.org/archive/id/draft-richardson-anima- | <https://www.ietf.org/archive/id/draft-richardson-anima- | |||
| state-for-joinrouter-03.txt>. | state-for-joinrouter-03.txt>. | |||
| [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with | ||||
| CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September | ||||
| 2003, <https://www.rfc-editor.org/info/rfc3610>. | ||||
| [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | |||
| "Transmission of IPv6 Packets over IEEE 802.15.4 | "Transmission of IPv6 Packets over IEEE 802.15.4 | |||
| Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | |||
| <https://www.rfc-editor.org/info/rfc4944>. | <https://www.rfc-editor.org/info/rfc4944>. | |||
| [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., | ||||
| Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, | ||||
| JP., and R. Alexander, "RPL: IPv6 Routing Protocol for | ||||
| Low-Power and Lossy Networks", RFC 6550, | ||||
| DOI 10.17487/RFC6550, March 2012, | ||||
| <https://www.rfc-editor.org/info/rfc6550>. | ||||
| [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | |||
| Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | |||
| <https://www.rfc-editor.org/info/rfc6690>. | <https://www.rfc-editor.org/info/rfc6690>. | |||
| [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service | [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service | |||
| Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, | Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, | |||
| <https://www.rfc-editor.org/info/rfc6763>. | <https://www.rfc-editor.org/info/rfc6763>. | |||
| [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | |||
| Bormann, "Neighbor Discovery Optimization for IPv6 over | Bormann, "Neighbor Discovery Optimization for IPv6 over | |||
| skipping to change at page 20, line 19 ¶ | skipping to change at page 22, line 45 ¶ | |||
| [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | |||
| Constrained-Node Networks", RFC 7228, | Constrained-Node Networks", RFC 7228, | |||
| DOI 10.17487/RFC7228, May 2014, | DOI 10.17487/RFC7228, May 2014, | |||
| <https://www.rfc-editor.org/info/rfc7228>. | <https://www.rfc-editor.org/info/rfc7228>. | |||
| [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
| Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
| DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
| <https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
| [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and | ||||
| Stateless Clients in the Constrained Application Protocol | ||||
| (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, | ||||
| <https://www.rfc-editor.org/info/rfc8974>. | ||||
| Appendix A. Stateless Proxy payload examples | Appendix A. Stateless Proxy payload examples | |||
| The examples show the request "GET coaps://192.168.1.200:5965/est/ | The examples show the request "GET coaps://192.168.1.200:5965/est/ | |||
| crts" to a Registrar. The header generated between Join Proxy and | crts" to a Registrar. The header generated between Join Proxy and | |||
| Registrar and from Registrar to Join Proxy are shown in detail. The | Registrar and from Registrar to Join Proxy are shown in detail. The | |||
| DTLS payload is not shown. | DTLS payload is not shown. | |||
| The request from Join Proxy to Registrar looks like: | The request from Join Proxy to Registrar looks like: | |||
| 85 # array(5) | 85 # array(5) | |||
| End of changes. 46 change blocks. | ||||
| 130 lines changed or deleted | 244 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||