Skip to main content

Safe(r) Limited Domains

Document Type Active Internet-Draft (individual)
Authors Warren "Ace" Kumari , Andrew Alston , Éric Vyncke , Suresh Krishnan
Last updated 2024-01-19
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Internet Area Working Group                                    W. Kumari
Internet-Draft                                               Google, LLC
Intended status: Standards Track                               A. Alston
Expires: 22 July 2024                    Liquid Intelligent Technologies
                                                               É. Vyncke
                                                             S. Krishnan
                                                         19 January 2024

                        Safe(r) Limited Domains


   There is a trend towards documents describing protocols that are only
   intended to be used within "limited domains".  Unfortunately, these
   drafts often do not clearly define how the boundary of the limited
   domain is established and enforced, or require that operators of
   these limited domains //perfectly// implement filters to protect the
   rest of the Internet from these protocols.

   In addition, these protocols sometimes require that networks that are
   outside of (and unaffiliated with) the limited domain explicitly
   implement filters in order to protect their networks if these
   protocols leak outside of the limited domain.

   This document discusses the concepts of "fail-open" versus "fail-
   closed" protocols and limited domains, and provides a mechanism for
   designing limited domain protocols that are safer to deploy.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Internet Area Working
   Group Working Group mailing list (, which is
   archived at

   Source for this draft and an issue tracker can be found at

Status of This Memo

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

Kumari, et al.            Expires 22 July 2024                  [Page 1]
Internet-Draft            safer-limited-domains             January 2024

   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

   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 22 July 2024.

Copyright Notice

   Copyright (c) 2024 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 (
   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Fail-open versus Fail-closed  . . . . . . . . . . . . . . . .   3
   4.  Making a transport type limited-domain protocol
           fail-closed . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [RFC8799] 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 segment routing [RFC8754])

Kumari, et al.            Expires 22 July 2024                  [Page 2]
Internet-Draft            safer-limited-domains             January 2024

   In order to provide context, this document will quote extensively
   from [RFC8799], but it is expected (well, hoped!) that the reader
   will actually read [RFC8799] in its entirety.  It's relatively short,
   and it is a very good read!

   [RFC8799] 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 [RFC8799] 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").

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  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
   configuration to enable them to transit an interface.  A classic
   example of a fail-closed protocol is MPLS ([RFC3031]): In order to
   allow MPLS to transit an interface, the operator must enable the MPLS
   protocol on that interface.  This helps ensure that MPLS traffic does

Kumari, et al.            Expires 22 July 2024                  [Page 3]
Internet-Draft            safer-limited-domains             January 2024

   not leak out of the network, while also ensuring 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 may ignore operational realities; 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), the network is at risk.  In
   addition, devices (especially those using TCAM based filter
   mechanisms) may have limitations in the number and complexity of
   filters that can be applied, and so adding new filter entries to
   protect against new protocols may not be possible.

   Fail-closed protocols, on the other hand, do not require any explicit
   filtering.  In order for the protocol to transit an interface, the
   operator must explicitly enable the protocol on that interface.  In
   addition, the protocol is inherently more robust, as it does not rely
   on filters that may be limited in number and complexity.  Finally,
   fail-closed protocols are inherently more secure, as they do not
   require that operators of networks outside of the limited domain
   implement filters to protect their networks from the limited domain

4.  Making a transport 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 drop
   the frame, and the host will not see it.  This is a very simple and
   effective mechanism to ensure that the protocol does not leak out of
   the limited domain.

   Note that this only works for transport-type limited domain protocols
   (e.g., SRv6).  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 [RFC8994] and

Kumari, et al.            Expires 22 July 2024                  [Page 4]
Internet-Draft            safer-limited-domains             January 2024

   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."
   ([I-D.ietf-intarea-rfc7042bis] Appendix B.1, citing [IESG_EtherType])

   During development and testing, the protocol can use a "Local
   Experimental Ethertype" (0x88B5 and 0x88B6 - [IANA_EtherType]).  Once
   the protocol is approved for publication, the IESG can request an
   EtherType from the IEEE.

5.  Security Considerations

   TODO Security

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,

7.2.  Informative References

              Eastlake, D. E., Abley, J., and Y. Li, "IANA
              Considerations and IETF Protocol and Documentation Usage
              for IEEE 802 Parameters", Work in Progress, Internet-

Kumari, et al.            Expires 22 July 2024                  [Page 5]
Internet-Draft            safer-limited-domains             January 2024

              Draft, draft-ietf-intarea-rfc7042bis-11, 6 November 2023,

              "IANA EtherType Registry", Web 

              "IESG Statement on EtherTypes", Web

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <>.


   We've been trying to reach you about your car's extended warranty.
   Please call us back at 1-800-555-1212.

   Much thanks to Brian Carpenter, for his 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.

Authors' Addresses

Kumari, et al.            Expires 22 July 2024                  [Page 6]
Internet-Draft            safer-limited-domains             January 2024

   Warren Kumari
   Google, LLC

   Andrew Alston
   Liquid Intelligent Technologies

   Éric Vyncke

   Suresh Krishnan

Kumari, et al.            Expires 22 July 2024                  [Page 7]