Safe(r) Limited Domains
draft-wkumari-intarea-safe-limited-domains-01

Internet Area Working Group                                    W. Kumari
Internet-Draft                                               Google, LLC
Intended status: Standards Track                               A. Alston
Expires: 9 January 2025                  Liquid Intelligent Technologies
                                                               É. Vyncke
                                                             S. Krishnan
                                                                   Cisco
                                                             8 July 2024

                        Safe(r) Limited Domains
             draft-wkumari-intarea-safe-limited-domains-01

Abstract

   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

   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 (int-area@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/int-area/.

   Source for this draft and an issue tracker can be found at
   https://github.com/wkumari/draft-wkumari-intarea-safe-limited-
   domains.

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

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

   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 9 January 2025.

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 (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 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 layer-3 type limited-domain protocol fail-closed . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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 in situ Operations, Administration, and
   maintenance [RFC9378]).

   In order to provide context, this document will quote extensively
   from [RFC8799], but it is assumed that the reader will actually read
   [RFC8799] in its entirety.

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

   [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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "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
   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 ([RFC3031]): 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.

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

   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.

4.  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 [RFC8994] and [RFC8995]).

   The EtherType is a 16-bit field in an Ethernet frame, and so it is a
   somewhat limited resource.

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

   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.

   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
   [RFC9542].

   [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. ]

5.  Security Considerations

   TODO Security

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

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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/rfc/rfc8799>.

7.2.  Informative References

   [I-D.ietf-intarea-rfc7042bis]
              Eastlake, D. E., Abley, J., and Y. Li, "IANA
              Considerations and IETF Protocol and Documentation Usage
              for IEEE 802 Parameters", Work in Progress, Internet-
              Draft, draft-ietf-intarea-rfc7042bis-11, 6 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
              rfc7042bis-11>.

   [IANA_EtherType]
              "IANA EtherType Registry", Web 
              <https://www.iana.org/assignments/ieee-802-numbers/ieee-
              802-numbers.xhtml#ieee-802-numbers-1>.

   [IESG_EtherType]
              "IESG Statement on EtherTypes", Web
              <https://www.ietf.org/about/groups/iesg/statements/
              ethertypes>, 1 May 2023.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/rfc/rfc3031>.

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

   [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,
              <https://www.rfc-editor.org/rfc/rfc8754>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/rfc/rfc8994>.

   [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, <https://www.rfc-editor.org/rfc/rfc8995>.

   [RFC9378]  Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T.
              Mizrahi, Ed., "In Situ Operations, Administration, and
              Maintenance (IOAM) Deployment", RFC 9378,
              DOI 10.17487/RFC9378, April 2023,
              <https://www.rfc-editor.org/rfc/rfc9378>.

   [RFC9542]  Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
              Considerations and IETF Protocol and Documentation Usage
              for IEEE 802 Parameters", BCP 141, RFC 9542,
              DOI 10.17487/RFC9542, April 2024,
              <https://www.rfc-editor.org/rfc/rfc9542>.

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.

Authors' Addresses

Kumari, et al.           Expires 9 January 2025                 [Page 7]
Internet-Draft            safer-limited-domains                July 2024

   Warren Kumari
   Google, LLC
   Email: warren@kumari.net

   Andrew Alston
   Liquid Intelligent Technologies
   Email: andrew-ietf@liquid.tech

   Éric Vyncke
   Cisco
   Email: evyncke@cisco.com

   Suresh Krishnan
   Cisco
   Email: suresh.krishnan@gmail.com

Kumari, et al.           Expires 9 January 2025                 [Page 8]