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.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/