idnits 2.17.1 draft-richardson-anima-state-for-joinrouter-01.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2016) is 2828 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-block' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 401, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-6lo-paging-dispatch-03 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-07 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational July 21, 2016 5 Expires: January 22, 2017 7 Considerations for stateful vs stateless join router in ANIMA bootstrap 8 draft-richardson-anima-state-for-joinrouter-01 10 Abstract 12 This document explores a number of issues affecting the decision to 13 use a stateful or stateless forwarding mechanism by the join router 14 (aka join assistant) during the bootstrap process for ANIMA. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 22, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Purpose of the Joiner Router/Join Assistant . . . . . . . . . 2 53 3. Overview of suggested methods . . . . . . . . . . . . . . . . 3 54 3.1. method 1: Circuit Proxy method . . . . . . . . . . . . . 3 55 3.2. method 2: NAPT66 method . . . . . . . . . . . . . . . . . 3 56 3.3. method 3: HTTP Proxy method . . . . . . . . . . . . . . . 4 57 3.4. method 4: CoAP/DTLS with relay mechanism . . . . . . . . 4 58 3.5. method 5: HTTP with IPIP tunnel . . . . . . . . . . . . . 4 59 3.6. method 6: CoAP/DTLS with IPIP tunnel . . . . . . . . . . 5 60 4. Comparison of methods . . . . . . . . . . . . . . . . . . . . 5 61 4.1. State required on Joining Router . . . . . . . . . . . . 6 62 4.2. Bandwidth required on Joining Router . . . . . . . . . . 6 63 4.2.1. Bandwidth considerations in constrained networks . . 7 64 4.3. State required on Registrar . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 6.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 The [I-D.pritikin-anima-bootstrapping-keyinfra] defines a process to 74 securely enroll new devices in an existing network. It order to 75 avoid providing globally reachable addresses to the prospective new 76 network member, it assumes that a Join Router. The role of this 77 router is common in this kind of architecture. 79 1.1. Terminology 81 EAP [RFC5247], 802.1X and PANA [RFC5191] use the term Authenticator 82 to refer this role. 84 The Thread architecture [threadcommish] uses the term Joiner Router 86 The 6tisch architecture ([I-D.ietf-6tisch-terminology]) uses the term 87 JA, short for Join Assistant. 89 2. Purpose of the Joiner Router/Join Assistant 91 This device is one layer-2 hop from the new device. In addition to 92 whatever secured networks it might connect to, it runs a sufficiently 93 unprotected network (either physical or wireless) such that a new 94 device can connect at layer-2 without any specific credentials. 96 The new node runs a discovery protocol as explained in 97 [I-D.pritikin-anima-bootstrapping-keyinfra] to find an address for a 98 registrar to which it can run the Enrollment over Secure Transport 99 (EST, [RFC7030]. EST runs RESTfully over protocols such as HTTP. 101 The new node does not have a globally routable address, so it can not 102 speak directly outside the current link. This an intentional 103 limitation so that the new node can neither be easily attacked from 104 the general internet, nor can it attack arbitrary parts of the 105 Internet. 107 The Joiner Router provides a limited channel between the new node, 108 and the Registrar. This document is about the various options and 109 considerations that need to be considered when chosing this limited 110 channel. 112 An additional goal of this document is to outline which methods could 113 be interchangeably be used by private negotiation between the Joining 114 Router and the Registar, without the knowledge of the New Node. 116 3. Overview of suggested methods 118 3.1. method 1: Circuit Proxy method 120 In response to discovery, the circuit proxy would return a link-local 121 address on the joining router. The joining router would have a TCP 122 (or UDP/CoAP) port open on that interface. It would accept 123 connections on that port, and would turn around and create a new TCP 124 connection to the registrar. 126 While non-blocking I/O and threading mechanisms permit a single 127 process to handle dozens to thousands of such connections, in effect 128 a new circuit is created for each connection. As a new TCP 129 connection is created to the registrar it might have a different 130 address family (IPv4 vs IPv6), and it might have a different set of 131 TCP options, MSS and windowing properties. 133 3.2. method 2: NAPT66 method 135 In response to discovery, the NAT66 would return a link-local address 136 on the joining router. The joining router would establish a NAPT66 137 mapping between the address/port combination on the join side, with 138 an address/port on the ACP side. The port would be randomly 139 allocated. 141 The join router would then do a stateful mapping between the pair of 142 link-local addresses and ports, and the ACP GUA and registrar 143 addresses and ports. This method is mostly identical to what is 144 sometimes called a "port forward"; but is used from the inside to the 145 outside, rather than the converse. 147 3.3. method 3: HTTP Proxy method 149 In response to discovery, the proxy would reply with a link-local 150 address and port combination, and possibly also a URL for the 151 registrar. 153 The new node would then establish an HTTP connection to the proxy, 154 and would use the HTTP CONNECT method with the given URL to establish 155 a connection to the proper registrar. See [RFC7231] section-4.3.6. 157 Potentially a new node might attempt to other resources than the 158 intended registar. This could be a permitted activity if the 159 connection is to the new node's vendor MASA, but it will in general 160 be difficult to know what URLs are expected, and which are not. 162 The HTTP proxy would put the normal HTTP proxy headers in, such as 163 the VIA header, which may well help the registrar determine where the 164 New Node has joined. 166 3.4. method 4: CoAP/DTLS with relay mechanism 168 In reponse to discovery, the proxy would respond with a link-local 169 address and port combination. 171 The new node would then initiate a DTLS session over UDP for the 172 purpose of running CoAP on top of it. See [RFC7252] section 9.1. 174 The Join Router would then use a mechanism such as envisioned by 175 [I-D.kumar-dice-dtls-relay] to mark the real origin of the packets. 176 (Note that this ID did not get to the point of actually specifying 177 the bytes on the wire). Alternatively, the [threadcommish] specifies 178 a way to encapsulate DTLS (that would contain CoAP packets) packets 179 into CoAP, along with a clear origin for the packets. 181 3.5. method 5: HTTP with IPIP tunnel 183 In reponse to discovery, the proxy would respond with a link-local 184 address and port combination. The new node would then initiate a 185 regular HTTPS session with the given address and port as in methods 1 186 and 2. 188 Rather than create a circuit proxy or NAT66 mapping, the joining 189 router would instead encapsulate the packet in an IPIP header and 190 send it to the registrar. 192 The registrar (or a device with the registrar's IP in front of it) 193 must then implement the IPIP decapsulation, along with some way to 194 accept the connection to the link-local address of the Joining 195 Router, and route packets back again. The technology to do this is 196 either one of NAT66, or the typical "transparent" application layer 197 proxy technology of the mid-1990s. See [transparentproxy] for a 198 description in an expired patent. The mechanism is simply to #if 0 199 out the "is dest-IP local" test. This is also supported by as 200 transparent proxying in linux and squid, see [transparentsquid], and 201 is also available on BSD systems' pf and ipf. Also see: [RFC1919] 203 An issue that arises in IPv6 with link-local addresses is if the 204 joining router has more than non-loopback interface. On such a 205 system, link-local addresses must be qualified by the interface 206 identifier, usually represented as the SMI if_index to software. 207 This is a serious concern, as even on IoT-type/mesh devices where 208 there is only a single radio, there will in general be two logical 209 networks: one secured as part of the production network, and a second 210 one for joining nodes. Alternatives to IPIP encapsulation have so- 211 far been motivated by the need to store this additional context. 213 A solution to this problem is to simply have the joining router send 214 the IPIP traffic from an IPv6 address that is unique to the interface 215 on which the traffic originates. That is, even if the join network 216 will use link-local addresses, the joining router should allocate 217 additional stable private addresses (via SLACC + [RFC7217] for each 218 interface on which it runs the join protocol. The number of these 219 addresses scales with the number of logical interfaces, not the 220 number of clients that are joining> 222 3.6. method 6: CoAP/DTLS with IPIP tunnel 224 In reponse to discovery, the proxy would respond with a link-local 225 address and port combination. The new node would then initiate a 226 regular CoAP/DTLS session with the given address and port as in 227 method 4. 229 Identically to method 5, the joining router would encapsulate the 230 packet in an IPIP header and send it to the registrar. 232 This method is otherwise identical to method 4 and method 5. 234 4. Comparison of methods 236 The Circuit Proxy and NAT66 methods are mostly indistinguishable from 237 an outside observer. Careful probing with exotic TCP options, or 238 strange MSS values would reveal which is used, but this will 239 otherwise be invisible to a new node. 241 Method 3 (http-proxy) and methods 1 (circuit), 2(nat66), and 5(ipip) 242 could be made indistinguishable to the new node if methods 1,2, and 5 243 also included the URL, and instead of running TLS immediately, always 244 used the CONNECT method first. That is, the registar would accept to 245 "proxy" to itself. 247 While it is possible to proxy between HTTP and CoAP forms in a 248 mechanical fashion, it is not possible to map between DTLS and TLS 249 mechanisms without access to the private keys of both ends. 250 Therefore it is not possible to accept DTLS/CoAP packets on the 251 Joining Router and turn them into an HTTPS session to a registrar 252 that accepts only HTTPS. It is reasonable for a registrar to speak 253 both CoAP and HTTP: this could be done inside the server itself, or 254 could be part of an HTTPS/DTLS front end that normalized both 255 protocols into HTTP. There are channel binding issues that must be 256 addressed within the registrar, but they are well understood in the 257 multi-tier web framework industry. 259 4.1. State required on Joining Router 261 Methods 1(circuit), 2(nat66), and 3(proxy) require state on the 262 joining router for each client. Method 3(proxy) will tend to require 263 the most processing and state as it requires re-assembly of TCP 264 packets sufficient to interpret HTTP and perform the CONNECT 265 operation. Methods 3 and 1 both require two TCP socket structures, 266 which are on the order of hundred bytes each. 268 Method 2(nat66) can require as little as space for 4 IPv6 addresses, 269 plus two TCP port numbers, a total of 68 bytes per client system. 270 Usually there will be some index or hash overhead. Many devices may 271 be able to do this operation for a data-plane (production) network 272 interface at wire speed using a hardware CAM. Joiner Router 273 functionality may not always be able to make use of hardware, as 274 being part of the ACP, it may be implemented entirely in the control 275 plane CPU. 277 Method 4 (dtls-relay), 5(ipip-http) and 6(ipip-coap) do not require 278 any additional per-client state to be maintained by the joining 279 router. 281 4.2. Bandwidth required on Joining Router 283 All the IPIP methods have an additional header cost of 40 bytes for 284 an IPv6 header between the Joining Router and the Registrar. 286 The DTLS relay method (whether inside DTLS or via CoAP extension), 287 has the cost of an additional CoAP header or DTLS extension, 288 estimated to be around 16 bytes. 290 The TLS or DTLS headers pass between the New Node and the Registrar 291 in all cases. The DTLS header is bigger than the TLS header, but 292 this is slightly compensated by the UDP vs TCP header cost of 8 vs 20 293 bytes. The DTLS header is providing much of what the TCP header was 294 providing. 296 The HTTP proxy mechanism has an initial packet cost to send the 297 CONNECT header. 299 In Autonomic networks the backhaul from Joining Router to Registrar 300 will be over the ACP. The ACP is not generally as well provisioned 301 as the production data-plane network, but in non-constrained (see 302 [RFC7228] section 2.2 and 2.3) situations, it would be IPv6 tunneled 303 over IPsec across well-provisioned ethernet. The ACP likely capable 304 of at least 1Mb/s of traffic without significant issues. 306 4.2.1. Bandwidth considerations in constrained networks 308 In constrained-network situations, there are two situations to 309 examine. The first scenario is where the Joining Router has an 310 interface on a constrained-network, and a backhaul on a non- 311 constrained network. For instance, when the Joining Router is the 312 6LBR in a mesh-under situation, or is at the top of the DODAG in a 313 route-over situation. In that situation, there are no significant 314 constrained for the cost of backhauled packets, all constrained are 315 on the join network side. 317 The second scenario is where in the route-over network where the 318 Joining Router is a 6LR within the mesh. In the situation the 319 backhaul network path travels through one or more hops of a LLN, and 320 packet size as well as throughput is constrained. 322 Note that nothing in the discussion in this section is concerned with 323 the capablities of the Joining Router: the device could well be 324 powered and very capable, but currently not connected by any data- 325 plane networks. For instance two physically adjacent HFRs might use 326 Bluetooth or an in-chassis 802.15.4 sensor network (originally 327 intended to collect temperature readings) to communicate in order to 328 agree on an appropriate lambda for a 100G/bs fiber link. 330 There are current efforts for optimizing ROLL route-over networks to 331 compress the overhead of IPIP headers out. This is the "Example of 332 Flow from not-RPL-aware-leaf to Internet" in section 5.7 of 333 [I-D.robles-roll-useofrplinfo] and which 334 [I-D.ietf-6lo-paging-dispatch] aims to compress. 336 4.3. State required on Registrar 338 All methods require that the registrar maintain an HTTP or CoAP 339 connection with the New Node for duration of each request. HTTP/1.1 340 clients may use persistent connections if there are multiple request/ 341 responses. 343 CoAP clients are inherently single-request/responses, but it is 344 anticipated that CoAP Block-Transfer Mode [I-D.ietf-core-block]would 345 be required by EST ([RFC7030]) to transfer the certificates and 346 certificate chains, which are likely to be larger than a single UDP 347 packet. The block-transfer mode is designed to be stateless for the 348 server. It could be made more stateless if a 201 Location: header 349 reply was issued in response to a POST for /simplereenroll. 351 In both HTTP and CoAP cases, the registrar will first have 352 established a TLS or DTLS session with the client. TLS sessions 353 require on the order of a few hundred bytes of storage per client 354 session. The new node will also have a similar expense during the 355 enrollment process. This will take multiple round-trips in general, 356 although the TLS session resumption protocol may be useful in a 357 limited number of re-authentication cases. 359 5. Security Considerations 361 STUFF 363 6. References 365 6.1. Normative References 367 [I-D.ietf-6lo-paging-dispatch] 368 Thubert, P. and R. Cragie, "6LoWPAN Paging Dispatch", 369 draft-ietf-6lo-paging-dispatch-03 (work in progress), July 370 2016. 372 [I-D.ietf-6tisch-terminology] 373 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 374 "Terminology in IPv6 over the TSCH mode of IEEE 375 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 376 progress), March 2016. 378 [I-D.ietf-core-block] 379 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 380 draft-ietf-core-block-21 (work in progress), July 2016. 382 [I-D.kumar-dice-dtls-relay] 383 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 384 for Constrained Environments", draft-kumar-dice-dtls- 385 relay-02 (work in progress), October 2014. 387 [I-D.pritikin-anima-bootstrapping-keyinfra] 388 Pritikin, M., Richardson, M., Behringer, M., and S. 389 Bjarnason, "Bootstrapping Key Infrastructures", draft- 390 pritikin-anima-bootstrapping-keyinfra-02 (work in 391 progress), July 2015. 393 [I-D.robles-roll-useofrplinfo] 394 Robles, I., Richardson, M., and P. Thubert, "When to use 395 RFC 6553, 6554 and IPv6-in-IPv6", draft-robles-roll- 396 useofrplinfo-02 (work in progress), October 2015. 398 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 399 RFC 1919, March 1996. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 405 Yegin, "Protocol for Carrying Authentication for Network 406 Access (PANA)", RFC 5191, May 2008. 408 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 409 Authentication Protocol (EAP) Key Management Framework", 410 RFC 5247, August 2008. 412 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 413 "Enrollment over Secure Transport", RFC 7030, 414 DOI 10.17487/RFC7030, October 2013, 415 . 417 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 418 Interface Identifiers with IPv6 Stateless Address 419 Autoconfiguration (SLAAC)", RFC 7217, 420 DOI 10.17487/RFC7217, April 2014, 421 . 423 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 424 Constrained-Node Networks", RFC 7228, 425 DOI 10.17487/RFC7228, May 2014, 426 . 428 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 429 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 430 DOI 10.17487/RFC7231, June 2014, 431 . 433 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 434 Application Protocol (CoAP)", RFC 7252, 435 DOI 10.17487/RFC7252, June 2014, 436 . 438 6.2. Informative References 440 [threadcommish] 441 Thread Group, , "Thread Commissioning", Jul 2015, 442 . 445 [transparentproxy] 446 Hung Vu, , "CA Patent 2,136,150: Apparatus and method for 447 providing a secure gateway for communication and data 448 exchanges between networks", 1994, 449 . 451 [transparentsquid] 452 Daniel Kiracofe, , "Transparent Proxy with Linux and Squid 453 mini-HOWTO v1.15", August 2002, 454 . 456 Author's Address 458 Michael C. Richardson 459 Sandelman Software Works 460 470 Dawson Avenue 461 Ottawa, ON K1Z 5V7 462 CA 464 Email: mcr+ietf@sandelman.ca 465 URI: http://www.sandelman.ca/