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
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ノードは、セキュアな通信を実現するために実装しなければならないことを意味推奨することです。 IPsecののサポートは、SIGTRANプロトコルを実行しているすべてのノードには必須です。 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
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].
ISDN Q.921ユーザアダプテーション層（IUA）の場合のO顧客宅内およびサービスプロバイダーの機器[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
ISDN：総合デジタル通信網
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
PKI：公開鍵インフラストラクチャ
SA: Security Association
さ： せくりｔｙ あっそしあちおん
SCTP: Stream Control Transmission Protocol
SCTP：ストリーム制御伝送プロトコル
SS7: Signaling System No. 7
SS7：信号システム第7号
SUA: SS7 SCCP User Adaptation Layer
SUA：SS7 SCCPユーザ適合レイヤ
TLS: Transport Layer Security
TLS：トランスポート層セキュリティ
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].
キーワードは、REQUIREDは、、、、彼らは、この文書に表示されたときに、[1]で説明したように解釈されるべきである、MAY、推奨しません、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
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.
インターネットの脅威は、主に2つのタイプのいずれかに分けることができます。最初の1は「受動的攻撃」と呼ばれています。攻撃者がネットワークからパケットを読み取りますが、それらを書き込みませんいつでもそれは起こります。このような攻撃の例としては、守秘義務違反、パスワード盗聴およびとりわけオフライン暗号攻撃が含まれます。
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.
脅威の第二種は、「アクティブな攻撃」と呼ばれています。この場合、攻撃者は、ネットワークにデータを書き込みます。この攻撃の例としては、とりわけ、リプレイ攻撃、メッセージの挿入、メッセージの削除、メッセージの変更やman-in-the-middle攻撃が含まれます。
In general, Internet protocols have the following security objectives: o Communication Security:
通信セキュリティの：一般的に、インターネット・プロトコルは、次のセキュリティ+の目標を持っています：
* Authentication of peers
*ピアの認証
* Integrity of user data transport
*ユーザーデータ伝送の整合性
* Confidentiality of user data
*ユーザデータの機密性
* Replay protection
*リプレイ保護
o Non-repudiation
または否認防止
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.
このセクションでは、SIGTRANノード間の通信を保護するためにIPsecを使用して、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ノードはパケットごとの認証、完全性保護と機密性を提供するために、null以外の暗号化および認証アルゴリズムとトランスポートモードでは、[4]のIPsec ESPを実装しなければならない、とIPsecのリプレイ保護メカニズムを実装しなければなりません。 IP層の保護が必要とされるこれらのシナリオでは、トンネルモードでESPを使用すべきです。 null以外の暗号化は、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ノードは、IPsec DOIを使用して、ピア認証、セキュリティ協会の交渉、およびキー管理のためのIKEをサポートしなければならない[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の間、ID保護と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）を運ばなければなりません。 DOIは、識別データのいくつかのタイプを提供します。準拠実装で使用される場合しかし、各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の限られた数を扱うことができるかもしれないので、フェーズ2の削除メッセージを最小限にアクティブフェーズ2つのSAの数を維持する手段として、アイドル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はマルチホームホストをサポートしており、これは1つのSCTPアソシエーションのために複数のセキュリティアソシエーションを持つための必要性につながることに留意すべきです。 IPsecのこの欠点は、[17]によって対処されています。そうSIGTRANノードによって使用されるIPsec実装は、[17]に記載のIPSec機能をサポートしなければなりません。
This section is only relevant for SIGTRAN nodes using TLS to secure the communication between SIGTRAN nodes.
このセクションでは、SIGTRANノード間の通信を保護するためにTLSを使用して、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.
別のSIGTRANノードにSCTPアソシエーションを開始SIGTRANノードは、TLSサーバーとして接続作用を受け入れ、[2]、及びSIGTRANノードに従ってTLSクライアントとして動作します。セキュリティのためにTLSを実装するSIGTRANピアは、相互TLSセッション確立の一環として認証する必要があります。相互認証を確実にするために、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_WITH_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.
ASPは、TLSを使用するように設定されている場合は、O、それはストリーム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.
ピアがTLSをサポートしていない場合は、O、それはサポートされていないメッセージの種類を示すエラーメッセージを送り返します。この場合、SCTPアソシエーションを終了して、ピアがTLSをサポートしていない経営層に報告されます。
o If the peer does support TLS, it sends back a STARTTLS_ACK message. The client then starts TLS based communication.
ピアがTLSをサポートしていない場合は、O、それは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.
T_TLSは、上記の回答のいずれかを取得せずに失効した場合、O、関連付けが終了し、失敗は経営層に報告されます。
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メッセージは、1 STARTTLS_ACKメッセージは同じメッセージクラス10を使用してメッセージクラス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.
この手順を使用して、それはのman-in-the-middleピアがTLSをサポートしていないことを示すことにより、サービス拒否攻撃を行うには可能です。しかし、この種の攻撃はのman-in-the-middleために常に可能です。
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を選択した場合TLSベースのソリューションでは、SCTP制御情報が暗号化されていないとのみ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.
任意のピア・ツー・ピア・プロトコルと同様に、ピア内の信頼モデルの適切な設定は、セキュリティに不可欠です。証明書が使用されている場合は、ピアが信頼するトラストアンカーを設定する必要があります。これらのトラストアンカーは、Webブラウジングなど、他の目的のために、信頼されるかもしれない信頼アンカーからSIGTRANの使用状況にユニークかつ明瞭である可能性が高いです。一般的には、ピアや他の組織をホストする組織間のビジネス関係を反映するように、これらのトラストアンカーが設定されることが期待されます。結果として、ピアは、典型的には、任意のピアとの接続を可能にするように構成されることはありません。証明書認証ピアが事前に知られていない場合、ピア発見が必要とされ得ます。
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.
事前共有鍵認証がSIGTRANベースの通信を保護するためにIPSecを使用する場合、一意の事前共有キーは、それらのIPアドレス（メインモード）によって識別されたピア、又はおそらくそのFQDN（AggressivenMode）で構成されています。ピアの集合が予め既知であるため、結果として、それが必要です。したがって、ピア発見は、典型的には必要ではありません。
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.
「私から任意の宛先ポートPに、IPsecを開始」。インバウンドトラフィックのために、政策は「宛先ポートP、いずれかからの私には、IPsecを要求する」だろう。ここで、PはSIGTRANプロトコルの登録ポート番号の1つを示しています。
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.
このポリシーは、IPsecがSIGTRANピアが別のSIGTRANピアとのセッションを開始するたびに使用される、およびインバウンドSIGTRANセッションが発生するたびに必要とされるようにします。それはポリシーがピアごとに設定するか、動的に新しいSIGTRANセッションが作成されるたびに変更する必要がないので、このポリシーは、魅力的です。 IPsecのSAは、自動的に単純な静的ポリシーに基づいて作成されます。 IPsecの拡張は、典型的には、ほとんどのプラットフォーム上のソケット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.
この文書では、SIGTRANのトラフィックを保護するためのIPsecとTLSの使用方法について説明します。
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は、シグナリングユーザー適応レイヤの割り当てレジストリに予約されています。このメッセージクラスは、メッセージ・タイプ1がSTARTTLSメッセージ、及びSTARTTLS_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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[5] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[5]パイパー、D.、 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、RFC 2407、1998年11月。
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[6]ハーキンズ、D.とD.カレル、 "インターネットキー交換（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.、Ankney、R.、Malpani、A.、Galperin、S.とC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.およびV.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年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.、カラ、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.、ポーク、W.、フォード、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[11] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[11]石、J.、スチュワート、R.及びD.オーティス、 "ストリーム制御伝送プロトコル（SCTP）チェックサムの変更"、RFC 3309、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.ハイツ、 "シグナリングシステム7（SS7）メッセージ転送部2（MTP2） - ユーザ適合層"、RFC 3331、 2002年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.編、Morneault、K.、エド。 。とJ.牧師-Balbas、エド、 "シグナリングシステム7（SS7）メッセージ転送部3（MTP3） - ユーザ適合レイヤ（M3UA）"、RFC 3332、2002年9月。
[14] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[14] Jungmaier、A.、レスコラ、E.およびM. Tuexen、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。
[15] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work in Progress, February 2004.
[15]ジョージ、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.スチュワート、RFC 3554、2003年7月 "IPsecでストリーム制御伝送プロトコル（SCTP）の使用に"。
John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
ジョンLoughneyノキア・リサーチセンター私書箱407 FIN-00045 Nokiaのグループフィンランド
EMail: john.loughney@nokia.com
メールアドレス：john.loughney@nokia.com
Michael Tuexen (editor) Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
マイケルTuexen（編集者）大学。応用科学ミュンスターStegerwaldstrの。 39 48565シュタインフルトドイツ
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Javier Pastor-Balbas Ericsson Espana S.A. Via de los Poblados, 13 28033 Madrid Spain
ハビエル牧師-BalbasエリクソンエスパーニャS.A.社Poblados、13 28033マドリードスペイン経由
EMail: j.javier.pastor@ericsson.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。