idnits 2.17.1 draft-ietf-lpwan-architecture-00.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 294: '... MAY be deemed as sufficient, if ...' RFC 2119 keyword, line 298: '... addresses SHOULD be used. End-t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 275 has weird spacing: '... . read delet...' -- The document date (May 18, 2021) is 1067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 408 == 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-04 Summary: 1 error (**), 0 flaws (~~), 4 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: November 19, 2021 Cisco Systems 6 A. Minaburo 7 Acklio 8 May 18, 2021 10 LPWAN Static Context Header Compression (SCHC) Architecture 11 draft-ietf-lpwan-architecture-00 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 November 19, 2021. 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. LPWAN Technologies and Profiles . . . . . . . . . . . . . . . 2 53 3. The Static Context Header Compression . . . . . . . . . . . . 3 54 4. SCHC Endpoints . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. SCHC Instances . . . . . . . . . . . . . . . . . . . . . . . 4 56 6. SCHC Data Model . . . . . . . . . . . . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 7 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 10.2. Informative References . . . . . . . . . . . . . . . . . 8 63 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 The IETF LPWAN WG defined the necessary operations to enable IPv6 69 over selected Low-Power Wide Area Networking (LPWAN) radio 70 technologies. [rfc8376] presents an overview of those technologies. 72 The Static Context Header Compression (SCHC) [rfc8724] technology is 73 the core product of the IETF LPWAN working group. [rfc8724] defines a 74 generic framework for header compression and fragmentation, based on 75 a static context that is pre-installed on the SCHC endpoints. 77 This document details the constitutive elements of a SCHC-based 78 solution, and how the solution can be deployed. It provides a 79 general architecture for a SCHC deployment, positioning the required 80 specifications, describing the possible deployment types, and 81 indicating models whereby the rules can be distributed and installed 82 to enable reliable and scalable operations. 84 2. LPWAN Technologies and Profiles 86 Because LPWAN technologies [rfc8376] have strict yet distinct 87 constraints, e.g., in terms of maximum frame size, throughput, and/or 88 directionality, a SCHC instance must be profiled to adapt to the 89 specific necessities of the technology to which it is applied. 91 Appendix D. "SCHC Parameters" of [rfc8724] lists the information 92 that an LPWAN technology-specific document must provide to profile 93 SCHC for that technology. 95 As an example, [rfc9011] provides the SCHC profile for LoRaWAN 96 networks. 98 3. The Static Context Header Compression 100 SCHC [rfc8724] specifies an extreme compression capability based on a 101 state that must match on the compressor and decompressor side. This 102 state comprises a set of Compression/Decompression (C/D) rules. 104 The SCHC Parser analyzes incoming packets and creates a list of 105 fields that it matches against the compression rules. The rule that 106 matches best is used to compress the packet, and the rule identifier 107 (RuleID) is transmitted together with the compression residue to the 108 decompressor. Based on the RuleID and the residue, the decompressor 109 can rebuild the original packet and forward it in its uncompressed 110 form over the Internet. 112 [rfc8724] also provides a Fragmentation/Reassembly (F/R) capability 113 to cope with the maximum frame size of a Link, which is extremely 114 constrained in the case of an LPWAN network. 116 If a SCHC-compressed packet is too large to be sent in a single Link- 117 Layer PDU, the SCHC fragmentation can be applied on the compressed 118 packet. The process of SCHC fragmentation is similar to that of 119 compression; the fragmentation rules that are programmed for this 120 device are checked to find the most appropriate one, regarding the 121 SCHC packet size, the link error rate, and the reliability level 122 required by the application. 124 The nature of a ruleID allows to determine if it is a compression or 125 fragmentation rule. 127 4. SCHC Endpoints 129 Section 3 of [rfc8724] depicts a typical network architecture for an 130 LPWAN network, simplified from that shown in [rfc8376] and reproduced 131 in Figure 1. 133 () () () | 134 () () () () / \ +---------+ 135 () () () () () () / \======| ^ | +-----------+ 136 () () () | | <--|--> | |Application| 137 () () () () / \==========| v |=============| Server | 138 () () () / \ +---------+ +-----------+ 139 Dev RGWs NGW App 141 Figure 1: Typical LPWAN Network Architecture 143 Typically, an LPWAN network topology is star-oriented, which means 144 that all packets between the same source-destination pair follow the 145 same path from/to a central point. In that model, highly constrained 146 Devices (Dev) exchange information with LPWAN Application Servers 147 (Apps) through a central Network Gateway (NGW), which can be powered 148 and is typically a lot less constrained than the Devices. Because 149 devices embed built-in applications, the traffic flows to be 150 compressed are known in advance and the location of the C/D and F/R 151 functions (e.g., at the Dev and NGW), and the associated rules, can 152 be pre provisionned in the network . 154 Then again, SCHC is very generic and its applicability is not limited 155 to star-oriented deployments and/or to use cases where applications 156 are very static and the state can provisionned in advance. 157 [I-D.thubert-intarea-schc-over-ppp] describes an alternate deployment 158 where the C/D and/or F/R operations are performed between peers of 159 equal capabilities over a PPP [rfc2516] connection. SCHC over PPP 160 illustrates that with SCHC, the protocols that are compressed can be 161 discovered dynamically and the rules can be fetched on-demand by both 162 parties from the same Uniform Resource Name (URN) [rfc8141], ensuring 163 that the peers use the exact same set of rules. 165 +----------+ Wi-Fi / +----------+ .... 166 | IP | Ethernet | IP | .. ) 167 | Host +-----/------+ Router +----------( Internet ) 168 | SCHC C/D | Serial | SCHC C/D | ( ) 169 +----------+ +----------+ ... 170 <-- SCHC --> 171 over PPP 173 Figure 2: PPP-based SCHC Deployment 175 5. SCHC Instances 177 The rule database contains a set of rules that are specific per 178 device. There is thus a SCHC instance per pair of endpoints. 179 [rfc8724] states that a SCHC instance obtains the rules to process C/ 180 D and F/R before the session starts, and that rules cannot be 181 modified during the session. 183 [rfc8724] was defined to compress IPv6 [rfc8200] and UDP; but SCHC 184 really is a generic compression and fragmentation technology. As 185 such, SCHC is agnostic to which protocol it compresses and at which 186 layer it is operated. The C/D peers may be hosted by different 187 entities for different layers, and the F/R operation may also be 188 performed between different parties, or different sub-layers in the 189 same stack, and/or managed by different organizations. 191 If a protocol or a layer requires additional capabilities, it is 192 always possible to document more specifically how to use SCHC in that 193 context, or to specify additional behaviours. For instance, 195 [I-D.ietf-lpwan-coap-static-context-hc] extends the compression to 196 CoAP [RFC7252] and OSCORE [RFC8613]. 198 As represented figure Figure 3, the fragmentation and the compression 199 of the IP and UDP headers may be operated by a network SCHC instance 200 whereas the end-to-end compression of the application payload happens 201 between the device and the application. The compression of the 202 application payload may be split in two instances to deal with the 203 encrypted portion of the application PDU. 205 (device) (NGW) (App) 207 +--------+ +--------+ 208 A S | CoAP | | CoAP | 209 p C | inner | | inner | 210 p H +--------+ +--------+ 211 . C | SCHC | | SCHC | 212 | inner | cryptographical boundary | inner | 213 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._ 214 A S | CoAP | | CoAP | 215 p C | outer | | outer | 216 p H +--------+ +--------+ 217 . C | SCHC | | SCHC | 218 | outer | layer / functional boundary | outer | 219 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._ 220 N . UDP . . UDP . 221 e .......... .................. .......... 222 t . IPv6 . . IPv6 . . IPv6 . 223 w S .......... .................. .......... 224 o C . SCHC . . SCHC . . . . 225 r H .......... .......... . . . 226 k C . LPWAN . . LPWAN . . . . 227 .......... .................. .......... 228 ((((LPWAN)))) ------ Internet ------ 230 Figure 3: Different SCHC instances in a global system 232 This document defines a generic architecture for SCHC that can be 233 used at any of these levels. The goal of the architectural document 234 is to orchestrate the different protocols and data model defined by 235 the LPWAN woeking group to design an operational and interoperable 236 framework for allowing IP application over contrained networks. 238 6. SCHC Data Model 240 A SCHC instance, summarized in the Figure 4, implies C/D and/or F/R 241 present in both end and that both ends are provisionned with the same 242 set of rules. 244 (-------) (-------) 245 ( Rules ) ( Rules ) 246 (-------) (-------) 247 . read . read 248 . . 249 +-------+ +-------+ 250 <===| R & D |<=== <===| C & F |<=== 251 ===>| C & F |===> ===>| R & D |===> 252 +-------+ +-------+ 253 +-------+ 255 Figure 4: Summarized SCHC elements 257 To be able to provision end-points from different vendors, a common 258 rule representation is needed that expresses the SCHC rules in an 259 interoperable fashion. To that effect, 260 [I-D.ietf-lpwan-schc-yang-data-model] defines a rule representation 261 using the YANG [1] formalism. 263 [I-D.ietf-lpwan-schc-yang-data-model] defines an YANG data model to 264 represent the rules. This enables the use of several protocols for 265 rule management, such as NETCONF[RFC6241], RESTCONF[RFC8040], and 266 CORECONF[I-D.ietf-core-comi]. NETCONF uses SSH, RESTCONF uses HTTPS, 267 and CORECONF uses CoAP(s) as their respective transport layer 268 protocols. The data is represented in XML under NETCONF, in 269 JSON[RFC8259] under RESTCONF and in CBOR[RFC8949] under CORECONF. 271 create 272 (-------) read +=======+ * 273 ( rules )<------->|Rule |<--|--------> 274 (-------) update |Manager| NETCONF, RESTCONF or CORECONF 275 . read delete +=======+ request 276 . 277 +-------+ 278 <===| R & D |<=== 279 ===>| C & F |===> 280 +-------+ 282 Figure 5: Summerized SCHC elements 284 The Rule Manager (RM) is in charge of handling data derived from the 285 YANG Data Model and apply changes to the rules database Figure 5. 287 The RM is a application using the Internet to exchange information, 288 therefore: 290 o for the network-level SCHC, the communication does not require 291 routing. Each of the end-points having an RM and both RMs can be 292 viewed on the same link, therefore wellknown Link Local addresses 293 can be used to identify the device and the core RM. L2 security 294 MAY be deemed as sufficient, if it provides the necessary level of 295 protection. 297 o for application-level SCHC, routing is involved and global IP 298 addresses SHOULD be used. End-to-end encryption is RECOMMENDED. 300 Management messages can also be carried in the negotiation protocol 301 as proposed in [I-D.thubert-intarea-schc-over-ppp]. The RM traffic 302 may be itself compressed by SCHC, especially if CORECONF is used, 303 [I-D.ietf-lpwan-coap-static-context-hc] can be used. 305 7. Security Considerations 307 SCHC is sensitive to the rules that could be abused to form arbitrary 308 long messages or as a form of attack against the C/D and/or F/R 309 functions, say to generate a buffer overflow and either modify the 310 device or crash it. It is thus critical to ensure that the rules are 311 distributed in a fashion that is protected against tempering, e.g., 312 encrypted and signed. 314 8. IANA Consideration 316 This document has no request to IANA 318 9. Acknowledgements 320 The authors would like to thank (in alphabetic order): 322 10. References 324 10.1. Normative References 326 [rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 327 Zuniga, "SCHC: Generic Framework for Static Context Header 328 Compression and Fragmentation", RFC 8724, 329 DOI 10.17487/RFC8724, April 2020, 330 . 332 [rfc9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context 333 Header Compression and Fragmentation (SCHC) over LoRaWAN", 334 RFC 9011, DOI 10.17487/RFC9011, April 2021, 335 . 337 10.2. Informative References 339 [I-D.ietf-core-comi] 340 Veillette, M., Stok, P., Pelov, A., Bierman, A., and I. 341 Petrov, "CoAP Management Interface (CORECONF)", draft- 342 ietf-core-comi-11 (work in progress), January 2021. 344 [I-D.ietf-lpwan-coap-static-context-hc] 345 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 346 Context Header Compression (SCHC) for CoAP", draft-ietf- 347 lpwan-coap-static-context-hc-19 (work in progress), March 348 2021. 350 [I-D.ietf-lpwan-schc-yang-data-model] 351 Minaburo, A. and L. Toutain, "Data Model for Static 352 Context Header Compression (SCHC)", draft-ietf-lpwan-schc- 353 yang-data-model-04 (work in progress), February 2021. 355 [I-D.thubert-intarea-schc-over-ppp] 356 Thubert, P., "SCHC over PPP", draft-thubert-intarea-schc- 357 over-ppp-03 (work in progress), April 2021. 359 [rfc2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 360 and R. Wheeler, "A Method for Transmitting PPP Over 361 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 362 February 1999, . 364 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 365 and A. Bierman, Ed., "Network Configuration Protocol 366 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 367 . 369 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 370 Application Protocol (CoAP)", RFC 7252, 371 DOI 10.17487/RFC7252, June 2014, 372 . 374 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 375 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 376 . 378 [rfc8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 379 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 380 . 382 [rfc8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 383 (IPv6) Specification", STD 86, RFC 8200, 384 DOI 10.17487/RFC8200, July 2017, 385 . 387 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 388 Interchange Format", STD 90, RFC 8259, 389 DOI 10.17487/RFC8259, December 2017, 390 . 392 [rfc8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 393 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 394 . 396 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 397 "Object Security for Constrained RESTful Environments 398 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 399 . 401 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 402 Representation (CBOR)", STD 94, RFC 8949, 403 DOI 10.17487/RFC8949, December 2020, 404 . 406 10.3. URIs 408 [1] RFC7950 410 Authors' Addresses 412 Alexander Pelov 413 Acklio 414 1137A avenue des Champs Blancs 415 35510 Cesson-Sevigne Cedex 416 France 418 Email: a@ackl.io 420 Pascal Thubert 421 Cisco Systems 422 45 Allee des Ormes - BP1200 423 06254 Mougins - Sophia Antipolis 424 France 426 Email: pthubert@cisco.com 427 Ana Minaburo 428 Acklio 429 1137A avenue des Champs Blancs 430 35510 Cesson-Sevigne Cedex 431 France 433 Email: ana@ackl.io