idnits 2.17.00 (12 Aug 2021) /tmp/idnits54746/draft-bormann-t2trg-interconnect-declared-01.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(343): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (11 January 2022) is 123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-asdf-sdf-09 == Outdated reference: A later version (-05) exists of draft-ietf-core-coral-04 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational 11 January 2022 5 Expires: 15 July 2022 7 Interconnecting Limited Domains Based on Declared Communication 8 Requirements 9 draft-bormann-t2trg-interconnect-declared-01 11 Abstract 13 "Limited Domains" are parts of an internet that may have notable 14 differences or are just convenient to separate from the general 15 Internet and can be delimited from that and from other Limited 16 Domains by a defined boundary (the "border"). 18 This memo focuses on the case where the nodes inside the Limited 19 Domain want to interact with nodes on (or reachable via) the general 20 Internet, but need some assistance at the border that is cognizant 21 about the specific properties of the nodes in the Limited Domain. 23 Self-Descriptions can provide the information needed for this 24 assistance. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 15 July 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Desirable Communication . . . . . . . . . . . . . . . . . . . 5 62 2.1. Example: Addressing Desirable Peers Only . . . . . . . . 5 63 3. Self-Descriptions . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Directions of Work . . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. Informative References . . . . . . . . . . . . . . . . . . . 8 68 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 [RFC8799] introduces the concept of "Limited Domains", i.e., parts of 74 an internet that may have notable differences or are just convenient 75 to separate from the general Internet and can be delimited from that 76 and from other Limited Domains by a defined boundary (the "border"). 78 Limited Domains are not a new concept, but they recently have gained 79 significant attention as a way to accelerate innovation without 80 always having to wait for the whole Internet to accept a new feature 81 [USEFUL]. 83 Some Limited Domains can be directly connected to or interconnected 84 via the Internet -- rules they use internally simply lose their force 85 outside the Limited Domain. Some require stripping off some 86 structures or translating some fields on the border to the Internet. 87 Some can only be interconnected by running tunnels on top of the 88 Internet. 90 This memo focuses on the case where the nodes inside the Limited 91 Domain want to interact with nodes on (or reachable via) the general 92 Internet, but need some assistance at the border that is cognizant 93 about the specific properties of the nodes in the Limited Domain. 95 6LoWPAN header compression [RFC6282] actually is such an example, 96 which can be considered a very small Limited Domain -- initially just 97 the link and adaptation layer between two LoWPAN nodes, which 98 themselves otherwise feel like standard Internet nodes. (6LoWPAN 99 neighbor discovery [RFC6775] already extends the Limited Domain out 100 to the border router (6LBR), but let's focus on header compression 101 itself for now.) Extending the Limited Domain to more than two nodes 102 may allow the nodes inside the Limited Domain to make use of the 103 knowledge that all of them share some common procedures, such as 104 using the [RFC8138] routing header (6LoRH); it is then the job of the 105 border router (6LBR) to decapsulate this form into packets that can 106 be used in the global Internet and to appropriately encapsulate 107 global Internet packets on the way in. (Virtual Reassembly Buffers 108 (VRBs, [RFC8930]) simulate a subnet-size Limited Domain based on 109 [RFC6282]'s hop-by-hop ones.) 111 This memo uses examples from the area of the Internet of Things 112 (IoT), both because the author is most familiar with it and because a 113 concept of self-descriptions has already been developed for this 114 area, which provide new opportunities for organizing Limited Domains 115 (Section 3). (To do: add more examples from outside the IoT core.) 117 1.1. Terminology 119 Limited Domain: An area in a network that is separate from others by 120 notable internal differences and/or by a strong administrative 121 demarcation. Examples are found in Section 4 of [RFC8799], 122 however this document is not limiting itself to those or to the 123 definition in [RFC8799]. In contrast to some other usage, the 124 nodes in a Limited Domain are expected to normally form a 125 connected graph, possibly by employing tunnels between them. 126 However, not all nodes in a Limited Domain always need to be aware 127 of their situation or implement all the internal differences. 129 .---------------------. .------------. 130 | | | | 131 | .-+-+-. Limited | 132 | | B | Domain | 133 | '-+-+-' LD2 | 134 | | | | 135 | | '------------' 136 | Limited Domain | 137 | LD1 | .---------. .------------. 138 | | / \ | | 139 | .-+--./ \.--+-. Limited | 140 | .---. | B + Internet + B | Domain | 141 | | Z | '-+--'\ /'--+-' LD3 | 142 | '---' | \ / | | 143 | | '-+-----+-' '------------' 144 '---------------------' | | 145 .-+-. .+-..---. 146 | X | | B ++ Y | 147 '---' '--''---' 149 Figure 1: Illustration for terms 151 Figure 1 illustrates the following additional terms: 153 Border: qualifier for network elements (B) (as in "border router" 154 etc.) that are situated on the boundary between a Limited Domain 155 and a different one and/or the general Internet. 157 Internally interoperable Limited Domains: Limited Domains that can 158 accommodate nodes that can operate as if they were in the Internet 159 (Z). 161 Globally interoperable Limited Domains: Limited Domains that can 162 interoperate with nodes in the global Internet (X). 164 Externally interoperable Limited Domains: Limited Domains that can 165 interoperate via the Internet (LD1), but possibly limited to 166 interoperation with other Limited Domains (LD3) or with specially 167 equipped Internet nodes (Limited Domains of size 1, Y logically 168 containing a B). 170 Internet, Global Internet, General Internet: (TBD, clarify usage 171 here) 173 2. Desirable Communication 175 All the examples so far presume an environment where it is desirable 176 that any node can communicate with any other node. This has 177 certainly served well as a guiding principle for quickly improving 178 the value of a network: Leaving open the potential to communicate 179 maximizes the potential network effect [METCALFE]. However, 180 firewalls are then widely used to suppress some of these potential 181 communication paths [FIREWALL]. MUD [RFC8520] was designed to aid 182 routers and switches in setting up limited connectivity to this end. 184 In the MUD architecture, we first build a system that fundamentally 185 supports unlimited connectivity from everyone to everyone and then 186 restrict it based on self-descriptions of the nodes. An alternative 187 approach would be an architecture that does not provide any 188 connectivity unless and until that is authorized by declared 189 communication requirements that have in turn been authorized by some 190 management entity. 192 2.1. Example: Addressing Desirable Peers Only 194 There may be other reasons for pursuing an architecture that limits 195 itself to desirable communication only. A trivial, but maybe not 196 overly useful example would be to number all the addresses of 197 correspondent hosts allowed by the self-descriptions and replace the 198 IP addresses in the packets by these numbers. 200 If this limitation becomes part of the architecture, protocols used 201 inside the Limited Domains could completely get rid of IP addresses 202 and use just the correspondent numbers (possibly packaged in 203 something that looks like an IP address, but is limited in its 204 variability to just encapsulating that number). 206 The border router would become a NAT, but one that is acting based on 207 extensive, precomputable information about the communication 208 requirements inside the Limited Domain, instead of learning and 209 potentially losing dynamic state that becomes a single point of 210 failure. 212 Again, this is a trivial example, but it should be sufficient as a 213 motivation for having a look at employing knowledge about the nodes 214 and their communication requirements in a Limited Domain for 215 interconnecting this with the Internet (and thus possibly to like- 216 minded (Limited Domains on the other side of an Internet path). 218 3. Self-Descriptions 220 Note that not all of the information that may be needed as a 221 description of Limited Domain nodes can come from MUD-like class 222 definitions. Limited Domain nodes are instantiations of these 223 classes, where the instantiations will differ between each other in 224 details. Different Limited Domain nodes may also be assigned a 225 different purpose in life, causing a need to further parameterize the 226 self-description. 228 Alongside a discussion of an interconnection architecture that can 229 make use of self-descriptions would therefore need to be a discussion 230 on how to structure self-description classes with this purpose in 231 mind and how to parameterize these and derive description instances. 233 For the Internet of Things (IoT), additional self-description 234 techniques have been defined that can provide information for Limited 235 Domain network elements. A fully instance-oriented description of an 236 IoT device is provided by a W3C WoT (Web of Things) Thing Description 237 [TD]. W3C WoT is presently in the process of adding a class-based 238 description technique to TDs, the Thing Model (previously called 239 Thing Description Template, TDT) [TD-WD]. The communication patterns 240 offered by the device are detailed in _Protocol Bindings_, which can 241 contain URIs combined with protocol-specific vocabulary ([TD-PB], 242 currently defined for HTTP, CoAP, MQTT). An experimental extension 243 to TDs that enables deriving the configuration of Time-Sensitive 244 Networking (TSN) networks from the self-description is described in 245 [TD-OPC-UA]. 247 An IoT-oriented description technique that, unlike TD, is class-based 248 from the outset is the Semantic Definition Format (SDF) for Data and 249 Interactions of Things [I-D.ietf-asdf-sdf]. A concept similar to WoT 250 Protocol Bindings is not defined yet, but a combination of MUD and 251 SDF descriptions could provide a basic description of a device 252 situated in a Limited Domain. 254 The Constrained RESTful Environments (CoRE) architecture also 255 provides instance-oriented self-descriptions in the form of the CoRE 256 Link Format [RFC6690], an instance of which is provided by each CoAP 257 server under /.well-known/core. Link-format information, as well as 258 self-describing information in the newer CoRAL format 259 [I-D.ietf-core-coral], can be stored in the CoRE Resource Directory 260 [I-D.ietf-core-resource-directory]. 262 All these potential sources of (self-)description only provide meager 263 information about purpose-in-life, i.e., beyond the intrinsic 264 properties of the device. Obtaining a full description of the 265 communication requirements of a node (including its desirable 266 correspondence nodes) will therefore require additional input, beyond 267 the class-based self-descriptions of the devices. 269 4. Directions of Work 271 The above discussion leads us to the following interrelated areas for 272 further exploration: 274 1. Extending the self-description mechanisms to provide more 275 information that may be useful in a Limited Domain. 277 2. Merging the self-description information with other 278 configuration/management information (such as purpose-in-life) 279 that may be available for the Limited Domain. 281 3. Defining Limited Domain architectures that can benefit from 282 information made available by (1) and (2), including defining the 283 operation of network elements and nodes inside the Limited 284 Domain. 286 4. Defining border network element functionality that makes such a 287 Limited Domain a Globally Interoperable Limited Domain. 289 5. Defining border network element functionality that makes such a 290 Limited Domain an Externally Interoperable Limited Domain. 292 6. Discovery between Limited Domains, between Limited Domain nodes 293 (Rendezvous problem); establishment of communications (cf. 294 [RFC8445]). 296 7. Defining appropriate security workflows and the supporting 297 security mechanisms for items 1 to 6. 299 8. Addressing operational considerations for items 1 to 7. 301 9. Addressing privacy considerations for items 1 to 8. 303 5. IANA Considerations 305 This document contains no requests to IANA. 307 6. Security Considerations 309 The security considerations of [RFC8799] apply. 311 Item 7 of Section 4 raises the need for security work, one example of 312 which might be: 314 Self-descriptions of nodes in many cases need to undergo an 315 authorization process before they can be used as the basis of network 316 configuration. The authorization process sketched by [RFC8520] may 317 be too simplistic, in particular the simplified number of 318 stakeholders assumed. The present document is not providing answers 319 in this space, but needs to raise the issue. 321 7. Informative References 323 [FIREWALL] Bellovin, S. and W. Cheswick, "Network firewalls", IEEE 324 Communications Magazine Vol. 32, pp. 50-57, 325 DOI 10.1109/35.312843, September 1994, 326 . 328 [I-D.ietf-asdf-sdf] 329 Koster, M. and C. Bormann, "Semantic Definition Format 330 (SDF) for Data and Interactions of Things", Work in 331 Progress, Internet-Draft, draft-ietf-asdf-sdf-09, 6 332 November 2021, . 335 [I-D.ietf-core-coral] 336 Amsüss, C. and T. Fossati, "The Constrained RESTful 337 Application Language (CoRAL)", Work in Progress, Internet- 338 Draft, draft-ietf-core-coral-04, 25 October 2021, 339 . 342 [I-D.ietf-core-resource-directory] 343 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 344 D. Stok, "CoRE Resource Directory", Work in Progress, 345 Internet-Draft, draft-ietf-core-resource-directory-28, 7 346 March 2021, . 349 [METCALFE] Metcalfe, B., "Metcalfe's Law after 40 Years of Ethernet", 350 Computer Vol. 46, pp. 26-31, DOI 10.1109/mc.2013.374, 351 December 2013, . 353 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 354 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 355 DOI 10.17487/RFC6282, September 2011, 356 . 358 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 359 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 360 . 362 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 363 Bormann, "Neighbor Discovery Optimization for IPv6 over 364 Low-Power Wireless Personal Area Networks (6LoWPANs)", 365 RFC 6775, DOI 10.17487/RFC6775, November 2012, 366 . 368 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 369 "IPv6 over Low-Power Wireless Personal Area Network 370 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 371 April 2017, . 373 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 374 Connectivity Establishment (ICE): A Protocol for Network 375 Address Translator (NAT) Traversal", RFC 8445, 376 DOI 10.17487/RFC8445, July 2018, 377 . 379 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 380 Description Specification", RFC 8520, 381 DOI 10.17487/RFC8520, March 2019, 382 . 384 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 385 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 386 . 388 [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On 389 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 390 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, 391 . 393 [TD] "Web of Things (WoT) Thing Description", (Link errors 394 corrected 23 June 2020), W3C Recommendation, April 2020, 395 . 397 [TD-OPC-UA] 398 Sciullo, L., Bhattacharjee, S., and M. Kovatsch, "Bringing 399 deterministic industrial networking to the W3C web of 400 things with TSN and OPC UA", Proceedings of the 10th 401 International Conference on the Internet of Things, 402 DOI 10.1145/3410992.3410997, October 2020, 403 . 405 [TD-PB] "Web of Things (WoT) Binding Templates", W3C Working Group 406 Note, January 2020, 407 . 409 [TD-WD] "Web of Things (WoT) Thing Description 1.1", W3C Editor's 410 Draft, May 2021, 411 . 413 [USEFUL] Carpenter, B., Crowcroft, J., and D. Trossen, "Limited 414 domains considered useful", ACM SIGCOMM Computer 415 Communication Review Vol. 51, pp. 22-28, 416 DOI 10.1145/3477482.3477487, July 2021, 417 . 419 Acknowledgments 421 Adrian Farrel provided substantive comments as well as the basis for 422 Figure 1. 424 Author's Address 426 Carsten Bormann 427 Universität Bremen TZI 428 Postfach 330440 429 D-28359 Bremen 430 Germany 432 Phone: +49-421-218-63921 433 Email: cabo@tzi.org