Safe(r) Limited Domains
draft-wkumari-intarea-safe-limited-domains-00
| 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) | ||
| Formats | |||
| 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) |
draft-wkumari-intarea-safe-limited-domains-00
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
Cisco
19 January 2024
Safe(r) Limited Domains
draft-wkumari-intarea-safe-limited-domains-00
Abstract
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 (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.
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 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 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 (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 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",
"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
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
protocols.
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
[RFC8995]).
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,
<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-
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,
<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>.
[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>.
[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>.
Acknowledgments
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
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 22 July 2024 [Page 7]