idnits 2.17.1 draft-ietf-lpwan-architecture-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 == Line 291 has weird spacing: '... . read delet...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (26 November 2021) is 872 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 427, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-11 == Outdated reference: A later version (-21) exists of draft-ietf-lpwan-schc-yang-data-model-06 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LPWAN Working Group A. Pelov 3 Internet-Draft Acklio 4 Intended status: Informational P. Thubert 5 Expires: 30 May 2022 Cisco Systems 6 A. Minaburo 7 Acklio 8 26 November 2021 10 LPWAN Static Context Header Compression (SCHC) Architecture 11 draft-ietf-lpwan-architecture-01 13 Abstract 15 This document defines the LPWAN SCHC architecture. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 30 May 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. LPWAN Technologies and Profiles . . . . . . . . . . . . . . . 3 52 3. The Static Context Header Compression . . . . . . . . . . . . 3 53 4. SCHC Applicability . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. LPWAN Overview . . . . . . . . . . . . . . . . . . . . . 4 55 4.2. Compressing Serial Streams . . . . . . . . . . . . . . . 4 56 4.3. Example: Goose and DLMS . . . . . . . . . . . . . . . . . 4 57 5. SCHC Architecture . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. SCHC Endpoints . . . . . . . . . . . . . . . . . . . . . 4 59 5.2. Layering with SCHC Instances . . . . . . . . . . . . . . 5 60 6. SCHC Data Model . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. SCHC Device Lifecycle . . . . . . . . . . . . . . . . . . . . 8 62 7.1. Device Development . . . . . . . . . . . . . . . . . . . 8 63 7.2. Rules Publication . . . . . . . . . . . . . . . . . . . . 8 64 7.3. SCHC Device Deployment . . . . . . . . . . . . . . . . . 9 65 7.4. SCHC Device Maintenance . . . . . . . . . . . . . . . . . 9 66 7.5. SCHC Device Decommissionning . . . . . . . . . . . . . . 9 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 10.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 The IETF LPWAN WG defined the necessary operations to enable IPv6 77 over selected Low-Power Wide Area Networking (LPWAN) radio 78 technologies. [rfc8376] presents an overview of those technologies. 80 The Static Context Header Compression (SCHC) [rfc8724] technology is 81 the core product of the IETF LPWAN working group. [rfc8724] defines a 82 generic framework for header compression and fragmentation, based on 83 a static context that is pre-installed on the SCHC endpoints. 85 This document details the constitutive elements of a SCHC-based 86 solution, and how the solution can be deployed. It provides a 87 general architecture for a SCHC deployment, positioning the required 88 specifications, describing the possible deployment types, and 89 indicating models whereby the rules can be distributed and installed 90 to enable reliable and scalable operations. 92 2. LPWAN Technologies and Profiles 94 Because LPWAN technologies [rfc8376] have strict yet distinct 95 constraints, e.g., in terms of maximum frame size, throughput, and/or 96 directionality, a SCHC instance must be profiled to adapt to the 97 specific necessities of the technology to which it is applied. 99 Appendix D. "SCHC Parameters" of [rfc8724] lists the information 100 that an LPWAN technology-specific document must provide to profile 101 SCHC for that technology. 103 As an example, [rfc9011] provides the SCHC profile for LoRaWAN 104 networks. 106 3. The Static Context Header Compression 108 SCHC [rfc8724] specifies an extreme compression capability based on a 109 state that must match on the compressor and decompressor side. This 110 state comprises a set of Compression/Decompression (C/D) rules. 112 The SCHC Parser analyzes incoming packets and creates a list of 113 fields that it matches against the compression rules. The rule that 114 matches best is used to compress the packet, and the rule identifier 115 (RuleID) is transmitted together with the compression residue to the 116 decompressor. Based on the RuleID and the residue, the decompressor 117 can rebuild the original packet and forward it in its uncompressed 118 form over the Internet. 120 [rfc8724] also provides a Fragmentation/Reassembly (F/R) capability 121 to cope with the maximum and/or variable frame size of a Link, which 122 is extremely constrained in the case of an LPWAN network. 124 If a SCHC-compressed packet is too large to be sent in a single Link- 125 Layer PDU, the SCHC fragmentation can be applied on the compressed 126 packet. The process of SCHC fragmentation is similar to that of 127 compression; the fragmentation rules that are programmed for this 128 Device are checked to find the most appropriate one, regarding the 129 SCHC packet size, the link error rate, and the reliability level 130 required by the application. 132 The ruleID allows to determine if it is a compression or 133 fragmentation rule. 135 4. SCHC Applicability 137 4.1. LPWAN Overview 139 4.2. Compressing Serial Streams 141 [rfc8724] was defined to compress IPv6 [rfc8200] and UDP; but SCHC 142 really is a generic compression and fragmentation technology. As 143 such, SCHC is agnostic to which protocol it compresses and at which 144 layer it is operated. The C/D peers may be hosted by different 145 entities for different layers, and the F/R operation may also be 146 performed between different parties, or different sub-layers in the 147 same stack, and/or managed by different organizations. 149 If a protocol or a layer requires additional capabilities, it is 150 always possible to document more specifically how to use SCHC in that 151 context, or to specify additional behaviours. For instance, 152 [I-D.ietf-lpwan-coap-static-context-hc] extends the compression to 153 CoAP [RFC7252] and OSCORE [RFC8613]. 155 4.3. Example: Goose and DLMS 157 5. SCHC Architecture 159 5.1. SCHC Endpoints 161 Section 3 of [rfc8724] depicts a typical network architecture for an 162 LPWAN network, simplified from that shown in [rfc8376] and reproduced 163 in Figure 1. 165 () () () | 166 () () () () / \ +---------+ 167 () () () () () () / \======| ^ | +-----------+ 168 () () () | | <--|--> | |Application| 169 () () () () / \==========| v |=============| Server | 170 () () () / \ +---------+ +-----------+ 171 Dev RGWs NGW App 173 Figure 1: Typical LPWAN Network Architecture 175 Typically, an LPWAN network topology is star-oriented, which means 176 that all packets between the same source-destination pair follow the 177 same path from/to a central point. In that model, highly constrained 178 Devices (Dev) exchange information with LPWAN Application Servers 179 (App) through a central Network Gateway (NGW), which can be powered 180 and is typically a lot less constrained than the Devices. Because 181 Devices embed built-in applications, the traffic flows to be 182 compressed are known in advance and the location of the C/D and F/R 183 functions (e.g., at the Dev and NGW), and the associated rules, can 184 be pre provisionned in the system before use. 186 Nevertheless, SCHC is very generic and its applicability is not 187 limited to star-oriented deployments and/or to use cases where 188 applications are very static and the state provisionned in advance. 189 [I-D.thubert-intarea-schc-over-ppp] describes an alternate deployment 190 where the C/D and/or F/R operations are performed between peers of 191 equal capabilities over a PPP [rfc2516] connection. SCHC over PPP 192 illustrates that with SCHC, the protocols that are compressed can be 193 discovered dynamically and the rules can be fetched on-demand by both 194 parties from the same Uniform Resource Name (URN) [rfc8141], ensuring 195 that the peers use the exact same set of rules. 197 +----------+ Wi-Fi / +----------+ .... 198 | IP | Ethernet | IP | .. ) 199 | Host +-----/------+ Router +----------( Internet ) 200 | SCHC C/D | Serial | SCHC C/D | ( ) 201 +----------+ +----------+ ... 202 <-- SCHC --> 203 over PPP 205 Figure 2: PPP-based SCHC Deployment 207 5.2. Layering with SCHC Instances 209 The rule database contains at least one set of rules that are 210 specific per Device. There is thus a SCHC instance per pair of 211 endpoints. [rfc8724] states that a SCHC instance needs the rules to 212 process C/D and F/R before the session starts, and that rules cannot 213 be modified during the session. 215 As represented figure Figure 3, the compression of the IP and UDP 216 headers may be operated by a network SCHC instance whereas the end- 217 to-end compression of the application payload happens between the 218 Device and the application. The compression of the application 219 payload may be split in two instances to deal with the encrypted 220 portion of the application PDU. Fragmentation applies before LPWAN 221 transportation layer. 223 (Device) (NGW) (App) 225 +--------+ +--------+ 226 A S | CoAP | | CoAP | 227 p C | inner | | inner | 228 p H +--------+ +--------+ 229 . C | SCHC | | SCHC | 230 | inner | cryptographical boundary | inner | 231 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._ 232 A S | CoAP | | CoAP | 233 p C | outer | | outer | 234 p H +--------+ +--------+ 235 . C | SCHC | | SCHC | 236 | outer | layer / functional boundary | outer | 237 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._ 238 N . UDP . . UDP . 239 e .......... .................. .......... 240 t . IPv6 . . IPv6 . . IPv6 . 241 w S .......... .................. .......... 242 o C .SCHC/L3 . . SCHC/L3. . . . 243 r H .......... .......... . . . 244 k C . LPWAN . . LPWAN . . . . 245 .......... .................. .......... 246 ((((LPWAN)))) ------ Internet ------ 248 Figure 3: Different SCHC instances in a global system 250 This document defines a generic architecture for SCHC that can be 251 used at any of these levels. The goal of the architectural document 252 is to orchestrate the different protocols and data model defined by 253 the LPWAN working group to design an operational and interoperable 254 framework for allowing IP application over contrained networks. 256 6. SCHC Data Model 258 A SCHC instance, summarized in the Figure 4, implies C/D and/or F/R 259 present in both end and that both ends are provisionned with the same 260 set of rules. 262 (-------) (-------) 263 ( Rules ) ( Rules ) 264 (-------) (-------) 265 . read . read 266 . . 267 +-------+ +-------+ 268 <===| R & D |<=== <===| C & F |<=== 269 ===>| C & F |===> ===>| R & D |===> 270 +-------+ 271 Figure 4: Summarized SCHC elements 273 A common rule representation that expresses the SCHC rules in an 274 interoperable fashion is needed yo be able to provision end-points 275 from different vendors To that effect, 276 [I-D.ietf-lpwan-schc-yang-data-model] defines a rule representation 277 using the YANG [rfc7950] formalism. 279 [I-D.ietf-lpwan-schc-yang-data-model] defines an YANG data model to 280 represent the rules. This enables the use of several protocols for 281 rule management, such as NETCONF[RFC6241], RESTCONF[RFC8040], and 282 CORECONF[I-D.ietf-core-comi]. NETCONF uses SSH, RESTCONF uses HTTPS, 283 and CORECONF uses CoAP(s) as their respective transport layer 284 protocols. The data is represented in XML under NETCONF, in 285 JSON[RFC8259] under RESTCONF and in CBOR[RFC8949] under CORECONF. 287 create 288 (-------) read +=======+ * 289 ( rules )<------->|Rule |<--|--------> 290 (-------) update |Manager| NETCONF, RESTCONF or CORECONF 291 . read delete +=======+ request 292 . 293 +-------+ 294 <===| R & D |<=== 295 ===>| C & F |===> 296 +-------+ 298 Figure 5: Summerized SCHC elements 300 The Rule Manager (RM) is in charge of handling data derived from the 301 YANG Data Model and apply changes to the rules database Figure 5. 303 The RM is an Application using the Internet to exchange information, 304 therefore: 306 * for the network-level SCHC, the communication does not require 307 routing. Each of the end-points having an RM and both RMs can be 308 viewed on the same link, therefore wellknown Link Local addresses 309 can be used to identify the Device and the core RM. L2 security 310 MAY be deemed as sufficient, if it provides the necessary level of 311 protection. 313 * for application-level SCHC, routing is involved and global IP 314 addresses SHOULD be used. End-to-end encryption is RECOMMENDED. 316 Management messages can also be carried in the negotiation protocol 317 as proposed in [I-D.thubert-intarea-schc-over-ppp]. The RM traffic 318 may be itself compressed by SCHC: if CORECONF protocol is used, 319 [I-D.ietf-lpwan-coap-static-context-hc] can be applied. 321 7. SCHC Device Lifecycle 323 In the context of LPWANs, the expectation is that SCHC rules are 324 associated with a physical device that is deployed in a network. 325 This section describes the actions taken to enable an autimatic 326 commissioning of the device in the network. SCHC 328 7.1. Device Development 330 The expectation for the development cycle is that message formats are 331 documented as a data model that is used to generate rules. Several 332 models are possible: 334 1. In the application model, an interface definition language and 335 binary communication protocol such as Apache Thrift is used, and 336 the serialization code includes the SCHC operation. This model 337 imposes that both ends are compiled with the generated structures 338 and linked with generated code that represents the rule 339 operation. 341 2. In the device model, the rules are generated separately. Only 342 the device-side code is linked with generated code. The Rules 343 are published separately to be used by a generic SCHC engine that 344 operates in a middle box such as a SCHC gateway. 346 3. In the protocol model, both endpoint generate a packet format 347 that is imposed by a protocol. In that case, the protocol itself 348 is the source to generate the Rules. Both ends of the SCHC 349 compression are operated in middle boxes, and special attention 350 must be taken to ensure that they operate on the compatible Rule 351 sets, basically the same major version of the same Rule Set. 353 Depending on the deployment, the tools thar generate the Rules should 354 provide knobs to optimize the Rule set, e.g., more rules vs. larger 355 residue. 357 7.2. Rules Publication 359 In the device model and in the protocol model, at least one of the 360 endpoints must obtain the rule set dynamically. The expectation is 361 that the Rule Sets are published to a reachable repository and 362 versionned (minor, major). Each rule set should have its own Uniform 363 Resource Names (URN) [RFC8141] and a version. 365 The Rule Set should be authenticated to ensure that it is genuine, or 366 obtained from a trusted app store. A corrupted Rule Set may be used 367 for multiple forms of attacks, more in Section 8. 369 7.3. SCHC Device Deployment 371 The device and the network should mutually authenticate themselves. 372 The autonomic approach [RFC8993] provides a model to achieve this at 373 scale with zero touchn, in networks where enough bandwidth and 374 compute are available. In highly constrained networks, one touch is 375 usually necessary to program keys in the devices. 377 The initial handshake between the SCHC endpoints should comprise a 378 capability exchange whereby URN and the version of the rule set are 379 obtained or compared. SCHC may not be used if both ends can not 380 agree on an URN and a major version. Manufacturer Usage Descriptions 381 (MUD) [RFC8520] may be used for that purpose in the device model. 383 Upon the handshake, both ends can agree on a rule set, their role 384 when the rules are asymmetrical, and fetch the rule set if necessary. 385 Optionally, a node that fetwhed a rule set may inform the other end 386 that it is reacy from transmission. 388 7.4. SCHC Device Maintenance 390 URN update without device update (bug fix) FUOTA => new URN => 391 reprovisionning 393 7.5. SCHC Device Decommissionning 395 Signal from device/vendor/network admin 397 8. Security Considerations 399 SCHC is sensitive to the rules that could be abused to form arbitrary 400 long messages or as a form of attack against the C/D and/or F/R 401 functions, say to generate a buffer overflow and either modify the 402 Device or crash it. It is thus critical to ensure that the rules are 403 distributed in a fashion that is protected against tempering, e.g., 404 encrypted and signed. 406 # IANA Consideration 408 This document has no request to IANA 410 9. Acknowledgements 412 The authors would like to thank (in alphabetic order): 414 10. References 416 10.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 424 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 432 Description Specification", RFC 8520, 433 DOI 10.17487/RFC8520, March 2019, 434 . 436 [rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 437 Zuniga, "SCHC: Generic Framework for Static Context Header 438 Compression and Fragmentation", RFC 8724, 439 DOI 10.17487/RFC8724, April 2020, 440 . 442 [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, 443 L., and J. Nobre, "A Reference Model for Autonomic 444 Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, 445 . 447 [rfc9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context 448 Header Compression and Fragmentation (SCHC) over LoRaWAN", 449 RFC 9011, DOI 10.17487/RFC9011, April 2021, 450 . 452 10.2. Informative References 454 [I-D.ietf-core-comi] 455 Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and 456 I. Petrov, "CoAP Management Interface (CORECONF)", Work in 457 Progress, Internet-Draft, draft-ietf-core-comi-11, 17 458 January 2021, . 461 [I-D.ietf-lpwan-coap-static-context-hc] 462 Minaburo, A., Toutain, L., and R. Andreasen, "Static 463 Context Header Compression (SCHC) for the Constrained 464 Application Protocol (CoAP)", Work in Progress, Internet- 465 Draft, draft-ietf-lpwan-coap-static-context-hc-19, 8 March 466 2021, . 469 [I-D.ietf-lpwan-schc-yang-data-model] 470 Minaburo, A. and L. Toutain, "Data Model for Static 471 Context Header Compression (SCHC)", Work in Progress, 472 Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-06, 473 24 November 2021, . 476 [I-D.thubert-intarea-schc-over-ppp] 477 Thubert, P., "SCHC over PPP", Work in Progress, Internet- 478 Draft, draft-thubert-intarea-schc-over-ppp-03, 21 April 479 2021, . 482 [rfc2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 483 and R. Wheeler, "A Method for Transmitting PPP Over 484 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 485 February 1999, . 487 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 488 and A. Bierman, Ed., "Network Configuration Protocol 489 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 490 . 492 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 493 Application Protocol (CoAP)", RFC 7252, 494 DOI 10.17487/RFC7252, June 2014, 495 . 497 [rfc7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 498 RFC 7950, DOI 10.17487/RFC7950, August 2016, 499 . 501 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 502 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 503 . 505 [rfc8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 506 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 507 . 509 [rfc8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 510 (IPv6) Specification", STD 86, RFC 8200, 511 DOI 10.17487/RFC8200, July 2017, 512 . 514 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 515 Interchange Format", STD 90, RFC 8259, 516 DOI 10.17487/RFC8259, December 2017, 517 . 519 [rfc8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 520 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 521 . 523 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 524 "Object Security for Constrained RESTful Environments 525 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 526 . 528 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 529 Representation (CBOR)", STD 94, RFC 8949, 530 DOI 10.17487/RFC8949, December 2020, 531 . 533 Authors' Addresses 535 Alexander Pelov 536 Acklio 537 1137A avenue des Champs Blancs 538 35510 Cesson-Sevigne Cedex 539 France 541 Email: a@ackl.io 542 Pascal Thubert 543 Cisco Systems 544 45 Allee des Ormes - BP1200 545 06254 Mougins - Sophia Antipolis 546 France 548 Email: pthubert@cisco.com 550 Ana Minaburo 551 Acklio 552 1137A avenue des Champs Blancs 553 35510 Cesson-Sevigne Cedex 554 France 556 Email: ana@ackl.io