idnits 2.17.1 draft-ietf-anima-constrained-join-proxy-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8995]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2021) is 920 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-13 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track P. van der Stok 5 Expires: April 21, 2022 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 October 18, 2021 10 Constrained Join Proxy for Bootstrapping Protocols 11 draft-ietf-anima-constrained-join-proxy-05 13 Abstract 15 This document defines a protocol to securely assign a Pledge to a 16 domain, represented by a Registrar, using an intermediary node 17 between Pledge and Registrar. This intermediary node is known as a 18 "constrained Join Proxy". 20 This document extends the work of [RFC8995] by replacing the Circuit- 21 proxy between Pledge and Registrar by a stateless/stateful 22 constrained (CoAP) Join Proxy. It relays join traffic from the 23 Pledge to the Registrar. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 4. Join Proxy functionality . . . . . . . . . . . . . . . . . . 4 63 5. Join Proxy specification . . . . . . . . . . . . . . . . . . 5 64 5.1. Statefull Join Proxy . . . . . . . . . . . . . . . . . . 5 65 5.2. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 7 66 5.3. Stateless Message structure . . . . . . . . . . . . . . . 8 67 6. Comparison of stateless and statefull modes . . . . . . . . . 9 68 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Join Proxy discovers Registrar . . . . . . . . . . . . . 11 70 7.1.1. CoAP discovery{#coap-disc} . . . . . . . . . . . . . 11 71 7.1.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 12 72 7.1.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 12 73 7.2. Pledge discovers Registrar . . . . . . . . . . . . . . . 12 74 7.2.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 12 75 7.2.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 12 76 7.2.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 13 77 7.3. Pledge discovers Join Proxy . . . . . . . . . . . . . . . 13 78 7.3.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 79 7.3.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 13 80 7.3.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 14 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. Resource Type registry . . . . . . . . . . . . . . . . . 14 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 86 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 12.1. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 15 88 12.2. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 15 89 12.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 15 90 12.4. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 15 91 12.5. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 15 92 12.6. 00 to 00 . . . . . . . . . . . . . . . . . . . . . . . . 16 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 13.2. Informative References . . . . . . . . . . . . . . . . . 17 96 Appendix A. Stateless Proxy payload examples . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 Enrolment of new nodes into networks with enrolled nodes present is 102 described in [RFC8995] ("BRSKI") and makes use of Enrolment over 103 Secure Transport (EST) [RFC7030] with [RFC8366] vouchers to securely 104 enroll devices. BRSKI connects a new joining device (called Pledge) 105 to "Registrars" via a Join Proxy. 107 The specified solutions use https and may be too large in terms of 108 code space or bandwidth required for constrained devices. 109 Constrained devices possibly part of constrained networks [RFC7228] 110 typically implement the IPv6 over Low-Power Wireless personal Area 111 Networks (6LoWPAN) [RFC4944] and Constrained Application Protocol 112 (CoAP) [RFC7252]. 114 CoAP can be run with the Datagram Transport Layer Security (DTLS) 115 [RFC6347] as a security protocol for authenticity and confidentiality 116 of the messages. This is known as the "coaps" scheme. A constrained 117 version of EST, using Coap and DTLS, is described in 118 [I-D.ietf-ace-coap-est]. The [I-D.ietf-anima-constrained-voucher] 119 extends [I-D.ietf-ace-coap-est] with BRSKI artefacts such as voucher, 120 request voucher, and the protocol extensions for constrained Pledges. 122 DTLS is a client-server protocol relying on the underlying IP layer 123 to perform the routing between the DTLS Client and the DTLS Server. 124 However, the new Pledge will not be IP routable until it is 125 authenticated to the network. A new Pledge can only initially use a 126 link-local IPv6 address to communicate with a neighbour on the same 127 link [RFC6775] until it receives the necessary network configuration 128 parameters. However, before the Pledge can receive these 129 configuration parameters, it needs to authenticate itself to the 130 network to which it connects. 132 During enrollment, a DTLS connection is required between Pledge and 133 Registrar. 135 This document specifies a new form of Join Proxy and protocol to act 136 as intermediary between Pledge and Registrar to relay DTLS messages 137 between Pledge and Registrar. Two versions of the Join Proxy are 138 specified: 140 1 A stateful Join Proxy that locally stores IP addresses 141 during the connection. 142 2 A stateless Join Proxy that where the connection state 143 is stored in the messages. 145 This document is very much inspired by text published earlier in 146 [I-D.kumar-dice-dtls-relay]. 147 [I-D.richardson-anima-state-for-joinrouter] outlined the various 148 options for building a Join Proxy. [RFC8995] adopted only the 149 Circuit Proxy method (1), leaving the other methods as future work. 150 This document standardizes the CoAP/DTLS (method 4). 152 2. Terminology 154 The following terms are defined in [RFC8366], and are used 155 identically as in that document: artifact, imprint, domain, Join 156 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 157 Authority (MASA), Pledge, Trust of First Use (TOFU), and Voucher. 159 The term "installation network" refers to all devices in the 160 installation and the network connections between them. The term 161 "installation IP_address" refers to the set of adresses which are 162 routable over the whole installation network. 164 3. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in 169 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 4. Join Proxy functionality 174 As depicted in the Figure 1, the Pledge (P), in an LLN mesh can be 175 more than one hop away from the Registrar (R) and not yet 176 authenticated into the network. 178 In this situation, the Pledge can only communicate one-hop to its 179 nearest neighbour, the Join Proxy (J) using their link-local IPv6 180 addresses. However, the Pledge (P) needs to communicate with end-to- 181 end security with a Registrar to authenticate and get the relevant 182 system/network parameters. If the Pledge (P), knowing the IP-address 183 of the Registrar, initiates a DTLS connection to the Registrar, then 184 the packets are dropped at the Join Proxy (J) since the Pledge (P) is 185 not yet admitted to the network or there is no IP routability to 186 Pledge (P) for any returned messages from the Registrar. 188 ++++ multi-hop 189 |R |---- mesh +--+ +--+ 190 | | \ |J |........|P | 191 ++++ \-----| | | | 192 +--+ +--+ 193 Registrar Join Proxy Pledge 195 Figure 1: multi-hop enrolment. 197 Without routing the Pledge (P) cannot establish a secure connection 198 to the Registrar (R) over multiple hops in the network. 200 Furthermore, the Pledge (P) cannot discover the IP address of the 201 Registrar (R) over multiple hops to initiate a DTLS connection and 202 perform authentication. 204 To overcome the problems with non-routability of DTLS packets and/or 205 discovery of the destination address of the Registrar, the Join Proxy 206 is introduced. This Join Proxy functionality is configured into all 207 authenticated devices in the network which may act as a Join Proxy 208 for Pledges. The Join Proxy allows for routing of the packets from 209 the Pledge using IP routing to the intended Registrar. An 210 authenticated Join Proxy can discover the routable IP address of the 211 Registrar over multiple hops. The following Section 5 specifies the 212 two Join Proxy modes. A comparison is presented in Section 6. 214 5. Join Proxy specification 216 A Join Proxy can operate in two modes: 218 o Statefull mode 220 o Stateless mode 222 A Join Proxy MUST implement one of the two modes. A Join Proxy MAY 223 implement both, with an unspecified mechanism to switch between the 224 two modes. 226 5.1. Statefull Join Proxy 228 In stateful mode, the Join Proxy forwards the DTLS messages to the 229 Registrar. 231 Assume that the Pledge does not know the IP address of the Registrar 232 it needs to contact. The Join Proxy has has been enrolled via the 233 Registrar and learns the IP address and port of the Registrar, for 234 example by using the discovery mechanism described in Section 7. The 235 Pledge first discovers (see Section 7) and selects the most 236 appropriate Join Proxy. (Discovery can also be based upon [RFC8995] 237 section 4.1, or via DNS-SD service discovery [RFC6763]). The Pledge 238 initiates its request as if the Join Proxy is the intended Registrar. 239 The Join Proxy receives the message at a discoverable join-port. The 240 Join Proxy constructs an IP packet by copying the DTLS payload from 241 the message received from the Pledge, and provides source and 242 destination addresses to forward the message to the intended 243 Registrar. The Join Proxy maintains a 4-tuple array to translate the 244 DTLS messages received from the Registrar and forward it back to the 245 Pledge. 247 In Figure 2 the various steps of the message flow are shown, with 248 5684 being the standard coaps port: 250 +------------+------------+-------------+--------------------------+ 251 | Pledge | Join Proxy | Registrar | Message | 252 | (P) | (J) | (R) | Src_IP:port | Dst_IP:port| 253 +------------+------------+-------------+-------------+------------+ 254 | --ClientHello--> | IP_P:p_P | IP_Ja:p_J | 255 | --ClientHello--> | IP_Jb:p_Jb| IP_R:5684 | 256 | | | | 257 | <--ServerHello-- | IP_R:5684 | IP_Jb:p_Jb | 258 | : | | | 259 | <--ServerHello-- : | IP_Ja:p_J | IP_P:p_P | 260 | : : | | | 261 | [DTLS messages] | : | : | 262 | : : | : | : | 263 | --Finished--> : | IP_P:p_P | IP_Ja:p_J | 264 | --Finished--> | IP_Jb:p_Jb| IP_R:5684 | 265 | | | | 266 | <--Finished-- | IP_R:5684 | IP_Jb:p_Jb | 267 | <--Finished-- | IP_Ja:p_J | IP_P:p_P | 268 | : : | : | : | 269 +---------------------------------------+-------------+------------+ 270 IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client) 271 IP_R:5684 = Routable IP address and coaps port of Registrar 272 IP_Ja:P_J = Link-local IP address and join-port of Join Proxy 273 IP_Jb:p_Rb = Routable IP address and client port of Join Proxy 275 Figure 2: constrained statefull joining message flow with Registrar 276 address known to Join Proxy. 278 5.2. Stateless Join Proxy 280 The stateless Join Proxy aims to minimize the requirements on the 281 constrained Join Proxy device. Stateless operation requires no 282 memory in the Join Proxy device, but may also reduce the CPU impact 283 as the device does not need to search through a state table. 285 If an untrusted Pledge that can only use link-local addressing wants 286 to contact a trusted Registrar, and the Registrar is more than one 287 hop away, it sends its DTLS messages to the Join Proxy. 289 When a Pledge attempts a DTLS connection to the Join Proxy, it uses 290 its link-local IP address as its IP source address. This message is 291 transmitted one-hop to a neighbouring (Join Proxy) node. Under 292 normal circumstances, this message would be dropped at the neighbour 293 node since the Pledge is not yet IP routable or is not yet 294 authenticated to send messages through the network. However, if the 295 neighbour device has the Join Proxy functionality enabled, it routes 296 the DTLS message to its Registrar of choice. 298 The Join Proxy sends a "new" JPY message which includes the DTLS data 299 as payload. 301 The JPY message payload consists of two parts: 303 o Header (H) field: consisting of the source link-local address and 304 port of the Pledge (P), and 306 o Contents (C) field: containing the original DTLS payload. 308 On receiving the JPY message, the Registrar (or proxy) retrieves the 309 two parts. 311 The Registrar transiently stores the Header field information. The 312 Registrar uses the Contents field to execute the Registrar 313 functionality. However, when the Registrar replies, it also extends 314 its DTLS message with the header field in a JPY message and sends it 315 back to the Join Proxy. The Registrar SHOULD NOT assume that it can 316 decode the Header Field, it should simply repeat it when responding. 317 The Header contains the original source link-local address and port 318 of the Pledge from the transient state stored earlier and the 319 Contents field contains the DTLS payload. 321 On receiving the JPY message, the Join Proxy retrieves the two parts. 322 It uses the Header field to route the DTLS message containing the 323 DTLS payload retrieved from the Contents field to the Pledge. 325 In this scenario, both the Registrar and the Join Proxy use 326 discoverable join-ports, which may be the default ports. 328 The Figure 3 depicts the message flow diagram: 330 +--------------+------------+---------------+-----------------------+ 331 | Pledge | Join Proxy | Registrar | Message | 332 | (P) | (J) | (R) |Src_IP:port|Dst_IP:port| 333 +--------------+------------+---------------+-----------+-----------+ 334 | --ClientHello--> | IP_P:p_P |IP_Ja:p_Ja | 335 | --JPY[H(IP_P:p_P),--> | IP_Jb:p_Jb|IP_R:p_Ra | 336 | C(ClientHello)] | | | 337 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jb:p_Jb | 338 | C(ServerHello)] | | | 339 | <--ServerHello-- | IP_Ja:p_Ja|IP_P:p_P | 340 | : | | | 341 | [ DTLS messages ] | : | : | 342 | : | : | : | 343 | --Finished--> | IP_P:p_P |IP_Ja:p_Ja | 344 | --JPY[H(IP_P:p_P),--> | IP_Jb:p_Jb|IP_R:p_Ra | 345 | C(Finished)] | | | 346 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jb:p_Jb | 347 | C(Finished)] | | | 348 | <--Finished-- | IP_Ja:p_Ja|IP_P:p_P | 349 | : | : | : | 350 +-------------------------------------------+-----------+-----------+ 351 IP_P:p_P = Link-local IP address and port of the Pledge 352 IP_R:p_Ra = Routable IP address and join-port of Registrar 353 IP_Ja:p_Ja = Link-local IP address and join-port of Join Proxy 354 IP_Jb:p_Jb = Routable IP address and port of Join Proxy 356 JPY[H(),C()] = Join Proxy message with header H and content C 358 Figure 3: constrained stateless joining message flow. 360 5.3. Stateless Message structure 362 The JPY message is constructed as a payload with media-type 363 aplication/cbor 365 Header and Contents fields together are one CBOR array of 5 elements: 367 1. header field: containing a CBOR array [RFC7049] with the Pledge 368 IPv6 Link Local address as a CBOR byte string, the Pledge's UDP 369 port number as a CBOR integer, the IP address family (IPv4/IPv6) 370 as a CBOR integer, and the proxy's ifindex or other identifier 371 for the physical port as CBOR integer. The header field is not 372 DTLS encrypted. 374 2. Content field: containing the DTLS payload as a CBOR byte string. 376 The Join Proxy cannot decrypt the DTLS payload and has no knowledge 377 of the transported media type. 379 JPY_message = 380 [ 381 ip : bstr, 382 port : int, 383 family : int, 384 index : int 385 payload : bstr 386 ] 388 Figure 4: CDDL representation of JPY message 390 The contents are DTLS encrypted. In CBOR diagnostic notation the 391 payload JPY[H(IP_P:p_P)], will look like: 393 [h'IP_p', p_P, family, ident, h'DTLS-payload'] 395 Examples are shown in Appendix A. 397 6. Comparison of stateless and statefull modes 399 The stateful and stateless mode of operation for the Join Proxy have 400 their advantages and disadvantages. This section should enable to 401 make a choice between the two modes based on the available device 402 resources and network bandwidth. 404 +-------------+----------------------------+------------------------+ 405 | Properties | Stateful mode | Stateless mode | 406 +-------------+----------------------------+------------------------+ 407 | State |The Join Proxy needs | No information is | 408 | Information |additional storage to | maintained by the Join | 409 | |maintain mapping between | Proxy. Registrar needs | 410 | |the address and port number | to store the packet | 411 | |of the Pledge and those | header. | 412 | |of the Registrar. | | 413 +-------------+----------------------------+------------------------+ 414 |Packet size |The size of the forwarded |Size of the forwarded | 415 | |message is the same as the |message is bigger than | 416 | |original message. |the original,it includes| 417 | | |additional information | 418 +-------------+----------------------------+------------------------+ 419 |Specification|The Join Proxy needs |New JPY message to | 420 |complexity |additional functionality |encapsulate DTLS payload| 421 | |to maintain state |The Registrar | 422 | |information, and specify |and the Join Proxy | 423 | |the source and destination |have to understand the | 424 | |addresses of the DTLS |JPY message in order | 425 | |handshake messages |to process it. | 426 +-------------+----------------------------+------------------------+ 427 | Ports | Join Proxy needs |Join Proxy and Registrar| 428 | | discoverable join-port |need discoverable | 429 | | | join-ports | 430 +-------------+----------------------------+------------------------+ 432 Figure 5: Comparison between stateful and stateless mode 434 7. Discovery 436 It is assumed that Join Proxy seamlessly provides a coaps connection 437 between Pledge and Registrar. In particular this section extends 438 section 4.1 of [RFC8995] for the constrained case. 440 The discovery follows two steps with two alternatives for step 1: 442 Step 1. Two alternatives exist (near and remote): 444 Near: the Pledge is one hop away from the Registrar. The Pledge 445 discovers the link-local address of the Registrar as described in 446 {{I-D.ietf-ace-coap-est}}. From then on, it follows the BRSKI process 447 as described in {{I-D.ietf-ace-coap-est}} and 448 {{I-D.ietf-anima-constrained-voucher}}, using link-local addresses. 450 Remote: the Pledge is more than one hop away from a relevant Registrar, 451 and discovers the link-local address and join-port of a Join Proxy. The 452 Pledge then follows the BRSKI procedure using the link-local address of 453 the Join Proxy. 455 Step 2. The enrolled Join Proxy discovers the join-port of the 456 Registrar. 458 The order in which the two alternatives of step 1 are tried is 459 installation dependent. The trigger for discovery in Step 2 in 460 implementation dependent. 462 Once a Pledge is enrolled, it may function as Join Proxy. The Join 463 Proxy functions are advertised as descibed below. In principle, the 464 Join Proxy functions are offered via a join-port, and not the 465 standard coaps port. Also the Registrar offers a join-port to which 466 the stateless Join Proxy sends the JPY message. The Join Proxy and 467 Registrar show the extra join-port number when reponding to a /.well- 468 known/core discovery request addressed to the standard coap/coaps 469 port. 471 Three discovery cases are discussed: Join Proxy discovers Registrar, 472 Pledge discovers Registrar, and Pledge discovers Join Proxy. Each 473 discovery case considers three alternatives: CoAP discovery, GRASP 474 discovery, and 6tisch discovery. 476 7.1. Join Proxy discovers Registrar 478 In this section, the Join Proxy and Registrar are assumed to 479 communicate via Link-Local addresses. This section describes the 480 discovery of the Registrar by the Join Proxy. 482 7.1.1. CoAP discovery{#coap-disc} 484 The discovery of the coaps Registrar, using coap discovery, by the 485 Join Proxy follows section 6 of [I-D.ietf-ace-coap-est]. The 486 stateless Join Proxy can discover the join-port of the Registrar by 487 sending a GET request to "/.well-known/core" including a resource 488 type (rt) parameter with the value "join-proxy" [RFC6690]. Upon 489 success, the return payload will contain the join-port of the 490 Registrar. 492 REQ: GET coap://[IP_address]/.well-known/core?rt=join-proxy 494 RES: 2.05 Content 495 ; rt="join-proxy" 497 The discoverable port numbers are usually returned for Join Proxy 498 resources in the of the payload (see section 5.1 of 499 [I-D.ietf-ace-coap-est]). 501 7.1.2. GRASP discovery 503 This section is normative for uses with an ANIMA ACP. In the context 504 of autonomic networks, the Join Proxy uses the DULL GRASP M_FLOOD 505 mechanism to announce itself. Section 4.1.1 of [RFC8995] discusses 506 this in more detail. The Registrar announces itself using ACP 507 instance of GRASP using M_FLOOD messages. Autonomic Network Join 508 Proxies MUST support GRASP discovery of Registrar as decribed in 509 section 4.3 of [RFC8995] . 511 7.1.3. 6tisch discovery 513 The discovery of the Registrar by the Join Proxy uses the enhanced 514 beacons as discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 516 7.2. Pledge discovers Registrar 518 In this section, the Pledge and Registrar are assumed to communicate 519 via Link-Local addresses. This section describes the discovery of 520 the Registrar by the Pledge. 522 7.2.1. CoAP discovery 524 The discovery of the coaps Registrar, using coap discovery, by the 525 Pledge follows section 6 of [I-D.ietf-ace-coap-est]. 527 7.2.2. GRASP discovery 529 This section is normative for uses with an ANIMA ACP. In the context 530 of autonomic networks, the Pledge uses the DULL GRASP M_FLOOD 531 mechanism to announce itself. Section 4.1.1 of [RFC8995] discusses 532 this in more detail. The Registrar announces itself using ACP 533 instance of GRASP using M_FLOOD messages. Autonomic Network Join 534 Proxies MUST support GRASP discovery of Registrar as decribed in 535 section 4.3 of [RFC8995] . 537 7.2.3. 6tisch discovery 539 The discovery of Registrar by the PLedge uses the enhanced beacons as 540 discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 542 7.3. Pledge discovers Join Proxy 544 In this section, the Pledge and Join Proxy are assumed to communicate 545 via Link-Local addresses. This section describes the discovery of 546 the Join Proxy by the Pledge. 548 7.3.1. CoAP discovery 550 In the context of a coap network without Autonomic Network support, 551 discovery follows the standard coap policy. The Pledge can discover 552 a Join Proxy by sending a link-local multicast message to ALL CoAP 553 Nodes with address FF02::FD. Multiple or no nodes may respond. The 554 handling of multiple responses and the absence of responses follow 555 section 4 of [RFC8995]. 557 The join-port of the Join Proxy is discovered by sending a GET 558 request to "/.well-known/core" including a resource type (rt) 559 parameter with the value "brski-proxy" [RFC6690]. Upon success, the 560 return payload will contain the join-port. 562 The example below shows the discovery of the join-port of the Join 563 Proxy. 565 REQ: GET coap://[FF02::FD]/.well-known/core?rt=brski-proxy 567 RES: 2.05 Content 568 ; rt="brski-proxy" 570 Port numbers are assumed to be the default numbers 5683 and 5684 for 571 coap and coaps respectively (sections 12.6 and 12.7 of [RFC7252] when 572 not shown in the response. Discoverable port numbers are usually 573 returned for Join Proxy resources in the of the 574 payload (see section 5.1 of [I-D.ietf-ace-coap-est]). 576 7.3.2. GRASP discovery 578 This section is normative for uses with an ANIMA ACP. The Pledge 579 MUST listen for GRASP M_FLOOD [RFC8990] announcements of the 580 objective: "AN_Proxy". See section Section 4.1.1 [RFC8995] for the 581 details of the objective. 583 7.3.3. 6tisch discovery 585 The discovery of the Join Proxy by the Pledge uses the enhanced 586 beacons as discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 588 8. Security Considerations 590 All of the concerns in [RFC8995] section 4.1 apply. The Pledge can 591 be deceived by malicious Join Proxy announcements. The Pledge will 592 only join a network to which it receives a valid [RFC8366] voucher 593 [I-D.ietf-anima-constrained-voucher]. Once the Pledge joined, the 594 payload between Pledge and Registrar is protected by DTLS. 596 It should be noted here that the contents of the CBOR map used to 597 convey return address information is not DTLS protected. When the 598 communication between JOIN Proxy and Registrar passes over an 599 unsecure network, an attacker can change the CBOR array, causing the 600 Registrar to deviate traffic from the intended Pledge. If such 601 scenario needs to be avoided, then it is reasonable for the Join 602 Proxy to encrypt the CBOR array using a locally generated symmetric 603 key. The Registrar would not be able to examine the result, but it 604 does not need to do so. This is a topic for future work. 606 Another possibility is to use level 2 protection between Registrar 607 and Join Proxy. 609 9. IANA Considerations 611 This document needs to create a registry for key indices in the CBOR 612 map. It should be given a name, and the amending formula should be 613 IETF Specification. 615 9.1. Resource Type registry 617 This specification registers a new Resource Type (rt=) Link Target 618 Attributes in the "Resource Type (rt=) Link Target Attribute Values" 619 subregistry under the "Constrained RESTful Environments (CoRE) 620 Parameters" registry. 622 rt="brski-proxy". This BRSKI resource is used to query and return 623 the supported BRSKI port of the Join Proxy. 625 rt="join-proxy". This BRSKI resource is used to query and return 626 the supported BRSKI port of the Registrar. 628 10. Acknowledgements 630 Many thanks for the comments by Brian Carpenter and Esko Dijk. 632 11. Contributors 634 Sandeep Kumar, Sye loong Keoh, and Oscar Garcia-Morchon are the co- 635 authors of the draft-kumar-dice-dtls-relay-02. Their draft has 636 served as a basis for this document. Much text from their draft is 637 copied over to this draft. 639 12. Changelog 641 12.1. 04 to 05 643 * Join Proxy and join-port consistent spelling 644 * some nits removed 645 * restructured discovery section 646 * rephrased parts of security section 648 12.2. 03 to 04 650 * mail address and reference 652 12.3. 02 to 03 654 * Terminology updated 655 * Several clarifications on discovery and routability 656 * DTLS payload introduced 658 12.4. 01 to 02 660 o Discovery of Join Proxy and Registrar ports 662 12.5. 00 to 01 664 o Registrar used throughout instead of EST server 666 o Emphasized additional Join Proxy port for Join Proxy and Registrar 668 o updated discovery accordingly 670 o updated stateless Join Proxy JPY header 672 o JPY header described with CDDL 674 o Example simplified and corrected 676 12.6. 00 to 00 678 o copied from vanderstok-anima-constrained-join-proxy-05 680 13. References 682 13.1. Normative References 684 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 685 (editor), D. D. and M. Richardson, "Encapsulation of 686 6TiSCH Join and Enrollment Information Elements", draft- 687 ietf-6tisch-enrollment-enhanced-beacon-14 (work in 688 progress), February 2020. 690 [I-D.ietf-ace-coap-est] 691 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 692 Raza, "EST over secure CoAP (EST-coaps)", draft-ietf-ace- 693 coap-est-18 (work in progress), January 2020. 695 [I-D.ietf-anima-constrained-voucher] 696 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 697 Dijk, "Constrained Voucher Artifacts for Bootstrapping 698 Protocols", draft-ietf-anima-constrained-voucher-13 (work 699 in progress), July 2021. 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, 703 DOI 10.17487/RFC2119, March 1997, 704 . 706 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 707 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 708 January 2012, . 710 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 711 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 712 October 2013, . 714 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 715 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 716 May 2017, . 718 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 719 "A Voucher Artifact for Bootstrapping Protocols", 720 RFC 8366, DOI 10.17487/RFC8366, May 2018, 721 . 723 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 724 Autonomic Signaling Protocol (GRASP)", RFC 8990, 725 DOI 10.17487/RFC8990, May 2021, 726 . 728 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 729 and K. Watsen, "Bootstrapping Remote Secure Key 730 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 731 May 2021, . 733 13.2. Informative References 735 [I-D.kumar-dice-dtls-relay] 736 Kumar, S. S., Keoh, S. L., and O. Garcia-Morchon, "DTLS 737 Relay for Constrained Environments", draft-kumar-dice- 738 dtls-relay-02 (work in progress), October 2014. 740 [I-D.richardson-anima-state-for-joinrouter] 741 Richardson, M. C., "Considerations for stateful vs 742 stateless join router in ANIMA bootstrap", draft- 743 richardson-anima-state-for-joinrouter-03 (work in 744 progress), September 2020. 746 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 747 "Transmission of IPv6 Packets over IEEE 802.15.4 748 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 749 . 751 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 752 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 753 . 755 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 756 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 757 . 759 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 760 Bormann, "Neighbor Discovery Optimization for IPv6 over 761 Low-Power Wireless Personal Area Networks (6LoWPANs)", 762 RFC 6775, DOI 10.17487/RFC6775, November 2012, 763 . 765 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 766 "Enrollment over Secure Transport", RFC 7030, 767 DOI 10.17487/RFC7030, October 2013, 768 . 770 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 771 Constrained-Node Networks", RFC 7228, 772 DOI 10.17487/RFC7228, May 2014, 773 . 775 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 776 Application Protocol (CoAP)", RFC 7252, 777 DOI 10.17487/RFC7252, June 2014, 778 . 780 Appendix A. Stateless Proxy payload examples 782 The examples show the request "GET coaps://192.168.1.200:5965/est/ 783 crts" to a Registrar. The header generated between Join Proxy and 784 Registrar and from Registrar to Join Proxy are shown in detail. The 785 DTLS payload is not shown. 787 The request from Join Proxy to Registrar looks like: 789 85 # array(5) 790 50 # bytes(16) 791 FE800000000000000000FFFFC0A801C8 # 792 19 BDA7 # unsigned(48551) 793 0A # unsigned(10) 794 00 # unsigned(0) 795 58 2D # bytes(45) 796 798 In CBOR Diagnostic: 800 [h'FE800000000000000000FFFFC0A801C8', 48551, 10, 0, 801 h''] 803 The response is: 805 85 # array(5) 806 50 # bytes(16) 807 FE800000000000000000FFFFC0A801C8 # 808 19 BDA7 # unsigned(48551) 809 0A # unsigned(10) 810 00 # unsigned(0) 811 59 026A # bytes(618) 812 814 In CBOR diagnostic: 816 [h'FE800000000000000000FFFFC0A801C8', 48551, 10, 0, 817 h''] 819 Authors' Addresses 821 Michael Richardson 822 Sandelman Software Works 824 Email: mcr+ietf@sandelman.ca 826 Peter van der Stok 827 vanderstok consultancy 829 Email: stokcons@bbhmail.nl 831 Panos Kampanakis 832 Cisco Systems 834 Email: pkampana@cisco.com