Network Working Group J. Loughney
Request for Comments: 3788 Nokia Research Center
Category: Standards Track M. Tuexen, Ed.
Univ. of Applied Sciences Muenster
J. Pastor-Balbas
Ericsson Espana S.A.
June 2004
Network Working Group J. Loughney
Request for Comments: 3788 Nokia Research Center
Category: Standards Track M. Tuexen, Ed.
Univ. of Applied Sciences Muenster
J. Pastor-Balbas
Ericsson Espana S.A.
June 2004
Security Considerations for Signaling Transport (SIGTRAN) Protocols
信令传输（SIGTRAN）协议的安全注意事项
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional.
本文档讨论如何使用传输层安全性（TLS）和IPsec来保护SIGTRAN协议的通信安全。主要目标是推荐SIGTRAN节点必须实现的最低安全性手段，以实现安全通信。所有运行SIGTRAN协议的节点都必须支持IPsec。TLS支持是可选的。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . 3
2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security in Telephony Networks . . . . . . . . . . . . . . . . 4
4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 4
5. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Support of IPsec and TLS . . . . . . . . . . . . . . . . . . . 8
8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . 3
2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security in Telephony Networks . . . . . . . . . . . . . . . . 4
4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 4
5. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Support of IPsec and TLS . . . . . . . . . . . . . . . . . . . 8
8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
The SIGTRAN protocols are designed to carry signaling messages for telephony services. These protocols will be used between
SIGTRAN协议设计用于承载电话服务的信令消息。这些协议将在
o customer premise and service provider equipment in case of ISDN Q.921 User Adaptation Layer (IUA) [9].
o ISDN Q.921用户适配层（IUA）[9]情况下的客户场所和服务提供商设备。
o service provider equipment only. This is the case for SS7 MTP2 User Adaptation Layer (M2UA) [12], SS7 MTP2 Peer-to-Peer User Adaptation Layer (M2PA) [15], SS7 MTP3 User Adaptation Layer (M3UA) [13] and SS7 SCCP User Adaptation Layer (SUA) [16]. The carriers may be different and may use other transport network providers.
o 仅限服务提供商设备。SS7 MTP2用户适配层（M2UA）[12]、SS7 MTP2对等用户适配层（M2PA）[15]、SS7 MTP3用户适配层（M3UA）[13]和SS7 SCCP用户适配层（SUA）[16]就是这种情况。运营商可以是不同的，并且可以使用其他传输网络提供商。
The security requirements for these situations may be different.
这些情况下的安全要求可能不同。
SIGTRAN protocols involve the security needs of several parties, the end-users of the services, the service providers and the applications involved. Additional security requirements may come from local regulation. While having some overlapping security needs, any security solution should fulfill all of the different parties' needs.
SIGTRAN协议涉及多方、服务最终用户、服务提供商和相关应用程序的安全需求。其他安全要求可能来自当地法规。尽管存在一些重叠的安全需求，但任何安全解决方案都应该满足不同各方的所有需求。
The SIGTRAN protocols assume that messages are secured by using either IPsec or TLS.
SIGTRAN协议假定消息通过使用IPsec或TLS进行保护。
This document uses the following abbreviations:
本文件使用以下缩写：
ASP: Application Server Process
ASP：应用程序服务器进程
CA: Certification Authority
CA：证书颁发机构
DOI: Domain Of Interpretation
DOI：解释领域
ESP: Encapsulating Security Payload
ESP：封装安全有效负载
FQDN: Full-Qualified Domain Names
FQDN：完全限定域名
IPsec: IP Security Protocol
IPsec:IP安全协议
IKE: Internet Key Exchange Protocol
IKE：因特网密钥交换协议
ISDN: Integrated Services Digital Network
综合业务数字网
IUA: ISDN Q.921 User Adaptation Layer
IUA:ISDN Q.921用户适配层
M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer
M2PA:SS7 MTP2对等用户适配层
M2UA: SS7 MTP2 User Adaptation Layer
M2UA:SS7 MTP2用户适配层
M3UA: SS7 MTP3 User Adaptation Layer
M3UA:SS7 MTP3用户适配层
PKI: Public Key Infrastructure
公钥基础设施
SA: Security Association
SA：安全协会
SCTP: Stream Control Transmission Protocol
SCTP：流控制传输协议
SS7: Signaling System No. 7
七号信令系统
SUA: SS7 SCCP User Adaptation Layer
SUA:SS7-SCCP用户适配层
TLS: Transport Layer Security
传输层安全
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [1].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、不推荐、可和可选时，应按照[1]中所述进行解释。
The security in telephony networks is mainly based on the closed network principle. There are two main protocols used: Access protocols (ISDN and others) are used for signaling in the access network and the SS7 protocol stack in the core network.
电话网络的安全性主要基于封闭网络原理。使用的主要协议有两种：接入协议（ISDN和其他）用于接入网络中的信令，以及核心网络中的SS7协议栈。
As SS7 networks are often physically remote and/or inaccessible to the user, it is assumed that they are protected from malicious users. Equipment is often under lock and key. At network boundaries between SS7 networks, packet filtering is sometimes used. End-users are not directly connected to SS7 networks.
由于SS7网络通常在物理上是远程的和/或用户无法访问的，因此假定它们受到恶意用户的保护。设备经常处于锁定状态。在SS7网络之间的网络边界处，有时使用包过滤。最终用户不直接连接到SS7网络。
The access protocols are used for end-user signaling. End-user signaling protocols are translated to SS7 based protocols by telephone switches run by network operators.
接入协议用于最终用户信令。最终用户信令协议由网络运营商运行的电话交换机转换为基于SS7的协议。
Regulatory Authorities often require SS7 switches with connections to different SS7 switches to be conformant to national and/or international test specifications.
监管机构通常要求连接到不同SS7交换机的SS7交换机符合国家和/或国际测试规范。
There are no standardized ways of using encryption technologies for providing confidentiality or using technologies for authentication.
没有使用加密技术提供机密性或使用技术进行身份验证的标准化方法。
This description applies to telephony networks operated by a single operator, and also to multiple telephony networks being connected and operated by different operators.
本说明适用于由单个运营商运营的电话网络，也适用于由不同运营商连接和运营的多个电话网络。
The Internet threats can be divided into one of two main types. The first one is called "passive attacks". It happens whenever the attacker reads packets off the network but does not write them. Examples of such attacks include confidentiality violations, password sniffing and offline cryptographic attacks amongst others.
互联网威胁可分为两种主要类型之一。第一种被称为“被动攻击”。每当攻击者从网络上读取数据包但不写入数据包时，就会发生这种情况。此类攻击的示例包括违反保密性、密码嗅探和离线加密攻击等。
The second kind of threat is called "active attacks". In this case, the attacker also writes data to the network. Examples for this attack include replay attacks, message insertion, message deletion, message modification or man-in-the-middle attacks, amongst others.
第二种威胁称为“主动攻击”。在这种情况下，攻击者还会将数据写入网络。此攻击的示例包括重播攻击、消息插入、消息删除、消息修改或中间人攻击等。
In general, Internet protocols have the following security objectives:
通常，互联网协议具有以下安全目标：
o Communication Security:
o 通信安全：
* Authentication of peers
* 对等身份验证
* Integrity of user data transport
* 用户数据传输的完整性
* Confidentiality of user data
* 用户数据的保密性
* Replay protection
* 重放保护
o Non-repudiation
o 不可抵赖
o System Security, avoidance of:
o 系统安全，避免：
* Unauthorized use
* 未经授权的使用
* Inappropriate use
* 不当使用
* Denial of Service
* 拒绝服务
Communication security is mandatory in some network scenarios to prevent malicious attacks. The main goal of this document is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. To achieve this goal, we will explore the different existing security options regarding communication.
在某些网络场景中，通信安全是必需的，以防止恶意攻击。本文档的主要目标是推荐SIGTRAN节点必须实现的最低安全性手段，以实现安全通信。为了实现这一目标，我们将探索与通信相关的各种现有安全选项。
All SIGTRAN protocols use the Stream Control Transmission Protocol (SCTP) defined in [8] and [11] as its transport protocol. SCTP provides certain transport related security features, such as resistance against:
所有SIGTRAN协议都使用[8]和[11]中定义的流控制传输协议（SCTP）作为其传输协议。SCTP提供了某些与传输相关的安全功能，如抗：
o Blind Denial of Service Attacks such as:
o 盲目拒绝服务攻击，例如：
* Flooding.
* 泛滥的。
* Masquerade.
* 掩藏
* Improper Monopolization of Services.
* 不正当的服务垄断。
There is no quick fix, one-size-fits-all solution for security.
没有快速修复、一刀切的安全解决方案。
When a network using SIGTRAN protocols involves more than one party, it may not be reasonable to expect that all parties have implemented security in a sufficient manner. End-to-end security should be the goal; therefore, it is recommended that IPsec or TLS be used to ensure confidentiality of user payload. Consult [3] for more information on configuring IPsec services.
当使用SIGTRAN协议的网络涉及多个参与方时，期望所有参与方以充分的方式实现安全性可能是不合理的。端到端安全应该是目标；因此，建议使用IPsec或TLS来确保用户负载的机密性。有关配置IPsec服务的更多信息，请参阅[3]。
This section is only relevant for SIGTRAN nodes using IPsec to secure communication between SIGTRAN nodes.
本节仅适用于使用IPsec保护SIGTRAN节点之间通信安全的SIGTRAN节点。
All SIGTRAN nodes using IPsec MUST implement IPsec ESP [4] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST implement the replay protection mechanisms of IPsec. In those scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. Non-null encryption should be used when using IPSec ESP.
使用IPsec的所有SIGTRAN节点必须在传输模式下使用非空加密和身份验证算法实现IPsec ESP[4]，以提供每包身份验证、完整性保护和机密性，并且必须实现IPsec的重播保护机制。在需要IP层保护的情况下，应使用隧道模式的ESP。使用IPSec ESP时应使用非空加密。
All SIGTRAN nodes MUST support IKE for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [5]. The IPsec implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [6] SHOULD NOT be used.
所有SIGTRAN节点必须支持IKE，以便使用IPsec DOI进行对等身份验证、安全关联协商和密钥管理[5]。IPsec实现必须支持使用预共享密钥的对等身份验证，并且可以支持使用数字签名的基于证书的对等身份验证。不应使用IKE第5.2节和第5.3节[6]中概述的使用公钥加密方法的对等身份验证。
Conformant implementations MUST support IKEs Main Mode and Aggressive Mode. For transport mode, when pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. When using ESP tunnel mode, IKE Main Mode MAY be used to create an ISAKMP association with identity protection during Phase 1.
一致性实现必须支持IKEs主模式和主动模式。对于传输模式，当使用预共享密钥进行身份验证时，应使用IKE主动模式，而不应使用IKE主模式。当数字签名用于身份验证时，可以使用IKE主模式或IKE攻击模式。当使用ESP隧道模式时，IKE主模式可用于在阶段1期间创建与身份保护的ISAKMP关联。
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certification authority (or authorities) that is trusted in accordance with its local policy. IKE negotiators SHOULD use pertinent certificate revocation checks before accepting a PKI certificate for use in IKE's authentication procedures. See [10] for certificate revocation and [7] for online-checking.
当使用数字签名实现身份验证时，IKE谈判者应使用IKE证书请求有效载荷来指定根据其本地策略受信任的证书颁发机构。IKE谈判者在接受用于IKE认证过程的PKI证书之前，应使用相关的证书撤销检查。证书撤销请参见[10]，在线检查请参见[7]。
The Phase 2 Quick Mode exchanges used to negotiate protection for SIGTRAN sessions MUST explicitly carry the Identity Payload fields (IDci and IDcr). The DOI provides for several types of identification data. However, when used in conformant implementations, each ID Payload MUST carry a single IP address and a single non-zero port number, and MUST NOT use the IP Subnet or IP Address Range formats. This allows the Phase 2 security association to correspond to specific TCP and SCTP connections.
用于协商SIGTRAN会话保护的第2阶段快速模式交换必须明确携带标识有效负载字段（IDci和IDcr）。内政部提供了几种类型的识别数据。但是，在一致性实现中使用时，每个ID有效负载必须携带一个IP地址和一个非零端口号，并且不得使用IP子网或IP地址范围格式。这允许阶段2安全关联对应于特定的TCP和SCTP连接。
Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down a SIGTRAN session. Rather, it is preferable to leave the connection up, whereby another IKE Phase 2 SA will be brought up to protect it if additional traffic is sent. This avoids the potential of continually bringing connections up and down.
由于IPsec加速硬件可能只能处理有限数量的活动IKE阶段2 SA，因此可以为空闲SA发送阶段2删除消息，以将活动阶段2 SA的数量保持在最小。收到IKE第2阶段删除消息不应被解释为中断SIGTRAN会话的原因。相反，最好保持连接处于打开状态，这样，如果发送了额外的通信量，将启动另一个IKE阶段2 SA来保护它。这避免了不断地使连接上下移动的可能性。
It should be noted that SCTP supports multi-homed hosts and this results in the need for having multiple security associations for one SCTP association. This disadvantage of IPsec has been addressed by [17]. So IPsec implementations used by SIGTRAN nodes SHOULD support the IPsec feature described in [17].
应该注意的是，SCTP支持多宿主主机，这导致一个SCTP关联需要有多个安全关联。[17]已经解决了IPsec的这一缺点。因此，SIGTRAN节点使用的IPsec实现应该支持[17]中描述的IPsec功能。
This section is only relevant for SIGTRAN nodes using TLS to secure the communication between SIGTRAN nodes.
本节仅适用于使用TLS保护SIGTRAN节点之间通信的SIGTRAN节点。
A SIGTRAN node that initiates a SCTP association to another SIGTRAN node acts as a TLS client according to [2], and a SIGTRAN node that accepts a connection acts as a TLS server. SIGTRAN peers implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, the SIGTRAN node acting as TLS server must request a certificate from the SIGTRAN node acting as TLS client, and the SIGTRAN node acting as TLS client MUST be prepared to supply a certificate on request.
根据[2]，启动与另一个SIGTRAN节点的SCTP关联的SIGTRAN节点充当TLS客户端，接受连接的SIGTRAN节点充当TLS服务器。作为TLS会话建立的一部分，实现TLS安全性的SIGTRAN对等方必须相互验证。为了确保相互身份验证，作为TLS服务器的SIGTRAN节点必须从作为TLS客户端的SIGTRAN节点请求证书，并且作为TLS客户端的SIGTRAN节点必须准备好根据请求提供证书。
[14] requires the support of the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. SIGTRAN nodes MAY negotiate other TLS cipher suites.
[14] 需要密码套件TLS_RSA_和_AES_128_CBC_SHA的支持。SIGTRAN节点可以协商其他TLS密码套件。
TLS MUST be used on all bi-directional streams. Other uni-directional streams MUST NOT be used.
TLS必须用于所有双向流。不得使用其他单向流。
It should also be noted that a SCTP implementation used for TLS over SCTP MUST support fragmentation of user data and might also need to support the partial delivery API. This holds even if all SIGTRAN messages are small. Furthermore, the 'unordered delivery' feature of SCTP can not be used in conjunction with TLS. See [14] for more details.
还应注意，用于通过SCTP的TLS的SCTP实现必须支持用户数据的分段，并且可能还需要支持部分交付API。即使所有的SIGTRAN消息都很小，这仍然有效。此外，SCTP的“无序交付”功能不能与TLS结合使用。有关更多详细信息，请参见[14]。
Because TLS only protects the payload, the SCTP header and all control chunks are not protected. This can be used for DoS attacks. This is a general problem with security provided at the transport layer.
由于TLS仅保护有效负载，因此SCTP头和所有控制块不受保护。这可用于DoS攻击。这是传输层提供的安全性的一般问题。
The SIGTRAN protocols use the same SCTP port number and payload protocol identifier when run over TLS. A session upgrade procedure has to be used to initiate the TLS based communication.
在TLS上运行时，SIGTRAN协议使用相同的SCTP端口号和有效负载协议标识符。必须使用会话升级过程来启动基于TLS的通信。
The session upgrade procedure should be as follows:
会话升级过程应如下所示：
o If an ASP has been configured to use TLS, it sends a STARTTLS message on stream 0 and starts a timer T_TLS. This is the first message sent and the ASP sends no other adaptation layer messages until the TLS based communication has been established.
o 如果ASP已配置为使用TLS，它将在流0上发送STARTTLS消息并启动计时器T_TLS。这是发送的第一条消息，在建立基于TLS的通信之前，ASP不会发送其他适配层消息。
o If the peer does not support TLS, it sends back an ERROR message indicating an unsupported message type. In this case, the SCTP association is terminated and it is reported to the management layer that the peer does not support TLS.
o 如果对等方不支持TLS，它会发回一条错误消息，指示不支持的消息类型。在这种情况下，SCTP关联被终止，并向管理层报告对等方不支持TLS。
o If the peer does support TLS, it sends back a STARTTLS_ACK message. The client then starts TLS based communication.
o 如果对等方确实支持TLS，它将发回STARTTLS_ACK消息。然后，客户端启动基于TLS的通信。
o If T_TLS expires without getting any of the above answers, the association is terminated and the failure is reported to the management layer.
o 如果T_TLS过期而未获得上述任何答案，则关联将终止，并将失败报告给管理层。
All SIGTRAN adaptation layers share a common message format. The STARTTLS message consists of a common header only using the message class 10 and message type 1. The STARTTLS_ACK message uses the same message class 10 and the message type 2. Neither messages contain any parameters.
所有SIGTRAN适配层共享一种通用消息格式。STARTTLS消息由一个仅使用消息类10和消息类型1的公共头组成。STARTTLS_ACK消息使用相同的消息类别10和消息类型2。这两条消息都不包含任何参数。
Using this procedure, it is possible for a man-in-the-middle to do a denial of service attack by indicating that the peer does not support TLS. But this kind of attack is always possible for a man-in-the-middle.
使用此过程，中间人可以通过指示对等方不支持TLS来进行拒绝服务攻击。但是这种攻击对于中间人来说总是可能的。
If content of SIGTRAN protocol messages is to be protected, either IPsec ESP or TLS can be used. In both IPsec ESP Transport Mode and TLS cases, the IP header information is neither encrypted nor protected. If IPsec ESP is chosen, the SCTP control information is encrypted and protected whereas in the TLS based solution, the SCTP control information is not encrypted and only protected by SCTP procedures.
如果要保护SIGTRAN协议消息的内容，可以使用IPsec ESP或TLS。在IPsec ESP传输模式和TLS情况下，IP头信息既不加密也不受保护。如果选择IPsec ESP，则SCTP控制信息将被加密和保护，而在基于TLS的解决方案中，SCTP控制信息不加密，仅由SCTP过程保护。
In general, both IPsec and TLS have enough mechanisms to secure the SIGTRAN communications.
通常，IPsec和TLS都有足够的机制来保护SIGTRAN通信。
Therefore, in order to have a secured model working as soon as possible, the following recommendation is made: A SIGTRAN node MUST support IPsec and MAY support TLS.
因此，为了使安全模型尽快工作，建议如下：SIGTRAN节点必须支持IPsec，并且可能支持TLS。
M2PA, M3UA and SUA support the peer-to-peer model as a generalization to the client-server model which is supported by IUA and M2UA. A SIGTRAN node running M2PA, M3UA or SUA and operating in the peer-to-peer mode is called a SIGTRAN peer.
M2PA、M3UA和SUA支持对等模型，作为IUA和M2UA支持的客户机-服务器模型的推广。运行M2PA、M3UA或SUA并在对等模式下运行的SIGTRAN节点称为SIGTRAN对等节点。
As with any peer-to-peer protocol, proper configuration of the trust model within a peer is essential to security. When certificates are used, it is necessary to configure the trust anchors trusted by the peer. These trust anchors are likely to be unique to SIGTRAN usage and distinct from the trust anchors that might be trusted for other purposes such as Web browsing. In general, it is expected that those trust anchors will be configured so as to reflect the business relationships between the organization hosting the peer and other organizations. As a result, a peer will not typically be configured to allow connectivity with any arbitrary peer. When certificate authentication peers may not be known beforehand, peer discovery may be required.
与任何对等协议一样，对等协议中信任模型的正确配置对于安全性至关重要。使用证书时，需要配置对等方信任的信任锚。这些信任锚可能是SIGTRAN使用中唯一的，不同于其他用途（如Web浏览）中可能信任的信任锚。一般来说，这些信任锚将被配置为反映托管对等方的组织与其他组织之间的业务关系。因此，通常不会将对等点配置为允许与任意对等点进行连接。当证书认证对等点可能事先未知时，可能需要对等点发现。
Note that IPsec is considerably less flexible than TLS when it comes to configuring trust anchors. Since use of Port identifiers is prohibited within IKE Phase 1, it is not possible to uniquely configure trusted trust anchors for each application individually within IPsec; the same policy must be used for all applications. This implies, for example, that a trust anchor trusted for use with a SIGTRAN protocol must also be trusted to protect other protocols (for example SNMP). These restrictions are awkward at best.
请注意，在配置信任锚时，IPsec的灵活性远远低于TLS。由于在IKE阶段1内禁止使用端口标识符，因此不可能在IPsec内单独为每个应用程序唯一地配置可信信任锚；所有应用程序都必须使用相同的策略。这意味着，例如，受信任用于SIGTRAN协议的信任锚也必须受信任以保护其他协议（例如SNMP）。这些限制充其量也很尴尬。
When pre-shared key authentication is used with IPsec to protect SIGTRAN based communication, unique pre-shared keys are configured with peers that are identified by their IP address (Main Mode), or possibly their FQDN (AggressivenMode). As a result, it is necessary for the set of peers to be known beforehand. Therefore, peer discovery is typically not necessary.
当预共享密钥身份验证与IPsec一起使用以保护基于SIGTRAN的通信时，唯一的预共享密钥将与通过其IP地址（主模式）或FQDN（攻击模式）标识的对等方一起配置。因此，必须事先知道对等点集。因此，通常不需要对等发现。
The following is intended to provide some guidance on the issue.
以下内容旨在就这一问题提供一些指导。
It is recommended that SIGTRAN peers use the same security mechanism (IPsec or TLS) across all its sessions with other SIGTRAN peers. Inconsistent use of security mechanisms can result in redundant security mechanisms being used (e.g., TLS over IPsec) or worse, potential security vulnerabilities. When IPsec is used with a SIGTRAN protocol, a typical security policy for outbound traffic is
建议SIGTRAN对等方在其与其他SIGTRAN对等方的所有会话中使用相同的安全机制（IPsec或TLS）。不一致地使用安全机制可能导致使用冗余安全机制（例如，IPsec上的TLS）或更糟糕的潜在安全漏洞。当IPsec与SIGTRAN协议一起使用时，出站流量的典型安全策略是
"Initiate IPsec, from me to any, destination port P"; for inbound traffic, the policy would be "Require IPsec, from any to me, destination port P". Here, P denotes one of the registered port numbers for a SIGTRAN protocol.
“启动IPsec，从me到任意目标端口P”；对于入站流量，策略将是“需要IPsec，从任意到me，目标端口P”。这里，P表示SIGTRAN协议的一个注册端口号。
This policy causes IPsec to be used whenever a SIGTRAN peer initiates a session to another SIGTRAN peer, and to be required whenever an inbound SIGTRAN session occurs. This policy is attractive, since it does not require policy to be set for each peer or dynamically modified each time a new SIGTRAN session is created; an IPsec SA is automatically created based on a simple static policy. Since IPsec extensions are typically not available to the sockets API on most platforms, and IPsec policy functionality is implementation dependent, use of a simple static policy is the often the simplest route to IPsec-enabling a SIGTRAN peer.
此策略导致每当SIGTRAN对等方向另一个SIGTRAN对等方发起会话时使用IPsec，并且每当发生入站SIGTRAN会话时都需要IPsec。此策略很有吸引力，因为它不需要为每个对等方设置策略，也不需要在每次创建新的SIGTRAN会话时动态修改策略；IPsec SA是基于简单的静态策略自动创建的。由于IPsec扩展通常不适用于大多数平台上的sockets API，并且IPsec策略功能依赖于实现，因此使用简单的静态策略通常是到IPsec的最简单的路由，从而启用SIGTRAN对等点。
If IPsec is used to secure a SIGTRAN peer-to-peer session, IPsec policy SHOULD be set so as to require IPsec protection for inbound connections, and to initiate IPsec protection for outbound connections. This can be accomplished via use of inbound and outbound filter policy.
如果IPsec用于保护SIGTRAN对等会话，则应设置IPsec策略，以便对入站连接要求IPsec保护，并对出站连接启动IPsec保护。这可以通过使用入站和出站筛选器策略来实现。
This document discusses the usage of IPsec and TLS for securing SIGTRAN traffic.
本文档讨论了IPsec和TLS用于保护SIGTRAN流量的用法。
The message class 12 has been reserved in the Signaling User Adaption Layer Assignments Registry. For this message class, message type 1 has been reserved for the STARTTLS message, and message type 2 for the STARTTLS_ACK message.
消息类12已保留在信令用户自适应层分配注册表中。对于此消息类，已为STARTTLS消息保留消息类型1，为STARTTLS\u ACK消息保留消息类型2。
The authors would like to thank B. Aboba, K. Morneault and many others for their invaluable comments and suggestions.
作者要感谢B.Aboba、K.Morneault和许多其他人的宝贵意见和建议。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[5] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[5] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[6] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[7] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[7] 迈尔斯，M.，安克尼，R.，马尔帕尼，A.，加尔佩林，S.和C.亚当斯，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC2560，1999年6月。
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[8] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[9] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
[9] Morneault，K.，Rengasami，S.，Kalla，M.和G.Sidebottom，“ISDN Q.921-用户适配层”，RFC 3057，2001年2月。
[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[10] Housley，R.，Polk，W.，Ford，W.和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[11] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[11] Stone，J.，Stewart，R.和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC3309，2002年9月。
[12] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", RFC 3331, September 2002.
[12] Morneault，K.，Dantu，R.，Sidebottom，G.，Bidulock，B.和J.Heitz，“信令系统7（SS7）消息传输第2部分（MTP2）-用户适配层”，RFC 33312002年9月。
[13] Sidebottom, G., Ed., Morneault, K., Ed. and J. Pastor-Balbas, Ed., "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 3332, September 2002.
[13] Sidebottom，G.，Ed.，Morneault，K.，Ed.和J.Pastor Balbas，Ed.，“信令系统7（SS7）消息传输第3部分（MTP3）-用户适配层（M3UA）”，RFC 33322002年9月。
[14] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[14] Jungmaier，A.，Rescorla，E.和M.Tuexen，“流控制传输协议上的传输层安全”，RFC 3436，2002年12月。
[15] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work in Progress, February 2004.
[15] George，T.，“SS7 MTP2用户点对点适应层”，正在进行的工作，2004年2月。
[16] Loughney, J., "Signalling Connection Control Part User Adaptation Layer (SUA)", Work in Progress, December 2003.
[16] Loughney，J.，“信令连接控制部分用户适配层（SUA）”，正在进行的工作，2003年12月。
[17] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[17] Bellovin，S.，Ioannidis，J.，Keromytis，A.和R.Stewart，“关于流控制传输协议（SCTP）与IPsec的使用”，RFC 3554，2003年7月。
John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
John Loughney诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: john.loughney@nokia.com
EMail: john.loughney@nokia.com
Michael Tuexen (editor) Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
Michael Tuexen（编辑）应用科学大学Muenster Stegerwaldstr。39 48565德国斯坦福德
EMail: tuexen@fh-muenster.de
EMail: tuexen@fh-muenster.de
Javier Pastor-Balbas Ericsson Espana S.A. Via de los Poblados, 13 28033 Madrid Spain
西班牙马德里13 28033号，西班牙埃斯帕萨纳大道哈维尔·帕斯托尔·巴尔巴斯·爱立信酒店
EMail: j.javier.pastor@ericsson.com
EMail: j.javier.pastor@ericsson.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
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 ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。