RFC 4375

Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain 🎀

Title block, bestie 💖

Network Working Group Request for Comments: 4375 Category: Informational Written by K. Carlberg (G11) Dated January 2006

This one doesn't obsolete or update anything. It's just a standalone set of requirements, and it's Informational, so it's sharing info with the Internet community and doesn't set any standard. 🧚

---

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice 🌸

Copyright (C) The Internet Society (2006).

Abstract 🦋

Okay so this doc lists the requirements that support Emergency Telecommunications Service (ETS) inside a single administrative domain. It's super focused on one specific set of admin constraints and scope. The solutions to these requirements? Not in here, bestie. This is the wishlist, not the recipe. 💅

1. Introduction 🍓

The whole point of this doc is to define a set of requirements that support ETS within one domain. The IEPREP mailing list and working group meetings have had a LOT of chats about whether a given mechanism is actually useful for ETS. Some people are all about over-provisioning, and others are more into specific schemas that give you a measurable level of service. 🤔

The thing everyone keeps coming back to is that administrative control of the resources matters a ton for how well any solution works. If you run a set of resources yourself, you can deploy pretty much any approach on that set. But once an approach crosses an administrative boundary, its effectiveness gets questionable, and at the very least it needs cooperation and trust from the other administrative domains. 😭 So to dodge that whole mess, we keep our scenario to the resources inside a single domain.

Here are some key terms used in this doc, so we're all on the same page. 📚

Resource: A resource can be looked at from the general level as IP nodes, like a router or host, plus the physical media (e.g., fiber) used to connect them. A host can also be called a client, server, or proxy if you want to get more specific. You can also look at resources more specifically, as the elements inside a node (e.g., CPU, buffer, memory). But this document is going to focus on the node level. 💖

Domain: This word gets used in a lot of ways. Here we only use it from the network layer's point of view, and we treat it as the same thing as an administrative domain. A domain can cover huge geographic regions and be made up of lots of different types of physical subnetworks. 🌈

Administrative Domain: This is the collection of resources under the control of one single administrative authority. That authority decides how the set of resources (i.e., the network) is designed and operated. 👑

Transit Domain: This is an administrative domain that forwards traffic from one domain to another. An Internet Service Provider (ISP) is an example of a transit domain. 🛰️

Stub Domain: This is an administrative domain that's either the source or the destination of a flow of IP packets. As a general rule, it doesn't forward traffic destined for other domains. The odd exception is Mobile IP and its use of "dog-leg" routing to visiting hosts sitting in foreign networks. An enterprise network is an example of a stub domain. 🎀

1.1. Previous Work 📖

[RFC3689] has a list of general requirements for supporting ETS. It lays out requirements for the broad case of supporting ETS over the Internet. Since it isn't tied to specific applications, administrative boundaries, or scenarios, its requirements are pretty general in how they're described and how far they reach. That's on purpose: the general requirements are meant to be a baseline, and more specific requirements that cover a narrower scope can be built on top of them if needed. ✨

The requirements in Section 3 below are the narrower, single-administrative-domain version. Just like [RFC3689], they're things to think about when solutions are being designed, specified, and deployed. 🫶 Key words such as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🔥

2. Scope 🌟

IETF standards that cover the resources within an administrative domain are in scope for this doc. That includes gateways, routers, servers, etc., that are located and administered inside the domain. This document also doesn't limit itself to one type of application, like Voice over IP. 🎧

Quality of Service (QoS) mechanisms are in scope too. These mechanisms may live at the application, transport, or IP network layer. QoS mechanisms might also exist at the link/physical layer, but this doc only looks at potential mappings of labels or code points there. 🧩

And since this doc is all about one single administrative domain, we don't make any further distinction between transit and stub domains here. 💅

2.1. Out of Scope 🚫

Resources owned or operated by other administrative authorities are out of scope. One example is a SIP server that operates in other domains. Another example is an access link connecting the stub domain to its provider. Controlling only 1/2 of a link (the egress traffic from the stub) is considered insufficient for counting inter-domain access links as a subject for this document. Half a link is not the whole vibe, periodt. 🙈

---

3. Requirements 📝

It must be understood that all of the following requirements pertain to mechanisms a domain's administrative authority picks to specifically support ETS. If that authority decides not to support ETS, or if these mechanisms exist inside the domain only for a different purpose, then the associated requirement doesn't apply. Totally fair! 🦋

3.1. Label Mechanisms 🏷️

Application or transport layer label mechanisms used for ETS MUST be extensible, so they can support more than one label. These mechanisms MUST avoid a single off/on type of label (e.g., a single bit). On top of that, designers of such a mechanism MUST assume there may be more than one set of ETS users. Big "plan for the crowd" energy 👑

Network layer label mechanisms used for ETS SHOULD be extensible so they can support more than one label. We make this distinction because there may be fewer bits (a smaller field) available at the network layer than at the transport or application layer. Less space, so the rules bend a little 🥺

3.2. Proxies 🧚

Proxies MAY set ETS labels on behalf of the source of a flow. This may involve removing labels that were set by upstream node(s).

If proxies take that kind of action, then the security measures discussed in [RFC3689] MUST be considered. More information about security in the single-domain context is found below in Section 5. Security is serious, bestie 😭🔒

3.3. QoS Mechanisms 📶

[RFC3689] defines a label as an identifier, and the set of characteristics associated with the label as policy. However, QoS in the traditional sense of delay or bandwidth is not automatically bound to a label. MPLS [RFC3031] is an example of a labeling mechanism that can provide specific QoS or just traffic engineering of labeled flows. 🛤️

In the context of ETS, QoS mechanisms, at either the network or application layer, SHOULD be used when networks can't be over-provisioned to handle high bursts of traffic load. Examples include bridging fiber networks to wireless subnetworks, or remote subnetworks connected over expensive, bandwidth-constrained wide area links. 🌩️

Note well. Over-provisioning is a normal, cost-effective practice among network administrators and engineers. How much over-provisioning is enough can be a topic of debate. There's a deeper dive on this in the companion Framework document [FRAME]. 🍿

3.4. Users 👥

When it comes to existing IETF-specified applications, augmentations in the form of labeling mechanisms that support ETS MUST NOT adversely affect their legacy usage by non-ETS users. For future applications, such labeling mechanisms SHOULD allow the application to support a "normal" (non-emergency) condition. Everyone gets a seat at the table 🫶

3.5. Policy ⚖️

Policy MUST be used to determine the percentage of a mechanism's resources used to support the various (ETS and non-ETS) users. Under certain conditions, this percentage MAY reach 100% for a specific set of users. However, we recommend that this "all-or-nothing" approach be considered with great care. Going all in is a big move, so think it through 🙈

3.6. Discovery 🔍

There should be a means of forwarding ETS labeled flows to those mechanisms within the domain used to support ETS. Discovery mechanisms SHOULD be used to determine where ETS labeled flows (either data or control) are to be forwarded. Finding the right path is everything ✨

3.7. MIB 📊

Management Information Bases (MIBs) SHOULD be defined for mechanisms specifically in place to support ETS. These MIBs MAY include objects representing accounting, policy, and authorization. Receipts, rules, and access, all in one place 💜

---

4. Issues 🌸

This section presents issues that come up when considering solutions for the requirements defined for stub domains that support ETS. This section doesn't specify solutions, and it's NOT to be confused with requirements. Subsequent documents that lay out a more specific set of requirements for a particular service may make a statement about the following issues. Think of these as the "watch out for this" notes 👀

4.1. Alternative Services 💫

The form of service given to ETS users, written up as policies, can show up in a few different ways. Better than best effort is probably what most ETS users would expect when the communication system is stressed and overall quality has dropped. But the idea of best available service should also be considered under those stressed conditions. A measure of degraded service may also be desirable, since it can keep some communication going versus none at all. These services may be made available at the network or application layer. 🌈

4.2. Redundancy 🔁

Making networks fault tolerant is important, but it's not something that can be easily written up as protocol requirements. Redundancy in connectivity and nodes (be it routers or servers) is probably the most common approach network administrators take, and it's fair to assume that administrative domains apply this approach to their own resources to varying degrees. Backup plans are very much iconic 💅

---

Part 1 wraps up right here, bestie! 🎀 Part 2 is coming with the rest of the doc, so keep your eyes peeled 👀💖

5. Security Considerations 🔐✨

Okay bestie, this section is SERIOUS 😭 The doc really wants you to review and follow the security comments and requirements in [RFC3689]. Here's the tea though: intra-domain security (stuff inside one administrative domain) is usually held to a lower standard than inter-domain security (stuff between domains). Like, admins might allow telnet between resources inside their own domain, but they would only allow SSH access from other domains. 💀

The policy mismatch can be a real problem when domains offer services other than best effort for ETS users 🙈 So any support for ETS within a domain should be accompanied by a detailed security policy for users and administrators. Non-negotiable, periodt 💅

Now, since Section 3.8 has that "SHOULD" statement about MIBs 👀 there are a few security things you need to know:

• Most current deployments of Simple Network Management Protocol (SNMP) are on versions prior to SNMPv3, even though there are well-known security vulnerabilities in those versions of SNMP. 🫠
• SNMP versions prior to SNMPv3 cannot support cryptographic security mechanisms. Hence, any use of SNMP prior to version 3 to write or modify MIB objects do so in a non-secure manner. As a result, it may be best to constrain the use of these objects to read-only by MIB managers. 🔒
• Finally, any MIB defining writable objects should carefully consider the security implications of an SNMP compromise on the mechanism(s) being controlled by those writable MIB objects. 👑

6. Acknowledgements 🎀

Big thank you to Ran Atkinson, James Polk, Scott Bradner, Jon Peterson, and Ian Brown for their comments on previous versions of this document. 🫶

7. Informative References 📚

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
• [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
• [FRAME] Carlberg, K., "A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain", Work in Progress, December 2005.

Author's Address 📮

Ken Carlberg
G11
123a Versailles Circle
Baltimore, MD
USA

EMail: carlberg@g11.org.uk

Full Copyright Statement ©️

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org. 🌸

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).