idnits 2.17.1 draft-pritikin-coap-bootstrap-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.) -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2724 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6347' is mentioned on line 128, but not defined ** Obsolete undefined reference: RFC 6347 (Obsoleted by RFC 9147) == Missing Reference: 'Empty' is mentioned on line 236, but not defined == Missing Reference: 'RFC4919' is mentioned on line 295, but not defined == Missing Reference: 'RFC0791' is mentioned on line 308, but not defined == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-20 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Pritikin 3 Internet-Draft P. Kampanakis 4 Intended status: Informational Cisco Systems 5 Expires: May 4, 2017 October 31, 2016 7 BRSKI over CoAP 8 draft-pritikin-coap-bootstrap-01 10 Abstract 12 This document provides an initial discussion of Bootstrapping of 13 Remote Secure key infrastructures (BRSKI) when the device being 14 bootstrapped speaks CoAP. The HTTPS REST methods leveraged by BRSKI 15 are mapped to CoAP methods. Fragmentation management of large 16 messages during EST certificate enrollment is addressed. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 4, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 3 55 4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Message Bindings . . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 6 59 5.3. csrattr . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.4. requestaudittoken, requestauditlog . . . . . . . . . . . 7 61 6. Data Fragmentation . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Fragmented response example with Block2 . . . . . . . . . 8 63 6.2. Fragmented request example with Block1 . . . . . . . . . 11 64 6.3. Fragmented request/response example with Block1, Size1 65 and Block2 . . . . . . . . . . . . . . . . . . . . . . . 11 66 7. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 8. CoAP Parameters . . . . . . . . . . . . . . . . . . . . . . . 11 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 10. Update Tracking . . . . . . . . . . . . . . . . . . . . . . . 11 70 11. Normative References . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 Many IoT and other devices are expected to use CoAP over UDP 76 extensively. Bootstrapping these devices without requiring a full 77 TCP stack is an often raised requirement for 78 [I-D.ietf-anima-bootstrapping-keyinfra]. BRSKI provides REST methods 79 over TLS that can be functional in a UDP setting with the folling 80 necessary additions: 82 DTLS: Because the CoAP use of DTLS includes support for large 83 handshake messages there is little to describe here. BRSKI and 84 EST [RFC7030] are expanded to include DTLS. 86 REST: The mapping of BRSKI and EST messages to CoAP REST calls is 87 described. 89 Fragmentation: Use of block chaining to support fragmentation of 90 large BRSKI and EST messages is described. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in 97 [RFC2119]. 99 3. Scope of solution 101 The definition of BRSKI over DTLS and CoAP is not intended to expand 102 the scope of BRSKI to highly constrained devices. (ref: [RFC7228]). 103 Instead it is intended to ensure that bootstrapping works for less 104 constained devices that choose to limit their communications stack to 105 UDP/CoAP. 107 The BRSKI document details extensions to EST as well as making 108 section 5.7 requirements on EST flows. This document's references to 109 BRSKI are intended to include all BRSKI extensions and all existing 110 EST messages. This document could replace BRSKI -03 section 5.7.5. 111 [[TODO: making this section 5.8 might make the most sense.]] 113 Support for Observe CoAP options ( https://tools.ietf.org/html/ 114 rfc7641 ) in Blocks with BRSKI is not supported in the current BRSKI/ 115 EST message flows and is thus out-of-scope for this discussion. 116 Observe options could be used by the server to notify clients about a 117 change in the cacerts or csr attributes (resources) and might be an 118 area of future work. 120 4. DTLS 122 COAP was designed to avoid fragmentation. DTLS is used to secure 123 COAP messages. When using DTLS, even though it can be avoided by 124 using pre-shared keys or ECC ciphersuites, sometimes fragmentation 125 will be needed. During the DTLS handshake, if fragmentation is 126 necessary, "DTLS provides a mechanism for fragmenting a handshake 127 message over a number of records, each of which can be transmitted 128 separately, thus avoiding IP fragmentation" [RFC6347]. 130 Within BRSKI and EST when "TLS" is referred to, it is understood that 131 CoAP security is provided using DTLS instead. No other changes are 132 necessary (all provisional modes etc are the same as for TLS). 134 In a constrained CoAP environment, endpoints can't afford to 135 establish a DTLS connection for every EST transaction. 136 Authenticating and negotiating DTLS keys requires resources on low- 137 end endpoints and consumes valuable bandwidth. The DTLS connection 138 SHOULD remain open for persistent EST connections. For example, an 139 EST cacerts request that is followed by an simpleenroll request can 140 use the same authenticated DTLS connection. Given that after a 141 successfull enrollment, it is more likely that a new EST transaction 142 will take place after a significant amount of time, the DTLS 143 connections SHOULD only be kept alive for EST messages that are 144 relatively close to each other. 146 5. Message Bindings 148 This section describes BRSKI to CoAP message mappings. 150 CoAP defines confirmed (CON), acknowledgements (ACK), reset (RST) and 151 non-corfirmed (NON) message types. For confirmable messages, the 152 responses are CoAP ACKs or RSTs. All /cacerts, /simpleenroll, 153 /simplereenroll, /csrattrs, /fullcmc and /serverkeygen EST messages 154 expect a response, so they are all COAP CON messages. 156 The HTTP responses in BRSKI are translated to COAP Response Codes as 157 explained in [RFC7252] section 5.3.1 159 A CoAP message has the following fields ([I-D.ietf-core-block]): 161 0 1 2 3 162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 |Ver| T | TKL | Code | Message ID | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Token (if any, TKL bytes) ... 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Options (if any) ... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |1 1 1 1 1 1 1 1| Payload (if any) ... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Then Ver, TKL, Token, Message ID are not affected in BRSKI. Their 174 use is the same as in CoAP. 176 The options that can be used in a CoAP header have the following 177 format (from [I-D.ietf-core-block] Figure 8): 179 0 1 2 3 4 5 6 7 180 +---------------+---------------+ 181 | Option Delta | Option Length | 1 byte 182 +---------------+---------------+ 183 / Option Delta / 0-2 bytes 184 \ (extended) \ 185 +-------------------------------+ 186 / Option Length / 0-2 bytes 187 \ (extended) \ 188 +-------------------------------+ 189 \ \ 190 / Option Value / 0 or more bytes 191 \ \ 192 +-------------------------------+ 194 Options are used to convey Uri-Host, Uri-Path, Uri-Port, Content- 195 Format and more in COAP. For BRSKI, COAP Options are used to 196 communicate the HTTP fields used in the BRSKI REST messages. 198 BRSKI URLs are HTTPS based (https:// ), in CoAP these will be assumed 199 to be transformed to coaps (coaps://) 201 Some examples of how an BRSKI message would be translated in CoAP 202 follow. [[TODO: This section to be expanded to ensure it covers all 203 BRSKI edge conditions.]] 205 5.1. cacerts 207 First let's see how a get cacerts message in EST would be in CoAP. 208 The HTTPS cacerts message can be 210 GET /.well-known/est/cacerts HTTP/1.1 211 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 212 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 213 Host: 192.0.2.1:8085 214 Accept: */* 216 The corresponding CoAP fields would be: 218 Ver = 1 219 T = 0 (CON) 220 Code = 0x01 (0.01 is GET) 221 Options 222 Option1 (Uri-Host) 223 Option Delta = 0x3 224 Option Length = 0x9 225 Option Value = 192.0.2.1 226 Option2 (Uri-Port) 227 Option Delta = 0xA 228 Option Length = 0x4 229 Option Value = 8085 230 Option3 (Uri-Path) 231 Option Delta = 0xD 232 Option Length = 0xD 233 Extended Option Delta = 0x08 234 Extended Option Length = 0x14 235 Option Value = /.well-known/est/cacerts HTTP/1.1 236 Payload = [Empty] 238 Now let's say we have a 200 OK response with a cert in EST: 240 HTTP/1.1 200 OK 241 Status: 200 OK 242 Content-Type: application/pkcs7-mime 243 Content-Transfer-Encoding: base64 (TODO: Verify if we need a new 244 option registry for Encoding?) 245 Content-Length: 4246 (TODO: this example overflows and would 246 need fragmentation. Choose a better example. 247 Regardless we might need an CoAP option for 248 the content-length ie the CoAP payload?) 250 MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC 251 +zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT 252 ... 254 The corresponding CoAP fields would be: 256 Ver = 1 257 T = 2 (ACK) 258 Code = 0x21 (TODO: Maybe we need to create a 0x200 response code.) 259 Options 260 Option1 (Content-Format) 261 Option Delta = 0xC 262 Option Length = 0xD 263 Extended Option Length = 0x09 264 Option Value = 265 (TODO: We need a new CoAP IANA registered value 266 application/pkcs7-mime; smime-type=certs-only, 267 application/csrattrs, application/pkcs10, 268 application/pkcs8, 269 application/pkcs12 ) 270 Payload = MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExA \ 271 DALBgkqhkiG9w0BBwGgggwMMIIC... 273 5.2. enroll / reenroll 275 [[TODO: username/password authentication can be described here but is 276 not a primary focus for BRSKI. It is important for generic EST 277 exchanges but would an endpoint device with sufficient user interface 278 to allow username/password input from an end user be required to use 279 CoAP instead of a full HTTPS exchange?]] 281 [[TODO: We might need a new Option for the Retry-After response 282 message. We might need a new Option for the WWW-Authenticate 283 response.]] 285 5.3. csrattr 287 5.4. requestaudittoken, requestauditlog 289 6. Data Fragmentation 291 Even though ECC certificates are small in size, they can vary greatly 292 based on signature algorithms, key sizes, and OID fields used. Even 293 with ECC certs, BRSKI CoAP messages carrying such certificates can 294 still exceed sizes in MTU of 1280 for IPv6 or 60-80 bytes for 6LoWPAN 295 [RFC4919]) (section 2 of [I-D.ietf-core-block]). For 256-bit curves, 296 common ECDSA cert sizes are 500-1000 bytes which could fluctuate 297 further based on the algorithms, OIDs, SANs and cert fields. For 298 384-bit curves, ECDSA certs increase in size and can sometimes reach 299 1.5KB. Additionally, there are times when the EST cacert response 300 from the server can include multiple certs that amount large 301 payloads. 303 CoAP RFC section 4.6 describes the possible payload sizes: "if 304 nothing is known about the size of the headers, good upper bounds are 305 1152 bytes for the message size and 1024 bytes for the payload size". 306 Also "If IPv4 support on unusual networks is a consideration, 307 implementations may want to limit themselves to more conservative 308 IPv4 datagram sizes such as 576 bytes; per [RFC0791], the absolute 309 minimum value of the IP MTU for IPv4 is as low as 68 bytes, which 310 would leave only 40 bytes minus security overhead for a UDP payload". 311 Thus, after the DTLS connection is established, fragmentation will 312 sometimes be needed for the CoAP messages which involve certificate 313 enrollment and management. A fragmentation solution for BRSKI and 314 EST CoAP message is required. 316 The [I-D.ietf-core-block] document describes how fragmentation can be 317 done by using a pair of Block options added to the CoAP flow. Block1 318 options are used by the client PUT and POST requests. A Block1 in a 319 client request requires a Block1 option in the responses. A Block2 320 comes from a server response that will also need Block2 from the 321 client to acknowledge the block and get the rest of blocks from the 322 server. So, Block1 is used when a request (POST for example) is done 323 in BRSKI over CoAP with a payload that needs fragmentation. Then the 324 server responds with Block1 option to acknowledge the fragment- 325 blocks. Block2 is used when a BRSKI server response is big and needs 326 fragmentation. The Block2 acknowledgements are requests with the 327 same options as the initial request and a Block2 option. "To 328 influence the block size used in a response, the requester MAY also 329 use the Block2 Option on the initial request, giving the desired 330 size, a block number of zero and an M bit of zero". As explained in 331 see section 2.8 of [I-D.ietf-core-block]), blockwise transfers SHOULD 332 be used in Confirmable COAP messages to avoid the exacerbation of 333 lost blocks. 335 In a scenario with a big BRSKI POST request we might have Block1 336 options from client to server and Block2 from server to client. In 337 this case the Block1 blocks get completed and then the Block2 comes 338 the other direction. 340 The BLOCK draft also defines Size1 and Size2 options. These are used 341 to convey the size of the resources in the requests or responses. 342 The Size1 response MAY be parsed by the client as an size indication 343 of the Block2 resource in the server response or by the server as a 344 request for a size estimate by the client. Similarly, Size2 option 345 defined in BLOCK should be parsed by the server as an indication of 346 the size of the resource carried in Block1 options and by the client 347 as a maximum size expected in the 4.13 (Request Entity Too Large) 348 response to a request. 350 6.1. Fragmented response example with Block2 352 An example of a server cacerts response that exceeds the MTU is: 354 An example of a server cacerts response that exceeds the MTU is 355 HTTP/1.1 200 OK 356 Status: 200 OK 357 Content-Type: application/pkcs7-mime; smime-type=certs-only 358 Content-Transfer-Encoding: base64 359 Content-Length: 1122 361 MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID 362 BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt 363 cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG 364 A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB 365 DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103 366 ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC 367 Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv 368 6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53 369 J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji 370 rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE 371 AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU 372 scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7 373 a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6 374 4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7 375 o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF 376 QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3 377 rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce 378 R4POrT2xz8ChADEA 380 Block options in CoAP messages can contain fields, SZX, M and NUM 381 which are not affected by BRSKI. 383 Let's assume that the cacerts message will need to be broken up to 3 384 messages. The first Block2 will be: 386 Ver = 1 387 T = 2 (ACK) 388 Code = 0x21 (2.01 success message. 389 TODO: Do we need to create a 0x200 respond code.) 390 Options 391 Option1 (Content-Format) 392 Option Delta = 0xC 393 Option Length = 0xD 394 Extended Option Length = 0x09 395 Option Value = 397 (TODO: We need a new CoAP IANA registered value 398 application/pkcs7-mime, application/csrattrs, 399 application/pkcs10, application/pkcs8, 400 application/pkcs12 ) 401 Option2 (Block2) 402 Option Delta = 0xD 403 Option Length = 0x1 404 Extended Option Delta = 0x16 405 Option Value = 0x0D 406 Payload = MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYC \ 407 AQExADALBgkqhkiG9w0BBwGgggwMMIIC... (512 bytes) 409 The second Block2: 411 Ver = 1 412 T = 2 (means ACK) 413 Code = 0x21 414 Options 415 Option1 (Content-Format) 416 Option Delta = 0xC 417 Option Length = 0xD 418 Extended Option Length = 0x09 419 Option Value = 421 (TODO: We need a new CoAP IANA registered value 422 application/pkcs7-mime, application/csrattrs, 423 application/pkcs10, application/pkcs8, 424 application/pkcs12 ) 425 Option2 (Block2) 426 Option Delta = 0xD 427 Option Length = 0x1 428 Extended Option Delta = 0x16 429 Option Value = 0x1D 430 Payload = ... (512 bytes) 432 The third and final Block2: 434 Ver = 1 435 T = 2 (means ACK) 436 Code = 0x21 437 Options 438 Option1 (Content-Format) 439 Option Delta = 0xC 440 Option Length = 0xD 441 Extended Option Length = 0x09 442 Option Value = 444 (TODO: We need a new CoAP IANA registered value 445 application/pkcs7-mime, application/csrattrs, 446 application/pkcs10, application/pkcs8, 447 application/pkcs12 ) 448 Option2 (Block2) 449 Option Delta = 0xD 450 Option Length = 0x1 451 Extended Option Delta = 0x16 452 Option Value = 0x25 453 Payload = ... 455 6.2. Fragmented request example with Block1 457 6.3. Fragmented request/response example with Block1, Size1 and Block2 459 7. Proxying 461 [[TODO: This section to be populated. It will address how proxying 462 can take place by an entity that resides at the edge of the CoAP 463 network, such as the Registrar, and can reach the BRSKI server 464 residing in a traditional "TCP setting". ]] 466 8. CoAP Parameters 468 [[TODO: This section to be populated. It will address transmission 469 parameters for BRSKI described in sections 4.7 and 4.8 of the CoAP 470 draft. BRSKI does not impose any unique parameters that affect the 471 CoAP parameters in Table 2 and 3 in the CoAP draft but the ones in 472 CoAP could be affecting BRSKI. For example the processing delay of 473 CAs could be less then 2s, but in this case they should send an CoAP 474 ACK every 2s while processing. ]] 476 9. Security Considerations 478 [[TODO: This section to be populated. This document describes an 479 existing protocol moved to CoAP and there should not be additional 480 security concerns added beyond the protocol's or CoAP's specifics 481 security considerations.]] 483 10. Update Tracking 485 -01: 487 Added more binding usecases and Block examples subsections to be 488 expanded on later. Made various text improvements and 489 clarifications. 491 Added two clarifying sentences in the relevant sections to address 492 Brian C.'s comments and explain that message fragmentation can be 493 avoided to a degree in DTLS and that fragments of block transfers 494 should be confirmed to prevent exacerbated fragment loss in 495 constrained networks. 497 11. Normative References 499 [I-D.ietf-anima-bootstrapping-keyinfra] 500 Pritikin, M., Richardson, M., Behringer, M., and S. 501 Bjarnason, "Bootstrapping Remote Secure Key 502 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 503 keyinfra-03 (work in progress), June 2016. 505 [I-D.ietf-core-block] 506 Bormann, D. and Z. Shelby, "Block-wise transfers in CoAP", 507 draft-ietf-core-block-20 (work in progress), April 2016. 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 515 "Enrollment over Secure Transport", RFC 7030, 516 DOI 10.17487/RFC7030, October 2013, 517 . 519 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 520 Constrained-Node Networks", RFC 7228, 521 DOI 10.17487/RFC7228, May 2014, 522 . 524 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 525 Application Protocol (CoAP)", RFC 7252, 526 DOI 10.17487/RFC7252, June 2014, 527 . 529 Authors' Addresses 531 Max Pritikin 532 Cisco Systems 534 Email: pritikin@cisco.com 536 Panos Kampanakis 537 Cisco Systems 539 Email: pkampana@cisco.com