| RFC 8799 | Limited Domains | July 2020 |
| Carpenter & Liu | Informational | [Page] |
There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.¶
This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8799.¶
Copyright (c) 2020 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.¶
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 network-specific and local requirements, behaviors, 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 in parallel with the Internet. We expand on these possibilities below. To capture the topic, this document refers to such networks as "limited domains". Of course, a similar situation may arise for a network that is completely disconnected from the Internet, but that is not our direct concern here. However, it should not be forgotten that interoperability is needed even within a disconnected network.¶
Some people have concerns about splintering of the Internet along political or linguistic boundaries by mechanisms that block the free flow of information. That is not the topic of this document, which does not discuss filtering mechanisms (see [RFC7754]) 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. In particular, with a "split horizon" DNS configuration [RFC6950], the split might be at the edge of a limited domain. A recent proposal for defining definite perimeters within the DNS namespace [DNS-PERIMETER] might also be considered to be a limited domain mechanism.¶
Another term that has been used in some contexts is "controlled environment". For example, [RFC8085] uses this to delimit the operational scope within which a particular tunnel encapsulation might be used. A specific example is GRE-in-UDP encapsulation [RFC8086], which explicitly states that "The controlled environment has less restrictive requirements than the general Internet." For example, non-congestion-controlled traffic might be acceptable within the controlled environment. The same phrase has been used to delimit the useful scope of quality-of-service protocols [RFC6398]. It is not necessarily the case that protocols will fail to operate outside the controlled environment, but rather that they might not operate optimally. In this document, we assume that "limited domain" and "controlled environment" mean the same thing in practice. The term "managed network" has been used in a similar way, e.g., [RFC6947]. In the context of secure multicast, a "group domain of interpretation" is defined by [RFC6407].¶
Yet more definitions of types of domains are to be found in the routing area, such as [RFC4397], [RFC4427], and [RFC4655]. We conclude that the notion of a limited domain is very widespread in many aspects of Internet technology.¶
The requirements of limited domains will depend on the deployment scenario. 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 document analyzes and discusses some of the consequences of this trend and how it may impact the idea of universal interoperability in the Internet. First, we list examples of limited domain scenarios and of technical solutions for limited domains, with the main focus being the Internet layer of the protocol stack. An appendix provides a taxonomy of the features to be found in limited domains. With this background, we discuss the resulting challenge to the idea that all Internet standards must be universal in scope and applicability. To the contrary, we assert that some protocols, although needing to be standardized and interoperable, also need to be specifically limited in their applicability. This implies that the concepts of a limited domain, and of its membership, need to be formalized and supported by secure mechanisms. While this document does not propose a design for such mechanisms, it does outline some functional requirements.¶
This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.¶
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. Earlier analyses of this topic have focused either on the loss of transparency of the Internet [RFC2775] [RFC4924] or on the middleboxes responsible for that loss [RFC3234] [RFC7663] [RFC8517]. 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 [FRAG-FRAGILE], and problems in TCP MSS negotiation have been reported [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. There are operational recommendations and practices that effectively guarantee arbitrary failures in realistic scenarios [IPV6-EXT-HEADERS].¶
Domain boundaries that are defined administratively (e.g., by address filtering rules in routers) are prone to leakage caused by human error, especially if the limited domain traffic appears otherwise normal to the boundary routers. In this case, the network operator needs to take active steps to protect the boundary. This form of leakage is much less likely if nodes must be explicitly configured to handle a given limited-domain protocol, for example, by installing a specific protocol handler.¶
Investigations of the unreliability of IP fragmentation [FRAG-FRAGILE] and the filtering of IPv6 extension headers [RFC7872] strongly suggest that at least for some protocol elements, transparency is a lost cause and middleboxes are here to stay. In the following two sections, we show that some application environments require protocol features that cannot, or should not, cross the whole Internet.¶
This section describes various examples where limited domain requirements can easily be identified, either based on an application scenario or on a technical imperative. It is, of course, not a complete list, and it is presented in an arbitrary order, loosely from smaller to bigger.¶
Three other aspects, while not tied to specific network types, also strongly depend on the concept of limited domains:¶
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 best 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 domains with specific requirements that is now emerging, specific standards (and ad hoc standards) will probably emerge for different types of domains. There will be attempts to capture each market sector, but the market will demand standardized solutions within each sector. In addition, operational choices will be made that can in fact only work within a limited domain. The history of RSVP [RFC2205] illustrates that a standard defined as if it could work over the open Internet might not in fact do so. In general, we can no longer assume that a protocol designed according to classical Internet guidelines will in fact work reliably across the network as a whole. However, the "open Internet" must remain as the universal method of interconnection. Reconciling these two aspects is a major challenge.¶
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. It is worth noting, however, that with recent developments such as Transparent Interconnection of Lots of Links (TRILL) [RFC6325] or Shortest Path Bridging [SPB], Layer 2 domains may become very large.¶
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 case of the extension header is particularly interesting, since its existence has been a major "selling point" for IPv6, but new extension headers are notorious for being virtually impossible to deploy across the whole Internet [RFC7045] [RFC7872]. It is worth noting that extension header filtering is considered an important security issue [IPV6-EXT-HEADERS]. There is considerable appetite among vendors or operators to have flexibility in defining extension headers for use in limited or specialized domains, e.g., [IPV6-SRH], [BIGIP], and [APP-AWARE]. Locally significant hop-by-hop options are also envisaged, that would be understood by routers inside a domain but not elsewhere, e.g., [IN-SITU-OAM].¶
All of these suggestions are only viable within a specified domain. Nevertheless, all of them are clearly intended for multivendor implementation on thousands or millions of network domains, so interoperable standardization would be beneficial. This argument might seem irrelevant to private or proprietary implementations, but these have a strong tendency to become de facto standards if they succeed, so the arguments of this document still apply.¶
One consequence of the deployment of limited domains in the Internet is that some protocols will be designed, extended, or configured so that they only work correctly between end systems in such domains. This is to some extent encouraged by some existing standards and by the assignment of code points for local or experimental use. In any case, it cannot be prevented. Also, by endorsing efforts such as Service Function Chaining, Segment Routing, and Deterministic Networking, the IETF is in effect encouraging such deployments. Furthermore, it seems inevitable, if the Internet of Things becomes reality, that millions of edge networks containing completely novel types of nodes will be connected to the Internet; each one of these edge networks will be a limited domain.¶
It is therefore appropriate to discuss whether protocols or protocol extensions should sometimes be standardized to interoperate only within a limited-domain boundary. Such protocols would not be required to interoperate across the Internet as a whole. Various scenarios could then arise if there are multiple domains using the limited-domain protocol in question:¶
If a domain is split into two parts connected over the Internet directly at the IP layer (i.e., with no tunnel encapsulating the packets), a limited-domain protocol could be operated between those two parts regardless of its special nature, as long as it respects standard IP formats and is not arbitrarily blocked by firewalls. A simple example is any protocol using a port number assigned to a specific non-IETF protocol.¶
Such a protocol could reasonably be described as an "inter-domain" protocol because the Internet is transparent to it, even if it is meaningless except in the two limited domains. This is, of course, nothing new in the Internet architecture.¶
If a limited-domain protocol does not respect standard IP formats (for example, if it includes a non-standard IPv6 extension header), it could not be operated between two domains connected over the Internet directly at the IP layer.¶
Such a protocol could reasonably be described as an "intra-domain" protocol, and the Internet is opaque to it.¶
If a limited-domain protocol is clearly specified to be invalid outside its domain of origin, neither scenario A nor B applies. The only solution would be a single virtual domain. For example, an encapsulating tunnel between two domains could be used to create the virtual domain. Also, nodes at the domain boundary must drop all packets using the limited-domain protocol.¶
If a limited-domain protocol has domain-specific variants, such that implementations in different domains could not interoperate if those domains were unified by some mechanism as in scenario C, the protocol is not interoperable in the normal sense. If two domains using it were merged, the protocol might fail unpredictably. A simple example is any protocol using a port number assigned for experimental use. Related issues are discussed in [RFC5704], including the complex example of Transport MPLS.¶
To provide a widespread example, consider Differentiated Services [RFC2474]. A packet containing any value whatsoever in the 6 bits of the Differentiated Services Code Point (DSCP) is well formed and falls into scenario A. However, because the semantics of DSCP values are locally significant, the packet also falls into scenario D. In fact, Differentiated Services are only interoperable across domain boundaries if there is a corresponding agreement between the operators; otherwise, a specific gateway function is required for meaningful interoperability. Much more detailed discussion is found in [RFC2474] and [RFC8100].¶
To provide a provocative example, consider the proposal in [IPV6-SRH] that the restrictions in [RFC8200] should be relaxed to allow IPv6 extension headers to be inserted on the fly in IPv6 packets. If this is done in such a way that the affected packets can never leave the specific limited domain in which they were modified, scenario C applies. If the semantic content of the inserted headers is locally defined, scenario D also applies. In neither case is the Internet outside the limited domain disturbed. However, inside the domain, nodes must understand the variant protocol. Unless it is standardized as a formal version, with all the complexity that implies [RFC6709], the nodes must all be non-standard to the extent of understanding the variant protocol. For the example of IPv6 header insertion, that means non-compliance with [RFC8200] within the domain, even if the inserted headers are themselves fully compliant. Apart from the issue of formal compliance, such deviations from documented standard behavior might lead to significant debugging issues. The possible practical impact of the header insertion example is explored in [IN-FLIGHT-IPV6].¶
The FAST proposal mentioned in Section 4, Paragraph 2, Item 5 is also an interesting case study. The semantics of FAST tickets [FAST] have limited scope. However, they are designed in a way that, in principle, allows them to traverse the open Internet, as standardized IPv6 hop-by-hop options or even as a proposed form of IPv4 extension header [IPV4-EXT-HEADERS]. Whether such options can be used reliably across the open Internet remains unclear [IPV6-EXT-HEADERS].¶
We conclude that it is reasonable to explicitly define limited-domain protocols, either as standards or as proprietary mechanisms, as long as they describe which of the above scenarios apply and they clarify how the domain is defined. As long as all relevant standards are respected outside the domain boundary, a well-specified limited-domain protocol need not damage the rest of the Internet. However, as described in the next section, mechanisms are needed to support domain membership operations.¶
Note that this conclusion is not a recommendation to abandon the normal goal that a standardized protocol should be global in scope and able to interoperate across the open Internet. It is simply a recognition that this will not always be the case.¶
Noting that limited-domain protocols have been defined in the past, and that others will undoubtedly be defined in the future, it is useful to consider how a protocol can be made aware of the domain within which it operates and how the domain boundary nodes can be identified. As the taxonomy in Appendix A shows, there are numerous aspects to a domain. However, we can identify some generally required features and functions that would apply partially or completely to many cases.¶
Today, where limited domains exist, they are essentially created by careful configuration of boundary routers and firewalls. If a domain is characterized by one or more address prefixes, address assignment to hosts must also be carefully managed. This is an error-prone method, and a combination of configuration errors and default routing can lead to unwanted traffic escaping the domain. Our basic assumption is therefore that it should be possible for domains to be created and managed automatically, with minimal human configuration. We now discuss requirements for automating domain creation and management.¶
First, if we drew a topology map, any given domain -- virtual or physical -- will have a well-defined boundary between "inside" and "outside". However, that boundary in itself has no technical meaning. What matters in reality is whether a node is a member of the domain and whether it is at the boundary between the domain and the rest of the Internet. Thus, the boundary in itself does not need to be identified, but boundary nodes face both inwards and outwards. Inside the domain, a sending node needs to know whether it is sending to an inside or outside destination, and a receiving node needs to know whether a packet originated inside or outside. Also, a boundary node needs to know which of its interfaces are inward facing or outward facing. It is irrelevant whether the interfaces involved are physical or virtual.¶
To underline that domain boundaries need to be identifiable, consider the statement from the Deterministic Networking Problem Statement [RFC8557] that "there is still a lack of clarity regarding the limits of a domain where a deterministic path can be set up". This remark can certainly be generalized.¶
With this perspective, we can list some general functional requirements. An underlying assumption here is that domain membership operations should be cryptographically secured; a domain without such security cannot be reliably protected from attack.¶
These requirements could form the basis for further analysis and solution design.¶
Another aspect is whether individual packets within a limited domain need to carry any sort of indicator that they belong to that domain or whether this information will be implicit in the IP addresses of the packet. A related question is whether individual packets need cryptographic authentication. This topic is for further study.¶
As noted above, a protocol intended for limited use may well be inadvertently used on the open Internet, so limited use is not an excuse for poor security. In fact, a limited use requirement potentially adds complexity to the security design.¶
Often, the boundary of a limited domain will also act as a security boundary. In particular, it will serve as a trust boundary and as a boundary of authority for defining capabilities. For example, segment routing [RFC8402] explicitly uses the concept of a "trusted domain" in this way. Within the boundary, limited-domain protocols or protocol features will be useful, but they will in many cases be meaningless or harmful if they enter or leave the domain.¶
The boundary also serves to provide confidentiality and privacy for operational parameters that the operator does not wish to reveal. Note that this is distinct from privacy protection for individual users within 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.¶
This document has no IANA actions.¶
This appendix develops a taxonomy for describing limited domains. Several major aspects are considered in this taxonomy:¶
The following sub-sections analyze each of these aspects.¶
This taxonomy could be used to design or analyze a specific type of limited domain. For the present document, it is intended only to form a background to the scope of protocols used in limited domains and the mechanisms required to securely define domain membership and properties.¶
Useful comments were received from Amelia Andersdotter, Edward Birrane, David Black, Ron Bonica, Mohamed Boucadair, Tim Chown, Darren Dukes, Donald Eastlake, Adrian Farrel, Tom Herbert, Ben Kaduk, John Klensin, Mirja Kuehlewind, Warren Kumari, Andy Malis, Michael Richardson, Mark Smith, Rick Taylor, Niels ten Oever, and others.¶