]> Google, LLC

warren@kumari.net

Liquid Intelligent Technologies

andrew-ietf@liquid.tech

Cisco

evyncke@cisco.com

Cisco

suresh.krishnan@gmail.com

Internet Internet Area Working Group Internet-Draft There is a trend towards documents describing protocols that are only intended to be used within "limited domains". These documents often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains //perfectly// implement filters to protect the rest of the global Internet from these protocols and vice-versa. This document discusses the concepts of "fail-open" versus "fail-closed" protocols and limited domains, and specifies a layer-2 mechanism that can be used for designing limited domain protocols that are safer to deploy. Discussion Venues Discussion of this document takes place on the Internet Area Working Group Working Group mailing list (int-area@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction discusses the concept of "limited domains", provides examples of limited domains, as well as Examples of Limited Domain Solutions, including Service Function Chaining (SFC), Segment Routing, "Creative uses of IPv6 features" (including Extension headers, e.g., for in situ Operations, Administration, and maintenance ). In order to provide context, this document will quote extensively from , but it is assumed that the reader will actually read in its entirety. Section 3, notes:

• 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.

Notably, in Section 2, states:

• 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.

This document addresses the problem of "leakage" of limited domain protocols by providing a mechanism so that nodes must be explicitly configured to handle the given limited-domain protocol ("fail-closed"), rather than relying on the network operator to take active steps to protect the boundary ("fail-open").

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Fail-open versus Fail-closed Protocols can be broadly classified as either "fail-open" or "fail-closed". Fail-closed protocols are those that require explicit interface or device-wide configuration to enable them to be accepted or processed when received on an interface. A classic example of a fail-closed protocol is MPLS (): In order to allow MPLS to transit an interface, the operator must enable the MPLS protocol on that interface and on the device itself. This ensures that outside MPLS traffic does not leak in. Fail-open protocols are those that require explicit configuration in order to ensure that they do not leak out of a domain, for example, through the application of filters. An example of a fail-open protocol is SRv6 - in order to ensure that SRv6 traffic does not leak out of a network, the operator must explicitly filter this traffic, and, in order to ensure that SRv6 traffic does not leak in, the operator must explicitly filter SRv6 traffic. Fail-open protocols are inherently more risky than fail-closed protocols, as they rely on perfect configuration of filters on all interfaces at the boundary of a domain, and, if the filters are removed for any reason (for example, during troubleshooting), there is a risk of inbound or oubound leaks. In addition, some devices or interfaces may have limitations in the size and complexity of filters that can be applied, and so adding new filter entries to limit leaks of a new protocol may not be possible. Fail-closed protocols, on the other hand, do not require any explicit filtering. In order for the protocol to be accepted and processed when received on an interface, the operator must explicitly enable the protocol on that interface and on the device itself. In addition, there is less risk of operational mistakes, as it does not rely on filters that may be limited in number and complexity. Finally, fail-closed protocols do not require that operators of networks outside of the limited domain implement filters to protect their networks from the limited domain traffic.

Making a layer-3 type limited-domain protocol fail-closed One way to make a limited-domain protocol fail-closed is to assign it a unique EtherType (this is the mechanism used by MPLS). In modern router and hosts, if the protocol (and so its associated EtherType) is not enabled on an interface, then the Ethernet chipset will ignore the frame, and the node OS will not process it. This is a very simple and effective mechanism to ensure that the protocol does not leak out of the limited domain if and when an operator makes a mistake in configuring filters. Note that this only works for transport-type limited domain protocols (i.e., protocols running at layer 3). Higher layer protocols cannot necessarily be protected in this way, and so cryptographically enforced mechanisms may need to be used instead (e.g as done used by ANIMA in and ). The EtherType is a 16-bit field in an Ethernet frame, and so it is a somewhat limited resource. Note that "Since EtherTypes are a fairly scarce resource, the IEEE RAC has let us know that they will not assign a new EtherType to a new IETF protocol specification until the IESG has approved the protocol specification for publication as an RFC. In exceptional cases, the IEEE RA is willing to consider "early allocation" of an EtherType for an IETF protocol that is still under development as long as the request comes from and has been vetted by the IESG." ( Appendix B.1, citing ) During development and testing, the protocol can use a "Local Experimental Ethertype" (0x88b5 and 0x88b6 - ). Once the protocol is approved for publication, the IESG can request an EtherType from the IEEE. For discussion: or simply defining one single EtherType for this testing? I.e., IPv4 and IPv6 can be identified by their first 4 bits. [ Editor note: EtherTypes are a scarce resource, and so we need to be careful about how we use them. It is likely that there will only be a very limited (sorry!) number of protocols that need to be protected in this way (on the order of 3 or 4). However, it is worth considering if there are other ways to achieve the same goal. An option would be to set aside a single EtherType, and then have a registry of "limited sub-EtherTypes" that are assigned by IANA. This would allow us to protect a large number of protocols, while only using a single EtherType, but would require something that looks more like a new L2 header. ] Another option to make a limited-domain protocol fail-closed is to use an identifier under the IANA OUI (00-00-5E) as explained in . [Editor note: This is a good idea, but it is not clear if it is practical. This above would need a bunch more text / discussion. It ends up being a bit like the "limited sub-EtherTypes" idea above, but with the additional complexity of not having the MAC address be the "normal" MAC address of the device that you are sending the traffic to. This will require more discussion with the WG, and the IEEE liaisons. ]

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance. Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042. Futurewei Technologies Cloudflare Huawei Technologies Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042.

Acknowledgments Much thanks to Brian Carpenter, for his review and comments. Also much thanks to Deborah Brungard, for her review and comments. Also much thanks to everyone else with whom we have discussed this topic; I've had numerous discussions with many many people on this, and I'm sure that I've forgotten some of them. Apologies if you were one of them.

Changelog

• 00-01:
  • Deborah pointed out that "this only works for transport-type limited domain protocols (e.g., SRv6)" could be read as SRv6 fails-closed.