RFC 3689

General Requirements for Emergency Telecommunication Service (ETS)

📅 published February 2004, from ietf

General Requirements for Emergency Telecommunication Service (ETS) 🚨

Okay bestie, this one is RFC 3689 🌸 Its title is "General Requirements for Emergency Telecommunication Service (ETS)." The authors are K. Carlberg from UCL and R. Atkinson from Extreme Networks. It's Informational 🦋 and it's dated February 2004. The title block doesn't list anything it obsoletes or updates.

Status of This Memo ✨

This memo gives information to the Internet community 💜 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2004). All Rights Reserved. 💅

Abstract 🫶

This document lists general requirements that support Emergency Telecommunications Service (ETS) 🚑 Solutions to these requirements are not presented here. Extra requirements for specific applications, or types of applications, are going to be specified in separate document(s) 📄

1. Introduction ✨

Okay so, effective telecom can be imperative for quick recovery after serious disasters 😭 Think hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, totally unexpectedly. For recovery work, responders need immediate access to whatever public telecom capabilities are on hand 📱 That includes conventional telephones, cellular phones, and Internet access through online terminals, IP telephones, and wireless PDAs. The commercial telecom infrastructure is rapidly evolving to Internet-based technology, so the Internet community needs to figure out how it can best support emergency management and recovery operations 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] 🧚

1.1. Terminology 🍓

Label: The term label has been floating around IETF protocols for years 🦋 It's simply an identifier. It can show up as a numeric value, an alphanumeric value, or a specific bit pattern, inside a field of a packet header. The exact form depends on the protocol it's used in.

An example of a label is in RFC 3031, the Multiprotocol Label Switching Architecture 💖 Another example is in RFC 2597 (and updated by RFC 3260): a bit pattern for the Assured Forwarding PHB group. This second case is a type of label that does not involve routing. Note that specifying labels is outside the scope of this document. More comments on labels are discussed below in section 3 🌸

The following are standards from other organizations that are specifically aimed at supporting emergency communications 📞 Most of them specify telephony mechanisms or define telephony related labels.

 Standard   / Organization
--------------------------
1) T1.631   /   ANSI
2) E.106    /   ITU
3) F.706    /   ITU
4) H.460.4  /   ITU
5) I.255.3  /   ITU

Okay, the first one, T1.631 from ANSI, specifies an indicator for SS7 networks that signals the need for a High Probability of Completion (HPC) service 🔥 This indicator is called National Security / Emergency Preparedness (NS/EP). The T1.631 standard [2] is the basis for the U.S. Government Emergency Telecommunications Service (GETS) [7] 🇺🇸

The second, E.106 from the ITU, describes functional capabilities for the Public Switched Telephone Network (PSTN) to support the International Emergency Preparedness System (IEPS) [3] 💜 From the PSTN perspective, you can view NS/EP as a standard with national boundaries, while IEPS extends that to international boundaries for telephony.

The third, F.706, extends IEPS beyond telephony into other forms that include multimedia [4] 🎀

The fourth and fifth, H.460.4 and I.255.3, focus on a multi-level labeling mechanism that separates emergency type traffic from everything else 👑 The first of these focuses on call signaling for H.323 networks [5], while the second has been applied to both SS7 [6] and data networks ✨

Now, while the above standards are outside the scope of the IETF, they do represent existing efforts in emergency communications, as opposed to just conceptual possibilities 🫶 They're example manifestations of Emergency Telecommunications Service (ETS) 💅

1.3. Problem 🙈

One problem the IEPREP working group faces is how, and to what degree, support for these standards should be realized within the Internet architecture and the existing suite of IETF standards and associated working groups 🧠 This support could take the form of interoperability with corresponding IETF protocols.

A follow-up problem is making sure that requirements for potential support aren't focused just on IP telephony applications 📲 The I-Am-Alive (IAA) database system is an example of an ETS type application used in Japan. It supports both signaled and non-signaled access by users [10] 🇯🇵 It's a distributed database system that provides registration, querying, and reply primitives to participants during emergencies (like an earthquake), so others can make an after-the-event determination about a person's status 🥺 In this case, a separate signaling protocol like SIP is not always required to establish or maintain a connection.

So, given that signaling is optional, the requirements and later solutions that address these problems must not assume signaling exists, and must be able to support applications that only have labels in data packets 🌈 These label(s) may sit in various places, such as the application or IP header.

2. Scope 🦋

This document defines a set of general system requirements to support ETS and to address the problem space presented in Section 1.3 💖 While defining these requirements, we considered known systems like GETS and IAA, which are existing manifestations of emergency related systems. These two examples also cover a broad spectrum of characteristics, ranging from signaling & interactive non-elastic applications to non-signaled & elastic applications ✨

We really stress that ETS, and its requirements, is not the only way to support authorized emergency communications 🫶 It's simply one approach, influenced by existing systems and standards.

Solutions to these requirements are not defined here. This document does not specify protocol enhancements or specifications. Requirements for specific types of applications that go beyond the general set in section 3 are to be specified in other document(s) 📝 As of this writing, [9] has been written for the case of IP telephony 📞

The current IEPREP charter says any proposed solution to support ETS that responds to this document's requirements is to be developed in other working groups 🧚 We note that other specific requirements (like those for IP telephony) may be defined as an extension of the general requirements in section 3 below.

2.1. Out of Scope 🚫

While the problem space in section 1.3 includes standards related to telephony, this document is meant to be broader in scope 🌸 So emulating specific architectures, like the PSTN, or focusing on one specific application is out of scope. Also out of scope are requirements aimed at adhering to government regulations or laws 🏛️ The focus of the IETF and its working groups is technical positions that follow the architecture of the Internet.

Another thing that's not in scope is mandating acceptance and support of the requirements in this document 🙅‍♀️ The expectation is that business contracts (e.g., Service Level Agreements) will be used to satisfy the requirements that apply to service providers. Absence of an SLA implies best effort service is provided 💀

3. General Requirements 💜

These are general requirements that apply to authorized emergency telecommunications service 👑 The first requirement is conditional, since not all applications use or rely on signaling.

1) Signaling

IF signaling is to be used to convey the state or existence of emergency, then signaling mechanism(s) MUST exist to carry applicable labels 📣

2) Labels

Labels may exist in various forms at different layers 🍓 They might be carried as part of signaling, and/or as part of the header of a data packet. Labels from different layers are NOT required to be the same, but they MAY be related to each other 🦋

3) Policy

Policy MUST be kept separate from label(s) 🙈 This topic has caused a fair amount of debate, so here's some additional guidance:

A set of labels may be defined as related to each other. Characteristics (e.g., drop precedence) may also be attributed to these labels. [11] is an example of a related set of labels based on a specific characteristic 🎀

However, the mechanisms used to achieve a stated characteristic MUST NOT be stated in the definition of a label. Local policy determines the mechanism(s) used to achieve or support a specific characteristic. This allows for the possibility of different mechanisms achieving the same stated characteristic ✨

The interaction between unrelated labels MUST NOT be embedded within the definition of a label. Local policy states the actions (if any) to be taken if unrelated labeled traffic merges at a node 🧠

Finally, labels may have additional characteristics added to them as a result of local policy 🌈

4) Network Functionality

Functionality that supports a better than best effort service SHOULD focus on probability versus guarantees 🌸 Probability can be realized in terms of reduced probability of packet loss, and/or minimal jitter, and/or minimal end-to-end delay. There is NO requirement that a better than best effort functionality MUST exist. There is NO requirement that if a better than best effort functionality exists, then it must be ubiquitous between end users 💅

Okay so these are the security requirements that pop out once you've got requirements 1 through 4 locked in 🔐🎀

5) Authorization 🗝️

Authorization is basically a way of checking that a user or some traffic is allowed, by policy, to use a particular service offering 💅

Mechanisms must be implemented so that only authorized users have access to emergency telecommunications services. Any mechanism for providing that authorization beyond closed private networks SHOULD meet IETF Security Area criterion (e.g., clear-text passwords would not generally be acceptable) 🙈 Authorization protects network resources from excessive use and from abuse, and it might also support billing and accounting for the offered service 💰

Such authorization mechanisms SHOULD be flexible enough to provide various levels of restriction and authorization, depending on the expectations of a particular service or customer 🌈

6) Integrity & Authentication 🫶

In practice, authentication and integrity for IP based communications are generally bound within a single mechanism, even though they're conceptually different things 🤓 Authentication makes sure that the user or traffic is who it claims to be. Integrity gives you assurance that unauthorized modifications to objects can be detected 🔍

Authorized emergency traffic needs to have reduced risk of adverse impact from denial of service, and that means it needs integrity of the authorized emergency network traffic. It should be noted, though, that the mechanisms used to ensure integrity can also be subject to Denial of Service attacks 😭

Users of emergency network services SHOULD consider deploying end-to-end integrity and authentication, rather than relying on services that might be offered by any single provider of emergency network services 🦋 Users SHOULD also carefully consider which application-layer security services might be appropriate to use 💖

7) Confidentiality 🤫

Some emergency communications might need to be kept away from interception or viewing by others, because emergency response activities are sensitive and urgent 🚨 An emergency telecommunications service MAY offer options to provide confidentiality for certain authorized user traffic ✨

Consistent with other IETF standards and the Internet Architecture, this document recommends that IEPREP users SHOULD deploy end-to-end security mechanisms, rather than rely on security services that might be offered by a single network operator 🌸 IEPREP users SHOULD carefully consider security alternatives (e.g., PGP, TLS, IPsec transport-mode) at different layers (e.g., Application Layer, Session Layer, Transport Layer) of the Internet Architecture before deployment 🧚

4. Issues 🔥

This section looks at issues that come up when you're thinking about solutions for the requirements already defined for ETS 🧠 It does not specify solutions, and it is not to be confused with requirements, so don't mix them up bestie 🙅‍♀️ Subsequent documents that spell out a more specific set of requirements for a particular service may make a statement about the following issues 📝

1) Accounting 💸

Accounting is a way of tracking actual usage of a service. We assume that the usage of any service better than best effort will be tracked and then billed to the user. Accounting is not addressed as a general requirement for ETS. However, solutions used to realize ETS should not preclude an accounting mechanism 🧾

2) Admission Control 🚪

The requirements in section 3 talk about labels and security. Those developing solutions should understand that the ability labels provide to distinguish emergency flows does not create an ability to selectively admit flows 🙃 Admission control, as it's commonly understood in circuit-switched networks, is not present in IP-based networks, and schemes which presume the ability to selectively admit flows when resources are scarce will fail outside of very controlled environments 💀 So when emergency related flows happen outside of controlled environments, developing technologies based on admission control is not recommended as the foundation of emergency services 🙅‍♀️

3) Digital Signatures ✍️

Verifying digital signatures is computationally expensive 🥵 If an operator acts upon a label and so needs to verify the authenticity of the label, there is a potential denial-of-service attack on the entity doing the authentication. The DoS attack works by flooding that entity with invalid (i.e., not authentic) labelled information, which makes the victim burn excessive amounts of computing resources on signature validation. Even though the invalid information might get discarded after the signature validation fails, the adversary has already forced the victim to spend significant computing resources 😤 Accordingly, any system requiring such validation SHOULD define operational and protocol measures to reduce the vulnerability to such a DoS attack 🛡️

RFC 3487 describes requirements for resource priority mechanisms for the Session Initiation Protocol [8] 🎀 The requirements in that RFC pertain to a specific application level protocol. This document is different: its requirements are a generalization that are not application specific. From this blueprint (acting as a guideline), more specific requirements may be described in future documents 🔮

6. Security Considerations 🔐

Security in terms of requirements is discussed sections 3.1 and 4. Yes, the security stuff is all in there, so go read it, it's serious business 😭💅

7. References 📖

7.1. Normative Reference

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

7.2. Informative References

[2] ANSI, "Signaling System No. 7(SS7) "High Probability of Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999).

[3] "Description of an International Emergency Preference Scheme (IEPS)", ITU-T Recommendation E.106 March, 2000.

[4] "Description for an International Emergency Multimedia Service", ITU Draft Recommendation F.706, February, 2002.

[5] "Call Priority Designation for H.323 Calls", ITU Recommendation H.460.4, November, 2002.

[6] ITU, "Multi-Level Precedence and Preemption Service, ITU, Recommendation, I.255.3, July, 1990.

[7] U.S. National Communications System: http://www.ncs.gov

[8] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.

[9] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service", RFC 3690, February 2004.

[10] Tada, N., et. al., "IAA System (I Am Alive): The Experiences of the Internet Disaster Drills", Proceedings of INET-2000, June.

[11] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.

8. Authors' Addresses 🧳

Ken Carlberg
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom

EMail: k.carlberg@cs.ucl.ac.uk


Ran Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
95051  USA

EMail: rja@extremenetworks.com

Copyright (C) The Internet Society (2004). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. The one condition is that the above copyright notice and this paragraph are included on all such copies and derivative works 📜 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it into languages other than English 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees ♾️

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 🙏

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from