RFC3788 日本語訳
3788 Security Considerations for Signaling Transport (SIGTRAN)Protocols. J. Loughney, M. Tuexen, Ed., J. Pastor-Balbas. June 2004. (Format: TXT=27125 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Loughneyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3788年のノキアリサーチセンターカテゴリ: 規格はエリクソンエスパニアS.A.2004年6月にエドM.Tuexen、応用科学Muenster J.牧師-Balbasの大学を追跡します。
Security Considerations for
Signaling Transport (SIGTRAN) Protocols
シグナリング輸送(SIGTRAN)プロトコルのためのセキュリティ問題
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはSIGTRANプロトコルのためのコミュニケーションを保証するのにどうTransport Layer Security(TLS)とIPsecを使用できるかについて議論します。 第一目的は、SIGTRANノードが達するように実装しなければならない最小のセキュリティ手段がコミュニケーションを保証したことを勧めることになっています。 IPsecのサポートはSIGTRANプロトコルを実行するすべてのノードに義務的です。 TLSサポートは任意です。
Loughney, et al. Standards Track [Page 1] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[1ページ]。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 概要. . . . . . . . . . . . . . . . . . . . . . . . 2 1.2。 略語. . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 電話のセキュリティは.4 4をネットワークでつなぎます。 脅威と目標. . . . . . . . . . . . . . . . . . . . . . 4 5。 IPsec用法. . . . . . . . . . . . . . . . . . . . . . . . . 6 6。 TLS用法. . . . . . . . . . . . . . . . . . . . . . . . . . 7 7。 IPsecとTLS. . . . . . . . . . . . . . . . . . . 8 8のサポート。 ピアツーピア問題. . . . . . . . . . . . . . . . . 9 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 10。 IANA問題. . . . . . . . . . . . . . . . . . . . . 10 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1。 引用規格. . . . . . . . . . . . . . . . . . 11 12.2。 有益な参照. . . . . . . . . . . . . . . . . 11 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 12 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
1.1. Overview
1.1. 概要
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 User Adaptation Layer(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 User Adaptation Layer(M2UA)[12]のためのそうです、SS7 MTP2 Peerから同輩へのUser Adaptation Layer(M2PA)[15]、SS7 MTP3 User Adaptation Layer(M3UA)[13]とSS7 SCCP User Adaptation Layer(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のどちらかを使用することによって保証されると仮定します。
Loughney, et al. Standards Track [Page 2] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[2ページ]。
1.2. Abbreviations
1.2. 略語
This document uses the following abbreviations:
このドキュメントは以下の略語を使用します:
ASP: Application Server Process
ASP: アプリケーション・サーバープロセス
CA: Certification Authority
カリフォルニア: 認証局
DOI: Domain Of Interpretation
土井: 解釈のドメイン
ESP: Encapsulating Security Payload
超能力: セキュリティが有効搭載量であるとカプセル化します。
FQDN: Full-Qualified Domain Names
FQDN: 完全に適切なドメイン名
IPsec: IP Security Protocol
IPsec: IPセキュリティー・プロトコル
IKE: Internet Key Exchange Protocol
イケ: インターネット・キー・エクスチェンジプロトコル
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: シグナリングシステムNo.7
SUA: SS7 SCCP User Adaptation Layer
SUA: SS7 SCCPユーザ適合層
TLS: Transport Layer Security
TLS: トランスポート層セキュリティ
2. Convention
2. コンベンション
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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Loughney, et al. Standards Track [Page 3] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[3ページ]。
3. Security in Telephony Networks
3. 電話ネットワークにおけるセキュリティ
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.
規定のAuthoritiesは、しばしば異なったSS7スイッチとの接続があるSS7スイッチが国家的である、そして/または、国際的な試験仕様書へのconformantであることを必要とします。
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.
この記述は単独のオペレータによって経営された電話ネットワークと、そして、異なったオペレータによって接続されて、経営される複数の電話ネットワークにも適用されます。
4. Threats and Goals
4. 脅威と目標
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:
一般に、インターネットプロトコルには、以下のセキュリティ目的があります:
Loughney, et al. Standards Track [Page 4] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[4ページ]。
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 システムSecurity、以下の回避
* 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]でトランスポート・プロトコルと定義されたStream Control Transmissionプロトコル(SCTP)を使用します。 SCTPは以下に対する抵抗などの関連するセキュリティ機能をある輸送に提供します。
o Blind Denial of Service Attacks such as:
o 以下などのサービス妨害Attacksの目をくらましてください。
* 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プロトコルを使用するネットワークが1回以上のパーティーにかかわるとき、すべてのパーティーが十分な方法におけるセキュリティを実装したと予想するのは妥当でないかもしれません。 終わりから終わりへのセキュリティは目標であるべきです。 したがって、IPsecかTLSがユーザペイロードの秘密性を確実にするのに使用されるのは、お勧めです。 IPsecサービスを構成する詳しい情報のための[3]に相談してください。
Loughney, et al. Standards Track [Page 5] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[5ページ]。
5. IPsec Usage
5. IPsec用法
This section is only relevant for SIGTRAN nodes using IPsec to secure communication between SIGTRAN nodes.
SIGTRANノードだけにおいて、このセクションは、SIGTRANノードのコミュニケーションを保証するのにIPsecを使用することで関連しています。
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ノードが、交通機関における非ヌル暗号化がある超能力[4]をIPsecに実装して、1パケットあたりの認証、保全保護、および秘密性を提供する認証アルゴリズムに実装しなければならなくて、反復操作による保護がIPsecのメカニズムであると実装しなければなりません。 IP層の保護が必要であり、トンネルモードにおける超能力がSHOULDであるそれらのシナリオでは、使用されてください。 IPSecを使用するとき、非ヌル暗号化は使用されるべきです。超能力。
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実装は、あらかじめ共有されたキーを使用するのを同輩認証にサポートして、デジタル署名を使用するベースの同輩認証を5月のサポート証明書にサポートしなければなりません。 公開鍵暗号化メソッドを使用する同輩認証がIKEのセクション5.2と5.3で[6] SHOULD NOTについて概説しました。使用されます。
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.
Conformant実装はIKEs Main ModeとAggressive Modeをサポートしなければなりません。 中古、そして、IKE Main Mode SHOULD NOTになってください。あらかじめ共有されると、交通機関において、キーは認証に使用されます、IKE Aggressive Mode SHOULD、使用されます。 デジタル署名が認証に使用されるとき、IKE Main ModeかIKE Aggressive Modeのどちらかが使用されるかもしれません。 超能力トンネルモードを使用するとき、IKE Main Modeは、Phase1の間、アイデンティティ保護との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交渉者SHOULDは、ローカルの方針によると、信じられる証明権威(または、当局)を指定するのにIKE Certificate Request有効搭載量を使用します。 PKI証明書を受け入れる前に、IKE交渉者SHOULDはIKEの認証手順における使用に適切な証明書取消しチェックを使用します。 証明書取消しのための[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セッションのために保護を交渉するのに使用されるPhase2クィックMode交換は明らかに、Identity有効搭載量野原(IDciとIDcr)を運ばなければなりません。 DOIはいくつかのタイプに関する識別情報に備えます。 しかしながら、conformant実装に使用されると、それぞれのID有効搭載量は、ただ一つのIPアドレスとただ一つの非ゼロポートナンバーを運ばなければならなくて、SubnetかIP Address RangeがフォーマットするIPを使用してはいけません。 これは特定のTCPとSCTP接続に相当するPhase2セキュリティ協会を許容します。
Loughney, et al. Standards Track [Page 6] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[6ページ]。
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加速ハードウェアが2SAs、Phase2が削除するアクティブなIKE Phaseの限られた数を扱うことができるだけであるかもしれないので、aが意味するように使用されていないSAsのためにアクティブなPhase2SAsの数を最小限に保つのについてメッセージを送るかもしれません。 IKE Phase2の領収書はメッセージSHOULD NOTを削除します。SIGTRANセッションを取りこわす理由として、解釈されます。 むしろ、接続を掲げるのが望ましい、どうして、追加トラフィックであるならそれを保護するために別のIKE Phase2SAを持って来させるでしょうか。 これは絶えず上下に接続を連れて来る可能性を避けます。
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協会において複数のセキュリティ協会を持つ必要性をもたらします。 IPsecのこの難点は[17]によって扱われました。 それで、SIGTRANノードSHOULDによって使用されたIPsec実装は[17]で説明されたIPsecの特徴をサポートします。
6. TLS Usage
6. TLS用法
This section is only relevant for SIGTRAN nodes using TLS to secure the communication between SIGTRAN nodes.
SIGTRANノードだけにおいて、このセクションは、SIGTRANノードのコミュニケーションを保証するのにTLSを使用することで関連しています。
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を実装するSIGTRAN同輩はTLSセッションの一部として互いに設立を認証しなければなりません。 互いの認証を確実にするために、TLSサーバとして機能するSIGTRANノードは、要求に応じて証明書を提供するようSIGTRANノードからのTLSクライアントとして作動する証明書、および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 MUST、他のuniの方向のストリームは使用してはいけません。
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 MUSTサポート断片化の上で使用されて、また、一部受け渡しAPIをサポートする必要であるかもしれないことに注意されるべきです。 すべてのSIGTRANメッセージが小さくても、これは成立します。 その上、TLSに関連してSCTPの'順不同の配送'の特徴を使用できません。 その他の詳細のための[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攻撃にこれを使用できます。 これはトランスポート層で提供するセキュリティに関する一般的問題です。
Loughney, et al. Standards Track [Page 7] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[7ページ]。
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を使用するために構成されたなら、それは、STARTTLSメッセージをストリーム0に送って、_タイマ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をサポートしないなら、それはサポートされないメッセージタイプを示すERRORメッセージを返送します。 この場合、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をサポートしないのを示すことによって中央の男性がサービス不能攻撃をするのは、可能です。 しかし、中の男性にとって、この種類の攻撃がいつも可能である、-、-、中央。
7. Support of IPsec and TLS
7. IPsecと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は超能力かTLSです。使用できます。 IPsec超能力Transport ModeとTLSケースの両方では、IPヘッダー情報は、暗号化されないで、また保護されません。 IPsecであるなら、超能力は選ばれていますが、SCTP制御情報は、TLSのベースのソリューションでは、暗号化されてSCTP制御情報が暗号化されて、保護されるのではなく、SCTP手順で保護されているだけです。
In general, both IPsec and TLS have enough mechanisms to secure the SIGTRAN communications.
一般に、IPsecとTLSの両方には、SIGTRANコミュニケーションを保証できるくらいのメカニズムがあります。
Loughney, et al. Standards Track [Page 8] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[8ページ]。
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を支えるかもしれません。
8. Peer-to-Peer Considerations
8. ピアツーピア問題
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用法にユニークであって、異なる傾向があります。 一般に、それらの信頼アンカーが組織の接待の同輩の、そして、他の組織の間の取引関係を反映するために構成されると予想されます。 その結果、同輩は、どんな任意の同輩がいる接続性も許容するために通常構成されないでしょう。 証明書認証同輩があらかじめ知られていないとき、同輩発見が必要であるかもしれません。
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よりかなりフレキシブルでないことに注意してください。 Port識別子の使用がIKE Phase1の中で禁止されているので、各アプリケーションのためにIPsecの中で唯一個別に信じられた信頼アンカーを構成するのは可能ではありません。 すべてのアプリケーションに同じ方針を使用しなければなりません。 例えば、これは、また、他のプロトコル(例えば、SNMP)を保護するとSIGTRANプロトコルによる使用のために信じられた信頼アンカーを信じなければならないのを含意します。 これらの制限はせいぜいまずいです。
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アドレス(主なMode)、またはことによると彼らの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プロトコルと共に使用されるとき、アウトバウンドトラフィックのための典型的な安全保障政策は使用されます。
Loughney, et al. Standards Track [Page 9] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[9ページ]。
"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.
本国行きのSIGTRANセッションが起こるときはいつも、この方針は、IPsecがSIGTRAN同輩が別のSIGTRAN同輩にセッションを開始するときはいつも、使用されて、必要であることを引き起こします。 この方針は魅力的です、新しいSIGTRANセッションが作成されるたびに方針が各同輩に設定されるか、またはダイナミックに変更されるのが必要でないので。 IPsec SAは簡単な静的な方針に基づいて自動的に作成されます。 ほとんどのプラットホームのソケットAPIについて、IPsec拡張子が通常なくて、IPsec方針の機能性が実装に依存しているので、簡単な静的な方針の使用はしばしば最も簡単です。SIGTRAN同輩を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がそうであるなら、SIGTRANピアツーピアセッション、IPsec方針SHOULDを固定するのにおいて使用されているのは、本国行きの接続、外国行きの接続のためにIPsec保護を開始するためにIPsec保護を必要とするセットです。 本国行きの、そして、外国行きのフィルタ方針の使用でこれを達成できます。
9. Security Considerations
9. セキュリティ問題
This document discusses the usage of IPsec and TLS for securing SIGTRAN traffic.
このドキュメントは、SIGTRANがトラフィックであると機密保護するためにIPsecとTLSの使用法について議論します。
10. IANA Considerations
10. IANA問題
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はSignaling User Adaption Layer Assignments Registryで予約されました。 このメッセージのクラス、タイプ1がSTARTTLSメッセージ、およびメッセージのために予約されたというメッセージに関しては、STARTTLS_ACKメッセージのために2をタイプしてください。
11. Acknowledgements
11. 承認
The authors would like to thank B. Aboba, K. Morneault and many others for their invaluable comments and suggestions.
作者は彼らの非常に貴重なコメントと提案についてB.Aboba、K.Morneault、および多くの他のものに感謝したがっています。
Loughney, et al. Standards Track [Page 10] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[10ページ]。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
12.2. Informative References
12.2. 有益な参照
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[3] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[4] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[5] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[5] パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[6] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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.、ガリペリン、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] スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、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-ユーザ適合層」、RFC3057、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.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。
[11] Stone, J., Stewart, R. and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[11] ストーン、J.、スチュワート、研究開発オーティス、「ストリーム制御伝動プロトコル(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.ハイツ、「システム7(SS7)メッセージに合図して、第2部(MTP2)を移してください--ユーザ適合層」、RFC3331、2002年9月。
Loughney, et al. Standards Track [Page 11] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[11ページ]。
[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)」、RFC3332、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、「ストリーム制御伝動プロトコルの上のトランスポート層セキュリティ」、RFC3436、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] J.、「合図接続コントロール部分ユーザ適合層の(SUA)」というLoughneyは進歩、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.スチュワート)は「ストリーム制御伝動の使用のときにIPsecと共に(SCTP)について議定書の中で述べます」、RFC3554、2003年7月。
13. Authors' Addresses
13. 作者のアドレス
John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
ジョンLoughneyノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: john.loughney@nokia.com
メール: john.loughney@nokia.com
Michael Tuexen (editor) Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学Muenster StegerwaldstrのマイケルTuexen(エディタ)大学。 39 48565Steinfurtドイツ
EMail: tuexen@fh-muenster.de
メール: tuexen@fh-muenster.de
Javier Pastor-Balbas Ericsson Espana S.A. Via de los Poblados, 13 28033 Madrid Spain
ハビエルPastor-BalbasエリクソンエスパニアS.A.Via de los Poblados、13 28033マドリードスペイン
EMail: j.javier.pastor@ericsson.com
メール: j.javier.pastor@ericsson.com
Loughney, et al. Standards Track [Page 12] RFC 3788 SIGTRAN Security June 2004
Loughney、他 規格はSIGTRANセキュリティ2004年6月にRFC3788を追跡します[12ページ]。
14. Full Copyright Statement
14. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Loughney, et al. Standards Track [Page 13]
Loughney、他 標準化過程[13ページ]
一覧
スポンサーリンク
