[要約] RFC 3788は、SIGTRANプロトコルのセキュリティに関する考慮事項をまとめたものです。その目的は、SIGTRANプロトコルの実装者や運用者に対して、セキュリティ上のリスクや対策についての情報を提供することです。
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）The Internet Society（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].
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
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
SA：セキュリティ協会
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].
キーワードは、このドキュメントに登場する場合、[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.
テレフォニーネットワークのセキュリティは、主にクローズドネットワークの原則に基づいています。使用される主なプロトコルは2つあります。アクセスプロトコル（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つの主要なタイプのいずれかに分けることができます。最初のものは「パッシブ攻撃」と呼ばれます。攻撃者がネットワークからパケットを読み取るが、それらを書き込まないときはいつでも起こります。このような攻撃の例には、機密保持違反、パスワードのスニッフィング、および他の人などのオフラインの暗号攻撃が含まれます。
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.
2番目の脅威は「アクティブ攻撃」と呼ばれます。この場合、攻撃者はネットワークにデータを書き込みます。この攻撃の例には、リプレイ攻撃、メッセージ挿入、メッセージの削除、メッセージの変更、または中間の攻撃などがあります。
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 非繰り返し
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ノードは、IPEEC DOI [5]を使用して、ピア認証、セキュリティ協会の交渉、および主要な管理のためにIKEをサポートする必要があります。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.
コンフォーマントの実装は、メインモードとアグレッシブモードをサポートする必要があります。トランスポートモードの場合、非共有キーを認証に使用する場合、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.
シグトランセッションの保護を交渉するために使用されるフェーズ2クイックモード交換は、IDペイロードフィールド（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 SASのみを処理できる可能性があるため、アクティブフェーズ2 SASの数を最小限に抑える手段として、フェーズ2の削除メッセージをアイドルSASに送信できます。IKE Phase 2削除メッセージの受領は、Sigtranセッションを削除する理由として解釈されるべきではありません。むしろ、追加のトラフィックが送信された場合、接続を維持することが望ましいです。これにより、接続を継続的に上下させる可能性が回避されます。
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.
このセクションは、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.
SCTPアソシエーションを別のSigtranノードに開始するSigtranノードは、[2]に従ってTLSクライアントとして機能し、接続を受け入れるSigtranノードはTLSサーバーとして機能します。セキュリティのためにTLSを実装するシグトランピアは、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] Cipher Suite 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をサポートする必要がある場合があることにも注意する必要があります。これは、すべてのシグトランメッセージが小さい場合でも保持されます。さらに、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.
Sigtranプロトコルは、TLSを介して実行すると同じ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を起動します。これは最初のメッセージであり、ASPはTLSベースの通信が確立されるまで他の適応レイヤーメッセージを送信しません。
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とTLの両方に、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を実行し、ピアツーピアモードで動作するシグトランノードは、シグトランピアと呼ばれます。
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ブラウジングなどの他の目的で信頼できる信頼アンカーとは異なる可能性があります。一般に、これらのトラストアンカーは、ピアをホストする組織と他の組織間のビジネス関係を反映するように構成されることが期待されています。その結果、ピアは通常、任意のピアとの接続を可能にするように構成されません。証明書認証のピアが事前に知られていない場合は、ピアディスカバリーが必要になる場合があります。
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よりもTLSよりも柔軟性が低いことに注意してください。IKEフェーズ1内ではポート識別子の使用は禁止されているため、IPSEC内で個別に各アプリケーションの信頼できる信頼できるアンカーを一意に構成することはできません。同じポリシーをすべてのアプリケーションに使用する必要があります。これは、たとえば、シグトランプロトコルで使用するために信頼される信頼のアンカーも、他のプロトコル（たとえば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で事前に共有キー認証を使用すると、一意の事前共有キーは、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
シグトランのピアは、他のシグトランピアとのすべてのセッションで同じセキュリティメカニズム（IPSECまたはTLS）を使用することをお勧めします。セキュリティメカニズムの一貫性のない使用により、冗長なセキュリティメカニズムが使用されている可能性があります（たとえば、IPSECを超えるTL）またはさらに悪いことに、潜在的なセキュリティの脆弱性が得られます。IPSECがシグトランプロトコルで使用される場合、アウトバウンドトラフィックの典型的なセキュリティポリシーは
"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を開始」。インバウンドトラフィックの場合、ポリシーは「IPSECを必要とします。私から宛先ポートP」。ここで、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が使用され、インバウンドシグトランセッションが発生するたびに必要になります。このポリシーは、新しいシグトランセッションが作成されるたびに、ピアごとにポリシーを設定するか、動的に変更する必要がないため、魅力的です。IPSEC SAは、単純な静的ポリシーに基づいて自動的に作成されます。IPSEC拡張機能は通常、ほとんどのプラットフォームでSockets APIで使用できないため、IPSECポリシー機能は実装に依存しているため、単純な静的ポリシーの使用は、多くの場合、シグトランピアを有効にするIPSECの最も単純なルートです。
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がシグトランピアツーピアセッションを確保するために使用される場合、IPSECポリシーを設定して、インバウンド接続にIPSEC保護を要求し、アウトバウンド接続のIPSEC保護を開始する必要があります。これは、インバウンドおよびアウトバウンドフィルターポリシーを使用することで実現できます。
This document discusses the usage of IPsec and TLS for securing SIGTRAN traffic.
このドキュメントでは、シグトラントラフィックを保護するための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] 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、「The Internet Key Exchange（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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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] 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、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.、Kalla、M。、およびG. Sidebottom、「Isdn Q.921-User適応層」、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。and D. Solo、「インターネット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] Stone、J.、Stewart、R。and D. Otis、「Stream Control Transmission Protocol（SCTP）Checksum Change」、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。and J. Heitz、「Signaling System 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.、ed。、Morneault、K.、ed。and J. Pastor -Balbas、ed。、「Signaling System 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.、Rescorla、E。and 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-USER PEER-to-Peer適応レイヤー」、2004年2月、Work in Progress。
[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。and R. Stewart、「IPSECを使用したストリーム制御伝送プロトコル（SCTP）の使用」、RFC 3554、2003年7月。
John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
ジョン・ラフニー・ノキア・リサーチ・センター私書箱407フィン-00045ノキア・グループフィンランド
EMail: john.loughney@nokia.com
Michael Tuexen (editor) Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
Michael Tuexen（編集者）大学。Applied Sciences MuensterStegerwaldStraßeの。39 48565 Steinfurtドイツ
EMail: tuexen@fh-muenster.de
Javier Pastor-Balbas Ericsson Espana S.A. Via de los Poblados, 13 28033 Madrid Spain
Javier Pastor-Balbas Ericsson Espana S.A. De Los Poblados、13 28033 Madrid Spain
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。