Network Working Group                                     T. Taylor, Ed.
Request for Comments: 5069                                        Nortel
Category: Informational                                    H. Tschofenig
                                                  Nokia Siemens Networks
                                                          H. Schulzrinne
                                                     Columbia University
                                                            M. Shanmugam
                                                            January 2008
Network Working Group                                     T. Taylor, Ed.
Request for Comments: 5069                                        Nortel
Category: Informational                                    H. Tschofenig
                                                  Nokia Siemens Networks
                                                          H. Schulzrinne
                                                     Columbia University
                                                            M. Shanmugam
                                                            January 2008

Security Threats and Requirements for Emergency Call Marking and Mapping


Status of This Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.




This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.


Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Marking, Mapping, and the Emergency Call Routing Process . . .  3
     3.1.  Call Marking . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Objectives of Attackers  . . . . . . . . . . . . . . . . . . .  4
   5.  Potential Attacks  . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Attacks Involving the Emergency Identifier . . . . . . . .  5
     5.2.  Attacks Against or Using the Mapping Process . . . . . . .  5
       5.2.1.  Attacks Against the Emergency Response System  . . . .  6
       5.2.2.  Attacks to Prevent a Specific Individual from
               Receiving Aid  . . . . . . . . . . . . . . . . . . . .  7
       5.2.3.  Attacks to Gain Information about an Emergency . . . .  7
   6.  Security Requirements Relating to Emergency Marking and
       Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Marking, Mapping, and the Emergency Call Routing Process . . .  3
     3.1.  Call Marking . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Objectives of Attackers  . . . . . . . . . . . . . . . . . . .  4
   5.  Potential Attacks  . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Attacks Involving the Emergency Identifier . . . . . . . .  5
     5.2.  Attacks Against or Using the Mapping Process . . . . . . .  5
       5.2.1.  Attacks Against the Emergency Response System  . . . .  6
       5.2.2.  Attacks to Prevent a Specific Individual from
               Receiving Aid  . . . . . . . . . . . . . . . . . . . .  7
       5.2.3.  Attacks to Gain Information about an Emergency . . . .  7
   6.  Security Requirements Relating to Emergency Marking and
       Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction
1. 介绍

Legacy telephone network users can summon help for emergency services (such as an ambulance, the fire department, and the police) using a well known number (e.g., 911 in North America, 112 in Europe). A key factor in the handling of such calls is the ability of the system to determine caller location and to route the call to the appropriate Public Safety Answering Point (PSAP) based on that location. With the introduction of IP-based telephony and multimedia services, support for emergency calling via the Internet also has to be provided. Two core components of IP-based emergency calling include an emergency service identifier and a mapping protocol. The emergency service identifier indicates that the call signaling establishes an emergency call, while the mapping protocol translates the emergency service identifier and the caller's geographic location into an appropriate PSAP URL.

传统电话网络用户可以使用众所周知的号码(例如,北美的911,欧洲的112)为紧急服务(如救护车、消防部门和警察)呼叫帮助。处理此类呼叫的一个关键因素是系统能够确定呼叫者的位置,并根据该位置将呼叫路由到适当的公共安全应答点(PSAP)。随着基于IP的电话和多媒体服务的引入,还必须通过互联网提供紧急呼叫支持。基于IP的紧急呼叫的两个核心组件包括紧急服务标识符和映射协议。紧急服务标识符指示呼叫信令建立紧急呼叫,而映射协议将紧急服务标识符和呼叫者的地理位置转换为适当的PSAP URL。

Attacks against the Public Switched Telephone Network (PSTN) have taken place for decades. The Internet is seen as an even more hostile environment. Thus, it is important to understand the types of attacks that might be mounted against the infrastructure providing emergency services and to develop security mechanisms to counter those attacks. While this can be a broad topic, the present document restricts itself to attacks on the mapping of locations to PSAP URIs and attacks based on emergency marking. Verification by the PSAP

对公共交换电话网(PSTN)的攻击已经发生了几十年。互联网被视为一个更加恶劣的环境。因此,了解可能针对提供紧急服务的基础设施发起的攻击类型并制定安全机制以应对这些攻击非常重要。虽然这可能是一个广泛的主题,但本文档仅限于攻击位置到PSAP URI的映射以及基于紧急标记的攻击。PSAP的验证

operator of the truthfulness of a reported incident and various other attacks against the PSAP infrastructure related to the usage of faked location information are outside the scope of the document.


This document is organized as follows: Section 2 describes basic terminology. Section 3 briefly describes how emergency marking and mapping fit within the process of routing emergency calls. Section 4 describes some motivations of attackers in the context of emergency calling, Section 5 describes and illustrates the attacks that might be used, and Section 6 lists the security-related requirements that must be met if these attacks are to be mitigated.


2. Terminology
2. 术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the qualification that unless otherwise stated, they apply to the design of the mapping protocol, not its implementation or application.


The terms "call taker", "mapping service", "emergency caller", "emergency identifier", "mapping", "mapping client", "mapping server", "mapping protocol", and "Public Safety Answering Point (PSAP)" are taken from [RFC5012].


The term "location information" is taken from RFC 3693 [RFC3693].

术语“位置信息”取自RFC 3693[RFC3693]。

The term "emergency caller's device" designates the IP host closest to the emergency caller in the signalling path between the emergency caller and the PSAP. Examples include an IP phone running SIP, H.323, or a proprietary signalling protocol, a PC running a soft client or an analogue terminal adapter, or a residential gateway controlled by a softswitch.


3. Marking, Mapping, and the Emergency Call Routing Process
3. 标记、映射和紧急呼叫路由流程

This memo deals with two topics relating to the routing of emergency calls to their proper destination: call marking and mapping.


3.1. Call Marking
3.1. 呼叫标记

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
3.2. 映射

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 the PSAP responsible for the caller's location, since misrouting consumes valuable time while the call taker locates and forwards the call to the right PSAP. As described in [RFC5012], mapping is part of the process of achieving this preferable outcome.


In brief, mapping involves a mapping client, a mapping server, and the protocol that passes between them. The protocol allows the 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 PSAP.


4. Objectives of Attackers
4. 攻击者的目标

Attackers may direct their efforts either against a portion of the emergency response system or against an individual. Attacks against the emergency response system have three possible objectives:


o to deny system services to all users in a given area. The motivation may range from thoughtless vandalism, to wide-scale criminality, to terrorism. One interesting variant on this motivation is the case where a victim of a large emergency hopes to gain faster service by blocking others' competing calls for help.

o 拒绝向给定区域中的所有用户提供系统服务。动机可能从轻率的故意破坏,到大规模的犯罪,再到恐怖主义。这种动机的一个有趣的变体是,一个大型紧急事件的受害者希望通过阻止其他人相互竞争的求助电话来获得更快的服务。

o to gain fraudulent use of services, by using an emergency identifier to bypass normal authentication, authorization, and accounting procedures.

o 通过使用紧急标识符绕过正常的身份验证、授权和记帐程序,获得对服务的欺诈性使用。

o to divert emergency calls to non-emergency sites. This is a form of a denial-of-service attack similar to the first item, but quite likely more confusing for the caller himself or herself since the caller expects to talk to a PSAP operator but instead gets connected to someone else.

o 将紧急呼叫转接至非紧急地点。这是一种类似于第一项的拒绝服务攻击形式,但很可能会让调用方自己更加困惑,因为调用方希望与PSAP操作员通话,但却与其他人连接。

Attacks against an individual fall into two classes:


o attacks to prevent an individual from receiving aid.

o 阻止个人接受援助的攻击。

o attacks to gain information about an emergency that can be applied either against an individual involved in that emergency or to the profit of the attacker.

o 获取有关紧急情况的信息的攻击,这些信息可以针对参与该紧急情况的个人,也可以对攻击者有利。

5. Potential Attacks
5. 潜在攻击
5.1. Attacks Involving the Emergency Identifier
5.1. 涉及紧急标识符的攻击

The main possibility of attack involves use of the emergency identifier to bypass the normal procedures in order to achieve fraudulent use of services. An attack of this sort is possible only if the following conditions are true:


a. The attacker is the emergency caller.

a. 攻击者是紧急呼叫者。

b. The call routing system assumes that the emergency caller's device signals the correct PSAP URI for the caller's location.

b. 呼叫路由系统假定紧急呼叫者的设备发出呼叫者位置的正确PSAPURI信号。

c. The call enters the domain of a service provider, which accepts it without applying normal procedures for authentication and authorization because the signalling carries the emergency identifier.

c. 呼叫进入服务提供商的域,服务提供商接受呼叫而不应用正常的身份验证和授权程序,因为信令带有紧急标识符。

d. The service provider routes the call according to the called address (e.g., SIP Request-URI), without verifying that this is the address of a PSAP (noting that a URI by itself does not indicate the nature of the entity it is pointing to).

d. 服务提供者根据被叫地址(例如,SIP请求URI)路由呼叫,而不验证这是否是PSAP的地址(注意URI本身并不指示它所指向的实体的性质)。

If these conditions are satisfied, the attacker can bypass normal service provider authorization procedures for arbitrary destinations, simply by reprogramming the emergency caller's device to add the emergency identifier to non-emergency call signalling. In this case, the call signalling most likely will not include any location information, or there could be location information, but it is false.


An attacker wishing to disrupt the emergency call routing system may use a similar technique to target components of that system for a denial-of-service attack. The attacker will find this attractive to reach components that handle emergency calls only. Flooding attacks are the most likely application of the technique, but it may also be used to identify target components for other attacks by analyzing the content of responses to the original signalling messages.


5.2. Attacks Against or Using the Mapping Process
5.2. 针对或使用映射过程的攻击

This section describes classes of attacks involving the mapping process that could be used to achieve the attacker goals described in Section 4.


5.2.1. Attacks Against the Emergency Response System
5.2.1. 对应急响应系统的攻击

This section considers attacks intended to reduce the effectiveness of the emergency response system for all callers in a given area. If the mapping operation is disabled, then the emergency caller's device might not have the correct PSAP URI. As a consequence, the probability that emergency calls will be routed to the wrong PSAP increases. In the worst case, the emergency caller's device might not be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a double consequence: emergency response to the affected calls is delayed, and PSAP call taker resources outside the immediate area of the emergency are consumed due to the extra effort required to redirect the calls. Alternatively, attacks that cause the client to receive a URI that does not lead to a PSAP have the immediate effect of causing emergency calls to fail.

本节考虑旨在降低特定区域内所有呼叫者应急响应系统有效性的攻击。如果映射操作被禁用,则紧急呼叫者的设备可能没有正确的PSAP URI。因此,紧急呼叫被路由到错误PSAP的可能性增加。在最坏的情况下,紧急呼叫方的设备可能根本无法获取PSAP URI。路由到错误的PSAP会产生双重后果:对受影响呼叫的紧急响应会延迟,并且由于重定向呼叫所需的额外努力,会消耗紧急区域以外的PSAP呼叫接受者资源。或者,导致客户端接收不导致PSAP的URI的攻击会立即导致紧急呼叫失败。

Three basic attacks on the mapping process can be identified: denial of service, impersonation of the mapping server, or corruption of the mapping database. Denial of service can be achieved in several ways:


o by a flooding attack on the mapping server;

o 通过对映射服务器的洪水攻击;

o by taking control of the mapping server and either preventing it from responding or causing it to send incorrect responses; or

o 通过控制映射服务器,防止其响应或导致其发送错误响应;或

o by taking control of any intermediary node (for example, a router) through which the mapping queries and responses pass, and then using that control to block them. An adversary may also attempt to modify the mapping protocol signalling messages. Additionally, the adversary may be able to replay past communication exchanges to fool an emergency caller by returning incorrect results.

o 通过控制映射查询和响应通过的任何中间节点(例如路由器),然后使用该控制阻止它们。对手还可能试图修改映射协议信令消息。此外,对手可能能够重播过去的通信交换,通过返回错误的结果来愚弄紧急呼叫方。

In an impersonation attack, the attacker induces the mapping client to direct its queries to a host under the attacker's control rather than the real mapping server, or the attacker suppresses the response from the real mapping server and sends a spoofed response.


The former type of impersonation attack itself is an issue of mapping server discovery rather than the mapping protocol directly. 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 mapping protocol design. Once corruption has been detected, the mapping protocol may have a role to play in determining which records have been corrupted.


Beyond these attacks on the mapping operation itself, it is possible to use mapping to attack other entities. One possibility is that mapping clients are misled into sending mapping queries to the target of the attack instead of the mapping server. Prevention of such an attack is an operational issue rather than one of protocol design. Another possible attack is where the mapping server is tricked into sending responses to the target of the attack through spoofing of the source address in the query.


5.2.2. Attacks to Prevent a Specific Individual from Receiving Aid
5.2.2. 阻止特定个人接受援助的攻击

If an attacker wishes to deny emergency service to a specific individual, the mass attacks described in Section 5.2.1 will obviously work provided that the target individual is within the affected population. Except for the flooding attack on the mapping server, the attacker can in theory limit these attacks to the target, but this requires extra effort that the attacker is unlikely to expend. If the attacker is using a mass attack but does not wish to have too broad an effect, it is more likely to attack for a carefully limited period of time.


If the attacker wants to be selective, however, it may make more sense to attack the mapping client rather than the mapping server. This is particularly so if the mapping client is the emergency caller's device. The choices available to the attacker are similar to those for denial of service on the server side:


o a flooding attack on the mapping client;

o 映射客户端上的洪水攻击;

o taking control of any intermediary node (for example, a router) through which the mapping queries and responses pass, and then using that control to block or modify them.

o 控制映射查询和响应通过的任何中间节点(例如路由器),然后使用该控制阻止或修改它们。

Taking control of the mapping client is also a logical possibility, but raises no issues for the mapping protocol.


5.2.3. Attacks to Gain Information about an Emergency
5.2.3. 获取紧急情况信息的攻击

This section discusses attacks used to gain information about an emergency. The attacker may be seeking the location of the caller (e.g., to effect a criminal attack). Alternatively, the attacker may be seeking information that could be used to link an individual (the caller or someone else involved in the emergency) with embarrassing information related to the emergency (e.g., "Who did the police take away just now?"). Finally, the attacker could be seeking to profit from the emergency, perhaps by offering his or her services (e.g., a news reporter, or a lawyer aggressively seeking new business).


The primary information that interceptions of mapping requests and responses will reveal are a location, a URI identifying a PSAP, the emergency service identifier, and the addresses of the mapping client and server. The location information can be directly useful to an attacker if the attacker has high assurance that the observed query is related to an emergency involving the target. The type of emergency (fire, police, or ambulance) might also be revealed by the emergency service identifier in the mapping query. The other pieces of information may provide the basis for further attacks on emergency call routing, but because of the time factor, are unlikely to be applicable to the routing of the current call. However, if the 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. 与应急标记和绘图相关的安全要求

This section describes the security requirements that must be fulfilled to prevent or reduce the effectiveness of the attacks described in Section 5. The requirements are presented in the same order as the attacks.


From Section 5.1:


Attack A1: fraudulent calls.


Requirement R1: For calls that meet conditions a) to c) of Section 5.1, the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP.


Attack A2: Use of emergency identifier to probe in order to identify emergency call routing entities for attack by other means.


Requirement: None identified, beyond the ordinary operational requirement to defend emergency call routing entities by means such as firewalls and, where possible, authentication and authorization.


From Section 5.2.1:


Attack A3: Flooding attack on the mapping client, mapping server, or a third entity.


Requirement R2: The mapping protocol MUST NOT create new opportunities for flooding attacks, including amplification attacks.


Attack A4: Insertion of interfering messages.


Requirement R3: The protocol MUST permit the mapping client to verify that the response it receives is responding to the query it sent out.


Attack A5: Man-in-the-middle modification of messages.


Requirement R4: The mapping protocol MUST provide integrity protection of requests and responses.


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.


Attack A6: Impersonation of the mapping server.


Requirement R6: The security considerations for any discussion of mapping server discovery MUST address measures to prevent impersonation of the mapping server.


Requirement R5 also follows from this attack.


Attack A7: Corruption of the mapping database.


Requirement R7: The security considerations for the mapping protocol MUST address measures to prevent database corruption by an attacker.


Requirement R8: The protocol SHOULD include information in the response that allows subsequent correlation of that response with internal logs that may be kept on the mapping server, to allow debugging of mis-directed calls.


From Section 5.2.2: No new requirements.


From Section 5.2.3:


Attack A8: Snooping of location and other information.


Requirement R9: The protocol and the system within which it is implemented MUST maintain confidentiality of the request and response.


7. Security Considerations
7. 安全考虑

This document addresses security threats and security requirements. Therefore, security is considered throughout this document.


8. Acknowledgements
8. 致谢

The writing of this document has been a task made difficult by the temptation to consider the security concerns of the entire personal emergency calling system, not just the specific pieces of work within the scope of the ECRIT Working Group. Hannes Tschofenig performed 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 earlier stage in the evolution of this document, Stephen Kent of the Security Directorate was asked to review it and provided extensive comments, which led to a complete rewriting of it. Brian Rosen, Roger Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran Aquil, and Ron Watro have also provided detailed reviews of this document at various stages. The authors thank them.

这份文件的撰写是一个困难的任务,因为考虑到整个个人紧急呼叫系统的安全问题,而不仅仅是急诊科工作组范围内的特定工作。Hannes Tschofenig为ECRIT进行了初步的安全分析,但从那时起,ECRIT工作组的评论和判断对其进行了调整。在本文件演变的早期阶段,安全局的斯蒂芬·肯特被要求对其进行审查,并提供了广泛的意见,这导致了对其进行了全面重写。Brian Rosen、Roger Marshall、Andrew Newton以及最近的Spencer Dawkins、Kamran Aquil和Ron Watro也在不同阶段对本文件进行了详细审查。作者感谢他们。

We would like to thank Donald Eastlake for his review on behalf of the Security Area Directorate and Christian Vogt for his review as part of the General Area Review Team.

我们要感谢Donald Eastlake代表安全区董事会进行审查,并感谢Christian Vogt作为一般区域审查小组的一部分进行审查。

Finally, we would like to thank Jari Arkko, Jon Peterson, and Russ Housley for their IETF Last Call comments.

最后,我们要感谢Jari Arkko、Jon Peterson和Russ Housley对IETF最后通话的评论。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

9.2. Informative References
9.2. 资料性引用

[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

[RFC3693]Cuellar,J.,Morris,J.,Mulligan,D.,Peterson,J.,和J.Polk,“地质驱动要求”,RFC 3693,2004年2月。

[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.

[RFC5012]Schulzrinne,H.和R.Marshall,Ed.“使用互联网技术解决紧急情况的要求”,RFC 5012,2008年1月。

Authors' Addresses


Tom Taylor (editor) Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada

汤姆·泰勒(编辑)加拿大安大略省渥太华洛林大道1852号北电K1H 6Z8


Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany



Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US


   Phone: +1 212 939 7004
   Phone: +1 212 939 7004

Murugaraj Shanmugam Detecon International GmbH Oberkasseler str 2 Bonn, NRW 53227 Germany

Murugaraj Shanmugam Detecon International GmbH Oberkasseler str 2 Bonn,NRW 53227德国


Full Copyright Statement


Copyright (C) The IETF Trust (2008).


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.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at