Line numbers are from ID-Nits 3 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track P. van der Stok 5 Expires: 16 October 2022 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 14 April 2022
10 Constrained Join Proxy for Bootstrapping Protocols 11 draft-ietf-anima-constrained-join-proxy-10 13 Abstract 15 This document extends the work of Bootstrapping Remote Secure Key 16 Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge 17 and Registrar by a stateless/stateful constrained Join Proxy. The NIT: "by replacing" - this this sounds wrong IMHO. First of all, a stateful constrained Join Proxy is arguably as much a circuit proxy as the TCP proxy given how it needs to figure out when to create and when to tear down the five tuple state, and secondly, the sentence makes it sound as if the circuit proxy is obsoleted by this draft. 18 constrained Join Proxy is a mesh neighbor of the Pledge and can relay 19 a DTLS session originating from a Pledge with only link-local 20 addresses to a Registrar which is not a mesh neighbor of the Pledge. NIT: "a mesh neighbor" - is i think wrong too. Calling an L3 network a "mesh" is just one option. This work is not only applicable to networks that like to be called "mesh". Suggested paragraph rewrite: | This document extends the work of Bootstrapping Remote Secure Key | Infrastructures (BRSKI) by introducing a stateless or stateful UDP Join Proxy | in support of enrollment protocol(s) relying on DTLS, such as constrained BRSKI. | This type of Join Proxy is targeted for constrained node Pledges and Join Proxies and | is hence called a constrained Join Proxy. Like the BRSKI (TCP circuit) Join Proxy, this constrained Join Proxy eliminates the need of Pledges to have routeable IP addresses before enrolment by utilizing link-local addresses on the Pledge to Join Proxy leg. Use of the constrained Join Proxy also eliminates the need of the Pledge to authenticate to the network or perform network-wide Registrar discover before enrolment. 22 This document defines a protocol to securely assign a Pledge to a 23 domain, represented by a Registrar, using an intermediary node NIT: This is wrong. Constrained BRSKI defines that protocol for assigning a Pledge to a domain. This particular document just introduces an optional component to that solution. Suggest to remove this whole paragraph if the above suggested rewrite is used. 24 between Pledge and Registrar. This intermediary node is known as a 25 "constrained Join Proxy". An enrolled Pledge can act as a 26 constrained Join Proxy. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 16 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 64 4. constrained Join Proxy functionality . . . . . . . . . . . . 5 65 5. constrained Join Proxy specification . . . . . . . . . . . . 7 66 5.1. Stateful Join Proxy . . . . . . . . . . . . . . . . . . . 7 67 5.2. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 8 68 5.3. Stateless Message structure . . . . . . . . . . . . . . . 10 69 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6.1. Join Proxy discovers Registrar . . . . . . . . . . . . . 12 71 6.1.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 72 6.1.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 13 73 6.1.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 13 74 6.2. Pledge discovers Registrar . . . . . . . . . . . . . . . 13 75 6.2.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 76 6.2.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 14 77 6.2.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 14 78 6.3. Pledge discovers Join Proxy . . . . . . . . . . . . . . . 14 79 6.3.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 14 80 6.3.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 15 81 6.3.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 15 82 7. Comparison of stateless and stateful modes . . . . . . . . . 15 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 9.1. Resource Type Attributes registry . . . . . . . . . . . . 17 86 9.2. service name and port number registry . . . . . . . . . . 17 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 88 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 89 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 12.1. 10 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 18 91 12.2. 09 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 18 92 12.3. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 18 93 12.4. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 19 94 12.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 19 95 12.6. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 19 96 12.7. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 19 97 12.8. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 19 98 12.9. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 19 99 12.10. 00 to 00 . . . . . . . . . . . . . . . . . . . . . . . . 19 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 13.2. Informative References . . . . . . . . . . . . . . . . . 21 103 Appendix A. Stateless Proxy payload examples . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 106 1. Introduction 108 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol 109 described in [RFC8995] provides a solution for a secure zero-touch 110 (automated) bootstrap of new (unconfigured) devices. In the context 111 of BRSKI, new devices, called "Pledges", are equipped with a factory- 112 installed Initial Device Identifier (IDevID) (see [ieee802-1AR]), and 113 are enrolled into a network. BRSKI makes use of Enrollment over 114 Secure Transport (EST) [RFC7030] with [RFC8366] vouchers to securely 115 enroll devices. A Registrar provides the security anchor of the 116 network to which a Pledge enrolls. In this document, BRSKI is NIT: Start new paragraph after end of sentence (sentence too long). 116 network to which a Pledge enrolls. In this document, BRSKI is 117 extended such that a Pledge connects to "Registrars" via a 118 constrained Join Proxy. In particular, the underlying IP network is 119 assumed to be a mesh newtork as described in [RFC4944], although 120 other IP-over-foo networks are not excluded. NIT: This is too limited in focus, and i am also not aware of any constraints in the proposed mechanism that would assume such a mesh network. Suggested rewrite last sentence to: | In particular, this solution is intended to support mesh networks as described in | [RFC4944]. NIT: Suggest adding the following broader goal/scope because filling that gap was AFAIK the original goal of this draft as agreed by the WG, and i think this draft does deliver. | The constrained Join Proxy as specified in this document is one of the Join Proxy | options referred to in [RFC8995] section 2.5.2 as future work. 122 A complete specification of the terminology is pointed at in 123 Section 2. 125 The specified solutions in [RFC8995] and [RFC7030] are based on POST 126 or GET requests to the EST resources (/cacerts, /simpleenroll, 127 /simplereenroll, /serverkeygen, and /csrattrs), and the brski 128 resources (/requestvoucher, /voucher_status, and /enrollstatus). 129 These requests use https and may be too large in terms of code space 130 or bandwidth required for constrained devices. Constrained devices 131 which may be part of constrained networks [RFC7228], typically 132 implement the IPv6 over Low-Power Wireless personal Area Networks 133 (6LoWPAN) [RFC4944] and Constrained Application Protocol (CoAP) 134 [RFC7252]. 136 CoAP can be run with the Datagram Transport Layer Security (DTLS) 137 [RFC6347] as a security protocol for authenticity and confidentiality 138 of the messages. This is known as the "coaps" scheme. A constrained 139 version of EST, using Coap and DTLS, is described in 140 [I-D.ietf-ace-coap-est]. The [I-D.ietf-anima-constrained-voucher] 141 extends [I-D.ietf-ace-coap-est] with BRSKI artifacts such as voucher, 142 request voucher, and the protocol extensions for constrained Pledges. NIT: would amend sentence with ... that use CoAP. There can be other constrained device protocols, so the sentence is confusing without this clarification. 144 DTLS is a client-server protocol relying on the underlying IP layer 145 to perform the routing between the DTLS Client and the DTLS Server. NIT: Would suggest to remove this sentence (144-145). It serves only to confuse (at least me). The fact that its Client/Server has nothing to do with the need for IP reachability for example. 146 However, the Pledge will not be IP routable over the mesh network NIT: Would suggest to expand here for folks who are not well aware of mesh network details: | However, in networks that require authentication, such as those using [RFC4944], 147 until it is authenticated to the mesh network. A new Pledge can only 148 initially use a link-local IPv6 address to communicate with a mesh 149 neighbor [RFC6775] until it receives the necessary network 150 configuration parameters. The Pledge receives these configuration 151 parameters from the Registrar. When the Registrar is not a direct 152 neighbor of the Registrar but several hops away, the Pledge discovers 153 a neighbor constrained Join Proxy, which transmits the DTLS protected NIT: s/neighbor constrained/neighbor that is operating the constrained/ 153 a neighbor constrained Join Proxy, which transmits the DTLS protected 154 request coming from the Pledge to the Registrar. The constrained NIT: s/which transmits the .. (sentence end)/which forwards the DTLS protected UDP messages between Pledge and Registrar./ 155 Join Proxy must be enrolled previously such that the message from 156 constrained Join Proxy to Registrar can be routed over one or more 157 hops. 159 During enrollment, a DTLS connection is required between Pledge and 160 Registrar. NIT: Remove sentence, duplicate (explained on 153/154). 162 Once a Pledge is enrolled, it can act as constrained Join Proxy 163 between other Pledges and the enrolling Registrar. 165 This document specifies a new form of constrained Join Proxy and 166 protocol to act as intermediary between Pledge and Registrar to relay 167 DTLS messages between Pledge and Registrar. Two modes of the NIT: Duplicate. Remove sentence. 167 DTLS messages between Pledge and Registrar. Two modes of the 168 constrained Join Proxy are specified: 170 1 A stateful Join Proxy that locally stores IP addresses 171 during the connection. NIT: change to at least "IP addresses and port numbers". Alhough i would prefer something more explanatory such as "per Pledge connection state consisting of IP addresses, port numbers and interfaces". 172 2 A stateless Join Proxy that where the connection state 173 is stored in the messages. NIT: I don't think that "connection state stored in the message" is correct. Suggest: "where connection state is replaced by a new proxy header in the UDP messages between constrained Join Proxy and Registrar". 175 This document is very much inspired by text published earlier in 176 [I-D.kumar-dice-dtls-relay]. 177 [I-D.richardson-anima-state-for-joinrouter] outlined the various 178 options for building a constrained Join Proxy. [RFC8995] adopted 179 only the Circuit Proxy method (1), leaving the other methods as 180 future work. 182 The stateful and stateless modes differ in the way that they store 183 the state required to forward the return packet to the pledge. 184 Similar to the difference between storing and non_storing Modes of 185 Operations (MOP) in RPL [RFC6550]. In the stateful method, the 186 return forward state is stored in the join proxy. In the stateless 187 method, the return forward state is stored in the network. 189 2. Terminology 191 The following terms are defined in [RFC8366], and are used 192 identically as in that document: artifact, imprint, domain, Join 193 Registrar/Coordinator (JRC), Pledge, and Voucher. 195 In this document, the term "Registrar" is used throughout instead of 196 "Join Registrar/Coordinator (JRC)". 198 The term "installation network" refers to all devices in the 199 installation and the network connections between them. The term 200 "installation IP_address" refers to an address out of the set of 201 addresses which are routable over the whole installation network. NIT: None of the terms "installation network", or "installation IP_address" are used in the document outside of this paragraph. Suggest something like: | 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. | | (Installation) IP addresses are assumed to be routeable over the whole installation | network except for link-local IP addresses. 203 The "Constrained Join Proxy" enables a pledge that is multiple hops 204 away from the Registrar, to securely execute the BRSKI protocol 205 [RFC8995] over a secure channel. 207 The term "join Proxy" is used interchangeably with the term 208 "constrained Join Proxy" throughout this document. Nit: You already always use "Join Proxy" (capital J), which is good (fix in line 207), or else RFC editor would complain later. But given how there could be confusion between a BRSKI Join Proxy and the constrained Join Proxy introduced here, it may be useful to add: | The [RFC8995] BRSKI Join Proxy is referred to as a TCP circuit Join Proxy. 210 3. Requirements Language 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 214 "OPTIONAL" in this document are to be interpreted as described in 215 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 216 capitals, as shown here. 218 4. constrained Join Proxy functionality 220 As depicted in the Figure 1, the Pledge (P), in a Low-Power and Lossy 221 Network (LLN) mesh [RFC7102] can be more than one hop away from the 222 Registrar (R) and not yet authenticated into the network. NIT: Text makes it sound as if this proxy is only for LNN mesh networks. Suggest: s/in a/in a network such as a/ 224 In this situation, the Pledge can only communicate one-hop to its 225 nearest neighbor, the constrained Join Proxy (J) using their link- 226 local IPv6 addresses. However, the Pledge (P) needs to communicate 227 with end-to-end security with a Registrar to authenticate and get the 228 relevant system/network parameters. If the Pledge (P), knowing the 229 IP-address of the Registrar, initiates a DTLS connection to the 230 Registrar, then the packets are dropped at the constrained Join Proxy 231 (J) since the Pledge (P) is not yet admitted to the network or there 232 is no IP routability to Pledge (P) for any returned messages from the 233 Registrar. NIT: For those readers like me uneducated in details of those mesh networks, a single sentence explaining one example of what actually needs to happen for a Pledge to get a routeable IP address after it is enrolled, would be nice. Or is there a good RFC reference to point to ? I for once couldn't find that in RFC4944. 235 ++++ multi-hop 236 |R |---- mesh +--+ +--+ 237 | | \ |J |........|P | 238 ++++ \-----| | | | 239 +--+ +--+ 240 Registrar Join Proxy Pledge 242 Figure 1: multi-hop enrollment. NIT: Label line "....." with "IPv6 subnet" 244 Without routing the Pledge (P) cannot establish a secure connection 245 to the Registrar (R) over multiple hops in the network. NIT: This sentence reads wrong in implication: Just adding routing does not suffice to establish a secure connection, because without voucher the DTLS connection is only "half-way secure". Suggested replacement: | Without a routeable IPv6 address, the Pledge (P) cannot exchange IPv6/UDP/DTLS traffic | with the Registrar (R), over multiple hops in the network. 247 Furthermore, the Pledge (P) cannot discover the IP address of the 248 Registrar (R) over multiple hops to initiate a DTLS connection and 249 perform authentication. NIT: s/cannot/may not be able to/ Aka: not always a problem: Just because the Pledge has only a link-local address doesn't mean that it can not discover the remote Registar IPv6 address. It just can not use it. E.g.: DNS-SD mechanisms. 251 To overcome the problems with non-routability of DTLS packets and/or 252 discovery of the destination address of the Registrar, the 253 constrained Join Proxy is introduced. This constrained Join Proxy 254 functionality is configured into all authenticated devices in the NIT: suggest "configured" -> "also (auto) configured" 254 functionality is configured into all authenticated devices in the 255 network which may act as a constrained Join Proxy for Pledges. The NIT: "which may" -> "so that they can" 255 network which may act as a constrained Join Proxy for Pledges. The 256 constrained Join Proxy allows for routing of the packets from the 257 Pledge using IP routing to the intended Registrar. An authenticated 258 constrained Join Proxy can discover the routable IP address of the 259 Registrar over multiple hops. The following Section 5 specifies the 260 two constrained Join Proxy modes. A comparison is presented in 261 Section 7. 263 When a mesh network is set up, it consists of a Registrar and a set 264 of connected pledges. No constrained Join Proxies are present. The NIT: I am guessing that "connected pledges" does NOT mean that all Pledges have subnet reachability to the registrar, right (or else we don't need Proxies). So maybe add something like this: | Only some of these pledges may be neighbors of the Registrar. Others would need | for their traffic to be routed across one or more enrolled devices to reach the Registrar. 265 wanted end-state is a network with a Registrar and a set of enrolled 266 devices. NIT: s/wanted/desired/ NIT: s/end-state/state of the installation/ NIT: s/a set of enrolled devices/all Pledges becoming enrolled devices/. 266 Some of these enrolled devices can act as constrained Join 267 Proxies. Pledges can only employ link-local communication untill NIT: s/untill/until/ 268 they are enrolled. A Pledge will regularly try to discover a 269 constrained Join Proxy or a Registrar with link-local discovery 270 requests. The Pledges which are neigbors of the Registrar will 271 discover the Registrar and be enrolled following the BRSKI protocol. NIT: s/BRSKI/constrained BRSKI/ 272 An enrolled device can act as constrained Join Proxy. The Pledges 273 which are not a neighbor of the Registrar will eventually discover a 274 constrained Join Proxy and follow the BRSKI protocol to be enrolled. NIT: s/BRSKI/constrained BRSKI/ 275 While this goes on, more and more constrained Join Proxies with a 276 larger hop distance to the Registrar will emerge. The network should 277 be configured such that at the end of the enrollment process, all 278 pledges have discovered a neigboring constrained Join Proxy or the 279 Registrar, and all "legal" Pledges are enrolled. MAYOR: At this point in the document, it would be IMHO important IMHO to give a summary as to how the proxy actually works, because that has not really happened yet. Nor is there a good summary below either. The whole draft swings by without explaining that it works at the UDP level, making the less pre-educated readers potentially think thart its somehow dealing actually with DTLS (IMHO). Proposed text: | The constrained Join Proxy is as a packet-by-packet proxy for UDP packets between Pledge and | Registrar. The constrained BRSKI protocol between Pledge and Registrar described in | [I-D.ietf-anima-constrained-voucher] for which the Join Proxy is initially defined | uses UDP messages with DTLS payload, but the Join Proxy as described here is unaware | of this payload. | | The l2 subnet leg between Join Proxy and pledge uses IPv6 link-local addresses. This | eliminates the need for the Pledge to have a routed IPv6 address before enrolment. The | Join Proxy itself is assumed to have all the necessary addressing and credentials | to talk to the Registrar via IPv6. This eliminates the problem that the Pledge may not | have the credentials to access the network towards the Registrar before enrolment. | | In the Stateful mode of the Join Proxy, it creates flow connection state for each | UDP connection. Creation of this state is triggered by the first packet from a Pledge | (on a new source UDP port) to the Join Proxy's UDP port. The state needs | to be timed out based on inactivity. | | In the Stateless mode of the Join Proxy, a new packet header is introduced for the | UDP packets between Join Proxy and Registrar, allowing the Join Proxy to operate | without flow connection state. Instead, the required link-local IP header information | is inserted into the new packet header before the packet is forwarded to the Registrar. | This allows the Registrar to main the necessary per-enrolment state and create | reply packets with the same new packet header. | | In both Stateless and Stateful mode, the Join Proxy needs to be configured with | or discover a Registrar to perform its service. This specification does not | discuss how a constrained Join Proxy selects a Registrar when it discovers 2 or more. Q: Is that "select" statement correct ? Is that a gap we should fix or are we fine with lettting selection be done on a local implementation basis ? 281 5. constrained Join Proxy specification 283 A Join Proxy can operate in two modes: 285 * Stateful mode 287 * Stateless mode 289 A Join Proxy MAY implement both. A mechanism to switch between modes 290 is out of scope of this document. It is recommended that a Join 291 Proxy uses only one of these modes at any given moment during an 292 installation lifetime. 294 5.1. Stateful Join Proxy 296 In stateful mode, the Join Proxy forwards the DTLS messages to the 297 Registrar. 299 Assume that the Pledge does not know the IP address of the Registrar 300 it needs to contact. The Join Proxy has been enrolled via the 301 Registrar and learns the IP address and port of the Registrar, for 302 example by using the discovery mechanism described in Section 6. The 303 Pledge first discovers (see Section 6) and selects the most 304 appropriate Join Proxy. (Discovery can also be based upon [RFC8995] 305 section 4.1). For service discovery via DNS-SD [RFC6763], this 306 document specifies the service names in Section 9.2. The Pledge 307 initiates its request as if the Join Proxy is the intended Registrar. 308 The Join Proxy receives the message at a discoverable join-port. The MAYOR: s/join-port/UDP join-port/ 309 Join Proxy constructs an IP packet by copying the DTLS payload from MAYOR: s/DTLS/UDP/ (The DTLS payload would be what is carried (encrypted) within the DTLS packet.) 310 the message received from the Pledge, and provides source and 311 destination addresses to forward the message to the intended NIT: s/intended/configured or discovered/ ? Q: is there ever the option the registrar gets configured ? If not, then remove that suggested option. MAYOR (IMHO): Change 5684 to p_r and accordingly fix text referring to it (below) Reason: BRSKI already made registrar port (for TLS) discoverable. There is no good reason to have it not be discovered in constrained BRSKI. Example: like "default" https:// server on port 443, assume some default COAPs server on 5864, but then constrained BRSKI is a separate application on the registrar with its own embedded coaps stack. That separate app cannot use port 5864, but needs to bind to its own port. My comments from here on assume p_r. 312 Registrar. The Join Proxy stores the 4-tuple array of the messages 313 received from the Registrar and copies it back to the header of the 314 message returned to the Pledge. MAYOR: That sentence an IMHO completely insufficient description of the required state machinery behavior. I would really suggest to consider writing a pseudo-code state machinery. Otherwise, implementers are left for a lot of guesswork, and likely will deliver partially broken implementation.s - What does "store" mean ? What exactly needs to be store ? - How does it work with multiple pledge-facing interface on the proxy ? - How does the Registrar distinguish multiple parallel Registrations - Oh, we need to allocate a new unique (IP_jr, p_Jr) for each Pledge. - Oh, we are finally talking about mapping state (IP_p%IF, p_P, IP_Jl%IF, p_Jl) <=> (IP_R, p_r, IP_jr, p_Jr) (i am using the notion %IF to indicate the interface. Maybe %ZONE would be better, see below) - And how does the proxy get rid of this mapping state ? IMHO we should define an expiry time, or else protocols using the proxy will have to guess how often they need to send refreshs (hint: 60 seconds is a good time IMHO). - We also may need to specify some good rule of thumbs for protection against DoS by too much state creation. Here is some example possible pseudocode that would describe all of this terser than text: | Receive_UDP_packet_from_pledge (IP_p, p_P, IP_Jl%IF, p_Jl) | Find mapping state (IP_p%IF, p_P, IP_Jl%IF, p_Jl) <=> (IP_R, p_r, IP_jr, p_Jr) | If it does not exist | allocate unique (IP_jr, p_Jr) across mapping states (e.g.: allocate new p_Jr) | establish mapping state | If allocation / establishment fails | return ICMP error ??? / terminate | rewrite packet header (IP_p%IF, p_P, IP_Jl%IF, p_Jl) => (IP_R, p_r, IP_jr, p_Jr) | send packet | | Receive_packet_from_registrar (IP_R, p_r, IP_jr, p_Jr) | Find mapping state (IP_p, p_P, IP_Jl%IF, p_Jl) <=> (IP_R, p_r, IP_jr, p_Jr) | If it does not exist | return ICMP error ??? / terminate | rewrite packet header (IP_R, p_r, IP_jr, p_Jr) => (IP_p%IF, p_P, IP_Jl%IF, p_Jl) | | Expire mapping state | If !received packet since XXX (TBD) seconds for (IP_p, p_P, IP_Jl%IF, p_Jl) <=> (IP_R, p_r, IP_jr, p_Jr) | remove that mapping state | | 316 In Figure 2 the various steps of the message flow are shown, with 317 5684 being the standard coaps port: 319 +------------+------------+-------------+--------------------------+ 320 | Pledge | Join Proxy | Registrar | Message | 321 | (P) | (J) | (R) | Src_IP:port | Dst_IP:port| 322 +------------+------------+-------------+-------------+------------+ 323 | --ClientHello--> | IP_P:p_P | IP_Jl:p_Jl | 324 | --ClientHello--> | IP_Jr:p_Jr| IP_R:5684 | 325 | | | | 326 | <--ServerHello-- | IP_R:5684 | IP_Jr:p_Jr | 327 | : | | | 328 | <--ServerHello-- : | IP_Jl:p_Jl| IP_P:p_P | 329 | : : | | | 330 | [DTLS messages] | : | : | 331 | : : | : | : | 332 | --Finished--> : | IP_P:p_P | IP_Jl:p_Jl | 333 | --Finished--> | IP_Jr:p_Jr| IP_R:5684 | 334 | | | | 335 | <--Finished-- | IP_R:5684 | IP_Jr:p_Jr | 336 | <--Finished-- | IP_Jl:p_Jl| IP_P:p_P | 337 | : : | : | : | 338 +---------------------------------------+-------------+------------+ 339 IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client) 340 IP_R:5684 = Routable IP address and coaps port of Registrar 341 IP_Jl:p_Jl = Link-local IP address and join-port of Join Proxy 342 IP_Jr:p_Jr = Routable IP address and client port of Join Proxy 344 Figure 2: constrained stateful joining message flow with 345 Registrar address known to Join Proxy. MINOR: ClientHello/ServerHello/Finished are DTLS messages. They should be written as "DTLS Client Hello/..." in the table. Likewise [DTLS messages] should be written as [other DTLS messages] MINOR: If possible, the %IF should be added (width of table may be issue). MINOR: The fact that the different message types are shown can make implementers think that there is any message type dependent mapping behavior, whereas in reality all messages have the same (IP_p%IF, p_P, IP_Jl%IF, p_Jl) <=> (IP_R, p_r, IP_jr, p_Jr) mapping. Therefore i do not find the table particularily helpful. Instead maybe something like this: +------------+---------------+-------------+ | Pledge | Join Proxy | Registrar | | (P) | (J) | (R) | +------------+---------------+-------------+ | --DTLS ClientHello--> | | ....................................... | | create mapping state: | |(IP_p%IF,p_P,IP_Jl%IF,p_Jl) | | <=> | | (IP_R, p_r, IP_jr, p_Jr)| | ....................................... | | --DTLS ClientHello--> | | | | <--DTLS ServerHello-- | | : | | <--DTLS ServerHello-- : | | : : | | [Other DTLS messages] | | : : | | --DTLS Finished--> : | | --DTLS Finished--> | | | | <--DTLS Finished-- | | <--DTLS Finished-- | | : : | | Timeout XXX seconds | | ....................................... | | expire mapping state | +------------------------------------------+ 339 IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client) 347 5.2. Stateless Join Proxy 349 The stateless Join Proxy aims to minimize the requirements on the 350 constrained Join Proxy device. Stateless operation requires no 351 memory in the Join Proxy device, but may also reduce the CPU impact NIT: s/but may/and it may/ 352 as the device does not need to search through a state table. 354 If an untrusted Pledge that can only use link-local addressing wants NIT: "untrusted" - remove. Wrong. (as in, whats a trusted Pledge and how would it work differently for it... no such thing). 355 to contact a trusted Registrar, and the Registrar is more than one 356 hop away, it sends its DTLS messages to the Join Proxy. NIT: s/DTLS/UDP/ 358 When a Pledge attempts a DTLS connection to the Join Proxy, it uses 359 its link-local IP address as its IP source address. This message is 360 transmitted one-hop to a neighboring (Join Proxy) node. MINOR: IMHO add after "node": | as in the case of the stateful proxy. To the Pledge, there is no difference between the stateful and stateless constrained Join Proxy. 360 Under normal 361 circumstances, this message would be dropped at the neighbor node 362 since the Pledge is not yet IP routable or is not yet authenticated 363 to send messages through the network. However, if the neighbor 364 device has the Join Proxy functionality enabled; it routes the DTLS 365 message to its Registrar of choice. MINOR: These two sentences are just wrong. The packet is addressed to a UDP port on the Join Proxy, so even if the join proxy was not running on the port, the packet would not be dropped because of the destination IP address, but because of no aplication sitting on the UDP port. Likewise the Join Proxy does not route the UDP (not DTLS) message, but it recreates a new UDP packet. And the Join Proxy does not make it a router, at least not for what i hope the IETF considers to be a router ;-) Aka: The draft gets better by removing these two sentences (or rewrite so they'd be correct, but i think it's surplus details). 367 The Join Proxy transforms the DTLS message to a JPY message which 368 includes the DTLS data as payload, and sends the JPY message to the 369 join-port of the Registrar. MINOR: Also wrong (UDP Message, JPY abbreviation used but not introduced, "transformation" may be a way to think about it as an implementer, but not correct wrt. to IETF terminology). Maybe something like this: The constrained Join Proxy creates a new "Join ProxY" (JPY) UDP message from the received UDP payload and forwards it to the Registrar. 371 The JPY message payload consists of two parts: 373 * Header (H) field: consisting of the source link-local address and 374 port of the Pledge (P), and NIT: source port of the Pledge NIT: ...and indication for the interface on which the Join Proxy received the message from the Pledge 376 * Contents (C) field: containing the original DTLS payload. NIT: UDP payload. 378 On receiving the JPY message, the Registrar (or proxy) retrieves the 379 two parts. NIT: I would remove the (or proxy) here, as it sounds confusing. Better keep the description how Registrar and Proxy handle received JPY messages separate, because there are significant differences. 381 The Registrar transiently stores the Header field information. The MAYOR: I think this is fundamentally wrong, but maybe i am wrong: AFAIK, DTLS operates like TLS (just with some crappy IPX 1980'th style stop-and-wait ARQ and shoving off responsiblity for congestion control to RFC8085 - sorry, couldn't resist). Aka: Received DTLS messages need to be assigned to a DTLS connection, and tht connection state is normally bound to the 5-tuple: (InitiatorIP,InitiatorPort,UDP,ResponderIP,ResponderPort) In the case of using a Join Proxy, this connection state really needs to be: ((InitiatorLL-IP,InitiatorInterface, JP-IP), (InitiatorPort, JP-Port) ,UDP,ResponderIP,ResponderPort) So the fields are not transient, but they become in one way of modelling it, part of new, composide InitiatorIP / InitiatorPort fields for the DTLS connection state. Of course, it's perfectly fine to assume the JPY header is opaque (as you do), in which case the description would say that accordingly, e.g.: DTLS connections state on registrar: (JPY-Header, JP-IP-address, JP-Port ,UDP, Registrar-IP, Registrar-Port) If this is not correctly described/implemented, we again would end up for Registrars only being able to register one Pledge only at a time across a particular Join Proxy. Maybe this is a limitation that is acceptable, but if so, then it should be very explicitly be described. I for once am quite worried about enrolments that are not finishing in a snap but linger on, and then you definitely do not want that limitation. 382 Registrar uses the Contents field to execute the Registrar 383 functionality. However, when the Registrar replies, it also extends 384 its DTLS message with the header field in a JPY message and sends it 385 back to the Join Proxy. The Registrar SHOULD NOT assume that it can NIT: DTLS/UDP message 386 decode the Header Field, it should simply repeat it when responding. 387 The Header contains the original source link-local address and port 388 of the Pledge from the transient state stored earlier and the 389 Contents field contains the DTLS payload. 391 On receiving the JPY message, the Join Proxy retrieves the two parts. 392 It uses the Header field to route the DTLS message containing the 393 DTLS payload retrieved from the Contents field to the Pledge. NIT: s/route/recreate/ NIT: s/the DTLS message/UDP message/ NIT: s/DTLS payload/UDP payload/ 395 In this scenario, both the Registrar and the Join Proxy use 396 discoverable join-ports, for the Join Proxy this may be a default NIT: s/join-ports/UDP join-ports/ 397 CoAP port. 399 The Figure 3 depicts the message flow diagram: 401 +--------------+------------+---------------+-----------------------+ 402 | Pledge | Join Proxy | Registrar | Message | 403 | (P) | (J) | (R) |Src_IP:port|Dst_IP:port| 404 +--------------+------------+---------------+-----------+-----------+ 405 | --ClientHello--> | IP_P:p_P |IP_Jl:p_Jl | 406 | --JPY[H(IP_P:p_P),--> | IP_Jr:p_Jr|IP_R:p_Ra | 407 | C(ClientHello)] | | | 408 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jr:p_Jr | 409 | C(ServerHello)] | | | 410 | <--ServerHello-- | IP_Jl:p_Jl|IP_P:p_P | 411 | : | | | 412 | [ DTLS messages ] | : | : | 413 | : | : | : | 414 | --Finished--> | IP_P:p_P |IP_Jr:p_Jr | 415 | --JPY[H(IP_P:p_P),--> | IP_Jl:p_Jl|IP_R:p_Ra | 416 | C(Finished)] | | | 417 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jr:p_Jr | 418 | C(Finished)] | | | 419 | <--Finished-- | IP_Jl:p_Jl|IP_P:p_P | 420 | : | : | : | 421 +-------------------------------------------+-----------+-----------+ 422 IP_P:p_P = Link-local IP address and port of the Pledge 423 IP_R:p_Ra = Routable IP address and join-port of Registrar 424 IP_Jl:p_Jl = Link-local IP address and join-port of Join Proxy 425 IP_Jr:p_Jr = Routable IP address and port of Join Proxy 427 JPY[H(),C()] = Join Proxy message with header H and content C 429 Figure 3: constrained stateless joining message flow. 431 5.3. Stateless Message structure 433 The JPY message is constructed as a payload with media-type 434 application/cbor NIT: UDP payload ?! NIT/Q: Why do you refer to media-type application/cbor ? Where would that media-type designation ever show up explicitly ? Aka: Is it not simply a CBOR encoded UDP payload ? I would avoid referrring to media-type unless there actually is any signaling where we use that designation for JPY messages. 436 Header and Contents fields together are one CBOR array of 5 elements: 438 1. header field: containing a CBOR array [RFC8949] with the Pledge 439 IPv6 Link Local address as a CBOR byte string, the Pledge's UDP 440 port number as a CBOR integer, the IP address family (IPv4/IPv6) 441 as a CBOR integer, and the proxy's ifindex or other identifier 442 for the physical port as CBOR integer. The header field is not 443 DTLS encrypted. MINOR: Why is the proxy not using RFC9164 for the Pledge IP address, including the zone-identifier to indicate port/interface ? That would reduce the header to two fields (ip-address and port) Here is the cut-down CDDL (from RFC9164) for what we'd need for the JP: ll-ip-address = ll-ipv6-address / ll-ipv4-address ll-ipv6-address = #6.54(ll-ipv6-address-with-prefix) ll-ipv4-address-or-prefix = #6.52(ll-ipv4-address-with-prefix) ipv6-address = bytes .size 16 ipv4-address = bytes .size 4 ll-ipv6-address-with-prefix = [ipv6-address, null, ip-zone-identifier] ll-ipv4-address-with-prefix = [ipv4-address, null, ip-zone-identifier] ipv6-prefix-bytes = bytes .size (uint .le 16) ipv4-prefix-bytes = bytes .size (uint .le 4) ip-zone-identifier = uint / text 445 2. Content field: containing the DTLS payload as a CBOR byte string. 447 The address family integer is defined in [family] with: 449 1 IP (IP version 4) 450 2 IP6 (IP version 6) 452 The Join Proxy cannot decrypt the DTLS payload and has no knowledge 453 of the transported media type. 455 JPY_message = 456 [ 457 ip : bstr, 458 port : int, 459 family : int, 460 index : int 461 content : bstr 462 ] MINOR: You need to specify that this is formatted in CDDL, RFC8610. Also, if you take my suggesting for the RFC9164 formatting, it would be: JPY_message = [ ll-ip-address, port : int, content : bstr ] Plus the CDDL to define ll-ip-address from above (or just referring to RFC9164 and specifying what options are permissible). 464 Figure 4: CDDL representation of JPY message 466 The contents are DTLS encrypted. In CBOR diagnostic notation the NIT: "content is" 467 payload JPY[H(IP_P:p_P)], will look like: 469 [h'IP_p', p_P, family, ident, h'DTLS-payload'] 471 On reception by the Registrar, the Registrar MUST verify that the 472 number of array elements is larger than or equal to 5, and reject the 473 message when the number of array elements is smaller than 5. After 474 replacing the 5th "content" element with the DTLS payload of the 475 response message and leaving all other array elements unchanged, the 476 Registrar returns the response message. MAYOR: Except - see above, the DTLS state machinery would not work if it didn't have access to the header fields to match the message to a connection (AFAIK). 478 Examples are shown in Appendix A. 480 The header field is completely opaque to the receiver. A Registrar 481 MUST copy the header and return it unmodified in the return message. NIT: s/copy the header// - copy where / what / why (aka: the MUST requirement applies to the unmodified return, how this is done internally is subject to the state explanations). 483 6. Discovery 485 It is assumed that Join Proxy seamlessly provides a coaps connection NIT: s/assumed/desirable/ NIT: s/that Join/that a Join/ NIT: s/provides/enables/ 486 between Pledge and Registrar. In particular this section extends NIT?: Add "without requiring additional configuration for the Join Proxy" ? 487 section 4.1 of [RFC8995] for the constrained case. 489 The discovery follows two steps with two alternatives for step 1: 491 * Step 1. Two alternatives exist (near and remote): 493 - Near: the Pledge is one hop away from the Registrar. The 494 Pledge discovers the link-local address of the Registrar as 495 described in [I-D.ietf-ace-coap-est]. From then on, it follows 496 the BRSKI process as described in [I-D.ietf-ace-coap-est] and 497 [I-D.ietf-anima-constrained-voucher], using link-local 498 addresses. 500 - Remote: the Pledge is more than one hop away from a relevant 501 Registrar, and discovers the link-local address and join-port 502 of a Join Proxy. The Pledge then follows the BRSKI procedure 503 using the link-local address of the Join Proxy. 505 * Step 2. The enrolled Join Proxy discovers the join-port of the 506 Registrar. NIT: ... in support of the Remote case of Step 1. 508 The order in which the two alternatives of step 1 are tried is 509 installation dependent. The trigger for discovery in Step 2 is 510 implementation dependent. MINOR: I do not know what "installation dependent" means. I understand "implementation choice", but i think you mean something else, and what that is is not explained. 512 Once a Pledge is enrolled, it may function as Join Proxy. The Join 513 Proxy functions are advertised as described below. In principle, the 514 Join Proxy functions are offered via a join-port, and not the 515 standard coaps port. Also, the Registrar offers a join-port to which 516 the stateless Join Proxy sends the JPY message. The Join Proxy and 517 Registrar show the extra join-port number when responding to a NIT: s/show/indicate/ 518 /.well-known/core discovery request addressed to the standard coap/ 519 coaps port. 521 Three discovery cases are discussed: Join Proxy discovers Registrar, 522 Pledge discovers Registrar, and Pledge discovers Join Proxy. Each 523 discovery case considers three alternatives: CoAP based discovery, 524 GRASP Based discovery, and 6tisch based discovery. The choice of NIT: add reference to GRASP [RFC8990] 525 discovery mechanism depends on the type of installation, and 526 manufacturers can provide the pledge/Join Proxy with support for more 527 than one discovery mechanism. The pledge/Join Proxy can be designed 528 to dynamically try different discovery mechanisms until a successful 529 discovery mechanism is found, or the choice of discovery mechanism 530 could be configured during device installation. 532 6.1. Join Proxy discovers Registrar 534 In this section, the Join Proxy and Registrar are assumed to 535 communicate via Link-Local addresses. This section describes the 536 discovery of the Registrar by the Join Proxy. 538 6.1.1. CoAP discovery 540 The discovery of the coaps Registrar, using coap discovery, by the 541 Join Proxy follows sections 6.3 and 6.5.1 of 542 [I-D.ietf-anima-constrained-voucher]. MINOR: I like the explicit reference to section numbres, but given how that draft may even finish IETF later than this one, it would be very prudent to add something like [RFC-editor: the section numbers are correct as of version XXX of the referenced draft] That is a goo indicator to update the section numbers as necessary should they change later on in the lifetime of that other draft when this one may already be waiting for unresolved dependencies. 542 [I-D.ietf-anima-constrained-voucher]. The stateless Join Proxy can 543 discover the join-port of the Registrar by sending a GET request to 544 "/.well-known/core" including a resource type (rt) parameter with the 545 value "brski.rjp" [RFC6690]. Upon success, the return payload will 546 contain the join-port of the Registrar. 548 REQ: GET coap://[IP_address]/.well-known/core?rt=brski.rjp 550 RES: 2.05 Content 551 <coaps://[IP_address]:join-port>; rt="brski.rjp" 553 The discoverable port numbers are usually returned for Join Proxy 554 resources in the <URI-Reference> of the payload (see section 5.1 of 555 [I-D.ietf-ace-coap-est]). Q: How does a join proxy discover the IP address of the Registrar ? A: I think this is the CoaP link-local multicast explained below. Some reshuffling so that the explanation is earlier here would be great (or forward reference to the section below). 557 6.1.2. GRASP discovery 559 This section is normative for uses with an ANIMA ACP. In the context 560 of autonomic networks, the Join Proxy uses the DULL GRASP M_FLOOD 561 mechanism to announce itself. Section 4.1.1 of [RFC8995] discusses 562 this in more detail. The Registrar announces itself using ACP 563 instance of GRASP using M_FLOOD messages. Autonomic Network Join 564 Proxies MUST support GRASP discovery of Registrar as described in 565 section 4.3 of [RFC8995]. 567 6.1.3. 6tisch discovery 569 The discovery of the Registrar by the Join Proxy uses the enhanced 570 beacons as discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. MINOR: That doesn't seem to work ? 572 6.2. Pledge discovers Registrar 574 In this section, the Pledge and Registrar are assumed to communicate 575 via Link-Local addresses. This section describes the discovery of 576 the Registrar by the Pledge. 578 6.2.1. CoAP discovery 580 The discovery of the coaps Registrar, using coap discovery, by the 581 Pledge follows sections 6.3 and 6.5.1 of 582 [I-D.ietf-anima-constrained-voucher]. 584 6.2.2. GRASP discovery 586 This section is normative for uses with an ANIMA ACP. In the context 587 of autonomic networks, the Pledge uses the DULL GRASP M_FLOOD 588 mechanism to announce itself. Section 4.1.1 of [RFC8995] discusses 589 this in more detail. The Registrar announces itself using ACP 590 instance of GRASP using M_FLOOD messages. Autonomic Network Join 591 Proxies MUST support GRASP discovery of Registrar as described in 592 section 4.3 of [RFC8995] . 594 6.2.3. 6tisch discovery 596 The discovery of Registrar by the Pledge uses the enhanced beacons as 597 discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 599 6.3. Pledge discovers Join Proxy 601 In this section, the Pledge and Join Proxy are assumed to communicate 602 via Link-Local addresses. This section describes the discovery of 603 the Join Proxy by the Pledge. 605 6.3.1. CoAP discovery 607 In the context of a coap network without Autonomic Network support, NIT: s/Autonomic Network/ACP ([RFC8994])/ 608 discovery follows the standard coap policy. The Pledge can discover 609 a Join Proxy by sending a link-local multicast message to ALL CoAP 610 Nodes with address FF02::FD. Multiple or no nodes may respond. The NIT: Can you give an RFC/section reference where that is specified (the ALL CoAP multicast functionality ? 611 handling of multiple responses and the absence of responses follow 612 section 4 of [RFC8995]. 614 The join-port of the Join Proxy is discovered by sending a GET 615 request to "/.well-known/core" including a resource type (rt) 616 parameter with the value "brski.jp" [RFC6690]. Upon success, the 617 return payload will contain the join-port. 619 The example below shows the discovery of the join-port of the Join 620 Proxy. 622 REQ: GET coap://[FF02::FD]/.well-known/core?rt=brski.jp 624 RES: 2.05 Content 625 <coaps://[IP_address]:join-port>; rt="brski.jp" 627 Port numbers are assumed to be the default numbers 5683 and 5684 for 628 coap and coaps respectively (sections 12.6 and 12.7 of [RFC7252]) 629 when not shown in the response. Discoverable port numbers are 630 usually returned for Join Proxy resources in the <URI-Reference> of 631 the payload (see section 5.1 of [I-D.ietf-ace-coap-est]). 633 6.3.2. GRASP discovery 635 This section is normative for uses with an ANIMA ACP. The Pledge 636 MUST listen for GRASP M_FLOOD [RFC8990] announcements of the 637 objective: "AN_Proxy". See section 4.1.1 [RFC8995] for the details 638 of the objective. 640 6.3.3. 6tisch discovery 642 The discovery of the Join Proxy by the Pledge uses the enhanced 643 beacons as discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 645 7. Comparison of stateless and stateful modes 647 The stateful and stateless mode of operation for the Join Proxy have 648 their advantages and disadvantages. This section should enable to 649 make a choice between the two modes based on the available device 650 resources and network bandwidth. 652 +-------------+----------------------------+------------------------+ 653 | Properties | Stateful mode | Stateless mode | 654 +-------------+----------------------------+------------------------+ 655 | State |The Join Proxy needs | No information is | 656 | Information |additional storage to | maintained by the Join | 657 | |maintain mapping between | Proxy. Registrar needs | 658 | |the address and port number | to store the packet | 659 | |of the Pledge and those | header. | 660 | |of the Registrar. | | 661 +-------------+----------------------------+------------------------+ 662 |Packet size |The size of the forwarded |Size of the forwarded | 663 | |message is the same as the |message is bigger than | 664 | |original message. |the original,it includes| 665 | | |additional information | 666 +-------------+----------------------------+------------------------+ 667 |Specification|The Join Proxy needs |New JPY message to | 668 |complexity |additional functionality |encapsulate DTLS payload| 669 | |to maintain state |The Registrar | 670 | |information, and specify |and the Join Proxy | 671 | |the source and destination |have to understand the | 672 | |addresses of the DTLS |JPY message in order | 673 | |handshake messages |to process it. | NIT: Yikes... specific references to "DTLS handshake messages" ? Whats special about them vs. any of the other DTLS messages. Seems to be incorrect. 674 +-------------+----------------------------+------------------------+ 675 | Ports | Join Proxy needs |Join Proxy and Registrar| 676 | | discoverable join-port |need discoverable | 677 | | | join-ports | 678 +-------------+----------------------------+------------------------+ 680 Figure 5: Comparison between stateful and stateless mode MAYOR: I did bring this up in a prior email, but just to repeat in this review: It is unclear to me, and should be explained in this document how to ensure interop between Pledges/Proxies and Registrars. E.g.: Is the interop model such that customers have to buy Pledges and Registrars by matching up their supported: - Proxy-Mode: stateful or stateless (only one can be active) - Discovery protocol: must be the same for all nodes in network... ? 682 8. Security Considerations 684 All the concerns in [RFC8995] section 4.1 apply. The Pledge can be 685 deceived by malicious Join Proxy announcements. The Pledge will only 686 join a network to which it receives a valid [RFC8366] voucher 687 [I-D.ietf-anima-constrained-voucher]. Once the Pledge joined, the 688 payload between Pledge and Registrar is protected by DTLS. 690 A malicious constrained Join Proxy has a number of routing 691 possibilities: 693 * It sends the message on to a malicious Registrar. This is the 694 same case as the presence of a malicious Registrar discussed in 695 RFC 8995. 697 * It does not send on the request or does not return the response 698 from the Registrar. This is the case of the not responding or 699 crashing Registrar discussed in RFC 8995. 701 * It uses the returned response of the Registrar to enroll itself in 702 the network. With very low probability it can decrypt the 703 response. Successful enrollment is deemed too unlikely. 705 * It uses the request from the pledge to appropriate the pledge 706 certificate, but then it still needs to acquire the private key of 707 the pledge. Also this is assumed to be highly unlikely. 709 * A malicious node can construct an invalid Join Proxy message. 710 Suppose, the destination port is the coaps port. In that case, a 711 Join Proxy can accept the message and add the routing addresses 712 without checking the payload. The Join Proxy then routes it to 713 the Registrar. In all cases, the Registrar needs to receive the 714 message at the join-port, checks that the message consists of two 715 parts and uses the DTLS payload to start the BRSKI procedure. It 716 is highly unlikely that this malicious payload will lead to node 717 acceptance. 719 * A malicious node can sniff the messages routed by the constrained 720 Join Proxy. It is very unlikely that the malicious node can 721 decrypt the DTLS payload. A malicious node can read the header 722 field of the message sent by the stateless Join Proxy. This 723 ability does not yield much more information than the visible 724 addresses transported in the network packets. 726 It should be noted here that the contents of the CBOR array used to 727 convey return address information is not DTLS protected. When the 728 communication between JOIN Proxy and Registrar passes over an 729 unsecure network, an attacker can change the CBOR array, causing the 730 Registrar to deviate traffic from the intended Pledge. These 731 concerns are also expressed in [RFC8974]. It is also pointed out 732 that the encryption in the source is a local matter. Similarly to 733 [RFC8974], the use of AES-CCM [RFC3610] with a 64-bit tag is 734 recommended, combined with a sequence number and a replay window. 736 If such scenario needs to be avoided, the constrained Join Proxy MUST 737 encrypt the CBOR array using a locally generated symmetric key. The 738 Registrar is not able to examine the encrypted result, but does not 739 need to. The Registrar stores the encrypted header in the return 740 packet without modifications. The constrained Join Proxy can decrypt 741 the contents to route the message to the right destination. 743 In some installations, layer 2 protection is provided between all 744 member pairs of the mesh. In such an enviroment encryption of the 745 CBOR array is unnecessay because the layer 2 protection already 746 provide it. MINOR: I think this is missing the state attack against the stateful proxy and in result against neighboring valid pledges that can not enroll. That should vbe the mayor reason IMHO to btw. be stronger above and recommend stateless unless there is a strong reason against it (which i am not aware what it should be). The second reason for stateless is easier diagnostics of enrolment on the REgistrar IMHO (might also go above into the table). 748 9. IANA Considerations 750 9.1. Resource Type Attributes registry 752 This specification registers two new Resource Type (rt=) Link Target 753 Attributes in the "Resource Type (rt=) Link Target Attribute Values" 754 subregistry under the "Constrained RESTful Environments (CoRE) 755 Parameters" registry per the [RFC6690] procedure. 757 Attribute Value: brski.jp 758 Description: This BRSKI resource type is used to query and return 759 the supported BRSKI resources of the constrained 760 Join Proxy. 761 Reference: [this document] 763 Attribute Value: brski.rjp 764 Description: This BRSKI resource type is used for the constrained 765 Join Proxy to query and return Join Proxy specific 766 BRSKI resources of a Registrar. 767 Reference: [this document] 769 9.2. service name and port number registry 771 This specification registers two service names under the "Service 772 Name and Transport Protocol Port Number" registry. 774 Service Name: brski-jp 775 Transport Protocol(s): udp 776 Assignee: IESG <[email protected]> 777 Contact: IESG <[email protected]> 778 Description: Bootstrapping Remote Secure Key Infrastructure 779 constrained Join Proxy 780 Reference: [this document] 782 Service Name: brski-rjp 783 Transport Protocol(s): udp 784 Assignee: IESG <[email protected]> 785 Contact: IESG <[email protected]> 786 Description: Bootstrapping Remote Secure Key Infrastructure 787 Registrar join-port used by stateless constrained 788 Join Proxy 789 Reference: [this document] 791 10. Acknowledgements 793 Many thanks for the comments by Cartsen, Bormann, Brian Carpenter, 794 Esko Dijk, Toerless Eckert, Russ Housley, Ines Robles, Juergen 795 Schoenwaelder, Malisa Vučinić, and Rob Wilton. NIT: Fix up Malisa's Surname please. NIT: One idea, i started in my latest draft was to put the role behind the name when the review was triggered by a role. 797 11. Contributors 799 Sandeep Kumar, Sye loong Keoh, and Oscar Garcia-Morchon are the co- 800 authors of the draft-kumar-dice-dtls-relay-02. Their draft has 801 served as a basis for this document. Much text from their draft is 802 copied over to this draft. 804 12. Changelog 806 12.1. 10 to 09 808 * OPSDIR review 809 * IANA review 810 * SECDIR review 811 * GENART review 813 12.2. 09 to 07 815 * typos 817 12.3. 06 to 07 819 * AD review changes 821 12.4. 05 to 06 823 * RT value change to brski.jp and brski.rjp 824 * new registry values for IANA 825 * improved handling of jpy header array 827 12.5. 04 to 05 829 * Join Proxy and join-port consistent spelling 830 * some nits removed 831 * restructured discovery 832 * section 833 * rephrased parts of security section 835 12.6. 03 to 04 837 * mail address and reference 839 12.7. 02 to 03 841 * Terminology updated 842 * Several clarifications on discovery and routability 843 * DTLS payload introduced 845 12.8. 01 to 02 847 * Discovery of Join Proxy and Registrar ports 849 12.9. 00 to 01 851 * Registrar used throughout instead of EST server 853 * Emphasized additional Join Proxy port for Join Proxy and Registrar 855 * updated discovery accordingly 857 * updated stateless Join Proxy JPY header 859 * JPY header described with CDDL 861 * Example simplified and corrected 863 12.10. 00 to 00 865 * copied from vanderstok-anima-constrained-join-proxy-05 867 13. References 868 13.1. Normative References 870 [family] "Address Family Numbers", 19 October 2021, 871 <https://www.iana.org/assignments/address-family-numbers/ 872 address-family-numbers.xhtml>. 874 [I-D.ietf-ace-coap-est] 875 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 876 Raza, "EST over secure CoAP (EST-coaps)", Work in 877 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 878 January 2020, <https://www.ietf.org/archive/id/draft-ietf- 879 ace-coap-est-18.txt>. 881 [I-D.ietf-anima-constrained-voucher] 882 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 883 Dijk, "Constrained Bootstrapping Remote Secure Key 884 Infrastructure (BRSKI)", Work in Progress, Internet-Draft, 885 draft-ietf-anima-constrained-voucher-17, 7 April 2022, 886 <https://www.ietf.org/archive/id/draft-ietf-anima- 887 constrained-voucher-17.txt>. 889 [ieee802-1AR] 890 "IEEE 802.1AR Secure Device Identifier", 2009, 891 <https://standards.ieee.org/standard/802.1AR-2009.html>. 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, 895 DOI 10.17487/RFC2119, March 1997, 896 <https://www.rfc-editor.org/info/rfc2119>. 898 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 899 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 900 January 2012, <https://www.rfc-editor.org/info/rfc6347>. 902 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 903 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 904 May 2017, <https://www.rfc-editor.org/info/rfc8174>. 906 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 907 "A Voucher Artifact for Bootstrapping Protocols", 908 RFC 8366, DOI 10.17487/RFC8366, May 2018, 909 <https://www.rfc-editor.org/info/rfc8366>. 911 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 912 Representation (CBOR)", STD 94, RFC 8949, 913 DOI 10.17487/RFC8949, December 2020, 914 <https://www.rfc-editor.org/info/rfc8949>. 916 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 917 Autonomic Signaling Protocol (GRASP)", RFC 8990, 918 DOI 10.17487/RFC8990, May 2021, 919 <https://www.rfc-editor.org/info/rfc8990>. 921 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 922 and K. Watsen, "Bootstrapping Remote Secure Key 923 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 924 May 2021, <https://www.rfc-editor.org/info/rfc8995>. 926 13.2. Informative References 928 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 929 (editor), D. D. and M. Richardson, "Encapsulation of 930 6TiSCH Join and Enrollment Information Elements", Work in 931 Progress, Internet-Draft, draft-ietf-6tisch-enrollment- 932 enhanced-beacon-14, 21 February 2020, 933 <https://www.ietf.org/archive/id/draft-ietf-6tisch- 934 enrollment-enhanced-beacon-14.txt>. 936 [I-D.kumar-dice-dtls-relay] 937 Kumar, S. S., Keoh, S. L., and O. Garcia-Morchon, "DTLS 938 Relay for Constrained Environments", Work in Progress, 939 Internet-Draft, draft-kumar-dice-dtls-relay-02, 20 October 940 2014, <https://www.ietf.org/archive/id/draft-kumar-dice- 941 dtls-relay-02.txt>. 943 [I-D.richardson-anima-state-for-joinrouter] 944 Richardson, M. C., "Considerations for stateful vs 945 stateless join router in ANIMA bootstrap", Work in 946 Progress, Internet-Draft, draft-richardson-anima-state- 947 for-joinrouter-03, 22 September 2020, 948 <https://www.ietf.org/archive/id/draft-richardson-anima- 949 state-for-joinrouter-03.txt>. 951 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 952 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 953 2003, <https://www.rfc-editor.org/info/rfc3610>. 955 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 956 "Transmission of IPv6 Packets over IEEE 802.15.4 957 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 958 <https://www.rfc-editor.org/info/rfc4944>. 960 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 961 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 962 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 963 Low-Power and Lossy Networks", RFC 6550, 964 DOI 10.17487/RFC6550, March 2012, 965 <https://www.rfc-editor.org/info/rfc6550>. 967 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 968 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 969 <https://www.rfc-editor.org/info/rfc6690>. 971 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 972 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 973 <https://www.rfc-editor.org/info/rfc6763>. 975 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 976 Bormann, "Neighbor Discovery Optimization for IPv6 over 977 Low-Power Wireless Personal Area Networks (6LoWPANs)", 978 RFC 6775, DOI 10.17487/RFC6775, November 2012, 979 <https://www.rfc-editor.org/info/rfc6775>. 981 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 982 "Enrollment over Secure Transport", RFC 7030, 983 DOI 10.17487/RFC7030, October 2013, 984 <https://www.rfc-editor.org/info/rfc7030>. 986 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 987 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 988 2014, <https://www.rfc-editor.org/info/rfc7102>. 990 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 991 Constrained-Node Networks", RFC 7228, 992 DOI 10.17487/RFC7228, May 2014, 993 <https://www.rfc-editor.org/info/rfc7228>. 995 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 996 Application Protocol (CoAP)", RFC 7252, 997 DOI 10.17487/RFC7252, June 2014, 998 <https://www.rfc-editor.org/info/rfc7252>. 1000 [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and 1001 Stateless Clients in the Constrained Application Protocol 1002 (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, 1003 <https://www.rfc-editor.org/info/rfc8974>. 1005 Appendix A. Stateless Proxy payload examples 1007 The examples show the request "GET coaps://192.168.1.200:5965/est/ 1008 crts" to a Registrar. The header generated between Join Proxy and 1009 Registrar and from Registrar to Join Proxy are shown in detail. The 1010 DTLS payload is not shown. 1012 The request from Join Proxy to Registrar looks like: 1014 85 # array(5) 1015 50 # bytes(16) 1016 FE800000000000000000FFFFC0A801C8 # 1017 19 BDA7 # unsigned(48551) 1018 01 # unsigned(1) IP 1019 00 # unsigned(0) 1020 58 2D # bytes(45) 1021 <cacrts DTLS encrypted request> 1023 In CBOR Diagnostic: 1025 [h'FE800000000000000000FFFFC0A801C8', 48551, 1, 0, 1026 h'<cacrts DTLS encrypted request>'] 1028 The response is: 1030 85 # array(5) 1031 50 # bytes(16) 1032 FE800000000000000000FFFFC0A801C8 # 1033 19 BDA7 # unsigned(48551) 1034 01 # unsigned(1) IP 1035 00 # unsigned(0) 1036 59 026A # bytes(618) 1037 <cacrts DTLS encrypted response> 1039 In CBOR diagnostic: 1041 [h'FE800000000000000000FFFFC0A801C8', 48551, 1, 0, 1042 h'<cacrts DTLS encrypted response>'] 1044 Authors' Addresses 1046 Michael Richardson 1047 Sandelman Software Works 1048 Email: [email protected] 1050 Peter van der Stok 1051 vanderstok consultancy 1052 Email: [email protected] 1054 Panos Kampanakis 1055 Cisco Systems 1056 Email: [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
