< draft-carlberg-ets-general-00.txt		draft-carlberg-ets-general-01.txt >
	Internet Engineering Task Force Ken Carlberg		Internet Engineering Task Force Ken Carlberg
	INTERNET DRAFT UCL		INTERNET DRAFT UCL
	September, 2002 Ran Atkinson		December, 2002 Ran Atkinson
	Extreme Networks		Extreme Networks
	General Requirements for		General Requirements for
	Emergency Telecommunication Service		Emergency Telecommunication Service
	<draft-carlberg-ets-general-00.txt>		<draft-carlberg-ets-general-01.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 4 ¶		skipping to change at page 2, line 4 ¶
	applications, are to be specified in separate document(s).		applications, are to be specified in separate document(s).
	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
			^L
	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
	commercial telecommunications infrastructure is rapidly evolving to		commercial telecommunications infrastructure is rapidly evolving to
	Internet-based technology. Therefore, the Internet community needs to		Internet-based technology. Therefore, the Internet community needs to
	consider how it can best support emergency management and recovery		consider how it can best support emergency management and recovery
	operations.		operations.
	1.1 Existing Emergency Related Standards		1.1 Existing Emergency Related Standards
	The following are standards from other organizations that are		The following are standards from other organizations that are
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	The fourth and fifth standard focuses on a multi-level labeling		The fourth and fifth standard focuses on a multi-level labeling
	mechanism distinguishing emergency type traffic from that which is		mechanism distinguishing emergency type traffic from that which is
	not. The former case focuses on H.323 networks [5], while the latter		not. The former case focuses on H.323 networks [5], while the latter
	is for SS7 networks [6].		is for SS7 networks [6].
	1.2 Problem		1.2 Problem
	One problem faced by the IEPREP working group entails how, and to		One problem faced by the IEPREP working group entails how, and to
	what degree, support for these standards are to be realized within		what degree, support for these standards are to be realized within
	the Internet architecture and the existing suite of IETF standards		the Internet architecture and the existing suite of IETF standards
			^L
	and associated working groups.		and associated working groups.
	A subsequent problem is to ensure that this support is not focused		A subsequent problem is to ensure that this support is not focused
	just on IP telephony applications. The I-Am-Alive (IAA) database		just on IP telephony applications. The I-Am-Alive (IAA) database
	system is an example of an emergency related application used in		system is an example of an emergency related application used in
	Japan that supports both signaled and non-signaled access by		Japan that supports both signaled and non-signaled access by
	users[12]. Hence, requirements and subsequent solutions that address		users[10]. Hence, requirements and subsequent solutions that address
	these problems must not assume the existance of signaling and must be		these problems must not assume the existance of signaling and must be
	able to support applications that only have labels in data packets.		able to support applications that only have labels in data packets.
	These label(s) may be in various places, such as the application or		These label(s) may be in various places, such as the application or
	IP header. Further comments on labels are discussed below in section		IP header. Further comments on labels are discussed below in section
	3.		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-elastic		of characteristics that range from signaling/interactive non-elastic
	applications to non-signaled/elastic applications. [10] provides		applications to non-signaled/elastic applications.
	additional insight in user applications and expectations.
	We stress that ETS, and its associated requirements, is not the only		We stress that ETS, and its associated requirements, is not the only
	means of supporting authorized emergency communications. It is		means of supporting authorized emergency communications. It is
	simply an approach influenced by by existing systems and standards.		simply an approach influenced by by existing systems and standards.
	Solutions to requirements are not defined. This document does not		Solutions to requirements are not defined. This document does not
	specify protocol enhancements or specifications. User requirements		specify protocol enhancements or specifications. Requirements for
	are specified in a separate document [10]. Requirements for specific		specific types of applications that go beyond the general set stated
	types of applications that go beyond the general set stated in		in section 3 are to be specified in other document(s). At the
	section 3 are to be specified in other document(s). At the current		current writing of this document, [9] has been written for the case
	writing of this document, [9] has been written for the case of IP		of IP telephony.
	telephony.
	Below we present a structural relationship of documents for the		Below we present a structural relationship of documents for the
	IEPREP working group. Specific solutions that are proposed in		IEPREP working group. Specific solutions that are proposed in
	response to the requirements are to be developed in other working		response to the requirements are to be developed in other working
	groups. We note that other specific requrements (like that of IP		groups. We note that other specific requrements (like that of IP
	telephony) may be defined as an extension of the general requirements		telephony) may be defined as an extension of the general requirements
	presented in section 3 below.		presented in section 3 below.
	2.1 Out of Scope		2.1 Out of Scope
	While the problem space stated in section 1.2 includes standards		While the problem space stated in section 1.2 includes standards
	related to telephony, this document is meant to be broader in scope.		related to telephony, this document is meant to be broader in scope.
	Hence, emulation of specific architectures, like the PSTN, or focus		Hence, emulation of specific architectures, like the PSTN, or focus
	on a specific application is out of scope. Further, the		on a specific application is out of scope. Further, the
	specifications of requirements that are aimed at adhering to		specifications of requirements that are aimed at adhering to
			^L
	regulations or laws of governments is also out of scope of this		regulations or laws of governments is also out of scope of this
	document. The focus of the IETF and its working groups is sound		document. The focus of the IETF and its working groups is technical
	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. The IETF does not mandate requirements or capabilities to		document. There is an expectation that business contracts, (e.g.,
	independent networks that comprise the Internet. There is an		Service Level Agreements) , will be used to satisfy those
	expectation that business contracts, (e.g., Service Level Agreements)		requirements that apply to service providers. Absence of an SLA
	, will be used to satisfy those requirements that apply to service		implies best effort service is provided.
	providers. Absence of an SLA implies best effort service is
	provided.
	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
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 39 ¶
	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 related to each other.		required to be related to each other.
	3) Policy		3) Policy
	Policy MUST be kept separate from the label(s).		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.
			^L
			The relationship 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		4) Network Functionality
	Functionality to support better than best effort SHOULD focus		Functionality to support better than best effort SHOULD focus
	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
	skipping to change at page 5, line 34 ¶		skipping to change at page 6, line 5 ¶
	6) Integrity & Authentication		6) Integrity & Authentication
	In practice, authentication and integrity for IP based		In practice, authentication and integrity for IP based
	communications are generally bound within a single mechanism,		communications are generally bound within a single mechanism,
	even though conceptually they are different. Authentication		even though conceptually they are different. Authentication
	ensures that the user or traffic is who it claims to be.		ensures that the user or traffic is who it claims to be.
	Integrity offers assurance that unauthorised modifications		Integrity offers assurance that unauthorised modifications
	to objects can be detected.		to objects can be detected.
			^L
	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.
	Users of emergency network services SHOULD consider deploying		Users of emergency network services SHOULD consider deploying
	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.
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 38 ¶
	IEPREP users should carefully consider security alternatives		IEPREP users should carefully consider security alternatives
	(e.g. PGP, TLS, IPsec transport-mode) at different layers		(e.g. PGP, TLS, IPsec transport-mode) at different layers
	(e.g. Application Layer, Session Layer, Transport Layer) of the		(e.g. Application Layer, Session Layer, Transport Layer) of the
	Internet Architecture before deployment.		Internet Architecture before deployment.
	4. Issues		4. Issues
	This section presents issues that arise in considering solutions for		This section presents issues that arise in considering solutions for
	the requirements that have been defined for ETS. This section does		the requirements that have been defined for ETS. This section does
	not specify solutions nor is it to be confused with requirements.		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		1) Accounting
	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 a requirement for ETS, but solutions used to		Accounting is not addressed as a general requirement for ETS.
	realize ETS should include an accounting mechanism.		However, solutions used to realize ETS should not preclude an
			accounting mechanism.
	2) Admission Control		2) Admission Control
			^L
	The requirements of section 3 discuss labels and security. In		The requirements of section 3 discuss labels and security. In
	going beyond this, the ability to distinguish emergency flows		going beyond this, the ability to distinguish emergency flows
	implies the need for admission control if resources become		implies the need for admission control if resources become
	scarce. Solutions must recognize this when trying to satisfy		scarce. Solutions must recognize this when trying to satisfy
	the above requirements such that the simple presence of a label		the above requirements such that the simple presence of a label
	does not imply admission control always exists along the		does not imply admission control always exists along the
	end-to-end path.		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
			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. Security		5. Security
	Security in terms of requirements is discussed section 3		Security in terms of requirements is discussed section 3 and 4.
	6. References		6. 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.
	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.		Completion (HPC) Network Capability" , ANSI T1.631, 1993.
	3 "Description of an International Emergency Preference		3 "Description of an International Emergency Preference
	Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002		Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002
	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 "Service Class Designations for H.323 Calls", ITU Draft		5 "Service Class Designations for H.323 Calls", ITU Draft
	Recommendation H.GEF.4, September, 2001		Recommendation H.GEF.4, September, 2001
			^L
	6 ITU, "Multi-Level Precedence and Preemption Service, ITU,		6 ITU, "Multi-Level Precedence and Preemption Service, ITU,
	Recomendation, I.255.3, July, 1990.		Recomendation, I.255.3, July, 1990.
	7 U.S. National Communications System: http://www.ncs.gov		7 U.S. National Communications System: http://www.ncs.gov
	8 U.K Office of Telecommunications (Oftel): http://www.oftel.gov.uk/		8 U.K Office of Telecommunications (Oftel): http://www.oftel.gov.uk/
	9 Carlberg, K., Atkinson, R., "General Requirements for Emergency		9 Carlberg, K., Atkinson, R., "General Requirements for Emergency
	Telecommunications Service", Internet Draft, Work In Progress,		Telecommunications Service", Internet Draft, Work In Progress,
	September, 2002		September, 2002
	10 Folts, H., et. al., "User Requirements for Emergency		10 Tada, N., et. al., "IAA System (I Am Alive): The Experiences of
	Telecommunications Service", Internet Draft, Work In
	Progress, September 2002
	11 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP",
	http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/,
	IETF Presentation: IPPM-Voiceip, Aug, 1997
	12 Tada, N., et. al., "IAA System (I Am Alive): The Experiences of
	the Internet Disaster Drills", Proceedings of INET-2000, June.		the Internet Disaster Drills", Proceedings of INET-2000, June.
			11 Heinanen, J., et. al., "Assured Forwarding PHB Group", RFC 2597,
			June 1999
	7. Author's Addresses		7. Author's Addresses
	Ken Carlberg Ran Atkinson		Ken Carlberg Ran Atkinson
	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
	skipping to change at page 8, line 20 ¶		skipping to change at page 9, line 4 ¶
	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
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided as an		This document and the information contained herein is provided as an
			^L
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.
End of changes. 21 change blocks.
	32 lines changed or deleted		78 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/