Interconnecting Limited Domains Based on Declared Communication Requirements

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 12 January 2023.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

[RFC8799] introduces the concept of "Limited Domains", i.e., parts of an internet that may have notable differences or are just convenient to separate from the general Internet and can be delimited from that and from other Limited Domains by a defined boundary (the "border").¶

Limited Domains are not a new concept, but they recently have gained significant attention as a way to accelerate innovation without always having to wait for the whole Internet to accept a new feature [USEFUL].¶

Some Limited Domains can be directly connected to or interconnected via the Internet -- rules they use internally simply lose their force outside the Limited Domain. Some require stripping off some structures or translating some fields on the border to the Internet. Some can only be interconnected by running tunnels on top of the Internet.¶

This memo focuses on the case where the nodes inside the Limited Domain want to interact with nodes on (or reachable via) the general Internet, but need some assistance at the border that is cognizant about the specific properties of the nodes in the Limited Domain.¶

6LoWPAN header compression [RFC6282] actually is such an example, which can be considered a very small Limited Domain -- initially just the link and adaptation layer between two LoWPAN nodes, which themselves otherwise feel like standard Internet nodes. (6LoWPAN neighbor discovery [RFC6775] already extends the Limited Domain out to the border router (6LBR), but let's focus on header compression itself for now.) Extending the Limited Domain to more than two nodes may allow the nodes inside the Limited Domain to make use of the knowledge that all of them share some common procedures, such as using the [RFC8138] routing header (6LoRH); it is then the job of the border router (6LBR) to decapsulate this form into packets that can be used in the global Internet and to appropriately encapsulate global Internet packets on the way in. (Virtual Reassembly Buffers (VRBs, [RFC8930]) simulate a subnet-size Limited Domain based on [RFC6282]'s hop-by-hop ones.)¶

This memo uses examples from the area of the Internet of Things (IoT), both because the author is most familiar with it and because a concept of self-descriptions has already been developed for this area, which provide new opportunities for organizing Limited Domains (Section 3). (To do: add more examples from outside the IoT core.)¶

2. Desirable Communication

All the examples so far presume an environment where it is desirable that any node can communicate with any other node. This has certainly served well as a guiding principle for quickly improving the value of a network: Leaving open the potential to communicate maximizes the potential network effect [METCALFE]. However, firewalls are then widely used to suppress some of these potential communication paths [FIREWALL]. MUD [RFC8520] was designed to aid routers and switches in setting up limited connectivity to this end.¶

In the MUD architecture, we first build a system that fundamentally supports unlimited connectivity from everyone to everyone and then restrict it based on self-descriptions of the nodes. An alternative approach would be an architecture that does not provide any connectivity unless and until that is authorized by declared communication requirements that have in turn been authorized by some management entity.¶

3. Self-Descriptions

Note that not all of the information that may be needed as a description of Limited Domain nodes can come from MUD-like class definitions. Limited Domain nodes are instantiations of these classes, where the instantiations will differ between each other in details. Different Limited Domain nodes may also be assigned a different purpose in life, causing a need to further parameterize the self-description.¶

Alongside a discussion of an interconnection architecture that can make use of self-descriptions would therefore need to be a discussion on how to structure self-description classes with this purpose in mind and how to parameterize these and derive description instances.¶

For the Internet of Things (IoT), additional self-description techniques have been defined that can provide information for Limited Domain network elements. A fully instance-oriented description of an IoT device is provided by a W3C WoT (Web of Things) Thing Description [TD]. W3C WoT is presently in the process of adding a class-based description technique to TDs, the Thing Model (previously called Thing Description Template, TDT) [TD-WD]. The communication patterns offered by the device are detailed in Protocol Bindings, which can contain URIs combined with protocol-specific vocabulary ([TD-PB], currently defined for HTTP, CoAP, MQTT). An experimental extension to TDs that enables deriving the configuration of Time-Sensitive Networking (TSN) networks from the self-description is described in [TD-OPC-UA].¶

An IoT-oriented description technique that, unlike TD, is class-based from the outset is the Semantic Definition Format (SDF) for Data and Interactions of Things [I-D.ietf-asdf-sdf]. A concept similar to WoT Protocol Bindings is not defined yet, but a combination of MUD and SDF descriptions could provide a basic description of a device situated in a Limited Domain.¶

The Constrained RESTful Environments (CoRE) architecture also provides instance-oriented self-descriptions in the form of the CoRE Link Format [RFC6690], an instance of which is provided by each CoAP server under /.well-known/core. Link-format information, as well as self-describing information in the newer CoRAL format [I-D.ietf-core-coral], can be stored in the CoRE Resource Directory [RFC9176].¶

All these potential sources of (self-)description only provide meager information about purpose-in-life, i.e., beyond the intrinsic properties of the device. Obtaining a full description of the communication requirements of a node (including its desirable correspondence nodes) will therefore require additional input, beyond the class-based self-descriptions of the devices.¶

4. Directions of Work

The above discussion leads us to the following interrelated areas for further exploration:¶

1. Extending the self-description mechanisms to provide more information that may be useful in a Limited Domain.¶
2. Merging the self-description information with other configuration/management information (such as purpose-in-life) that may be available for the Limited Domain.¶
3. Defining Limited Domain architectures that can benefit from information made available by (1) and (2), including defining the operation of network elements and nodes inside the Limited Domain.¶
4. Defining border network element functionality that makes such a Limited Domain a Globally Interoperable Limited Domain.¶
5. Defining border network element functionality that makes such a Limited Domain an Externally Interoperable Limited Domain.¶
6. Discovery between Limited Domains, between Limited Domain nodes (Rendezvous problem); establishment of communications (cf. [RFC8445]).¶
7. Defining appropriate security workflows and the supporting security mechanisms for items 1 to 6.¶
8. Addressing operational considerations for items 1 to 7.¶
9. Addressing privacy considerations for items 1 to 8.¶

5. IANA Considerations

This document contains no requests to IANA.¶

6. Security Considerations

The security considerations of [RFC8799] apply.¶

Item 7 of Section 4 raises the need for security work, one example of which might be:¶

Self-descriptions of nodes in many cases need to undergo an authorization process before they can be used as the basis of network configuration. The authorization process sketched by [RFC8520] may be too simplistic, in particular the simplified number of stakeholders assumed. The present document is not providing answers in this space, but needs to raise the issue.¶

Acknowledgments

Adrian Farrel provided substantive comments as well as the basis for Figure 1.¶

Author's Address