Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT UCL
June 18, 2003 Ran Atkinson
Extreme Networks
General Requirements for
Emergency Telecommunication Service
<draft-ietf-ieprep-ets-general-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
This document presents a list of general requirements in support of
Emergency Telecommunications Service (ETS). Solutions to these
requirements are not presented in this document. Additional
requirements pertaining to specific applications, or types of
applications, are to be specified in separate document(s).
Conventions Used In This Document
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 [12].
Carlberg & Atkinson Expires December 18, 2003 [Page 1]
Internet Draft ETS General Requirements June 18, 2003
1. Introduction
Effective telecommunications capabilities can be imperative to
facilitate immediate recovery operations for serious disaster events,
such as, hurricanes, floods, earthquakes, and terrorist attacks.
Disasters can happen any time, any place, unexpectedly. Quick
response for recovery operations requires immediate access to any
public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet
access via online terminals, IP telephones, and wireless PDAs. The
commercial telecommunications infrastructure is rapidly evolving to
Internet-based technology. Therefore, the Internet community needs
to consider how it can best support emergency management and recovery
operations.
1.1 Existing Emergency Related Standards
The following are standards from other organizations that are
specifically aimed at supporting emergency communications. Most of
these standards 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
The first specifies an indicator for SS7 networks that signals the
need for a High Probability of Completion (HPC) service. This
indicator is termed National Security / Emergency Preparedness
(NS/EP) The T1.631 standard [2] is the basis for the U.S. Government
Emergency Telecomunications Service (GETS) [7].
The second standard describes functional capabilities for the PSTN to
support International Emergency Preparedness System (IEPS) [3]. From
the PSTN perspective, one can view NS/EP as a standard with national
boundaries, while IEPS is an extention to international boundaries
for telephony.
The third standard extends IEPS beyond the scope of telephony into
other forms that encompass multimedia [4].
The fourth and fifth standard focuses on a multi-level labeling
mechanism distinguishing emergency type traffic from that which is
Carlberg & Atkinson Expires December 18, 2003 [Page 2]
Internet Draft ETS General Requirements June 18, 2003
not. The former case focuses on call signaling for H.323 networks
[5], while the latter has been applied for both SS7 [6] and data
networks.
While the above standards are outside the scope of the IETF, they do
represent existing efforts in the area of emergency communications,
as opposed to conceptual of potential possibilities. They act as
example manifestations of Emergency Telecommunications Service (ETS).
1.2 Problem
One problem faced by the IEPREP working group entails how, and to
what degree, support for these standards are to be realized within
the Internet architecture and the existing suite of IETF standards
and associated working groups. This support could be in the form of
interoperability with correponding IETF protocols.
A subsequent problem is to ensure that requirements associated with
potential support is not focused just on IP telephony applications.
The I-Am-Alive (IAA) database system is an example of an ETS type
application used in Japan that supports both signaled and non-
signaled access by users[10]. It is a distributed database system
that provides registration, querying, and reply primitives to
participants during times of an emergency (e.g., an earthquake) so
that others can make an after-the-event determination about the
status of a person. In this case, a separate signaling protocol like
SIP is not always required to establish or maintain a connection.
Given the case where signaling is optional, requirements and
subsequent solutions that address these problems must not assume the
existance of signaling and must be able to support applications that
only have labels in data packets. These label(s) may be in various
places, such as the application or IP header.
Note. The term label has been used for a number of years in various
IETF protocols. It is simply an identifier. It can be manifested in
the form of an alphanumeric value, or it can be a specific bit
pattern, within a field of a packet header. Further comments on
labels are discussed below in section 3.
2. Scope
This document defines a set of general system requirements to achieve
support for ETS and addressing the problem space presented in Section
1.2. In defining these requirements, we consider known systems such
as GETS and IAA that represent existing manifestations of emergency
related systems. These two examples also represent a broad spectrum
of characteristics that range from signaling & interactive non-
Carlberg & Atkinson Expires December 18, 2003 [Page 3]
Internet Draft ETS General Requirements June 18, 2003
elastic applications to non-signaled & elastic applications.
We stress that ETS, and its associated requirements, is not the only
means of supporting authorized emergency communications. It is
simply an approach influenced by existing systems and standards.
Solutions to requirements are not defined. This document does not
specify protocol enhancements or specifications. Requirements for
specific types of applications that go beyond the general set stated
in section 3 are to be specified in other document(s). At the
current writing of this document, [9] has been written for the case
of IP telephony.
The current IEPREP charter stipulates that any proposed solution to
support ETS that responds to the requirements of this document are to
be developed in other working groups. We note that other specific
requirements (like that of IP telephony) may be defined as an
extension of the general requirements presented in section 3 below.
2.1 Out of Scope
While the problem space stated in section 1.2 includes standards
related to telephony, this document is meant to be broader in scope.
Hence, emulation of specific architectures, like the PSTN, or focus
on a specific application is out of scope. Further, the
specifications of requirements that are aimed at adhering to
regulations or laws of governments is also out of scope of this
document. The focus of the IETF and its working groups is technical
positions that follow the architecture of the Internet.
Another item that is not in scope of this document is mandating
acceptance and support of the requirements presented in this
document. There is an expectation that business contracts, (e.g.,
Service Level Agreements) , will be used to satisfy those
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 presented as a
conditional one since not all applications use or are reliant on
signaling.
1) Signaling
IF signaling is to be used to convey the state or existance of
emergency, then signaling mechanism(s) MUST exist to carry
Carlberg & Atkinson Expires December 18, 2003 [Page 4]
Internet Draft ETS General Requirements June 18, 2003
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 MAY be related to each other.
3) Policy
Policy MUST be kept separate from label(s). This topic has
generated a fair amount of debate, and so we provide additional
guidance from the following:
A set of labels may be defined as being 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 mechanism(s) used to achieve or support a specific
characteristic. This allows for the possibility of different
mechanisms to achieve 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 to support better than best effort 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 better than best effort functionality MUST
exist. There is NO requirement that if better-than-best effort
functionality exists then it must be ubuiquitous between end
users.
3.1 General Security Related Requirements
The following are security related requirements that emerge given the
Carlberg & Atkinson Expires December 18, 2003 [Page 5]
Internet Draft ETS General Requirements June 18, 2003
requirements 1 through 4 above.
5) Authorisation
Authorisation is a method of validating that a user or some
traffic is allowed by policy to use a particular service
offering.
Mechanisms must be implemented so that only authorised users
have access to emergency telecommunications services. Any
mechanism for providing such authorisation 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,
from abuse, and 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 conceptually they are different. Authentication
ensures that the user or traffic is who it claims to be.
Integrity offers assurance that unauthorised modifications
to objects can be detected.
Authorised emergency traffic needs to have reduced risk of
adverse impact from denial of service. This implies a need to
ensure integrity of the authorised emergency network traffic.
It should be noted, though, that mechanisms used to ensure
integrity can also be subjects 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 have a requirement that they
not be susceptible to interception or viewing by others, due to
the sensitive and urgent nature of emergency response activities.
Carlberg & Atkinson Expires December 18, 2003 [Page 6]
Internet Draft ETS General Requirements June 18, 2003
An emergency telecommunications service MAY offer options to
provide confidentiality for certain authorised 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 presents issues that arise in considering solutions for
the requirements that have been defined for ETS. This section does
not specify solutions nor is it to be confused with requirements.
Subsequent documents that articulate a more specific set of
requirements for a particular service may make a statement about the
following issues.
1) Accounting
Accounting represents a method of tracking actual usage of a
service. We assume that the usage of any service better than
best effort will be tracked and subsequently 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 of section 3 discuss labels and security. In
going beyond this, the ability to distinguish emergency flows
implies the need for admission control if resources become
scarce. Solutions must recognize this when trying to satisfy
the above requirements such that the simple presence of a label
does not imply admission control always exists along the
end-to-end path.
3) Digital Signatures
Verification of digital signatures is computationally expensive.
If an operator acts upon a label and hence needs to verify the
authenticity of the label, then there is a potential denial-of-
service attack on the entity performing the authentication.
The DoS attack works by flooding the entity performing the
Carlberg & Atkinson Expires December 18, 2003 [Page 7]
Internet Draft ETS General Requirements June 18, 2003
authentication with invalid (i.e. not authentic) labelled
information, causing the victim to spend 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
expend significant amounts of computing resource. Accordingly,
any system requiring such validation SHOULD define operational
and protocol measures to reduce the vulnerability to such a DoS
attack.
5. Related Work
RFC 3487 describes requirements for resource priority mechanisms for
the Session Initiation Protocol [8]. The requirements specified in
that RFC pertain to a specific application level protocol. In
contrast, the requirements of this document 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.
7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
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,
Recomendation, I.255.3, July, 1990.
7 U.S. National Communications System: http://www.ncs.gov
Carlberg & Atkinson Expires December 18, 2003 [Page 8]
Internet Draft ETS General Requirements June 18, 2003
8 Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, Feb 2003
9 Carlberg, K., Atkinson, R., "IP Telephony Reqirements for
Emergency Telecommunications Service", Internet Draft, Work In
Progress, March 1, 2003
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., et. al., "Assured Forwarding PHB Group", RFC 2597,
June 1999
12 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
8. Author's Addresses
Ken Carlberg Ran Atkinson
University College London Extreme Networks
Department of Computer Science 3585 Monroe Street
Gower Street Santa Clara, CA
London, WC1E 6BT 95051 USA
United Kingdom
k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com
Full Copyright Statement
"Copyright (C) The Internet Society (2003). 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, provided 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, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as 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 assigns.
Carlberg & Atkinson Expires December 18, 2003 [Page 9]
Internet Draft ETS General Requirements June 18, 2003
This document and the information contained herein is provided as 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 OR
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.
Carlberg & Atkinson Expires December 18, 2003 [Page 10]
