< draft-ietf-ecrit-security-threats-03.txt		draft-ietf-ecrit-security-threats-04.txt >
	ECRIT T. Taylor		ECRIT T. Taylor
	Internet-Draft (Editor) Nortel		Internet-Draft (Editor) Nortel
	Expires: January 13, 2007 H. Tschofenig		Expires: October 18, 2007 H. Tschofenig
	Siemens		Siemens
	H. Schulzrinne		H. Schulzrinne
	Columbia U.		Columbia U.
	M. Shanmugam		M. Shanmugam
	Siemens		Siemens
	July 12, 2006		April 16, 2007
	Security Threats and Requirements for Emergency Call Marking and Mapping		Security Threats and Requirements for Emergency Call Marking and Mapping
	draft-ietf-ecrit-security-threats-03.txt		draft-ietf-ecrit-security-threats-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 13, 2007.		This Internet-Draft will expire on October 18, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document reviews the security threats associated with:		This document reviews the security threats associated with:
	o the marking of signalling messages to indicate that they are		o the marking of signalling messages to indicate that they are
	related to an emergency; and		related to an emergency; and
	o the process of mapping from locations to Universal Resource		o the process of mapping from locations to Universal Resource
	Identifiers (URIs) pointing to Public Safety Answering Points		Identifiers (URIs) pointing to Public Safety Answering Points
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 26 ¶
	Based on the identified threats, this document establishes a set of		Based on the identified threats, this document establishes a set of
	security requirements for the mapping protocol and for the handling		security requirements for the mapping protocol and for the handling
	of emergency-marked calls.		of emergency-marked calls.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Marking, Mapping, and the Emergency Call Routing Process . . . 5		3. Marking, Mapping, and the Emergency Call Routing Process . . . 5
			3.1. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 5
			3.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6		4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6
	5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7		5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7		5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7
	5.2. Attacks Against or Using the Mapping Process . . . . . . . 7		5.2. Attacks Against or Using the Mapping Process . . . . . . . 7
	5.2.1. Attacks Against the Emergency Response System . . . . 7		5.2.1. Attacks Against the Emergency Response System . . . . 8
	5.2.2. Attacks To Prevent a Specific Individual From		5.2.2. Attacks To Prevent a Specific Individual From
	Receiving Aid . . . . . . . . . . . . . . . . . . . . 9		Receiving Aid . . . . . . . . . . . . . . . . . . . . 9
	5.2.3. Attacks To Gain Information About an Emergency . . . . 9		5.2.3. Attacks To Gain Information About an Emergency . . . . 9
	6. Security Requirements Relating To Emergency Marking and		6. Security Requirements Relating To Emergency Marking and
	Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Legacy telephone network users can summon help for emergency services		Legacy telephone network users can summon help for emergency services
	such as ambulance, fire and police using a well known number (e.g.,		such as ambulance, fire and police using a well known number (e.g.,
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	The term "emergency caller's device" designates the IP host closest		The term "emergency caller's device" designates the IP host closest
	to the emergency caller in the signalling path between the emergency		to the emergency caller in the signalling path between the emergency
	caller and the PSAP. Examples include an IP phone running SIP,		caller and the PSAP. Examples include an IP phone running SIP,
	H.323, or a proprietary signalling protocol, a PC running a soft		H.323, or a proprietary signalling protocol, a PC running a soft
	client, or an analogue terminal adapter or a residential gateway		client, or an analogue terminal adapter or a residential gateway
	controlled by a softswitch.		controlled by a softswitch.
	3. Marking, Mapping, and the Emergency Call Routing Process		3. Marking, Mapping, and the Emergency Call Routing Process
	This memo deals with two topics relating to the routing of emergency		This memo deals with two topics relating to the routing of emergency
	calls to their proper destination. The first is the marking of call		calls to their proper destination: call marking and mapping.
	signalling to enable entities along the signalling path to recognize
	that a particular signalling message is associated with an emergency
	call. Signalling containing the emergency identifier may be given
	priority treatment, special processing, and/or special routing.
	The first goal of emergency call routing is to ensure that any		3.1. Call Marking
			Marking of call signalling enables entities along the signalling path
			to recognize that a particular signalling message is associated with
			an emergency call. Signalling containing the emergency identifier
			may be given priority treatment, special processing, and/or special
			routing.
			3.2. Mapping
			An important goal of emergency call routing is to ensure that any
	emergency call is routed to a PSAP. Preferably the call is routed to		emergency call is routed to a PSAP. Preferably the call is routed to
	the PSAP responsible for the caller's location, since misrouting		the PSAP responsible for the caller's location, since misrouting
	consumes valuable time while the call taker locates and forwards the		consumes valuable time while the call taker locates and forwards the
	call to the right PSAP. As described in [I-D.ecrit-requirements],		call to the right PSAP. As described in [I-D.ecrit-requirements],
	mapping is part of the process of achieving this preferable outcome.		mapping is part of the process of achieving this preferable outcome.
	In brief, mapping involves a mapping client, a mapping server, and		In brief, mapping involves a mapping client, a mapping server, and
	the protocol that passes between them. The protocol allows the		the protocol that passes between them. The protocol allows the
	client to pass location information to the mapping server and to		client to pass location information to the mapping server and to
	receive back a URI which can be used to direct call signalling to a		receive back a URI which can be used to direct call signalling to a
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 30 ¶
	Three basic attacks on the mapping process can be identified: denial		Three basic attacks on the mapping process can be identified: denial
	of service, impersonation of the mapping server, or corruption of the		of service, impersonation of the mapping server, or corruption of the
	mapping database. Denial of service can be achieved in several ways:		mapping database. Denial of service can be achieved in several ways:
	o by a flooding attack on the mapping server;		o by a flooding attack on the mapping server;
	o by taking control of the mapping server and either preventing it		o by taking control of the mapping server and either preventing it
	from responding or causing it to send incorrect responses; or		from responding or causing it to send incorrect responses; or
	o by taking control of a router through which the mapping queries		o by taking control of any intermediary node (for example, a router)
	and responses pass and using that control to block them. An		through which the mapping queries and responses pass and using
	adversary may also attempt to modify the mapping protocol		that control to block them. An adversary may also attempt to
	signaling messages. Additionally, the adversary may be able to		modify the mapping protocol signaling messages. Additionally, the
	replay past communication exchanges to fool an emergency caller by		adversary may be able to replay past communication exchanges to
	returning incorrect results.		fool an emergency caller by returning incorrect results.
	In an impersonation attack, the attacker induces the mapping client		In an impersonation attack, the attacker induces the mapping client
	to direct its queries to a host under the attacker's control rather		to direct its queries to a host under the attacker's control rather
	than the real mapping server. Impersonation itself is an issue for		than the real mapping server or the attacker suppress the response
	mapping server discovery rather than for the mapping protocol		from the real mapping server, and send a spoofed response.
	directly. However, the mapping protocol may allow impersonation to
	be detected, thereby preventing acceptance of responses from an		The former type of impersonation attack itself is an issue of mapping
	impersonating entity and possibly triggering a more secure discovery		server discovery rather than for the mapping protocol directly.
	procedure.		However, the mapping protocol may allow impersonation to be detected,
			thereby preventing acceptance of responses from an impersonating
			entity and possibly triggering a more secure discovery procedure.
	Corruption of the mapping database cannot be mitigated directly by		Corruption of the mapping database cannot be mitigated directly by
	mapping protocol design. The mapping protocol may have a role to		mapping protocol design. The mapping protocol may have a role to
	play in analysis of which records have been corrupted, once that		play in analysis of which records have been corrupted, once that
	corruption has been detected.		corruption has been detected.
	Beyond these attacks on the mapping operation itself, it is possible		Beyond these attacks on the mapping operation itself, it is possible
	to use mapping to attack other entities. One possibility is that		to use mapping to attack other entities. One possibility is that
	mapping clients are misled into sending mapping queries to the target		mapping clients are misled into sending mapping queries to the target
	of the attack instead of the mapping server. Prevention of such an		of the attack instead of the mapping server. Prevention of such an
	attack is an operational issue rather than one of protocol design.		attack is an operational issue rather than one of protocol design.
			Another possible attack is one where the the mapping server is
	The other possible attack is one where the the mapping server is
	tricked into sending responses to the target of the attack through		tricked into sending responses to the target of the attack through
	spoofing of the source address in the query.		spoofing of the source address in the query.
	5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid		5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid
	If an attacker wishes to deny emergency service to a specific		If an attacker wishes to deny emergency service to a specific
	individual the mass attacks described in Section 5.2.1 will obviously		individual the mass attacks described in Section 5.2.1 will obviously
	work provided that the target individual is within the affected		work provided that the target individual is within the affected
	population. Except for the flooding attack on the mapping server,		population. Except for the flooding attack on the mapping server,
	the attacker can in theory limit these attacks to the target, but		the attacker can in theory limit these attacks to the target, but
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 34 ¶
	carefully limited period of time.		carefully limited period of time.
	If the attacker wants to be selective, however, it may make more		If the attacker wants to be selective, however, it may make more
	sense to attack the mapping client rather than the mapping server.		sense to attack the mapping client rather than the mapping server.
	This is particularly so if the mapping client is the emergency		This is particularly so if the mapping client is the emergency
	caller's device. The choices available to the attacker are similar		caller's device. The choices available to the attacker are similar
	to those for denial of service on the server side:		to those for denial of service on the server side:
	o a flooding attack on the mapping client;		o a flooding attack on the mapping client;
	o taking control of a router through which the mapping queries and		o taking control of any intermediary node (for example, a router)
	responses pass and using that control to block or modify them.		through which the mapping queries and responses pass and using
			that control to block or modify them.
	Taking control of the mapping client is also a logical possibility,		Taking control of the mapping client is also a logical possibility,
	but raises no issues for the mapping protocol.		but raises no issues for the mapping protocol.
	5.2.3. Attacks To Gain Information About an Emergency		5.2.3. Attacks To Gain Information About an Emergency
	This section discusses attacks used to gain information about an		This section discusses attacks used to gain information about an
	emergency. The attacker may be seeking the location of the caller		emergency. The attacker may be seeking the location of the caller
	(e.g., to effect a criminal attack). Alternatively, the attacker may		(e.g., to effect a criminal attack). Alternatively, the attacker may
	be seeking information that could be used to link an individual (the		be seeking information that could be used to link an individual (the
	caller or someone else involved in the emergency) with embarrassing		caller or someone else involved in the emergency) with embarrassing
	information related to the emergency (e.g., "Who did the police take		information related to the emergency (e.g., "Who did the police take
	away just now?"). Finally, the attacker could be seeking to profit		away just now?"). Finally, the attacker could be seeking to profit
	from the emergency, perhaps by offering his or her services (e.g.,		from the emergency, perhaps by offering his or her services (e.g.,
	news reporter, lawyer aggressively seeking new business).		news reporter, lawyer aggressively seeking new business).
	The primary information that interceptions of mapping requests and		The primary information that interceptions of mapping requests and
	responses will reveal are a location, a URI identifying a PSAP, and		responses will reveal are a location, a URI identifying a PSAP, the
	the addresses of the mapping client and server. The location		emergency service identifier, and the addresses of the mapping client
	information can be directly useful to an attacker if the attacker has		and server. The location information can be directly useful to an
	high assurance that the observed query is related to an emergency		attacker if the attacker has high assurance that the observed query
	involving the target. The other pieces of information may provide		is related to an emergency involving the target. The type of
	the basis for further attacks on emergency call routing, but because		emergency (fire, police or ambulance) might also be revealed by the
	of the time factor, are unlikely to be applicable to the routing of		emergency service identifier in the mapping query. The other pieces
	the current call. However, if the mapping client is the emergency		of information may provide the basis for further attacks on emergency
	caller's device, the attacker may gain information that allows for		call routing, but because of the time factor, are unlikely to be
	interference with the call after it has been set up or for		applicable to the routing of the current call. However, if the
	interception of the media stream between the caller and the PSAP.		mapping client is the emergency caller's device, the attacker may
			gain information that allows for interference with the call after it
			has been set up or for interception of the media stream between the
			caller and the PSAP.
	6. Security Requirements Relating To Emergency Marking and Mapping		6. Security Requirements Relating To Emergency Marking and Mapping
	This section describes the security requirements which must be		This section describes the security requirements which must be
	fulfilled to prevent or reduce the effectiveness of the attacks		fulfilled to prevent or reduce the effectiveness of the attacks
	described in Section 5. The requirements are presented in the same		described in Section 5. The requirements are presented in the same
	order as the attacks.		order as the attacks.
	From Section 5.1:		From Section 5.1:
	Attack: fraudulent calls.		Attack A1: fraudulent calls.
	Requirement: for calls which meet conditions a) to c) of Section 5.1,		Requirement R1: for calls which meet conditions a) to c) of
	the service provider's call routing entity MUST verify that the		Section 5.1, the service provider's call routing entity MUST verify
	destination address (e.g., SIP Request-URI) presented in the call		that the destination address (e.g., SIP Request-URI) presented in the
	signalling is that of a PSAP.		call signalling is that of a PSAP.
	Attack: use of emergency identifier to probe in order to identify		Attack A2: use of emergency identifier to probe in order to identify
	emergency call routing entities.		emergency call routing entities for attack by other means.
	Requirement: topology hiding SHOULD be applied to call signalling		Requirement: none identified, beyond the ordinary operational
	returned to the emergency caller, so that the identity of		requirement to defend emergency call routing entities by means such
	intermediate routing entities is not disclosed. The obvious		as firewalls and, where possible, authentication and authorization.
	exception is where these entities are already visible to the caller.
	Note that there is little point in hiding the PSAP itself.
	From Section 5.2.1:		From Section 5.2.1:
	Attack: flooding attack on the mapping client, mapping server, or a		Attack A3: flooding attack on the mapping client, mapping server, or
	third entity.		a third entity.
	Requirement: The mapping protocol MUST NOT create new opportunities		Requirement R2: The mapping protocol MUST NOT create new
	for flooding attacks, including amplification attacks.		opportunities for flooding attacks, including amplification attacks.
	Attack: insertion of interfering messages.		Attack A4: insertion of interfering messages.
	Requirement: The protocol MUST permit the mapping client to verify		Requirement R3: The protocol MUST permit the mapping client to verify
	that the response it receives is responding to the query it sent out.		that the response it receives is responding to the query it sent out.
	Attack: man-in-the-middle alteration of messages.		Attack A5: man-in-the-middle modification of messages.
	Requirement: The protocol or the system within which it is		Requirement R4: The mapping protocol MUST provide integrity
	implemented MUST maintain request and response integrity.		protection of requests and responses.
	Attack: impersonation of the mapping server.		Requirement R5: The mapping protocol or the system within which the
			protocol is implemented MUST permit the mapping client to
			authenticate the source of mapping responses.
	Requirement: the security considerations for any discussion of		Attack A6: impersonation of the mapping server.
			Requirement R6: the security considerations for any discussion of
	mapping server discovery MUST address measures to prevent		mapping server discovery MUST address measures to prevent
	impersonation of the mapping server.		impersonation of the mapping server.
	Requirement: the protocol or the system within which it is		Requirement R5 also follows from this attack.
	implemented MUST permit the mapping client to authenticate the source
	of mapping responses.
	Attack: corruption of the mapping database.		Attack A7: corruption of the mapping database.
	Requirement: the security considerations for the mapping protocol		Requirement R7: the security considerations for the mapping protocol
	MUST address measures to prevent database corruption by an attacker.		MUST address measures to prevent database corruption by an attacker.
	Requirement: the protocol SHOULD include information in the response		Requirement R8: the protocol SHOULD include information in the
	that allows subsequent correlation of that response with internal		response that allows subsequent correlation of that response with
	logs that may be kept on the mapping server, to allow debugging of		internal logs that may be kept on the mapping server, to allow
	mis-directed calls. One example of a way to meet this requirement		debugging of mis-directed calls. One example of a way to meet this
	would be by means of an opaque parameter in the returned URI.		requirement would be by means of an opaque parameter in the returned
			URI.
	From Section 5.2.2: no new requirements.		From Section 5.2.2: no new requirements.
	From Section 5.2.3:		From Section 5.2.3:
	Attack: snooping of location and other information.		Attack A8: snooping of location and other information.
	Requirement: the protocol or the system within which it is		Requirement R9: the protocol or the system within which it is
	implemented MUST maintain confidentiality of the request and		implemented MUST maintain confidentiality of the request and
	response.		response.
	7. Security Considerations		7. Security Considerations
	This document addresses security threats and security requirements.		This document addresses security threats and security requirements.
	Therefore, security is considered throughout this document.		Therefore, security is considered throughout this document.
	8. Acknowledgements		8. IANA Considerations
			This document does not require actions by the IANA.
			9. Acknowledgements
	The writing of this document has been a task made difficult by the		The writing of this document has been a task made difficult by the
	temptation to consider the security concerns of the entire personal		temptation to consider the security concerns of the entire personal
	emergency calling system, not just the specific pieces of work within		emergency calling system, not just the specific pieces of work within
	the scope of the ECRIT Working Group. Hannes Tschofenig performed		the scope of the ECRIT Working Group. Hannes Tschofenig performed
	the initial security analysis for ECRIT, but it has been shaped since		the initial security analysis for ECRIT, but it has been shaped since
	then by the comments and judgement of the ECRIT WG at large. At an		then by the comments and judgement of the ECRIT WG at large. At an
	earlier stage in the evolution of this document, Stephen Kent of the		earlier stage in the evolution of this document, Stephen Kent of the
	Security Directorate was asked to review it and provided extensive		Security Directorate was asked to review it and provided extensive
	comments which led to a complete rewriting of it. Brian Rosen, Roger		comments which led to a complete rewriting of it. Brian Rosen, Roger
	Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran		Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran
	Aquil, and Ron Watro have also provided detailed reviews of this		Aquil, and Ron Watro have also provided detailed reviews of this
	document at various stages. The authors thank them.		document at various stages. The authors thank them.
	9. IANA Considerations
	This document does not require actions by the IANA.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	10.2. Informative References		10.2. Informative References
	[I-D.ecrit-requirements]		[I-D.ecrit-requirements]
	Schulzrinne, H. and R. Marshall, "Requirements for		Schulzrinne, H. and R. Marshall, "Requirements for
	Emergency Context Resolution with Internet Technologies",		Emergency Context Resolution with Internet Technologies",
	March 2006.		March 2006.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	Text on Security Considerations", BCP 72, RFC 3552,		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	July 2003.
	Authors' Addresses		Authors' Addresses
	Tom Taylor		Tom Taylor
	Nortel		Nortel
	1852 Lorraine Ave		1852 Lorraine Ave
	Ottawa, Ontario K1H 6Z8		Ottawa, Ontario K1H 6Z8
	Canada		Canada
	Email: taylor@nortel.com		Email: taylor@nortel.com
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 5 ¶
	URI: http://www.cs.columbia.edu/~hgs		URI: http://www.cs.columbia.edu/~hgs
	Murugaraj Shanmugam		Murugaraj Shanmugam
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	Email: murugaraj.shanmugam@siemens.com		Email: murugaraj.shanmugam@siemens.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			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, THE IETF TRUST 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 regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 18, line 29 ¶		skipping to change at page 18, line 45 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	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.
	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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 40 change blocks.
	104 lines changed or deleted		114 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/