Independent Submission M. Saito
Request for Comments: 6193 NTT Communications
Category: Informational D. Wing
ISSN: 2070-1721 Cisco Systems
M. Toyama
NTT Corporation
April 2011
Independent Submission M. Saito
Request for Comments: 6193 NTT Communications
Category: Informational D. Wing
ISSN: 2070-1721 Cisco Systems
M. Toyama
NTT Corporation
April 2011
Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)
会话描述协议（SDP）中Internet密钥交换协议（IKE）的媒体描述
Abstract
摘要
This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate.
本文档指定如何使用会话启动协议建立表示虚拟专用网络的媒体会话，以便在对等方之间按需共享媒体/应用程序。它扩展了会话描述协议（SDP）的协议标识符，以便可以在SDP提供/应答模型中协商使用因特网密钥交换协议（IKE）进行媒体会话。它还指定了使用自签名证书启动IKE和生成IPsec安全关联的方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6193.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6193.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Applicability Statement .........................................3
2. Introduction ....................................................3
2.1. Problem Statement ..........................................4
2.2. Approach to Solution .......................................4
2.3. Alternative Solution under Prior Relationship
between Two Nodes ..........................................6
2.4. Authorization Model ........................................6
2.5. Conventions Used in This Document ..........................6
3. Protocol Overview ...............................................7
4. Protocol Identifiers ............................................8
5. Normative Behavior ..............................................9
5.1. SDP Offer and Answer Exchange ..............................9
5.2. Maintenance and Termination of VPN Session ................10
5.3. Forking ...................................................11
5.4. Port Usage ................................................11
5.5. Multiplexing UDP Messages When Using ICE ..................11
6. Examples .......................................................13
6.1. Example of SDP Offer and Answer Exchange without
IPsec NAT-Traversal .......................................13
6.2. Example of SDP Offer and Answer Exchange with
IPsec NAT-Traversal .......................................14
7. Application to IKE .............................................15
8. Specifications Assuming Prior Relationship between Two Nodes ...16
8.1. Certificates Signed by Trusted Third Party ................16
8.2. Configured Pre-Shared Key .................................16
9. Security Considerations ........................................17
10. IANA Considerations ...........................................19
11. Acknowledgments ...............................................20
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
1. Applicability Statement .........................................3
2. Introduction ....................................................3
2.1. Problem Statement ..........................................4
2.2. Approach to Solution .......................................4
2.3. Alternative Solution under Prior Relationship
between Two Nodes ..........................................6
2.4. Authorization Model ........................................6
2.5. Conventions Used in This Document ..........................6
3. Protocol Overview ...............................................7
4. Protocol Identifiers ............................................8
5. Normative Behavior ..............................................9
5.1. SDP Offer and Answer Exchange ..............................9
5.2. Maintenance and Termination of VPN Session ................10
5.3. Forking ...................................................11
5.4. Port Usage ................................................11
5.5. Multiplexing UDP Messages When Using ICE ..................11
6. Examples .......................................................13
6.1. Example of SDP Offer and Answer Exchange without
IPsec NAT-Traversal .......................................13
6.2. Example of SDP Offer and Answer Exchange with
IPsec NAT-Traversal .......................................14
7. Application to IKE .............................................15
8. Specifications Assuming Prior Relationship between Two Nodes ...16
8.1. Certificates Signed by Trusted Third Party ................16
8.2. Configured Pre-Shared Key .................................16
9. Security Considerations ........................................17
10. IANA Considerations ...........................................19
11. Acknowledgments ...............................................20
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
This document provides information about a deployed use of the Session Initiation Protocol (SIP) [RFC3261] for the Internet community. It is not currently an IETF standards track proposal. The mechanisms in this document use SIP as a name resolution and authentication mechanism to initiate an Internet Key Exchange Protocol (IKE) [RFC5996] session. The purpose of this document is to establish an on-demand virtual private network (VPN) to a home router that does not have a fixed IP address using self-signed certificates. It is only applicable under the condition that the integrity of the Session Description Protocol (SDP) [RFC4566] is assured. The method to ensure this integrity of SDP is outside the scope of this document. This document specifies the process in which a pair of SIP user agents resolve each other's names, exchange the fingerprints of their self-signed certificates securely, and agree to establish an IPsec-based VPN [RFC4301]. However, this document does not make any modifications to the specifications of IPsec/IKE. Despite the limitations of the conditions under which this document can be applied, there are sufficient use cases in which this specification is helpful, such as the following:
本文档提供了有关为Internet社区部署使用会话启动协议（SIP）[RFC3261]的信息。它目前不是IETF标准跟踪提案。本文档中的机制使用SIP作为名称解析和身份验证机制来启动Internet密钥交换协议（IKE）[RFC5996]会话。本文档的目的是使用自签名证书为没有固定IP地址的家庭路由器建立按需虚拟专用网络（VPN）。它仅在确保会话描述协议（SDP）[RFC4566]的完整性的情况下适用。确保SDP完整性的方法不在本文件范围内。本文档规定了一对SIP用户代理解析彼此名称、安全交换自签名证书的指纹以及同意建立基于IPsec的VPN的过程[RFC4301]。但是，本文档不对IPsec/IKE的规范进行任何修改。尽管本规范适用的条件存在局限性，但本规范仍有足够的使用案例，例如：
o Sharing media using a framework developed by Digital Living Network Alliance (DLNA) or similar protocols over VPN between two user devices.
o 使用由数字生活网络联盟（DLNA）开发的框架或类似协议在两个用户设备之间通过VPN共享媒体。
o Accessing remote desktop applications over VPN initiated by SIP call. As an additional function of click-to-call, a customer service agent can access a customer's PC remotely to troubleshoot the problem while talking with the customer over the phone.
o 通过SIP呼叫启动的VPN访问远程桌面应用程序。作为点击呼叫的附加功能，客户服务代理可以远程访问客户的PC，在与客户通过电话交谈时排除故障。
o Accessing and controlling medical equipment (medical robotics) remotely to monitor the elderly in a rural area (remote care services).
o 远程访问和控制医疗设备（医疗机器人），以监控农村地区的老年人（远程护理服务）。
o Using a LAN-based gaming protocol based on peer-to-peer rather than via a gaming server.
o 使用基于局域网的基于点对点的游戏协议，而不是通过游戏服务器。
This section describes the problem in accessing home networks and provides an overview of the proposed solution.
本节描述了访问家庭网络的问题，并概述了建议的解决方案。
Home servers and network-capable consumer electronic devices have been widely deployed. People using such devices are willing to share content and applications and are therefore seeking ways to establish multiple communication channels with each other. However, there are several obstacles to be overcome in the case of remote home access.
家庭服务器和具有网络功能的消费电子设备已经广泛部署。使用这类设备的人愿意共享内容和应用程序，因此正在寻求彼此建立多个通信渠道的方法。然而，在远程家庭接入的情况下，有几个障碍需要克服。
It is often not possible for a device outside the home network to connect to another device inside the home network because the home device is behind a network address translation (NAT) or firewall that allows outgoing connections but blocks incoming connections. One effective solution for this problem is VPN remote access to the NAT device, which is usually a home router. With this approach, once the external device joins the home network securely, establishing connections with all the devices inside the home will become easy because popular LAN-based communication methods such as DLNA can be used transparently. However, there are more difficult cases in which a home router itself is located behind the NAT. In such cases, it is also necessary to consider NAT traversal of the remote access to the home router. In many cases, because the global IP address of the home router is not always fixed, it is necessary to make use of an effective name resolution mechanism.
家庭网络外部的设备通常不可能连接到家庭网络内部的另一个设备，因为家庭设备位于网络地址转换（NAT）或防火墙之后，该防火墙允许传出连接，但阻止传入连接。这个问题的一个有效解决方案是VPN远程访问NAT设备，通常是家庭路由器。通过这种方法，一旦外部设备安全地加入家庭网络，就可以很容易地与家庭内的所有设备建立连接，因为可以透明地使用流行的基于局域网的通信方法，如DLNA。然而，在更困难的情况下，家庭路由器本身位于NAT后面。在这种情况下，还需要考虑NAT穿越对家庭路由器的远程访问。在许多情况下，由于家庭路由器的全局IP地址并不总是固定的，因此有必要使用有效的名称解析机制。
In addition, there is the problem of how a remote client and a home router authenticate each other over IKE to establish IPsec for remote access. It is not always possible for the two devices to securely exchange a pre-shared key in advance. Administrative costs can make it impractical to distribute authentication certificates signed by a well-known root certification authority (CA) to all the devices. In addition, it is inefficient to publish a temporary certificate to a device that does not have a fixed IP address or hostname. To resolve these authentication issues, this document proposes a mechanism that enables the devices to authenticate each other using self-signed certificates.
此外，还有一个问题，即远程客户端和家庭路由器如何通过IKE相互验证，以建立用于远程访问的IPsec。这两个设备并不总是能够事先安全地交换预共享密钥。管理成本会使将由知名的根证书颁发机构（CA）签名的身份验证证书分发到所有设备变得不切实际。此外，将临时证书发布到没有固定IP地址或主机名的设备是低效的。为了解决这些身份验证问题，本文档提出了一种机制，使设备能够使用自签名证书相互进行身份验证。
This document proposes the use of SIP as a name resolution and authentication mechanism because of three main advantages:
本文档建议使用SIP作为名称解析和身份验证机制，因为有三个主要优点：
o Delegation of Authentication to Third Party
o 将身份验证委托给第三方
Devices can be free from managing their signed certificates and whitelists by taking advantage of authentication and authorization mechanisms supported by SIP.
通过利用SIP支持的身份验证和授权机制，设备可以不必管理其签名证书和白名单。
o UDP Hole Punching for IKE/IPsec
o IKE/IPsec的UDP打孔
SIP has a cross-NAT rendezvous mechanism, and Interactive Connectivity Establishment (ICE) [RFC5245] has a function to open ports through the NAT. The combination of these effective functions can be used for general applications as well as real-time media. It is difficult to set up a session between devices without SIP if the devices are behind various types of NAT.
SIP具有跨NAT会合机制，交互式连接建立（ICE）[RFC5245]具有通过NAT打开端口的功能。这些有效功能的组合可用于一般应用以及实时媒体。如果设备落后于各种类型的NAT，则很难在没有SIP的设备之间建立会话。
o Reuse of Existing SIP Infrastructure
o 重用现有SIP基础设施
SIP servers are widely distributed as a scalable infrastructure, and it is quite practical to reuse them without any modifications.
SIP服务器作为一种可扩展的基础设施广泛分布，在不做任何修改的情况下重用它们是非常实际的。
Today, SIP is applied to not only Voice over IP (VoIP) but also various applications and is recognized as a general protocol for session initiation. Therefore, it can also be used to initiate IKE/IPsec sessions.
如今，SIP不仅应用于IP语音（VoIP），而且还应用于各种应用，并被公认为会话启动的通用协议。因此，它也可用于启动IKE/IPsec会话。
However, there is also a specification that uses a self-signed certificate for authentication in the SIP/SDP framework. "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572] (hereafter referred to as comedia-tls) specifies a method to exchange the fingerprint of a self-signed certificate to establish a Transport Layer Security (TLS) [RFC5246] connection. This specification defines a mechanism by which self-signed certificates can be used securely, provided that the integrity of the SDP description is assured. Because a certificate itself is used for authentication not only in TLS but also in IKE, this mechanism will be applied to the establishment of an IPsec security association (SA) by extending the protocol identifier of SDP so that it can specify IKE.
但是，还有一种规范在SIP/SDP框架中使用自签名证书进行身份验证。“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”[RFC4572]（以下称为comedia TLS）指定了一种交换自签名证书指纹以建立传输层安全（TLS）[RFC5246]连接的方法。本规范定义了一种机制，只要SDP描述的完整性得到保证，就可以通过该机制安全地使用自签名证书。由于证书本身不仅用于TLS中的身份验证，而且还用于IKE中的身份验证，因此该机制将通过扩展SDP的协议标识符来应用于IPsec安全关联（SA）的建立，以便SDP可以指定IKE。
One easy method to protect the integrity of the SDP description, which is the premise of this specification, is to use the SIP identity [RFC4474] mechanism. This approach is also referred to in [RFC5763]. Because the SIP identity mechanism can protect the integrity of a body part as well as the value of the From header in a SIP request by using a valid Identity header, the receiver of the request can establish secure IPsec connections with the sender by confirming that the hash value of the certificate sent during IKE negotiation matches the fingerprint in the SDP. Although SIP identity does not protect the identity of the receiver of the SIP request, SIP-connected identity [RFC4916] does. Note that the possible deficiencies discussed in [RFC4474-Concerns] could affect this specification if SIP identity is used for the security mechanism.
保护SDP描述完整性的一种简单方法是使用SIP标识[RFC4474]机制，这是本规范的前提。[RFC5763]中也提到了这种方法。因为SIP标识机制可以通过使用有效的标识头来保护主体部分的完整性以及SIP请求中From头的值，通过确认IKE协商期间发送的证书的哈希值与SDP中的指纹匹配，请求的接收方可以与发送方建立安全的IPsec连接。虽然SIP标识不保护SIP请求的接收方的标识，但SIP连接标识[RFC4916]保护。注意，如果安全机制使用SIP标识，[RFC4474关注点]中讨论的可能缺陷可能会影响本规范。
Considering the above background, this document defines new media formats "ike-esp" and "ike-esp-udpencap", which can be used when the protocol identifier is "udp", to enable the negotiation of using IKE for media sessions over SDP exchange on the condition that the integrity of the SDP description is assured. It also specifies the method to set up an IPsec SA by exchanging fingerprints of self-signed certificates based on comedia-tls, and it notes the example of SDP offer/answer [RFC3264] and the points that should be taken care of by implementation. Because there is a chance that devices are behind NAT, this document also covers the method to combine IKE/IPsec NAT-Traversal [RFC3947][RFC3948] with ICE. In addition, it defines the attribute "ike-setup" for IKE media sessions, similar to the "setup" attribute for TCP-based media transport defined in RFC 4145 [RFC4145]. This attribute is used to negotiate the role of each endpoint in the IKE session.
考虑到上述背景，本文档定义了新的媒体格式“ike esp”和“ike esp udpencap”，可在协议标识符为“udp”时使用，以便在确保SDP描述完整性的前提下，通过SDP交换对媒体会话使用ike进行协商。它还指定了通过交换基于comedia tls的自签名证书的指纹来建立IPsec SA的方法，并指出了SDP提供/应答[RFC3264]的示例以及实现时应注意的要点。由于NAT背后可能存在设备，因此本文档还介绍了将IKE/IPsec NAT遍历[RFC3947][RFC3948]与ICE相结合的方法。此外，它为ike媒体会话定义了属性“ike setup”，类似于RFC 4145[RFC4145]中定义的基于TCP的媒体传输的“setup”属性。此属性用于协商IKE会话中每个端点的角色。
Under quite limited conditions, certificates signed by trusted third parties or pre-shared keys between endpoints could be used for authentication in IKE, using SIP servers only for name resolution and authorization of session initiation. Such limited cases are addressed in Section 8.
在相当有限的条件下，由可信第三方签署的证书或端点之间的预共享密钥可用于IKE中的身份验证，仅使用SIP服务器进行名称解析和会话启动授权。第8节讨论了这种有限的情况。
In this document, SIP servers are used for authorization of each SIP call. The actual media sessions of IPsec/IKE are not authorized by SIP servers but by the remote client and the home router based on the information in SIP/SDP. For example, the home router recognizes the remote client with its SIP-URI and IP address in the SDP. If it decides to accept the remote client as a peer of a VPN session, it will accept the following IKE session. Then, during the IKE negotiation, the certificate fingerprint in the SDP is compared with the certificate exchanged in the IKE session. If they match, IKE negotiation continues. Only a successful IKE negotiation establishes an IPsec session with the remote peer.
在本文档中，SIP服务器用于每个SIP呼叫的授权。IPsec/IKE的实际媒体会话不是由SIP服务器授权的，而是由远程客户端和家庭路由器根据SIP/SDP中的信息授权的。例如，家庭路由器通过其SIP-URI和SDP中的IP地址识别远程客户端。如果它决定接受远程客户端作为VPN会话的对等方，它将接受以下IKE会话。然后，在IKE协商期间，将SDP中的证书指纹与IKE会话中交换的证书进行比较。如果他们匹配，IKE谈判将继续。只有成功的IKE协商才能与远程对等方建立IPsec会话。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Figure 1 shows a case of VPN remote access from a device outside the home to a home router whose IP address is not fixed. In this case, the external device, a remote client, recognizes the Address of Record of the home router but does not have any information about its contact address and certificate. Generally, establishing an IPsec SA dynamically and securely in this situation is difficult. However, as specified in comedia-tls [RFC4572], if the integrity of SDP session descriptions is assured, it is possible for the home router and the remote client to have a prior relationship with each other by exchanging certificate fingerprints, i.e., secure one-way hashes of the distinguished encoding rules (DER) form of the certificates.
图1显示了一个VPN远程访问的案例，从家庭以外的设备访问IP地址不固定的家庭路由器。在这种情况下，外部设备（远程客户端）识别家庭路由器的记录地址，但不具有关于其联系人地址和证书的任何信息。通常，在这种情况下很难动态安全地建立IPsec SA。然而，如comesia tls[RFC4572]中所述，如果SDP会话描述的完整性得到保证，则家庭路由器和远程客户端可以通过交换证书指纹（即证书的可分辨编码规则（DER）形式的安全单向散列）彼此具有优先关系。
REGISTRATION REGISTRATION
(1) +----------+ (1)
+------------->| |<---------+
| INVITE(2) | | |
| +----------->| SIP |--------+ |
| | 200 OK(2) | Proxy | | |
| | +----------| |<-----+ | |
| | | | | | | | _________
| | V +----------+ | V | / \
+----------+ IKE (Media Session) +---------+ \
| Remote |<---------(3)------->| Home | Home \
| Client | | Router | Network |
| ============(4)==================== |
|(SIP UAC) | VPN (IPsec SA) |(SIP UAS)| /
+----------+ +---------+ /
\_________/
REGISTRATION REGISTRATION
(1) +----------+ (1)
+------------->| |<---------+
| INVITE(2) | | |
| +----------->| SIP |--------+ |
| | 200 OK(2) | Proxy | | |
| | +----------| |<-----+ | |
| | | | | | | | _________
| | V +----------+ | V | / \
+----------+ IKE (Media Session) +---------+ \
| Remote |<---------(3)------->| Home | Home \
| Client | | Router | Network |
| ============(4)==================== |
|(SIP UAC) | VPN (IPsec SA) |(SIP UAS)| /
+----------+ +---------+ /
\_________/
Figure 1: Remote Access to Home Network
图1：远程访问家庭网络
(1) Both Remote Client and Home Router generate secure signaling channels. They may REGISTER to SIP Proxy using TLS.
(1) 远程客户端和家庭路由器都生成安全的信令通道。他们可以使用TLS注册到SIP代理。
(2) Remote Client sends an offer SDP with an INVITE request to Home Router, and Home Router returns an answer SDP with a reliable response (e.g., 200 OK). Both exchange the fingerprints of their self-signed certificates in SDP during this transaction. Remote Client does not accept an answer SDP with an unreliable response as the final response.
(2) 远程客户端向家庭路由器发送带有INVITE请求的要约SDP，家庭路由器返回带有可靠响应的应答SDP（例如，200 OK）。双方在此事务期间在SDP中交换其自签名证书的指纹。远程客户端不接受带有不可靠响应的应答SDP作为最终响应。
(3) After the SDP exchange, Remote Client, which has the active role, initiates IKE with Home Router, which has the passive role, to establish an IPsec SA. Both validate that the certificate presented in the IKE exchange has a fingerprint that
(3) 在SDP交换之后，具有主动角色的远程客户端与具有被动角色的家庭路由器发起IKE，以建立IPsec SA。两者都验证IKE交换中提供的证书是否具有
matches the fingerprint from SDP. If they match, IKE negotiation proceeds as normal.
匹配来自SDP的指纹。如果它们匹配，IKE协商将正常进行。
(4) Remote Client joins the Home Network.
(4) 远程客户端加入家庭网络。
By this method, the self-signed certificates of both parties are used for authentication in IKE, but SDP itself is not concerned with all the negotiations related to key-exchange, such as those of encryption and authentication algorithms. These negotiations are up to IKE. In many cases where IPsec is used for remote access, a remote client needs to dynamically obtain a private address inside the home network while initiating the remote access. Therefore, the IPsec security policy also needs to be set dynamically at the same time. However, such a management function of the security policy is the responsibility of the high-level application. SDP is not concerned with it. The roles of SDP here are to determine the IP addresses of both parties used for IKE connection with c-line in SDP and to exchange the fingerprints of the certificates used for authentication in IKE with the fingerprint attribute in SDP.
通过这种方法，双方的自签名证书用于IKE中的身份验证，但SDP本身并不涉及与密钥交换相关的所有协商，例如加密和身份验证算法的协商。这些谈判由艾克决定。在许多使用IPsec进行远程访问的情况下，远程客户端需要在启动远程访问时动态获取家庭网络内的专用地址。因此，还需要同时动态设置IPsec安全策略。但是，安全策略的这种管理功能是高级应用程序的责任。SDP与此无关。SDP在这里的作用是确定用于与SDP中的c-line进行IKE连接的双方的IP地址，并使用SDP中的指纹属性交换IKE中用于身份验证的证书的指纹。
This document defines two SDP media formats for the "udp" protocol under the "application" media type: "ike-esp" and "ike-esp-udpencap". The format "ike-esp" indicates that the media described is IKE for the establishment of an IPsec security association as described in IPsec Encapsulating Security Payload (ESP) [RFC4303]. In contrast, "ike-esp-udpencap" indicates that the media described is IKE, which is capable of NAT traversal for the establishment of UDP encapsulation of IPsec packets through NAT boxes as specified in [RFC3947] and [RFC3948]. Even if the offerer and answerer exchange "ike-esp-udpencap", IKE conforming to [RFC3947] and [RFC3948] can end up establishing a normal IPsec tunnel when there is no need to use UDP encapsulation of IPsec. Both the offerer and answerer can negotiate IKE by specifying "udp" in the "proto" field and "ike-esp" or "ike-esp-udpencap" in the "fmt" field in SDP.
本文档在“应用程序”媒体类型下为“udp”协议定义了两种SDP媒体格式：“ike esp”和“ike esp udpencap”。格式“ike esp”表示所描述的媒体是ike，用于建立IPsec安全关联，如IPsec封装安全有效负载（esp）[RFC4303]中所述。相反，“ike esp udpencap”表示所描述的媒体是ike，它能够遍历NAT，以便按照[RFC3947]和[RFC3948]中的规定，通过NAT盒建立IPsec数据包的UDP封装。即使报价人和应答人交换“ike esp udpencap”，符合[RFC3947]和[RFC3948]的ike最终也可以在不需要使用IPsec的UDP封装时建立正常的IPsec隧道。报价人和应答人都可以通过在“协议”字段中指定“udp”和在SDP的“fmt”字段中指定“IKE esp”或“IKE esp udpencap”来协商IKE。
In addition, this document defines a new attribute "ike-setup", which can be used when the protocol identifier is "udp" and the "fmt" field is "ike-esp" or "ike-esp-udpencap", in order to describe how endpoints should perform the IKE session setup procedure. The "ike-setup" attribute indicates which of the end points should initiate the establishment of an IKE session. The "ike-setup" attribute is charset-independent and can be a session- or media-level attribute. The following is the ABNF of the "ike-setup" attribute.
此外，本文档定义了一个新属性“ike setup”，当协议标识符为“udp”且“fmt”字段为“ike esp”或“ike esp udpencap”时，可使用该属性，以描述端点应如何执行ike会话设置过程。“ike setup”属性指示哪些端点应启动ike会话的建立。“ike setup”属性与字符集无关，可以是会话级或媒体级属性。以下是“ike设置”属性的ABNF。
ike-setup-attr = "a=ike-setup:" role
role = "active" / "passive" / "actpass"
ike-setup-attr = "a=ike-setup:" role
role = "active" / "passive" / "actpass"
'active': The endpoint will initiate an outgoing session. 'passive': The endpoint will accept an incoming session. 'actpass': The endpoint is willing to accept an incoming session or to initiate an outgoing session.
“活动”：终结点将启动传出会话被动”：终结点将接受传入会话actpass”：端点愿意接受传入会话或启动传出会话。
Both endpoints use the SDP offer/answer model to negotiate the value of "ike-setup", following the procedures determined for the "setup" attribute defined in Section 4.1 of [RFC4145]. However, "holdconn", as defined in [RFC4145], is not defined for the "ike-setup" attribute.
Both endpoints use the SDP offer/answer model to negotiate the value of "ike-setup", following the procedures determined for the "setup" attribute defined in Section 4.1 of [RFC4145]. However, "holdconn", as defined in [RFC4145], is not defined for the "ike-setup" attribute.translate error, please retry
Offer Answer
----------------------------
active passive
passive active
actpass active / passive
Offer Answer
----------------------------
active passive
passive active
actpass active / passive
The semantics for the "ike-setup" attribute values of "active", "passive", and "actpass" in the offer/answer exchange are the same as those described for the "setup" attribute in Section 4.1 of [RFC4145], except that "ike-setup" applies to an IKE session instead of a TCP connection. The default value of the "ike-setup" attribute is "active" in the offer and "passive" in the answer.
提供/应答交换中“ike设置”属性值“主动”、“被动”和“actpass”的语义与[RFC4145]第4.1节中“设置”属性的语义相同，只是“ike设置”适用于ike会话而不是TCP连接。“ike设置”属性的默认值在报价中为“主动”，在应答中为“被动”。
In this section, a method to negotiate the use of IKE for media sessions in the SDP offer/answer model is described.
在本节中，描述了在SDP提供/应答模型中协商媒体会话使用IKE的方法。
An offerer and an answerer negotiate the use of IKE following the usage of the protocol identifiers defined in Section 4. If IPsec NAT-Traversal is not necessary, the offerer MAY use the media format "ike-esp" to indicate an IKE session.
在使用第4节中定义的协议标识符之后，报价人和应答人协商IKE的使用。如果不需要IPsec NAT穿越，则报价人可以使用媒体格式“ike esp”来指示ike会话。
If either of the endpoints that negotiate IKE is behind the NAT, the endpoints need to transmit both IKE and IPsec packets over the NAT. That mechanism is specified in [RFC3947] and [RFC3948]: both endpoints encapsulate IPsec-ESP packets with a UDP header and multiplex them into the UDP path that IKE generates.
如果协商IKE的任一端点位于NAT后面，则端点需要通过NAT传输IKE和IPsec数据包。该机制在[RFC3947]和[RFC3948]中指定：两个端点都使用UDP报头封装IPsec ESP数据包，并将其多路传输到IKE生成的UDP路径中。
To indicate this type of IKE session, the offerer uses "ike-esp-udpencap" media lines. In this case, the offerer MAY decide their transport addresses (combination of IP address and port) before
为了指示这种类型的IKE会话，报价人使用“IKE esp udpencap”媒体行。在这种情况下，报价人可以在确定其传输地址之前（IP地址和端口的组合）
starting IKE, making use of the ICE framework. Because UDP-encapsulated ESP packets and IKE packets go through the same UDP hole of a NAT, IPsec NAT-Traversal works if ICE reserves simply one UDP path through the NAT. However, those UDP packets need to be multiplexed with Session Traversal Utilities for NAT (STUN) [RFC5389] packets if ICE is required to use STUN. A method to coordinate IPsec NAT-Traversal and ICE is described in Sections 5.4 and 5.5.
启动IKE，利用ICE框架。因为UDP封装的ESP数据包和IKE数据包通过NAT的同一个UDP孔，所以如果ICE只保留一条通过NAT的UDP路径，IPsec NAT遍历就可以工作。但是，如果ICE需要使用STUN，则这些UDP数据包需要与NAT（STUN）[RFC5389]数据包的会话遍历实用程序进行多路复用。第5.4节和第5.5节描述了协调IPsec NAT穿越和ICE的方法。
The offer MAY contain media lines for media other than "ike-esp" or "ike-esp-udpencap". For example, audio stream may be included in the same SDP to have a voice session when establishing the VPN. This may be useful to verify that the connected device is indeed operated by somebody who is authorized to access it, as described in Section 9. If that occurs, the negotiation described in this specification occurs only for the "ike-esp" or "ike-esp-udpencap" media lines; other media lines are negotiated and set up normally. If the answerer determines it will refuse the IKE session without beginning the IKE negotiation (e.g., the From address is not on the permitted list), it SHOULD reject the "ike-esp" or "ike-esp-udpencap" media line in the normal manner by setting the port number in the SDP answer to 0 and SHOULD process the other media lines normally (only if it is still reasonable to establish that media without VPN).
报价可能包含除“ike esp”或“ike esp udpencap”以外的媒体的媒体行。例如，音频流可以包括在同一SDP中，以便在建立VPN时具有语音会话。如第9节所述，这可能有助于验证连接的设备确实由有权访问它的人操作。如果出现这种情况，则本规范中描述的协商仅针对“ike esp”或“ike esp udpencap”媒体线路进行；其他媒体线路正常协商和设置。如果应答者确定其将在不开始IKE协商的情况下拒绝IKE会话（例如，发件人地址不在允许列表中），则应通过将SDP应答中的端口号设置为0，以正常方式拒绝“IKE esp”或“IKE esp udpencap”媒体线，并应正常处理其他媒体线（只有在仍然合理的情况下，才能建立没有VPN的媒体）。
If the offerer and the answerer agree to start an IKE session by the offer/answer exchange, they will start the IKE setup. Following the comedia-tls specification [RFC4572], the fingerprint attribute, which may be either a session- or a media-level SDP attribute, is used to exchange fingerprints of self-signed certificates. If the fingerprint attribute is a session-level attribute, it applies to all IKE sessions and TLS sessions for which no media-level fingerprint attribute is defined.
如果报价人和应答人同意通过报价/应答交换启动IKE会话，他们将启动IKE设置。按照comedia tls规范[RFC4572]，指纹属性可以是会话级或媒体级SDP属性，用于交换自签名证书的指纹。如果指纹属性是会话级属性，则它适用于未定义媒体级指纹属性的所有IKE会话和TLS会话。
Note that it is possible for an offerer to become the IKE responder and an answerer to become the IKE initiator. For example, when a Remote Access Server (RAS) sends an INVITE to an RAS client, the server may expect the client to become an IKE initiator. In this case, the server sends an offer SDP with ike-setup:passive and the client returns an answer SDP with ike-setup:active.
请注意，报价人有可能成为IKE响应者，而应答者有可能成为IKE发起人。例如，当远程访问服务器（RAS）向RAS客户端发送邀请时，服务器可能期望客户端成为IKE启动器。在这种情况下，服务器发送带有ike setup:passive的报价SDP，客户端返回带有ike setup:active的应答SDP。
If the high-level application recognizes a VPN session as the media session, it MAY discard the IPsec SA and terminate IKE when that media session is terminated by a BYE request. Therefore, the application aware of the VPN session MUST NOT send a BYE request as long as it needs the IPsec SA. On the other hand, if the high-level application detects that a VPN session is terminated, it MAY terminate the media associated with the VPN or the entire SIP
如果高级应用程序将VPN会话识别为媒体会话，则当媒体会话被BYE请求终止时，它可能会丢弃IPsec SA并终止IKE。因此，只要知道VPN会话的应用程序需要IPsec SA，就不能发送BYE请求。另一方面，如果高级应用程序检测到VPN会话被终止，则它可以终止与VPN或整个SIP相关联的媒体
session. Session timers in SIP [RFC4028] MAY be used for the session maintenance of the SIP call, but this does not necessarily ensure that the VPN session is alive. If the VPN session needs session maintenance such as keep-alive and rekeying, it MUST be done utilizing its own maintenance mechanisms. SIP re-INVITE MUST NOT be used for this purpose. Note that each party can cache the certificate of the other party as described in the Security Considerations section of comedia-tls [RFC4572].
一场SIP[RFC4028]中的会话计时器可用于SIP呼叫的会话维护，但这并不一定确保VPN会话处于活动状态。如果VPN会话需要会话维护，如保持活动状态和密钥更新，则必须使用其自身的维护机制来完成。SIP重新邀请不得用于此目的。请注意，各方可以缓存另一方的证书，如comedia tls[RFC4572]的安全注意事项部分所述。
Forking to multiple registered instances is outside the scope of this document. At least, it is assumed that a User Agent Client (UAC) establishes a session with only one User Agent Server (UAS). Encountering forked answers should be treated as an illegal process, and the UAC should cancel the session.
分叉到多个已注册实例超出了本文档的范围。至少，假设用户代理客户端（UAC）仅与一个用户代理服务器（UAS）建立会话。遇到分叉答案应视为非法过程，UAC应取消会话。
IKE generally uses local UDP port 500, but the IPsec NAT-Traversal specification requires a port transition to local UDP port 4500 during IKE negotiation because IPsec-aware NAT may multiplex IKE sessions using port 500 without changing the port number. If using ICE for IPsec Nat-Traversal, this port transition of IKE means ICE has to generate an additional UDP path for port 4500, and this would be unnecessary overhead. However, IPsec NAT-Traversal allows an IKE session to use local UDP port 4500 from the beginning without using port 500. Therefore, the endpoints SHOULD use their local UDP port 4500 for an IKE session from the beginning, and ICE will only need to generate a UDP path of port 4500.
IKE通常使用本地UDP端口500，但IPsec NAT穿越规范要求在IKE协商期间将端口转换为本地UDP端口4500，因为支持IPsec的NAT可以使用端口500复用IKE会话，而不更改端口号。如果使用ICE进行IPsec Nat遍历，IKE的此端口转换意味着ICE必须为端口4500生成额外的UDP路径，这将是不必要的开销。但是，IPsec NAT遍历允许IKE会话从一开始就使用本地UDP端口4500，而不使用端口500。因此，端点应该从一开始就将其本地UDP端口4500用于IKE会话，ICE只需要生成端口4500的UDP路径。
When using ICE, a responder's IKE port observed by an initiator is not necessarily 500 or 4500. Therefore, an IKE initiator MUST allow any destination ports in addition to 500 and 4500 for the IKE packets that it sends. An IKE initiator just initiates an IKE session to the port number decided by an SDP offer/answer or ICE.
使用ICE时，发起者观察到的响应者IKE端口不一定是500或4500。因此，IKE启动器必须允许其发送的IKE数据包除了500和4500之外的任何目标端口。IKE发起方仅根据SDP提供/应答或ICE决定的端口号发起IKE会话。
Conforming to ICE, an offerer and an answerer start a STUN connectivity check after SDP exchange. Then the offerer initiates the IKE session making use of the UDP path generated by STUN packets. In addition, UDP-encapsulated ESP packets are multiplexed into the same UDP path as IKE. Thus, it is necessary to multiplex the three different packets, STUN, IKE, and UDP-encapsulated ESP, into the same UDP path. This section describes how to demultiplex these three packets.
根据ICE，报价人和应答人在SDP交换后开始眩晕连接检查。然后，提供方利用STUN包生成的UDP路径发起IKE会话。此外，UDP封装的ESP数据包被多路复用到与IKE相同的UDP路径中。因此，有必要将三个不同的数据包STUN、IKE和UDP封装的ESP多路复用到相同的UDP路径中。本节介绍如何对这三个数据包进行解复用。
At the first step, the endpoint that received a UDP packet at the multiplexed port MUST check the first 32 bits (bits 0-31) of the UDP payload. If they are all 0, which is defined as a non-ESP marker, that packet MUST be treated as an IKE packet.
在第一步，在多路复用端口接收UDP数据包的端点必须检查UDP有效负载的前32位（位0-31）。如果它们都是0（定义为非ESP标记），则必须将该数据包视为IKE数据包。
Otherwise, it is judged as an ESP packet in the IPsec NAT-Traversal specification. It is furthermore necessary to distinguish STUN from ESP. Therefore, the bits 32-63 from the beginning of the UDP payload MUST be checked. If the bits do not match the magic cookie of STUN 0x2112A442 (most packets do not match), the packet is treated as an ESP packet because it is no longer a STUN packet.
否则，在IPsec NAT穿越规范中将其判断为ESP数据包。此外，还需要区分STUN和ESP。因此，必须检查UDP有效负载开头的32-63位。如果位与STUN 0x2112A442的魔法cookie不匹配（大多数数据包不匹配），则该数据包将被视为ESP数据包，因为它不再是STUN数据包。
However, if the bits do match the magic cookie, an additional test is necessary to determine if the packet is STUN or ESP. The magic cookie field of STUN overlaps the sequence number field of ESP, so a possibility still remains that the sequence number of ESP coincides with 0x2112A442. In this additional test, the validity of the fingerprint attribute of the STUN message MUST be checked. If there is a valid fingerprint in the message, it is judged as a STUN packet; otherwise, it is an ESP packet.
但是，如果位与magic cookie匹配，则需要进行额外的测试以确定数据包是STUN还是ESP。STUN的magic cookie字段与ESP的序列号字段重叠，因此ESP的序列号与0x2112A442一致的可能性仍然存在。在此附加测试中，必须检查STUN消息的指纹属性的有效性。如果消息中存在有效指纹，则判断为STUN数据包；否则，它是一个ESP数据包。
The above logic is expressed as follows.
上述逻辑表示如下。
if SPI-field-is-all-zeros
{ packet is IKE }
else
{
if bits-32-through-63 == stun-magic-cookie-value and
bits-0-through-1 == 0 and
bits-2-through-15 == a STUN message type and
bits-16-through-31 == length of this UDP packet
{
fingerprint_found == parse_for_stun_fingerprint();
if fingerprint_found == 1
{ packet is STUN }
else
{ packet is ESP }
}
else
{ packet is ESP }
}
if SPI-field-is-all-zeros
{ packet is IKE }
else
{
if bits-32-through-63 == stun-magic-cookie-value and
bits-0-through-1 == 0 and
bits-2-through-15 == a STUN message type and
bits-16-through-31 == length of this UDP packet
{
fingerprint_found == parse_for_stun_fingerprint();
if fingerprint_found == 1
{ packet is STUN }
else
{ packet is ESP }
}
else
{ packet is ESP }
}
6.1. Example of SDP Offer and Answer Exchange without IPsec NAT-Traversal
6.1. 无IPsec NAT遍历的SDP提供和应答交换示例
If IPsec NAT-Traversal is not necessary, SDP negotiation to set up IKE is quite simple. Examples of SDP exchange are as follows.
如果不需要IPsec NAT遍历，那么设置IKE的SDP协商非常简单。SDP交换的示例如下。
(Note: Due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.)
（注意：由于RFC格式约定，本文档在内容超过72个字符的行之间拆分SDP。反斜杠字符标记发生此行折叠的位置。此反斜杠及其尾部CRLF和空格不会出现在实际SDP内容中。）
offer SDP ... m=application 500 udp ike-esp c=IN IP4 192.0.2.10 a=ike-setup:active a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB ...
提供SDP。。。m=应用程序500 udp ike esp c=在IP4 192.0.2.10中a=ike设置：活动a=指纹：SHA-1\4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB。。。
answer SDP ... m=application 500 udp ike-esp c=IN IP4 192.0.2.20 a=ike-setup:passive a=fingerprint:SHA-1 \ D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E ...
回答SDP。。。m=application 500 udp ike esp c=IN IP4 192.0.2.20 a=ike设置：被动a=fingerprint:SHA-1\D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E。。。
Figure 2: SDP Example When Offerer Is an IKE Initiator
图2：当报价人是IKE发起人时的SDP示例
offer SDP ... m=application 500 udp ike-esp c=IN IP4 192.0.2.10 a=ike-setup:passive a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB ...
提供SDP。。。m=application 500 udp ike esp c=IN IP4 192.0.2.10 a=ike设置：被动a=fingerprint:SHA-1\4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB。。。
answer SDP ... m=application 500 udp ike-esp c=IN IP4 192.0.2.20 a=ike-setup:active a=fingerprint:SHA-1 \ D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E ...
回答SDP。。。m=应用程序500 udp ike esp c=在IP4 192.0.2.20中a=ike设置：活动a=指纹：SHA-1\D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E。。。
Figure 3: SDP Example When Offerer Is an IKE Responder
图3：当报价人是IKE响应者时的SDP示例
We consider the following scenario here.
我们考虑下面的场景。
+---------------------+
| |
| Internet |
| |
+---------------------+
| |
| |(192.0.2.20:45664)
| +---------+
| | NAT |
| +---------+
| |
(192.0.2.10:4500)| |(192.0.2.100:4500)
+---------+ +----------+
| offerer | | answerer |
+---------+ +----------+
+---------------------+
| |
| Internet |
| |
+---------------------+
| |
| |(192.0.2.20:45664)
| +---------+
| | NAT |
| +---------+
| |
(192.0.2.10:4500)| |(192.0.2.100:4500)
+---------+ +----------+
| offerer | | answerer |
+---------+ +----------+
Figure 4: NAT-Traversal Scenario
图4:NAT遍历场景
As shown above, an offerer is on the Internet, but an answerer is behind the NAT. The offerer cannot initiate an IKE session unless the answerer prepares a global routable transport address that accepts IKE packets. In this case, the following offer/answer exchange will take place.
如上所示，报价人在互联网上，但应答人在NAT后面。除非应答者准备一个接受IKE数据包的全局可路由传输地址，否则报价者不能发起IKE会话。在这种情况下，将进行以下报价/应答交换。
offer SDP ... a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-ufrag:9uB6 m=application 4500 udp ike-esp-udpencap c=IN IP4 192.0.2.10 a=ike-setup:active a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=candidate:1 1 udp 2130706431 192.0.2.10 4500 typ host ...
提供SDP。。。a=ice pwd:YH75Fviy6338Vbrhrlp8Yh a=ice ufrag:9uB6 m=application 4500 udp ike esp udpencap c=IN IP4 192.0.2.10 a=ike设置：活动a=fingerprint:SHA-1\4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=候选者：1 udp 213076431 192.0.2.10 4500典型主机。。。
answer SDP ... a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=application 45664 udp ike-esp-udpencap c=IN IP4 192.0.2.20 a=ike-setup:passive a=fingerprint:SHA-1 \ D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E a=candidate:1 1 udp 2130706431 192.0.2.100 4500 typ host a=candidate:2 1 udp 1694498815 192.0.2.20 45664 typ srflx \ raddr 192.0.2.100 rport 4500 ...
回答SDP。。。a=ice pwd:asd88fgpdd777uzjYhagZg a=ice ufrag:8hy m=application 45664 udp ike esp udpencap c=IN IP4 192.0.2.20 a=ike设置：被动a=fingerprint:SHA-1\D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:4A=候选者：1 udp 21307076431 192.0.2.100 4500典型主机a=候选者：2 169810.45815.SR20rport 4500。。。
Figure 5: SDP Example with IPsec NAT-Traversal
图5:IPsec NAT遍历的SDP示例
After the fingerprints of both parties are securely shared over the SDP exchange, the IKE initiator MAY start the IKE session with the other party. To follow this specification, a digital signature MUST be chosen as an authentication method in IKE phase 1. In this process, a certificate whose hash value matches the fingerprint exchanged over SDP MUST be used. If the certificate used in IKE does not match the original fingerprint, the endpoint MUST terminate the IKE session by detecting an authentication failure.
双方的指纹通过SDP交换安全共享后，IKE发起方可以启动与另一方的IKE会话。要遵循此规范，必须在IKE阶段1中选择数字签名作为身份验证方法。在此过程中，必须使用哈希值与通过SDP交换的指纹匹配的证书。如果IKE中使用的证书与原始指纹不匹配，则端点必须通过检测身份验证失败来终止IKE会话。
In addition, each party MUST present a certificate and be authenticated by each other.
此外，每一方必须出示证书，并经对方认证。
The example described in Section 3 is for tunnel mode IPsec used for remote access, but the mode of negotiated IPsec is not limited to tunnel mode. For example, IKE can negotiate transport mode IPsec to encrypt multiple media sessions between two parties with only a pair of IPsec security associations. The only thing for which the SDP offer/answer model is responsible is to exchange the fingerprints of
第3节中描述的示例是用于远程访问的隧道模式IPsec，但协商IPsec的模式不限于隧道模式。例如，IKE可以协商传输模式IPsec，以仅使用一对IPsec安全关联对双方之间的多个媒体会话进行加密。SDP提供/应答模型唯一负责的事情是交换用户的指纹
certificates used for IKE; therefore, the SDP offer/answer is not responsible for setting the security policy.
IKE使用的证书；因此，SDP提供/应答不负责设置安全策略。
This section describes the specification for the limited cases in which certificates signed by trusted third parties or pre-shared keys between endpoints can be used for authentication in IKE. Because the endpoints already have a prior relationship in this case, they use SIP servers for only name resolution and authorization. However, even in this case, the integrity of the SDP description MUST be assured.
本节描述了由受信任的第三方签署的证书或端点之间的预共享密钥可用于IKE中身份验证的有限情况的规范。因为在这种情况下，端点已经具有优先关系，所以它们仅使用SIP服务器进行名称解析和授权。但是，即使在这种情况下，也必须确保SDP描述的完整性。
The protocol overview in this case is the same as in Section 3. The SDP offer/answer procedure is also the same as in Sections 5 and 6. Both endpoints have a prior relationship through the trusted third parties, and SIP servers are used for name resolution and authorization of session initiation. Even so, they MAY exchange fingerprints in the SDP because one device can have several certificates and it would be necessary to specify in advance which certificate will be used for the following IKE authentication. This process also ensures that the certificate offered in the IKE process is the same as that owned by the peer that has been authorized at the SIP/SDP layer. By this process, authorization in SIP and authentication in IKE become consistent with each other.
本例中的协议概述与第3节相同。SDP报价/应答程序也与第5节和第6节相同。两个端点通过受信任的第三方具有优先关系，SIP服务器用于名称解析和会话启动授权。即使如此，它们也可能在SDP中交换指纹，因为一个设备可以有多个证书，并且有必要预先指定将用于以下IKE认证的证书。此过程还确保IKE过程中提供的证书与已在SIP/SDP层授权的对等方拥有的证书相同。通过这个过程，SIP中的授权和IKE中的认证变得一致。
If a pre-shared key for IKE authentication is installed in both endpoints in advance, they need not exchange the fingerprints of their certificates. However, they may still need to specify which pre-shared key they will use in the following IKE authentication in SDP because they may have several pre-shared keys. Therefore, a new attribute, "psk-fingerprint", is defined to exchange the fingerprint of a pre-shared key over SDP. This attribute also has the role of making authorization in SIP consistent with authentication in IKE. Attribute "psk-fingerprint" is applied to pre-shared keys as the "fingerprint" defined in [RFC4572] is applied to certificates. The following is the ABNF of the "psk-fingerprint" attribute. The use of "psk-fingerprint" is OPTIONAL.
如果提前在两个端点中安装了用于IKE身份验证的预共享密钥，则它们不需要交换证书的指纹。但是，他们可能仍然需要指定他们将在SDP中的以下IKE身份验证中使用的预共享密钥，因为他们可能有多个预共享密钥。因此，定义了一个新属性“psk指纹”，用于通过SDP交换预共享密钥的指纹。该属性还具有使SIP中的授权与IKE中的身份验证一致的作用。属性“psk指纹”应用于预共享密钥，因为[RFC4572]中定义的“指纹”应用于证书。以下是“psk指纹”属性的ABNF。“psk指纹”的使用是可选的。
attribute =/ psk-fingerprint-attribute
属性=/psk指纹属性
psk-fingerprint-attribute = "psk-fingerprint" ":" hash-func SP psk-fingerprint
psk fingerprint attribute=“psk fingerprint”“：”哈希函数SP psk fingerprint
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" / token
; Additional hash functions can only come
; from updates to RFC 3279
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" / token
; Additional hash functions can only come
; from updates to RFC 3279
psk-fingerprint = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons.
psk指纹=2UHEX*（“：”2UHEX）；每个字节以大写十六进制表示，分开；科隆。
UHEX = DIGIT / %x41-46 ; A-F uppercase
UHEX = DIGIT / %x41-46 ; A-F uppercase
An example of SDP negotiation for IKE with pre-shared key authentication without IPsec NAT-Traversal is as follows.
IKE的SDP协商的一个示例，具有预共享密钥身份验证，无需IPsec NAT遍历，如下所示。
offer SDP ... m=application 500 udp ike-esp c=IN IP4 192.0.2.10 a=ike-setup:active a=psk-fingerprint:SHA-1 \ 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02 ...
提供SDP。。。m=application 500 udp ike esp c=IN IP4 192.0.2.10 a=ike设置：活动a=psk指纹：SHA-1\12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02。。。
answer SDP ... m=application 500 udp ike-esp c=IN IP4 192.0.2.20 a=ike-setup:passive a=psk-fingerprint:SHA-1 \ 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02 ...
回答SDP。。。m=application 500 udp ike esp c=IN IP4 192.0.2.20 a=ike设置：被动a=psk指纹：SHA-1\12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02。。。
Figure 6: SDP Example of IKE with Pre-Shared Key Authentication
图6：带有预共享密钥身份验证的IKE的SDP示例
This entire document concerns security, but the security considerations applicable to SDP in general are described in the SDP specification [RFC4566]. The security issues that should be considered in using comedia-tls are described in Section 7 in its specification [RFC4572]. This section mainly describes the security considerations specific to the negotiation of IKE using comedia-tls.
整个文档涉及安全性，但SDP规范[RFC4566]中描述了一般适用于SDP的安全注意事项。使用comedia tls时应考虑的安全问题在其规范[RFC4572]的第7节中进行了描述。本节主要介绍使用comedia tls进行IKE协商时的安全注意事项。
Offering IKE in SDP (or agreeing to one in the SDP offer/answer model) does not create an obligation for an endpoint to accept any IKE session with the given fingerprint. However, the endpoint must engage in the standard IKE negotiation procedure to ensure that the chosen IPsec security associations (including encryption and
在SDP中提供IKE（或同意在SDP提供/应答模型中提供IKE）不会产生端点接受具有给定指纹的任何IKE会话的义务。但是，端点必须参与标准IKE协商过程，以确保所选IPsec安全关联（包括加密和
authentication algorithms) meet the security requirements of the higher-level application. When IKE has finished negotiating, the decision to conclude IKE and establish an IPsec security association with the remote peer is entirely the decision of each endpoint. This procedure is similar to how VPNs are typically established in the absence of SIP.
身份验证算法）满足更高级别应用程序的安全要求。当IKE完成协商后，结束IKE并与远程对等方建立IPsec安全关联的决定完全由每个端点决定。此过程类似于在没有SIP的情况下通常如何建立VPN。
In the general authentication process in IKE, subject DN or subjectAltName is recognized as the identity of the remote party. However, by using SIP identity and SIP-connected identity mechanisms in this spec, certificates are used simply as carriers for the public keys of the peers and there is no need for the information about who is the signer of the certificate and who is indicated by subject DN.
在IKE中的常规身份验证过程中，subject DN或subjectAltName被识别为远程方的身份。然而，通过在本规范中使用SIP标识和SIP连接的标识机制，证书仅用作对等方公钥的载体，并且不需要关于谁是证书的签名者以及谁由主体DN指示的信息。
In this document, the purpose of using IKE is to launch the IPsec SA; it is not for the security mechanism of RTP and RTCP [RFC3550] packets. In fact, this mechanism cannot provide end-to-end security inside the VPN as long as the VPN uses tunnel mode IPsec. Therefore, other security methods such as the Secure Real-time Transport Protocol (SRTP) [RFC3711] must be used to secure the packets.
在本文档中，使用IKE的目的是启动IPsec SA；它不适用于RTP和RTCP[RFC3550]数据包的安全机制。事实上，只要VPN使用隧道模式IPsec，这种机制就无法在VPN内提供端到端安全性。因此，必须使用安全实时传输协议（SRTP）[RFC3711]等其他安全方法来保护数据包。
When using the specification defined in this document, it needs to be considered that under the following circumstances, security based on SIP authentication provided by SIP proxy may be breached.
在使用本文档中定义的规范时，需要考虑在以下情况下，可能会违反基于SIP代理提供的SIP身份验证的安全性。
o If a legitimate user's terminal is used by another person, it may be able to establish a VPN with the legitimate identity information. This issue also applies to the general VPN cases based on the shared secret key. Furthermore, in SIP we have a similar problem when file transfer, IM, or comedia-tls where non-voice/video is used as a means of communication.
o 如果一个合法用户的终端被另一个人使用，它可能能够用合法的身份信息建立一个VPN。该问题也适用于基于共享密钥的一般VPN情况。此外，在SIP中，当文件传输、IM或喜剧tls使用非语音/视频作为通信手段时，我们也会遇到类似的问题。
o If a malicious user hijacks the proxy, he or she can use whatever credential is on the Access Control List (ACL) to gain access to the home network.
o 如果恶意用户劫持代理，他或她可以使用访问控制列表（ACL）上的任何凭据来访问家庭网络。
For countermeasures to these issues, it is recommended to use unique information such as a password that only a legitimate user knows for VPN establishment. Validating the originating user by voice or video before establishing VPN would be another method.
对于这些问题的对策，建议使用唯一的信息，例如只有合法用户才知道的VPN建立密码。另一种方法是在建立VPN之前通过语音或视频验证发起用户。
IANA has registered the following new SDP attributes and media formats.
IANA已注册了以下新的SDP属性和媒体格式。
Attribute name: ike-setup Long form name: IKE setup extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Attribute to indicate initiator and responder of IKE-based media session Appropriate values: See Section 4 of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
属性名称：ike设置长格式名称：ike设置扩展属性类型：会话级别和媒体级别根据字符集：无目的：属性用于指示基于ike的媒体会话的发起方和响应方适当值：请参阅RFC 6193第4节联系人姓名：马萨诸塞州Makoto Saito。saito@nttv6.jp
Media format name: ike-esp Long form name: IKE followed by IPsec ESP Associated media: application Associated proto: udp Subject to charset: No Purpose: Media format that indicates IKE and IPsec ESP as a VPN session Reference to the spec: See Section 5 of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
媒体格式名称：ike esp长格式名称：ike后跟IPsec esp关联媒体：应用程序关联协议：udp受字符集约束：无用途：指示ike和IPsec esp作为VPN会话的媒体格式参考规范：请参阅RFC 6193第5节联系人姓名：马萨诸塞州Makoto Saito。saito@nttv6.jp
Media format name: ike-esp-udpencap Long form name: IKE followed by IPsec ESP or UDP encapsulated IPsec ESP Associated media: application Associated proto: udp Subject to charset: No Purpose: Media format that indicates IKE that supports NAT-Traversal and IPsec ESP or UDP encapsulation of IPsec ESP packets as a VPN session Reference to the spec: See Section 5 of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
媒体格式名称：ike esp udpencap长格式名称：ike后跟IPsec esp或UDP封装的IPsec esp关联媒体：应用程序关联的协议：UDP受字符集约束：无用途：表示支持NAT遍历和IPsec esp或UDP封装IPsec esp数据包作为VPN会话的ike的媒体格式参考规范：参见RFC 6193第5节联系人姓名：马萨诸塞州斋藤Makoto。saito@nttv6.jp
Attribute name: psk-fingerprint Long form name: Fingerprint of pre-shared key extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Attribute to indicate a pre-shared key that will be used in the following media session Appropriate values: See Section 8.2. of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
属性名称：psk指纹长格式名称：预共享密钥扩展的指纹属性类型：会话级别和媒体级别取决于字符集：无用途：用于指示将在以下媒体会话中使用的预共享密钥的属性适当值：请参阅第8.2节。RFC 6193的联系人姓名：马库托斋藤，马萨诸塞州。saito@nttv6.jp
We would like to thank Remi Denis-Courmont, Dale Worley, Richard Barnes, David Hancock, Stuart Hoggan, Jean-Francois Mule, Gonzalo Camarillo, and Robert Sparks for providing comments and suggestions contributing to this document. Eric Rescorla especially gave insightful comments from a security point of view. Shintaro Mizuno and Shida Schubert also contributed a lot of effort to improving this document.
我们要感谢雷米·丹尼斯·库尔蒙、戴尔·沃利、理查德·巴恩斯、大卫·汉考克、斯图尔特·霍根、让·弗朗索瓦·穆尔、冈萨洛·卡马里洛和罗伯特·斯帕克斯为本文件提供了意见和建议。Eric Rescorla特别从安全角度发表了富有洞察力的评论。水野真太郎和舒伯特也为改进这份文件做出了很大的努力。
[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月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC4474-Concerns] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, February 2008.
[RFC4474关注点]Rosenberg，J.，“关于RFC 4474适用性的关注点”，正在进行的工作，2008年2月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028]Donovan，S.和J.Rosenberg，“会话启动协议（SIP）中的会话计时器”，RFC4028，2005年4月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 4916，2007年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763]Fischl，J.，Tschofenig，H.，和E.Rescorla，“使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”，RFC 5763，2010年5月。
Authors' Addresses
作者地址
Makoto Saito NTT Communications 1-1-6 Uchisaiwai-Cho, Chiyoda-ku Tokyo 100-8019 Japan
Makoto Saito NTT Communications 1-1-6 Uchisaiwai Cho，千代田区东京100-8019
EMail: ma.saito@nttv6.jp
EMail: ma.saito@nttv6.jp
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
Dan Wing Cisco Systems美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Masashi Toyama NTT Corporation 9-11 Midori-Cho 3-Chome, Musashino-Shi Tokyo 180-8585 Japan
日本东京武藏县富山新田株式会社9-11 Midori Cho 3-Chome 180-8585
EMail: toyama.masashi@lab.ntt.co.jp
EMail: toyama.masashi@lab.ntt.co.jp