< draft-ietf-ieprep-ets-general-03.txt   draft-ietf-ieprep-ets-general-04.txt >
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT UCL INTERNET DRAFT UCL
June 18, 2003 Ran Atkinson August 25, 2003 Ran Atkinson
Extreme Networks Extreme Networks
General Requirements for General Requirements for
Emergency Telecommunication Service Emergency Telecommunication Service
<draft-ietf-ieprep-ets-general-03.txt> <draft-ietf-ieprep-ets-general-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 5 skipping to change at page 2, line 5
requirements are not presented in this document. Additional requirements are not presented in this document. Additional
requirements pertaining to specific applications, or types of requirements pertaining to specific applications, or types of
applications, are to be specified in separate document(s). applications, are to be specified in separate document(s).
Conventions Used In This Document Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [12]. document are to be interpreted as described in [12].
^L
Terminology
Label:
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 a numeric, alphanumeric value, or a specific bit
pattern, within a field of a packet header. The exact form is
dependent on the protocol in which it is used.
An example of a label can be found in RFC 3031; the Multiprotocol
label switching architecture. Another example can be found in RFC
2597 (and updated by RFC 3260); a bit pattern for the Assured
Forwarding PHB group. This latter case is a type of label that
does not involve routing. Note that specification of labels is
outside the scope of this document. Further comments on labels are
discussed below in section 3.
1. Introduction 1. Introduction
Effective telecommunications capabilities can be imperative to Effective telecommunications capabilities can be imperative to
facilitate immediate recovery operations for serious disaster events, facilitate immediate recovery operations for serious disaster events,
such as, hurricanes, floods, earthquakes, and terrorist attacks. such as, hurricanes, floods, earthquakes, and terrorist attacks.
Disasters can happen any time, any place, unexpectedly. Quick Disasters can happen any time, any place, unexpectedly. Quick
response for recovery operations requires immediate access to any response for recovery operations requires immediate access to any
public telecommunications capabilities at hand. These capabilities public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet include: conventional telephone, cellular phones, and Internet
access via online terminals, IP telephones, and wireless PDAs. The access via online terminals, IP telephones, and wireless PDAs. The
skipping to change at page 2, line 35 skipping to change at page 3, line 5
related labels. related labels.
Standard / Organization Standard / Organization
-------------------------- --------------------------
1) T1.631 / ANSI 1) T1.631 / ANSI
2) E.106 / ITU 2) E.106 / ITU
3) F.706 / ITU 3) F.706 / ITU
4) H.460.4 / ITU 4) H.460.4 / ITU
5) I.255.3 / ITU 5) I.255.3 / ITU
^L
The first specifies an indicator for SS7 networks that signals the The first specifies an indicator for SS7 networks that signals the
need for a High Probability of Completion (HPC) service. This need for a High Probability of Completion (HPC) service. This
indicator is termed National Security / Emergency Preparedness indicator is termed National Security / Emergency Preparedness
(NS/EP) The T1.631 standard [2] is the basis for the U.S. Government (NS/EP) The T1.631 standard [2] is the basis for the U.S. Government
Emergency Telecomunications Service (GETS) [7]. Emergency Telecomunications Service (GETS) [7].
The second standard describes functional capabilities for the PSTN to The second standard describes functional capabilities for the PSTN to
support International Emergency Preparedness System (IEPS) [3]. From support International Emergency Preparedness System (IEPS) [3]. From
the PSTN perspective, one can view NS/EP as a standard with national the PSTN perspective, one can view NS/EP as a standard with national
boundaries, while IEPS is an extention to international boundaries boundaries, while IEPS is an extention to international boundaries
skipping to change at page 3, line 34 skipping to change at page 3, line 54
application used in Japan that supports both signaled and non- application used in Japan that supports both signaled and non-
signaled access by users[10]. It is a distributed database system signaled access by users[10]. It is a distributed database system
that provides registration, querying, and reply primitives to that provides registration, querying, and reply primitives to
participants during times of an emergency (e.g., an earthquake) so participants during times of an emergency (e.g., an earthquake) so
that others can make an after-the-event determination about the that others can make an after-the-event determination about the
status of a person. In this case, a separate signaling protocol like status of a person. In this case, a separate signaling protocol like
SIP is not always required to establish or maintain a connection. SIP is not always required to establish or maintain a connection.
Given the case where signaling is optional, requirements and Given the case where signaling is optional, requirements and
subsequent solutions that address these problems must not assume the subsequent solutions that address these problems must not assume the
existance of signaling and must be able to support applications that existence of signaling and must be able to support applications that
^L
only have labels in data packets. These label(s) may be in various only have labels in data packets. These label(s) may be in various
places, such as the application or IP header. 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 2. Scope
This document defines a set of general system requirements to achieve This document defines a set of general system requirements to achieve
support for ETS and addressing the problem space presented in Section support for ETS and addressing the problem space presented in Section
1.2. In defining these requirements, we consider known systems such 1.2. In defining these requirements, we consider known systems such
as GETS and IAA that represent existing manifestations of emergency as GETS and IAA that represent existing manifestations of emergency
related systems. These two examples also represent a broad spectrum related systems. These two examples also represent a broad spectrum
of characteristics that range from signaling & interactive non- of characteristics that range from signaling & interactive non-
elastic applications to non-signaled & elastic applications. elastic applications to non-signaled & elastic applications.
skipping to change at page 4, line 41 skipping to change at page 5, line 5
document. The focus of the IETF and its working groups is technical document. The focus of the IETF and its working groups is technical
positions that follow the architecture of the Internet. positions that follow the architecture of the Internet.
Another item that is not in scope of this document is mandating Another item that is not in scope of this document is mandating
acceptance and support of the requirements presented in this acceptance and support of the requirements presented in this
document. There is an expectation that business contracts, (e.g., document. There is an expectation that business contracts, (e.g.,
Service Level Agreements) , will be used to satisfy those Service Level Agreements) , will be used to satisfy those
requirements that apply to service providers. Absence of an SLA requirements that apply to service providers. Absence of an SLA
implies best effort service is provided. implies best effort service is provided.
^L
3. General Requirements 3. General Requirements
These are general requirements that apply to authorized emergency These are general requirements that apply to authorized emergency
telecommunications service. The first requirement is presented as a telecommunications service. The first requirement is presented as a
conditional one since not all applications use or are reliant on conditional one since not all applications use or are reliant on
signaling. signaling.
1) Signaling 1) Signaling
IF signaling is to be used to convey the state or existance of IF signaling is to be used to convey the state or existence of
emergency, then signaling mechanism(s) MUST exist to carry emergency, then signaling mechanism(s) MUST exist to carry
applicable labels. applicable labels.
2) Labels 2) Labels
Labels may exist in various forms at different layers. They Labels may exist in various forms at different layers. They
might be carried as part of signaling, and/or as part of the might be carried as part of signaling, and/or as part of the
header of a data packet. Labels from different layers are NOT header of a data packet. Labels from different layers are NOT
required to be the same, but MAY be related to each other. required to be the same, but MAY be related to each other.
skipping to change at page 5, line 41 skipping to change at page 6, line 4
within the definition of a label. Local policy states the within the definition of a label. Local policy states the
actions (if any) to be taken if unrelated labeled traffic actions (if any) to be taken if unrelated labeled traffic
merges at a node. merges at a node.
Finally, labels may have additional characteristics added to Finally, labels may have additional characteristics added to
them as a result of local policy. them as a result of local policy.
4) Network Functionality 4) Network Functionality
Functionality to support better than best effort SHOULD focus Functionality to support better than best effort SHOULD focus
^L
on probability versus guarantees. Probability can be realized on probability versus guarantees. Probability can be realized
in terms of reduced probability of packet loss, and/or minimal in terms of reduced probability of packet loss, and/or minimal
jitter, and/or minimal end-to-end delay. There is NO jitter, and/or minimal end-to-end delay. There is NO
requirement that better than best effort functionality MUST requirement that better than best effort functionality MUST
exist. There is NO requirement that if better-than-best effort exist. There is NO requirement that if better-than-best effort
functionality exists then it must be ubuiquitous between end functionality exists then it must be ubuiquitous between end
users. users.
3.1 General Security Related Requirements 3.1 General Security Related Requirements
The following are security related requirements that emerge given the The following are security related requirements that emerge given the
requirements 1 through 4 above. requirements 1 through 4 above.
5) Authorisation 5) Authorization
Authorisation is a method of validating that a user or some Authorization is a method of validating that a user or some
traffic is allowed by policy to use a particular service traffic is allowed by policy to use a particular service
offering. offering.
Mechanisms must be implemented so that only authorised users Mechanisms must be implemented so that only authorised users
have access to emergency telecommunications services. Any have access to emergency telecommunications services. Any
mechanism for providing such authorisation beyond closed mechanism for providing such authorization beyond closed
private networks SHOULD meet IETF Security Area criterion private networks SHOULD meet IETF Security Area criterion
(e.g. clear-text passwords would not generally be acceptable). (e.g. clear-text passwords would not generally be acceptable).
Authorization protects network resources from excessive use, Authorization protects network resources from excessive use,
from abuse, and might also support billing and accounting for from abuse, and might also support billing and accounting for
the offered service. the offered service.
Such authorization mechanisms SHOULD be flexible enough to Such authorization mechanisms SHOULD be flexible enough to
provide various levels of restriction and authorization depending provide various levels of restriction and authorization depending
on the expectations of a particular service or customer. on the expectations of a particular service or customer.
skipping to change at page 6, line 41 skipping to change at page 7, line 4
Integrity offers assurance that unauthorised modifications Integrity offers assurance that unauthorised modifications
to objects can be detected. to objects can be detected.
Authorised emergency traffic needs to have reduced risk of Authorised emergency traffic needs to have reduced risk of
adverse impact from denial of service. This implies a need to adverse impact from denial of service. This implies a need to
ensure integrity of the authorised emergency network traffic. ensure integrity of the authorised emergency network traffic.
It should be noted, though, that mechanisms used to ensure It should be noted, though, that mechanisms used to ensure
integrity can also be subjects to Denial of Service attacks. integrity can also be subjects to Denial of Service attacks.
Users of emergency network services SHOULD consider deploying Users of emergency network services SHOULD consider deploying
^L
end-to-end integrity and authentication, rather than relying on end-to-end integrity and authentication, rather than relying on
services that might be offered by any single provider of services that might be offered by any single provider of
emergency network services. Users SHOULD also carefully emergency network services. Users SHOULD also carefully
consider which application-layer security services might be consider which application-layer security services might be
appropriate to use. appropriate to use.
7) Confidentiality 7) Confidentiality
Some emergency communications might have a requirement that they Some emergency communications might have a requirement that they
not be susceptible to interception or viewing by others, due to not be susceptible to interception or viewing by others, due to
skipping to change at page 7, line 37 skipping to change at page 7, line 49
Accounting represents a method of tracking actual usage of a Accounting represents a method of tracking actual usage of a
service. We assume that the usage of any service better than service. We assume that the usage of any service better than
best effort will be tracked and subsequently billed to the user. best effort will be tracked and subsequently billed to the user.
Accounting is not addressed as a general requirement for ETS. Accounting is not addressed as a general requirement for ETS.
However, solutions used to realize ETS should not preclude an However, solutions used to realize ETS should not preclude an
accounting mechanism. accounting mechanism.
2) Admission Control 2) Admission Control
The requirements of section 3 discuss labels and security. In The requirements of section 3 discuss labels and security.
going beyond this, the ability to distinguish emergency flows Those developing solutions should understand that the
implies the need for admission control if resources become ability labels provide to distinguish emergency flows does
scarce. Solutions must recognize this when trying to satisfy not create an ability to selectively admit flows. Admission
the above requirements such that the simple presence of a label
does not imply admission control always exists along the ^L
end-to-end path. control as it is 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. In cases where emergency related flows occur
outside of controlled environments, the development of
technologies based on admission control is not recommended
as the foundation of emergency services.
3) Digital Signatures 3) Digital Signatures
Verification of digital signatures is computationally expensive. Verification of digital signatures is computationally expensive.
If an operator acts upon a label and hence needs to verify the If an operator acts upon a label and hence needs to verify the
authenticity of the label, then there is a potential denial-of- authenticity of the label, then there is a potential denial-of-
service attack on the entity performing the authentication. service attack on the entity performing the authentication.
The DoS attack works by flooding the entity performing the The DoS attack works by flooding the entity performing the
authentication with invalid (i.e. not authentic) labelled authentication with invalid (i.e. not authentic) labelled
information, causing the victim to spend excessive amounts of information, causing the victim to spend excessive amounts of
skipping to change at page 8, line 33 skipping to change at page 9, line 5
6. Security Considerations 6. Security Considerations
Security in terms of requirements is discussed sections 3.1 and 4. Security in terms of requirements is discussed sections 3.1 and 4.
7. References 7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
^L
2 ANSI, "Signaling System No. 7(SS7) "High Probability of 2 ANSI, "Signaling System No. 7(SS7) "High Probability of
Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999). Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999).
3 "Description of an International Emergency Preference 3 "Description of an International Emergency Preference
Scheme (IEPS)", ITU-T Recommendation E.106 March, 2000. Scheme (IEPS)", ITU-T Recommendation E.106 March, 2000.
4 "Description for an International Emergency Multimedia Service", 4 "Description for an International Emergency Multimedia Service",
ITU Draft Recommendation F.706, February, 2002. ITU Draft Recommendation F.706, February, 2002.
5 "Call Priority Designation for H.323 Calls", ITU Recommendation 5 "Call Priority Designation for H.323 Calls", ITU Recommendation
skipping to change at page 9, line 33 skipping to change at page 10, line 4
University College London Extreme Networks University College London Extreme Networks
Department of Computer Science 3585 Monroe Street Department of Computer Science 3585 Monroe Street
Gower Street Santa Clara, CA Gower Street Santa Clara, CA
London, WC1E 6BT 95051 USA London, WC1E 6BT 95051 USA
United Kingdom United Kingdom
k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved. "Copyright (C) The Internet Society (2003). All Rights Reserved.
^L
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
 End of changes. 16 change blocks. 
20 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/