Limited Domains and Internet Protocols
draft-carpenter-limited-domains-03

Abstract

There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions, and develops a related taxonomy. It shows the needs for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists.

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 March 16, 2019.

Copyright Notice

Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Failure Modes in Today's Internet
• 3. Examples of Limited Domain Requirements
• 4. Examples of Limited Domain Solutions
• 5. Taxonomy of Limited Domains
• 5.1. The Domain as a Whole
• 5.2. Individual Nodes
• 5.3. The Domain Boundary
• 5.4. Topology
• 5.5. Technology
• 5.6. Connection to the Internet
• 5.7. Security, Trust and Privacy Model
• 5.8. Operations
• 6. Common Features of Limited Domains
• 7. Defining a Limited Domain Boundary
• 8. Defining Protocol Scope
• 9. Security Considerations
• 10. IANA Considerations
• 11. Contributors
• 12. Acknowledgements
• 13. Informative References
• Appendix A. Change log [RFC Editor: Please remove]
• Authors' Addresses

1. Introduction

As the Internet continues to grow and diversify, with a realistic prospect of tens of billions of nodes being connected directly and indirectly, there is a noticeable trend towards local requirements, behaviours and semantics. The word "local" should be understood in a special sense, however. In some cases it may refer to geographical and physical locality - all the nodes in a single building, on a single campus, or in a given vehicle. In other cases it may refer to a defined set of users or nodes distributed over a much wider area, but drawn together by a single virtual network over the Internet, or a single physical network running partially in parallel with the Internet. We expand on these possibilities below. To capture the topic, this document refers to such networks as "limited domains".

Some people have concerns about splintering of the Internet along political or linguistic boundaries by mechanisms that block the free flow of information across the network. That is not the topic of this document, which does not discuss filtering mechanisms and does not apply to protocols that are designed for use across the whole Internet. It is only concerned with domains that have specific technical requirements.

The word "domain" in this document does not refer to naming domains in the DNS, although in some cases a limited domain might incidentally be congruent with a DNS domain.

The requirements of limited domains will be different in different scenarios. Policies, default parameters, and the options supported may vary. Also, the style of network management may vary, between a completely unmanaged network, one with fully autonomic management, one with traditional central management, and mixtures of the above. Finally, the requirements and solutions for security and privacy may vary.

This documents analyses and discusses some of the consequences of this trend, and how it impacts the idea of universal interoperability in the Internet. In particular, we challenge the notion that all Internet standards must be universal in scope and applicability. To the contrary, we assert that some standards need to be specifically limited in their applicability. This requires that the concepts of a limited domain, and of its boundary, need to be formalised.

2. Failure Modes in Today's Internet

Today, the Internet does not have a well-defined concept of limited domains. One result of this is that certain protocols and features fail on certain paths. Previously, this has been analysed in terms of transparency [RFC2775], [RFC4924] or of intrusive middleboxes [RFC3234], [RFC7663], [I-D.dolson-plus-middlebox-benefits]. Unfortunately the problems persist, both in application protocols, and even in very fundamental mechanisms. For example, the Internet is not transparent to IPv6 extension headers [RFC7872], and Path MTU Discovery has been unreliable for many years [RFC2923], [RFC4821]. IP fragmentation is also unreliable [I-D.bonica-intarea-frag-fragile], and problems in TCP MSS negotiation have been reported [I-D.andrews-tcp-and-ipv6-use-minmtu].

On the security side, the widespread insertion of firewalls at domain boundaries that are perceived by humans but unknown to protocols results in arbitrary failure modes as far as the application layer is concerned.

This situation is not acceptable, so it seems that a new approach is needed.

3. Examples of Limited Domain Requirements

This section describes various examples where limited domain requirements can easily be identified. It is of course not a complete list.

NOTE: The authors welcome more suggestions and references for this list.

1. A home network. It will be unmanaged, constructed by a non-specialist, and will possibly include wiring errors such as physical loops. It must work with devices "out of the box" as shipped by their manufacturers and must create adequate security by default. Remote access may be required. The requirements and applicable principles are summarised in [RFC7368].
2. A small office network. This is very similar to a home network, since whoever is in charge will probably have little or no specialist knowledge, but may have differing security and privacy requirements. Remote access may be required.
3. A vehicle network. This will be designed by the vehicle manufacturer but may include devices added by the vehicle's owner or operator. Parts of the network will have demanding performance and reliability requirements with implications for human safety. Remote access may be required to certain functions, but absolutely forbidden for others. Communication with other vehicles, roadside infrastructure, and external data sources will be required. See [I-D.ietf-ipwave-vehicular-networking] for a survey of use cases.
4. A building services network. This will be designed specifically for a particular building, but using standard components. Additional devices may need to be added at any time. Parts of the network may have demanding reliability requirements with implications for human safety. Remote access may be required to certain functions, but absolutely forbidden for others. [I-D.martocci-6lowapp-building-applications] (need current reference!)
5. Supervisory Control And Data Acquisition (SCADA) networks in general, which will exhibit widely differing requirements, including tough real-time performance targets, of which building networks are a simple example. See for example [I-D.ietf-detnet-use-cases]
6. The three preceding cases will all include sensors, but some networks may be specifically limited to sensors and the collection and processing of sensor data. They may be in remote or technically challenging locations and installed by non-specialists.
7. "Traditional" enterprise and campus networks, which may be spread over many kilometres and over multiple separate sites.
8. Data centres and hosting centres, or distributed services acting as such centres. These will have high performance, security and privacy requirements and will typically include large numbers of independent "tenant" networks overlaid on shared infrastructure.
9. Content Delivery Networks, comprising distributed data centres and the paths between them, spanning thousands of kilometres.
10. Internet of Things (IoT) networks. While this term is very flexible and covers many innovative types of network, including ad hoc networks that are formed spontaneously, it seems reasonable to expect that many IoT edge networks will have special requirements and protocols that are useful only within a specific domain, and that these protocols cannot, and for security reasons should not, run over the Internet as a whole.
11. An important subclass of IoT networks consists of constrained networks [RFC7228] in which the nodes are limited in power consumption and communications bandwidth, and are therefore limited to using very frugal protocols.
12. Delay tolerant networks may consist of domains that are relatively isolated and are connected only intermittently to the outside, with a very long latency on such connections [RFC4838]. Clearly the protocol requirements and possibilities are very specialised in such networks.
13. Many of the above types of network may be extended throughout the Internet by a variety of virtual private network (VPN) techniques. Therefore we may argue that limited domains may overlap each other in an arbitrary fashion by use of virtualization techniques.

Two other concepts, while not tied to specific network types, also strongly depend on the concept of limited domains:

1. Intent Based Networking. In this concept, a network domain is configured and managed in accordance with an abstract policy known as "Intent", to ensure that the network performs as required [I-D.moulchan-nmrg-network-intent-concepts]. Whatever technologies are used to support this, they will be applied within the domain boundary.
2. Network Slicing. A network slice is a virtual network that consists of a managed set of resources carved off from a larger network [I-D.geng-netslices-architecture]. Whatever technologies are used to support slicing, they will require a clear definition of the boundary of a given slice.

While it is clearly desirable to use common solutions, and therefore common standards, wherever possible, it is increasingly difficult to do so while satisfying the widely varying requirements outlined above. However, there is a tendency when new protocols and protocol extensions are proposed to always ask the question "How will this work across the open Internet?" This document suggests that this is not always the right question. There are protocols and extensions that are not intended to work across the open Internet. On the contrary, their requirements and semantics are specifically limited (in the sense defined above).

A common argument is that if a protocol is intended for limited use, the chances are very high that it will in fact be used (or misused) in other scenarios including the so-called open Internet. This is undoubtedly true and means that limited use is not an excuse for bad design or poor security. In fact, a limited use requirement potentially adds complexity to both the protocol and its security design, as discussed later.

Nevertheless, because of the diversity of limited environments with specific requirements that is now emerging, specific standards will necessarily emerge. There will be attempts to capture each market sector, but the market will demand standardised limited solutions. However, the "open Internet" must remain as the universal method of interconnection. Reconciling these two aspects is a major challenge.

4. Examples of Limited Domain Solutions

This section lists various examples of specific limited domain solutions that have been proposed or defined. It intentionally does not include Layer 2 technology solutions, which by definition apply to limited domains.

NOTE: Please suggest additional items for this list.

1. Differentiated Services. This mechanism [RFC2474] allows a network to assign locally significant values to the 6-bit Differentiated Services Code Point field in any IP packet. Although there are some recommended codepoint values for specific per-hop queue management behaviours, these are specifically intended to be domain-specific codepoints with traffic being classified, conditioned and re-marked at domain boundaries (unless there is an inter-domain agreement that makes re-marking unnecessary).
2. Network function virtualisation. As described in [I-D.irtf-nfvrg-gaps-network-virtualization], this general concept is an open research topic, in which virtual network functions are orchestrated as part of a distributed system. Inevitably such orchestration applies to an administrative domain of some kind, even though cross-domain orchestration is also a research area.
3. Service Function Chaining (SFC). This technique [RFC7665] assumes that services within a network are constructed as sequences of individual functions within a specific SFC-enabled domain. As that RFC states: "Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information". A Network Service Header (NSH) [RFC8300] is used to encapsulate packets flowing through the service function chain: "The intended scope of the NSH is for use within a single provider's operational domain."
4. Data Centre Network Virtualization Overlays. A common requirement in data centres that host many tenants (clients) is to provide each one with a secure private network, all running over the same physical infrastructure. [RFC8151] describes various use cases for this, and specifications are under development. These include use cases in which the tenant network is physically split over several data centres, but which must appear to the user as a single secure domain.
5. Segment Routing. This is a technique which "steers a packet through an ordered list of instructions, called segments" [I-D.ietf-spring-segment-routing]. The semantics of these instructions are explicitly local to a segment routing domain or even to a single node. Technically, these segments or instructions are represented as an MPLS label or an IPv6 address, which clearly adds a semantic interpretation to them within the domain.
6. Autonomic Networking. As explained in [I-D.ietf-anima-reference-model], an autonomic network is also a security domain within which an autonomic control plane [I-D.ietf-anima-autonomic-control-plane] is used by service agents. These service agents manage technical objectives, which may be locally defined, subject to domain-wide policy. Thus the domain boundary is important for both security and protocol purposes.
7. Homenet. As shown in [RFC7368], a home networking domain has specific protocol needs that differ from those in an enterprise network or the Internet as a whole. These include the Home Network Control Protocol (HNCP) [RFC7788] and a naming and discovery solution [I-D.ietf-homenet-simple-naming].
8. Creative uses of IPv6 features. As IPv6 enters more general use, engineers notice that it has much more flexibility than IPv4. Innovative suggestions have been made for:
   • The flow label, e.g. [RFC6294], [I-D.fioccola-v6ops-ipv6-alt-mark].
   • Extension headers, e.g. for segment routing [I-D.ietf-6man-segment-routing-header].
   • Meaningful address bits, e.g. [I-D.jiang-semantic-prefix]. Also, segment routing uses IPv6 addresses as segment identifiers with specific local meanings [I-D.ietf-spring-segment-routing].

   All of these suggestions are only viable within a specified domain. The case of the extension header is particularly interesting, since its existence has been a major "selling point" for IPv6, but it is notorious that new extension headers are virtually impossible to deploy across the whole Internet

   [RFC7045], [RFC7872]. It is worth noting that extension header filtering is considered as an important security issue [I-D.ietf-opsec-ipv6-eh-filtering]. There is considerable appetite among vendors or operators to have flexibility in defining extension headers for use in limited or specialised domains, e.g. [I-D.voyer-6man-extension-header-insertion] and [BIGIP].
9. Deterministic Networking (DetNet). The Deterministic Networking Architecture [I-D.ietf-detnet-architecture] and encapsulation [I-D.ietf-detnet-dp-sol] aim to support flows with extremely low data loss rates and bounded latency, but only within a part of the network that is "DetNet aware". Thus, as for differentiated services above, the concept of a domain is fundamental.
10. Provisioning Domains (PvDs). An architecture for Multiple Provisioning Domains has been defined [RFC7556] to allow hosts attached to multiple networks to learn explicit details about the services provided by each of those networks.

5. Taxonomy of Limited Domains

This section develops a taxonomy for describing limited domains. Several major aspects are considered in this taxonomy:

• The domain as a whole.
• The individual nodes.
• The domain boundary.
• The domain's topology.
• The domain's technology.
• How the domain connects to the Internet.
• The security, trust and privacy model.
• Operations.

The following sub-sections analyse each of these aspects.

5.1. The Domain as a Whole

• Why does the domain exist? (e.g., human choice, administrative policy, orchestration requirements, technical requirements)
• If there are special requirements, are they at Layer 2, Layer 3 or an upper layer?
• Is the domain managed by humans or fully autonomic?
• If managed, what style of management applies? (Manual configuration, automated configuration, orchestration?)
• Is there a policy model? (Intent, configuration policies?)
• Does the domain provide controlled or paid service or open access?

5.2. Individual Nodes

• Is a domain member a complete node, or only one interface of a node?
• Are nodes permanent members of a given domain, or are join and leave operations possible?
• Are nodes physical or virtual devices?
• Are virtual nodes general-purpose, or limited to specific functions, applications or users?
• Are nodes constrained (by battery etc)?
• Are devices installed "out of the box" or pre-configured?

5.3. The Domain Boundary

• How is the domain boundary identified or defined?
• Is the domain boundary fixed or dynamic?
• Are boundary nodes special? Or can any node be at the boundary?

5.4. Topology

• Is the domain a subset of a layer 2 or 3 connectivity domain?
• In IP addressing terms, is the domain Link-local, Site-local, or Global?
• Does the domain overlap other domains? (In other words, a node may or may not be allowed to be a member of multiple domains.)
• Does the domain match physical topology, or does it have a virtual (overlay) topology?
• Is the domain in a single building, vehicle or campus? Or is it distributed?
• If distributed, are the interconnections private or over the Internet?
• In IP addressing terms, is the domain Link-local, Site-local, or Global?

5.5. Technology

• In routing terms, what routing protocol(s) are used, or even different forwarding mechanisms (MPLS or other non-IP mechanism)?
• In an overlay domain, what overlay technique is used (L2VPN, L3VPN,...)?
• Are there specific QoS requirements?
• Link latency - normal or long latency links?
• Mobility - are nodes mobile? Is the whole network mobile?
• Which specific technologies, such as those in Section 4, are applicable?

5.6. Connection to the Internet

• Is the Internet connection permanent or intermittent? (Never connected is out of scope.)
• What traffic is blocked, in and out?
• What traffic is allowed, in and out?
• What traffic is transformed, in and out?
• Is secure and privileged remote access needed?
• Does the domain allow unprivileged remote sessions?

5.7. Security, Trust and Privacy Model

• Must domain members be authorized?
• Are all nodes in the domain at the same trust level?
• Is traffic authenticated?
• Is traffic encrypted?
• What is hidden from the outside?

5.8. Operations

• Safety level - does the domain have a critical (human) safety role?
• Reliability requirement - normal or 99.999% ?
• Environment - hazardous conditions?
• Installation - are specialists needed?
• Service visits - easy, difficult, impossible?
• Software/firmware updates - possible or impossible?

6. Common Features of Limited Domains

As the preceding taxonomy shows, there are very numerous aspects to a domain, so the common features are not immediately obvious. It would be possible, but tedious, to apply the taxonomy to each of the domain types described in Section 3. However, we can observe some recurrent features without doing so:

1. It must be possible to define the domain boundary.
2. It must be possible for domain members to determine whether a particular node is in the the domain.
3. It must be possible for a node to determine which domain(s) it is in.
4. It must be possible for a node to find boundary nodes (interfacing to the Internet).
5. In a domain with security requirements, it must be possible for a node to present and acquire security credentials.
6. In a domain with management requirements, it must be possible for a node to acquire domain policy and/or domain configuration data.
7. In a domain with dynamic membership, join and leave operations must be possible.

More TBD

7. Defining a Limited Domain Boundary

This section justifies the need for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists.

More TBD

8. Defining Protocol Scope

This section suggests that protocols or protocol extensions should, when appropriate, be standardised to interoperate only within a Limited Domain Boundary. Such protocols are not required to operate across the Internet as a whole.

Point noted in discussion: "Operate" is a weaker statement than "interoperate". A question to be addressed is whether a limited-domain protocol is allowed to have local variants, such that implementations in different domains could not interoperate if those domains were unified by some mechanism.

More TBD

9. Security Considerations

Clearly, the boundary of a limited domain will almost always also act as a security boundary. In particular, it will serve as a trust boundary, and as a boundary of authority for defining capabilities. Within the boundary, limited-domain protocols or protocol features will be useful, but they will be meaningless if they enter or leave the domain.

The security model for a limited-scope protocol must allow for the boundary, and in particular for a trust model that changes at the boundary. Typically, credentials will need to be signed by a domain-specific authority.

10. IANA Considerations

This document makes no request of the IANA.

11. Contributors

Sheng Jiang made important contributions to this document.

12. Acknowledgements

Useful comments were received from Edward Birrane, Ron Bonica, Tim Chown, Darren Dukes, John Klensin, Michael Richardson, Rick Taylor, Niels ten Oever, and other members of the ANIMA and INTAREA WGs.

13. Informative References

Appendix A. Change log [RFC Editor: Please remove]

draft-carpenter-limited-domains-00, 2018-06-11:

Initial version

draft-carpenter-limited-domains-01, 2018-07-01:

Minor terminology clarifications

draft-carpenter-limited-domains-02, 2018-08-03:

Additions following IETF102 discussions

Updated authorship/contributors

draft-carpenter-limited-domains-03, 2018-09-12:

First draft of taxonomy

Editorial improvements

Authors' Addresses