Network Working Group H. Tschofenig
Request for Comments: 4081 D. Kroeselberg
Category: Informational Siemens
June 2005
Security Threats for Next Steps in Signaling (NSIS)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite.
この脅威の文書では、シグナリング（NSIS）プロトコルスイートの次のステップに関連するセキュリティの脅威の詳細な分析を提供します。これは、に注意を呼び出し、NSIS要件、フレームワーク、およびプロトコルの提案では、さまざまなセキュリティ上の考慮事項の理解に役立ちます。この文書では、NSISプロトコル群の特定の部分の脆弱性を説明していません。
Table of Contents
目次
1. Introduction ....................................................2
2. Communications Models ...........................................3
3. Generic Threats .................................................7
3.1. Man-in-the-Middle Attacks ..................................8
3.2. Replay of Signaling Messages ..............................11
3.3. Injecting or Modifying Messages ...........................11
3.4. Insecure Parameter Exchange and Negotiation ...............12
4. NSIS-Specific Threat Scenarios .................................12
4.1. Threats during NSIS SA Usage ..............................13
4.2. Flooding ..................................................13
4.3. Eavesdropping and Traffic Analysis ........................15
4.4. Identity Spoofing .........................................15
4.5. Unprotected Authorization Information .....................17
4.6. Missing Non-Repudiation ...................................18
4.7. Malicious NSIS Entity .....................................19
4.8. Denial of Service Attacks .................................20
4.9. Disclosing the Network Topology ...........................21
4.10. Unprotected Session or Reservation Ownership .............21
4.11. Attacks against the NTLP .................................23
5. Security Considerations ........................................23
6. Contributors ...................................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
Whenever a new protocol is developed or existing protocols are modified, threats to their security should be evaluated. To address security in the NSIS working group, a number of steps have been taken:
新しいプロトコルが開発されたり、既存のプロトコルが変更されるたびに、彼らの安全保障への脅威は評価されるべきです。 NSISワーキンググループでのセキュリティに対処するために、ステップ数がとられています。
NSIS Analysis Activities (see [RSVP-SEC] and [SIG-ANAL])
NSIS分析アクティビティ（参照[RSVP-SEC]と[SIG-ANAL]）
Security Threats for NSIS
NSISのためのセキュリティの脅威
NSIS Requirements (see [RFC3726])
NSIS要件（[RFC3726]を参照）
NSIS Framework (see [RFC4080])
NSISフレームワーク（[RFC4080]を参照）
NSIS Protocol Suite (see GIMPS [GIMPS], NAT/Firewall NSLP [NATFW-NSLP] and QoS NSLP [QOS-NSLP])
NSISプロトコルスイート（GIMPS [GIMPS]、NAT /ファイアウォールNSLP [NATFW-NSLP]およびQoS NSLP [QOS-NSLP]を参照してください）
This document identifies the basic security threats that need to be addressed during the design of the NSIS protocol suite. Even if the base protocol is secure, certain extensions may cause problems when used in a particular environment.
この文書では、NSISプロトコル群の設計時に対処する必要がある基本的なセキュリティの脅威を識別します。基本プロトコルが安全であっても、特定の環境で使用する場合、特定の拡張子は、問題が発生することがあります。
This document cannot provide detailed threats for all possible NSIS Signaling Layer Protocols (NSLPs). QoS [QOS-NSLP], NAT/Firewall [NATFW-NSLP], and other NSLP documents need to provide a description of their trust models and a threat assessment for their specific application domain. This document aims to provide some help for the subsequent design of the NSIS protocol suite. Investigations of security threats in a specific architecture or context are outside the scope of this document.
この文書では、すべての可能なNSISシグナリング層プロトコル（NSLPs）の詳細な脅威を提供することはできません。 QoSの[QOS-NSLP]、NAT /ファイアウォール[NATFW-NSLP]、およびその他のNSLPドキュメントは彼らの信頼モデルの説明と、その特定のアプリケーションドメインの脅威の評価を提供する必要があります。この文書では、NSISプロトコル群のその後の設計のためのいくつかの助けを提供することを目的とします。特定のアーキテクチャや文脈におけるセキュリティ脅威の調査は、この文書の範囲外です。
We use the NSIS terms defined in [RFC3726] and in [RFC4080].
私たちは、[RFC3726]にし、[RFC4080]で定義されたNSISの用語を使用します。
The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate state at nodes along the data flow path through the network. As such, the NSIS protocol suite involves the communication between different entities.
プロトコルのNSISスイートをインストール及び/又はネットワークを介してデータ流路に沿ったノードの状態を操作する必要がある様々なシグナリングアプリケーションをサポートするために想定されます。このように、NSISプロトコル群は、異なるエンティティ間の通信を含みます。
This section offers terminology for common communication models that are relevant to securing the NSIS protocol suite.
このセクションでは、NSISプロトコル・スイートの確保に関連する一般的な通信モデルのための専門用語を提供しています。
An abstract network topology with its administrative domains is shown in Figure 1, and in Figure 2 the relationship between NSIS entities along the path is shown. For illustrative reasons, only end-to-end NSIS signaling is depicted, yet it might be used in other variations as well. Signaling can start at any place and might terminate at any other place within the network. Depending on the trust relationship between NSIS entities and the traversed network parts, different security problems arise.
その管理ドメインと抽象ネットワーク・トポロジは、図1に示され、図2のパスに沿ったNSISエンティティ間の関係が示されています。例示的な理由のために、唯一のエンドツーエンドのNSISシグナリングが示されている、まだそれは、他の変形例で使用されるかもしれません。シグナリングは、任意の場所で開始することができ、ネットワーク内の他の場所で終了することがあります。 NSISエンティティと横断ネットワーク部品間の信頼関係に応じて、異なるセキュリティ上の問題が生じます。
The notion of trust and trust relationship used in this document is informal and can best be captured by the definition provided in Section 1.1 of [RFC3756]. For completeness we include the definition of a trust relationship, which denotes a mutual a priori relationship between the involved organizations or parties wherein the parties believe that the other parties will behave correctly even in the future.
この文書で使用されている信頼と信頼関係の概念は非公式で、最高[RFC3756]のセクション1.1で提供されていた定義で捕捉することができます。完全を期すために、私たちは、当事者が他の当事者も、将来的に正しく動作することを信じてここ関与組織や当事者間の相互の先験的の関係を示して信頼関係の定義が含まれます。
An important observation for NSIS is that a certain degree of trust has to be placed into intermediate NSIS nodes along the path between an NSIS Initiator and an NSIS Responder, specifically so that they perform message processing and take the necessary actions. A complete lack of trust between any of the participating entities will cause NSIS signaling to fail.
NSISのための重要な観察は、信頼のある程度は、それらがメッセージの処理を実行し、必要な行動を取る具体ように、NSISイニシエータとNSISレスポンダとの間の経路に沿った中間NSISノードに入れなければならないことです。参加事業体のいずれかの間の信頼の完全な欠如が失敗し、シグナリングNSISの原因となります。
Note that it is not possible to describe a trust model completely without considering the details and behavior of the NTLP, the NSLP (e.g., QoS NSLP), and the deployment environment. For example, securing the communication between an end host (which acts as the NSIS Initiator) and the first NSIS node (which might be in the attached network or even a number of networks away) is impacted by the trust relationships between these entities. In a corporate network environment, a stronger degree of trust typically exists than in an unmanaged network.
（例えば、QoSのNSLP）NTLP、NSLP、およびデプロイメント環境の詳細と動作を考慮せずに、完全に信頼モデルを記述することは不可能であることに注意してください。例えば、（NSIS開始剤として作用する）と（接続されたネットワークまたは離れネットワークの偶数であるかもしれない）最初のNSISノードは、これらのエンティティ間の信頼関係によって影響を受けるエンドホスト間の通信を確保します。企業のネットワーク環境では、信頼の強い程度が一般的に管理されていないネットワークに比べて存在しています。
Figure 1 introduces convenient abbreviations for network parts with similar properties: first-peer, last-peer, intra-domain, or inter-domain.
最初のピア、最後のピア、イントラドメイン、またはドメイン間：図1は、類似の特性を有するネットワーク部品のための便利な略語を導入します。
+------------------+ +---------------+ +------------------+
| | | | | |
| Administrative | | Intermediate | | Administrative |
| Domain A | | Domains | | Domain B |
| | | | | |
| (Inter-domain Communication) |
| +-------->+---+<------------->+---+<--------+ |
| (Intra-domain | | | | (Intra-domain |
| Communication) | | | | Communication) |
| | | | | | | |
| v | | | | v |
+--------+---------+ +---------------+ +---------+--------+
^ ^
| |
First Peer Communication Last Peer Communication
| |
v v
+-----+-----+ +-----+-----+
| NSIS | | NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
Figure 1: Communication patterns in NSIS
図1：NSISにおけるコミュニケーションパターン
First-Peer/Last-Peer Communication:
まず、ピア/ラスト・ピア通信：
The end-to-end communication scenario depicted in Figure 1 includes the communication between the end hosts and their nearest NSIS hops. "First-peer communications" refers to the peer-to-peer interaction between a signaling message originator, the NSIS Initiator (NI), and the first NSIS-aware entity along the path. This "first-peer communications" commonly comes with specific security requirements that are especially important for addressing security issues between the end host (and a user) and the network it is attached to.
図1に示すエンド・ツー・エンドの通信シナリオは、エンドホストとその最も近いNSISホップとの間の通信を含みます。 「ファースト・ピア通信」は、シグナリングメッセージの発信、NSISイニシエータ（NI）、及び経路に沿って第1のNSIS対応エンティティ間のピアツーピア相互作用を指します。この「第一ピア通信」は、一般に、エンドホスト（およびユーザ）と、それが接続されているネットワーク間のセキュリティ問題に対処するために特に重要であり、特定のセキュリティ要件が付属しています。
To illustrate this, in roaming environments, it is difficult to assume the existence of a pre-established security association directly available for NSIS peers involved in first-peer communications, because these peers cannot be assumed to have any pre-existing relationship with each other. In contrast, in enterprise networks usually there is a fairly strong (pre-established) trust relationship between the peers. Enterprise network administrators usually have some degree of freedom to select the appropriate security protection and to enforce it. The choice of selecting a security mechanism is therefore often influenced by the infrastructure already available, and per-session negotiation of security mechanisms is often not required (although, in contrast, it is required in a roaming environment).
環境ローミングで、これを説明するために、これらのピアは、互いに任意の既存の関係を有すると仮定することができないので、最初のピア通信に関与するNSISピアのために直接使用可能な事前に確立されたセキュリティアソシエーションの存在を想定することは困難です。対照的に、企業ネットワークで通常のピアとの間のかなり強い（予め確立された）信頼関係が存在します。企業のネットワーク管理者は、通常、適切なセキュリティ保護を選択するようにして、それを強制するためにいくつかの自由度を持っています。セキュリティ・メカニズムの選択の選択は、それゆえ、多くの場合、既に利用可能なインフラに影響され、そして（対照的に、それはローミング環境で必要とされる、が）セキュリティメカニズムのセッションごとの交渉が頻繁に必要とされていません。
Last-Peer communication is a variation of First-Peer communication in which the roles are reversed.
ラスト・ピア通信は、役割が逆転された第1ピア通信の変形です。
Intra-Domain Communication:
ドメイン内のコミュニケーション：
After verification of the NSIS signaling message at the border of an administrative domain, an NSIS signaling message traverses the network within the same administrative domain to which the first peer belongs. It might not be necessary to repeat the authorization procedure of the NSIS initiator again at every NSIS node within this domain. Key management within the administrative domain might also be simpler.
管理ドメインの境界におけるNSISシグナリングメッセージの検証後に、NSISシグナリングメッセージは、最初のピアが属する同一の管理ドメイン内のネットワークを横断します。このドメイン内のすべてのNSISノードで再びNSIS開始剤の承認手順を繰り返す必要はないかもしれません。管理ドメイン内の鍵の管理も簡単になるかもしれません。
Security protection is still required to prevent threats by non-NSIS nodes in this network.
セキュリティ保護は、まだこのネットワーク内の非NSISノードによって脅威を防止するために必要とされます。
Inter-Domain Communication:
ドメイン間通信：
Inter-Domain communication deals with the interaction between administrative domains. For some NSLPs (for example, QoS NSLP), this interaction is likely to take place between neighboring domains, whereas in other NSLPs (such as the NAT/Firewall NSLP), the core network is usually not involved.
ドメイン間の通信は、管理ドメイン間の相互作用を扱います。一部NSLPs（例えば、のQoS NSLP）のために、この相互作用は、（NAT /ファイアウォールNSLPのような）他のNSLPsに、コアネットワークは通常関与しないのに対し、隣接するドメイン間で起こる可能性があります。
If signaling messages are conveyed transparently in the core network (i.e., if they are neither intercepted nor processed in the core network), then the signaling message communications effectively takes place between access networks. This might place a burden on authorization handling and on the key management infrastructure required between these access networks, which might not know of each other in advance.
シグナリングメッセージは、コアネットワークに透過的に搬送される場合（それらはいずれも傍受も、コアネットワークで処理される場合、すなわち、）、次いで、シグナリング・メッセージ通信を効果的にアクセスネットワークとの間で行われます。これは、認可取り扱い上、事前にお互いを知っていない可能性がありますこれらのアクセスネットワーク間で必要なキー管理インフラストラクチャ、に負担をかけるかもしれません。
To refine the above differentiation based on the network parts that NSIS signaling may traverse, we subsequently consider relationships between involved entities. Because a number of NSIS nodes might actively participate in a specific protocol exchange, a larger number of possible relationships need to be analyzed than in other protocols. Figure 2 illustrates possible relationships between the entities involved in the NSIS protocol suite.
NSISシグナリングが通過することがネットワーク部に基づいて上記の分化を絞り込むには、我々はその後、関係エンティティ間の関係を検討してください。 NSISノードの数が積極的に特定のプロトコル交換に参加する可能性があるため、可能な関係の数が多いほど、他のプロトコルに比べて分析する必要があります。図2は、NSISプロトコルスイートに関与するエンティティ間の可能な関係を示しています。
****************************************
* *
+----+-----+ +----------+ +----+-----+
+-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+
| | Node 1 | | Node 2 | | Node 3 | |
| +----------+ +----+-----+ +----------+ |
| ~ |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| ~ |
+--+--+-----+ +---------+-+
| NSIS +//////////////////////////////////////////+ NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
Legend:
-----: Peer-to-Peer Relationship
/////: End-to-End Relationship
*****: Middle-to-Middle Relationship
~~~~~: End-to-Middle Relationship
Figure 2: Possible NSIS Relationships
図2：可能NSIS関係
End-to-Middle Communications:
エンド・ツー・ミドル・コミュニケーションズ：
The scenario in which one NSIS entity involved is an end-entity (Initiator or Responder) and the other entity is any intermediate hop other than the immediately adjacent peer is typically called the end-to-middle scenario (see Figure 2). A motivation for including this scenario can, for example, be found in SIP [RFC3261].
関与する1つのNSISエンティティがエンドエンティティ（イニシエータまたはレスポンダ）と他のエンティティであるシナリオはすぐ隣接ピア以外の任意の中間ホップは、典型的には、エンド・ツー・ミドルシナリオ（図2参照）と呼ばれています。このシナリオを含むための動機は、例えば、SIP [RFC3261]に見出すことができます。
An example of end-to-middle interaction might be an explicit authorization from the NSIS Initiator to some intermediate node. Threats specific to this scenario may be introduced by some intermediate NSIS hops that are not allowed to eavesdrop or modify certain objects.
エンド・ツー・ミドル相互作用の例は、いくつかの中間ノードへNSISイニシエータからの明示的な許可であるかもしれません。このシナリオの特定の脅威は、特定のオブジェクトを盗聴または変更することが許可されていないいくつかの中間NSISホップによって導入することができます。
Middle-to-Middle Communications:
中東・ツー・ミドル・コミュニケーションズ：
Middle-to-middle communication refers to the exchange of information between two non-neighboring NSIS nodes along the path. Intermediate NSIS hops may have to deal with specific security threats that do not involve the NSIS Initiator or the NSIS Responder directly.
中間に中間通信パスに沿って2つの非隣接NSISノードとの間の情報の交換を指します。中間NSISホップは直接NSISイニシエータまたはNSIS Responderのを伴わない特定のセキュリティ上の脅威に対処する必要があります。
End-to-End Communications:
エンドツーエンドの通信：
NSIS aims to signal information from an Initiator to some NSIS nodes along the path to a data receiver. In the case of end-to-end NSIS signaling, the last node is the NSIS Responder, as it is the data receiver. The NSIS protocol suite is not an end-to-end protocol used to exchange information purely between end hosts.
NSISは、データ受信機への経路に沿っていくつかのNSISノードにイニシエータからの情報をシグナリングすることを目的とします。エンドツーエンドのNSISシグナリングの場合には、最後のノードは、データ受信機であるように、NSISレスポンダです。 NSISプロトコル群は、純粋にエンドホストとの間で情報を交換するために使用されるエンドツーエンドのプロトコルではありません。
Typically, it is not required to protect NSIS messages cryptographically between the NSIS Initiator and the NSIS Responder. Protecting the entire signaling message end-to-end might not be feasible since intermediate NSIS nodes need to add, inspect, modify, or delete objects from the signaling message.
典型的には、NSISイニシエータとNSIS Responderの間で、暗号NSISメッセージを保護する必要はありません。中間NSISノードがシグナリングメッセージからオブジェクトを、追加検査、変更、または削除する必要があるので、全体のシグナリングメッセージのエンドツーエンドの保護は実現可能ではないかもしれません。
This section provides scenarios of threats that are applicable to signaling protocols in general. Note that some of these scenarios use the term "user" instead of "NSIS Initiator". This is mainly because security protocols allow differentiation between entities that are hosts and those that are users (based on the identifiers used).
このセクションでは、一般的にシグナリングプロトコルに適用される脅威のシナリオを提供します。これらのシナリオのいくつかは、用語「ユーザー」の代わりに「NSISイニシエータ」を使用していることに注意してください。セキュリティプロトコル、ホストおよび（使用される識別子に基づいて）ユーザであるものであるエンティティ間の差別を許すので、これは主にです。
For the following subsections, we use the general distinction in two cases in which attacks may occur. These are according to the separate steps, or phases, normally encountered when applying protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH). Therefore, this section starts by briefly describing a motivation for this separation.
以下のサブセクションでは、我々は攻撃が起こる可能性のある2つの場合に一般的な区別を使用しています。プロトコルのセキュリティを適用する場合、これらは別々の工程、又は相によれば、通常（と、例えば、IPsecの、TLS、ケルベロス、またはSSH）に遭遇します。したがって、このセクションでは、簡単にこの分離のための動機を説明することによって開始します。
Security protection of protocols is often separated into two steps. The first step primarily provides entity authentication and key establishment (which result in a persistent state often called a security association), whereas the second step provides message protection (some combination of data origin authentication, data integrity, confidentiality, and replay protection) using the previously established security association. The first step tends to be more expensive than the second, which is the main reason for the separation. If messages are transmitted infrequently, then these two steps may be collapsed into a single and usually rather costly one. One such example is e-mail protection via S/MIME. The two steps may be tightly bound into a single protocol, as in TLS, or defined in separate protocols, as with IKE and IPsec. We use this separation to cover the different threats in more detail.
プロトコルのセキュリティ保護は、多くの場合、2つのステップに分けています。第2のステップは使用してメッセージ保護（データ発信元認証のいくつかの組み合わせ、データの整合性、機密性、および再生保護）を提供する一方、最初のステップは、主に、（多くの場合、セキュリティアソシエーションと呼ばれる永続的な状態をもたらす）エンティティ認証及び鍵確立を提供します以前にセキュリティアソシエーションを確立しました。最初のステップは、分離のための主な理由である第二の、より高価になる傾向があります。メッセージがまれに送信される場合、これらの2つのステップは、単一の、通常はかなり高価なものに折り畳まれてもよいです。その一例は、S / MIMEを経由して電子メールの保護です。 2つのステップがしっかりTLSのように、単一のプロトコルに結合し、又はIKEとIPsecのように、別のプロトコルで定義されてもよいです。私たちは、より詳細に異なる脅威をカバーするために、この分離を使用します。
This section describes both security threats that exist if two peers do not already share a security association or do not use security mechanisms at all, and threats that are applicable when a security association is already established.
このセクションでは、セキュリティ上の2つのピアがすでにセキュリティアソシエーションを共有しない、またはまったくセキュリティ・メカニズムを使用しない場合に存在する脅威、およびセキュリティアソシエーションがすでに確立されたときに適用されている脅威の両方を説明しています。
Attacks during NSIS SA Establishment:
NSIS SA設立時の攻撃：
While establishing a security association, an adversary fools the signaling message Initiator with respect to the entity to which it has to authenticate. The Initiator authenticates to the man-in-the-middle adversary, who is then able to modify signaling messages to mount DoS attacks or to steal services that get billed to the Initiator. In addition, the adversary may be able to terminate the Initiator's NSIS messages and to inject messages to a peer itself, thereby acting as the peer to the Initiator and as the Initiator to the peer. As a result, the Initiator wrongly believes that it is talking to the "real" network, whereas it is actually attached to an adversary. For this attack to be successful, pre-conditions that are described in the following three cases have to hold:
セキュリティアソシエーションを確立しながら、敵対者は、それが有する認証するためのエンティティに対するシグナリングメッセージのイニシエータを愚か者。イニシエータは、DoS攻撃をマウントするか、イニシエータに請求を受けるサービスを盗むためにシグナリングメッセージを修正することができなman-in-the-middle攻撃者に認証を行います。また、敵はイニシエータのNSISメッセージを終了することができる場合があり、これによりイニシエータにピアとしてピアの開始剤として作用し、ピア自体にメッセージを注入します。その結果、イニシエータは、誤って、それが実際に敵に装着されているのに対し、それは、「本物の」ネットワークに話していると考えています。この攻撃を成功させるには、次の3つの場合で説明されている前提条件が保持する必要があります：
Missing Authentication:
行方不明の認証：
In the first case, this threat can be carried out because of missing authentication between neighboring peers: without authentication, an NI, NR, or NF is unable to detect an adversary. However, in some practical cases, authentication might be difficult to accomplish, either because the next peer is unknown, because there are misbelieved trust relationships in parts of the network, or because of the inability to establish proper security protection (inter-domain signaling messages, dynamic establishment of a security association, etc.). If one of the communicating endpoints is unknown, then for some security mechanisms it is either impossible or impractical to apply appropriate security protection. Sometimes network administrators use intra-domain signaling messages without proper security. This configuration allows an adversary on a compromised non-NSIS-aware node to interfere with nodes running an NSIS signaling protocol. Note that this type of threat goes beyond those caused by malicious NSIS nodes (described in Section 4.7).
最初のケースでは、この脅威があるため、隣接ピア間行方不明の認証を行うことができる：認証なし、NI、NR、又はNFは敵を検出することができません。しかし、いくつかの実用的な例では、認証が実現するのは困難かもしれないが、いずれかの適切なセキュリティ保護（ドメイン間のシグナリングメッセージを確立するため、またはため不能のネットワークの一部でmisbelieved信頼関係があるので、次のピアは、不明であるため、セキュリティアソシエーションの、動的確立、等）。通信エンドポイントの1つが不明な場合は、その後、いくつかのセキュリティメカニズムのためには、適切なセキュリティ保護を適用することは不可能または非現実的のいずれかです。時には、ネットワーク管理者は、適切なセキュリティなしでシグナリングメッセージ内のドメインを使用しています。この構成は、損なわ非NSIS認識ノード上の敵は、NSISシグナリングプロトコルを実行しているノードを妨害することを可能にします。脅威のこのタイプは（4.7節に記述）悪意のあるNSISノードによって引き起こされたものを超えていることに注意してください。
Unilateral Authentication:
片側認証：
In the case of unilateral authentication, the NSIS entity that does not authenticate its peer is unable to discover a man-in-the-middle adversary. Although mutual authentication of signaling messages should take place between each peer participating in the protocol operation, special attention is given here to first-peer communications. Unilateral authentication between an end host and the first peer (just authenticating the end host) is still common today, but it opens up many possibilities for man-in-the-middle attackers impersonating either the end host or the (administrative domain represented by the) first peer.
一方的な認証の場合には、そのピアを認証しないNSIS実体はのman-in-the-middle敵を発見することができません。シグナリングメッセージの相互認証は、プロトコル動作に参加する各ピア間で行われるべきであるが、特別な注意が最初のピア通信にここに与えられています。エンドホストと最初のピア間の一方的な認証が（ちょうどエンドホストを認証する）今日まだ一般的ですが、それはエンドホストまたはによって表される（管理ドメインのいずれかになりすますのman-in-the-middle攻撃のための多くの可能性を開きます）最初のピア。
Missing or unilateral authentication, as described above, is part of a general problem of network access with inadequate authentication, and it should not be considered something unique to the NSIS signaling protocol. Obviously, there is a strong need to address this correctly in a future NSIS protocol suite. The signaling protocols addressed by NSIS are different from other protocols in which only two entities are involved. Note that first-peer authentication is especially important because a security breach there could impact nodes beyond the entities directly involved (or even beyond a local network).
前述したように、存在しないか、または一方的な認証は、不十分な認証とネットワークアクセスの一般的な問題の一部であり、それはNSISシグナリングプロトコルに固有のものと考えるべきではありません。もちろん、将来のNSISプロトコル・スイートでこれを正しく対処する強い必要性があります。 NSISによって対処シグナリングプロトコルは、唯一の2つのエンティティが関与している他のプロトコルとは異なります。セキュリティ侵害が直接関与するエンティティを越えて（あるいはローカルネットワークを超えて）のノードが影響を与える可能性があるため、最初のピアの認証が特に重要であることに注意してください。
Finally, note that the signaling protocol should be considered a peer-to-peer protocol, wherein the roles of Initiator and Responder can be reversed at any time. Thus, unilateral authentication is not particularly useful for such a protocol. However, some form of asymmetry might be needed in the authentication process, whereby one entity uses an authentication mechanism different from that of the other one. As an example, the combination of symmetric and asymmetric cryptography should be mentioned.
最後に、イニシエータとレスポンダの役割は、任意の時点で反転させることができる前記シグナリングプロトコルは、ピア・ツー・ピア・プロトコルを考慮すべきであることに注意してください。従って、一方的認証は、そのようなプロトコルのために特に有用ではありません。しかしながら、非対称のいくつかの形態は、一つのエンティティが他方とは異なる認証メカニズムを使用することにより、認証処理で必要とされるかもしれません。一例として、対称および非対称暗号の組み合わせは言及されるべきです。
Weak Authentication:
弱い認証：
In the case of weak authentication, the threat can be carried out because information transmitted during the NSIS SA establishment process may leak passwords or allow offline dictionary attacks. This threat is applicable to NSIS for the process of selecting certain security mechanisms.
NSIS SA確立プロセス中に送信された情報は、パスワードの漏洩またはオフライン辞書攻撃を可能にすることができるので、弱い認証の場合には、脅威を行うことができます。この脅威は、特定のセキュリティメカニズムを選択するプロセスのためにNSISに適用されます。
Finally, we conclude with a description of a man-in-the-middle (MITM) attack during the discovery phase. This attack benefits from the fact that NSIS nodes are likely to be unaware of the network topology. Furthermore, an authorization problem might arise if an NSIS QoS NSLP node pretends to be an NSIS NAT/Firewall-specific node or vice versa.
最後に、我々は発見フェーズ中のman-in-the-middle（MITM）攻撃の説明と結論付けています。この攻撃は、NSISノードがネットワークトポロジを知らない可能性が高いという事実から利益を得ます。 NSISのQoS NSLPノードはNSIS NAT /ファイアウォール、特定のノードまたはその逆になりすました場合さらに、許可の問題が発生する可能性があります。
An adversary might inject a bogus reply message, forcing the discovery message initiator to start a messaging association establishment with either an adversary or with another NSIS node that is not along the path. Figure 3 describes the attack in more detail for peer-to-peer addressed messages with a discovery mechanism. For end-to-end addressed messages, the attack is also applicable, particularly if the adversary is located along the path and able to intercept the discovery message that traverses the adversary. The man-in-the-middle adversary might redirect to another legitimate NSIS node. A malicious NSIS node can be detected with the corresponding security mechanisms, but a legitimate NSIS node that is not the next NSIS node along the path cannot be detected without topology knowledge.
敵は敵のいずれかで、または経路に沿ってない別のNSISノードとメッセージング・アソシエーションの確立を開始するために、発見メッセージ開始を強制する、偽の応答メッセージを注入する可能性があります。図3は、ピア・ツー・ピアのためのより詳細な攻撃が検出メカニズムとメッセージを対処について説明します。エンドツーエンドのメッセージをアドレス指定するために、攻撃が敵の経路に沿って配置され、敵を横断する発見メッセージを傍受することが可能である場合は特に、適用することも可能です。 man-in-the-middle攻撃者は、別の正当なNSISノードにリダイレクトすることがあります。悪意のあるNSISノードは、対応するセキュリティ・メカニズムを用いて検出することができるが、パスに沿って次のNSISノードではない正規NSISノードはトポロジ知識なしに検出することができません。
+-----------+ Messaging Association
Message | Adversary | Establishment
Association +--->+ +<----------------+
Establish- | +----+------+ |(4)
ment | IPx | |
(3)| |Discovery Reply v
| | (IPx) +---+-------+
v | (2) | NSIS |
+------+-----+ | /----------->+ Node B +--------
| NSIS +<--+ / Discovery +-----------+
| Node A +---------/ Request IPr
+------------+ (1)
IPi
Figure 3: MITM Attack during the Discovery Exchange
図3：ディスカバリー交換時にMITM攻撃
This attack assumes that the adversary is able to eavesdrop on the initial discovery message sent by the sender of the discovery message. Furthermore, we assume that the discovery reply message by the adversary returns to the discovery message initiator faster than the real response. This represents some race condition characteristics if the next NSIS node is very close (in IP-hop terms) to the initiator. Note that the problem is self-healing since the discovery process is periodically repeated. If an adversary is unable to mount this attack with every discovery message, then the correct next NSIS node along the path will be discovered again. A ping-pong behavior might be the consequence.
この攻撃は、敵が発見メッセージの送信者によって送信された最初の発見メッセージを盗聴することが可能であることを前提としています。さらに、我々は敵によって発見応答メッセージが速く、実際の応答より発見メッセージイニシエータに戻すことを前提としています。次のNSISノードがイニシエータに（IPホップに関して）非常に近い場合、これは、いくつかの競合状態の特性を表します。検出プロセスが定期的に繰り返されているので問題は自己回復であることに注意してください。敵があらゆる発見メッセージで、この攻撃を仕掛けることができない場合は、パスに沿った正しい次のNSISノードが再び検出されます。ピンポン動作が結果かもしれません。
As shown in message step (2) in Figure 3, the adversary returns a discovery reply message with its own IP address as the next NSIS-aware node along the path. Without any additional information, the discovery message initiator has to trust this information. Then a messaging association is established with an entity at a given IP address IPx (i.e., with the adversary) in step (3). The adversary then establishes a messaging association with a further NSIS node and forwards the signaling message. Note that the adversary might just modify the Discovery Reply message to force NSIS Node A to establish a messaging association with another NSIS node that is not along the path. This can then be exploited by the adversary. The interworking with NSIS-unaware NATs in particular might cause additional unexpected problems.
図3のメッセージ・ステップ（2）に示すように、敵対者は、経路に沿った次のNSIS対応ノードとして自身のIPアドレスを発見応答メッセージを返します。任意の追加情報がなければ、発見メッセージイニシエータは、この情報を信頼する必要があります。次いで、メッセージング・アソシエーションは、（3）工程で指定されたIPアドレス（敵とすなわち、）IPxをにてエンティティとの間で確立されています。敵対者は、その後、さらにNSISノードとのメッセージング・アソシエーションを確立し、シグナリングメッセージを転送します。敵がただの経路に沿っていない別のNSISノードとのメッセージングの関連付けを確立するために、NSISノードAを強制的に発見応答メッセージを変更する場合があります。そして、これは敵によって悪用される可能性があります。特にNSIS非対応のNATとのインターワーキングは、追加の予期しない問題が発生する可能性があります。
As a variant of this attack, an adversary not able to eavesdrop on transmitted discovery requests could flood a node with bogus discovery reply messages. If the discovery message sender accidentally accepts one of those bogus messages, then a MITM attack as described in Figure 3 is possible.
この攻撃の変種として、送信された発見要求を盗聴することはできません敵は偽の発見応答メッセージでノードをあふれさせることができました。発見メッセージの送信者が誤ってこれらの偽のメッセージのいずれかを受け入れる場合、図3で説明したように、その後MITM攻撃が可能です。
This threat scenario covers the case in which an adversary eavesdrops, collects signaling messages, and replays them at a later time (or at a different place, or uses parts of them at a different place or in a different way; e.g., cut-and-paste attacks). Without proper replay protection, an adversary might mount man-in-the-middle, denial of service, and theft of service attacks.
この脅威シナリオは、シグナリングメッセージを収集し、敵が盗聴した場合をカバーし、後でそれを再生（または別の場所で、または別の場所で、または別の方法でそれらの部品を使用し、例えば、カットと-paste攻撃）。適切な再生保護がなければ、敵はイン・ザ・ミドル男-、サービス拒否、およびサービス攻撃の窃盗をマウントすることがあります。
A more difficult attack (that may cause problems even if there is replay protection) requires that the adversary crash an NSIS-aware node, causing it to lose state information (sequence numbers, security associations, etc.), and then replay old signaling messages. This attack takes advantage of re-synchronization deficiencies.
より困難な攻撃は、敵はそれが状態情報（シーケンス番号、セキュリティアソシエーションなど）を失うことを引き起こして、NSIS認識ノードがクラッシュすることが必要です（つまり、そこリプレイ保護されていても問題を引き起こす場合があります）してから、古いシグナリングメッセージを再生します。この攻撃は、再同期の欠陥を利用しています。
This type of threat involves integrity violations, whereby an adversary modifies signaling messages (e.g., by acting as a man-in-the-middle) in order to cause unexpected network behavior. Possible actions an adversary might consider for its attack are reordering, delaying, dropping, injecting, truncating, and otherwise modifying messages.
脅威のこのタイプは、敵対者が予期しないネットワーク動作を引き起こすために（のman-in-the-middleとして作用することにより、例えば、）シグナリングメッセージを変更することにより、整合性違反を伴います。敵はその攻撃のために検討するかもしれない可能なアクションは、並べ替え遅延、ドロップ、注入、切り捨て、およびそれ以外のメッセージを変更しています。
An adversary may inject a signaling message requesting a large amount of resources (possibly using a different user's identity). Other resource requests may then be rejected. In combination with identity spoofing, it is possible to carry out fraud. This attack is only feasible in the absence of authentication and signaling message protection.
敵対者は、（おそらくは異なるユーザのアイデンティティを使用して）大量のリソースを要求するシグナリングメッセージを注入することができます。その他のリソース要求は拒否することができます。身元詐称との組み合わせでは、不正行為を行うことが可能です。この攻撃は、認証とシグナリングメッセージ保護が存在しない場合にのみ可能です。
Some threats directly related to these are described in Sections 4.4, 4.7, and 4.8.
直接これらに関連するいくつかの脅威は、セクション4.4、4.7、および4.8で説明されています。
First, protocols may be useful in a variety of scenarios with different security requirements. Second, different users (e.g., a university, a hospital, a commercial enterprise, or a government ministry) have inherently different security requirements. Third, different parts of a network (e.g., within a building, across a public carrier's network, or over a private microwave link) may need different levels of protection. It is often difficult to meet these (sometimes conflicting) requirements with a single security mechanism or fixed set of security parameters, so often a selection of mechanisms and parameters is offered. Therefore, a protocol is required to agree on certain security mechanisms and parameters. An insecure parameter exchange or security negotiation protocol can help an adversary to mount a downgrading attack to force selection of mechanisms weaker than those mutually desired. Thus, without binding the negotiation process to the legitimate parties and protecting it, an NSIS protocol suite might only be as secure as the weakest mechanism provided (e.g., weak authentication), and the benefits of defining configuration parameters and a negotiation protocol are lost.
まず、プロトコルが異なるセキュリティ要件を持つ様々なシナリオにおいて有用であり得ます。第二に、異なるユーザが（例えば、大学、病院、商業の企業、あるいは政府の省庁）は、本質的に異なるセキュリティ要件があります。 （例えば、建物内、公衆通信事業者のネットワークを介して、あるいは民間のマイクロ波リンクを介して）ネットワークの第三に、異なる部分異なるレベルの保護を必要とするかもしれません。そう頻繁に、単一のセキュリティメカニズムやセキュリティパラメータの固定セットこれらの（時には矛盾）の要件を満たすためにしばしば提供される機構およびパラメータの選択は困難です。したがって、プロトコルは、特定のセキュリティメカニズムおよびパラメータに同意する必要があります。安全でないパラメータ交換またはセキュリティネゴシエーションプロトコルは、互いに所望のものよりも弱い機構の選択を強制的にダウングレード攻撃をマウントする敵を助けることができます。したがって、正当関係者に交渉プロセスを結合し、それを保護することなく、NSISプロトコル群は、（例えば、弱い認証）が設けられ、最も弱いメカニズムほど安全であるかもしれない、と設定パラメータとネゴシエーションプロトコルを定義することの利点は失われます。
This section describes eleven threat scenarios in terms of attacks on and security deficiencies in the NSIS signaling protocol. A number of security deficiencies might enable an attack. Fraud is an example of an attack that might be enabled by missing replay protection, missing protection of authorization tokens, identity spoofing, missing authentication, and other deficiencies that help an adversary steal resources. Different threat scenarios based on deficiencies that could enable an attack are addressed in this section.
このセクションでは、NSISシグナリングプロトコルでの攻撃やセキュリティ上の欠陥の面で11脅威のシナリオについて説明します。セキュリティ欠陥の数は、攻撃を可能にするかもしれません。詐欺は、認証トークンの保護、身元詐称、行方不明の認証、および敵対者がリソースを盗む助けて他の欠陥が欠落し、再生保護の欠落によって有効にされるかもしれない攻撃の一例です。攻撃を可能にすることができる欠陥に基づいて、異なる脅威シナリオは、このセクションで取り上げています。
The threat scenarios are not independent. Some of them (e.g., denial of service) are well-established security terms and, as such, need to be addressed, but they are often enabled by one or more deficiencies described under other scenarios.
脅威のシナリオは独立していません。それらのいくつか（例えば、サービス拒否）セキュリティ条件を十分に確立されており、など、対処する必要があるが、彼らは多くの場合、他のシナリオの下に記載の1つまたは複数の欠陥で有効になっています。
Once a security association is established (and used) to protect signaling messages, many basic attacks are prevented. However, a malicious NSIS node is still able to perform various attacks as described in Section 4.7. Replay attacks may be possible when an NSIS node crashes, restarts, and performs state re-establishment. Proper re-synchronization of the security mechanism must therefore be provided to address this problem.
セキュリティアソシエーションが確立（および使用）シグナリングメッセージを保護するためにされると、多くの基本的な攻撃が阻止されます。しかし、悪意があるNSISノードはまだ4.7節で説明したように様々な攻撃を行うことが可能です。 NSISのノードがクラッシュし、再起動し、状態の再確立を行う際リプレイ攻撃が可能であってもよいです。セキュリティ・メカニズムの適切な再同期は、したがって、この問題に対処するために提供されなければなりません。
This section describes attacks that allow an adversary to flood an NSIS node with bogus signaling messages to cause a denial of service attack.
このセクションでは、敵対者がサービス拒否攻撃を引き起こすために偽のシグナリングメッセージをNSISノードをあふれさせることができた攻撃について説明します。
We will discuss this threat at different layers in the NSIS protocol suite:
私たちは、NSISプロトコル・スイートに異なる層で、この脅威を説明します：
Processing of Router Alert Options:
ルータアラートオプションの処理：
The processing of Router Alert Option (RAO) requires that a router do some additional processing by intercepting packets with IP options, which might lead to additional delay for legitimate requests, or even rejection of some of them. A router being flooded with a large number of bogus messages requires resources before finding out that these messages have to be dropped.
ルータアラートオプションの処理（RAO）は、ルータが正当な要求、またはそれらのいくつかのさえ拒否するために追加の遅延につながる可能性があるIPオプション付きパケットを傍受することによって、いくつかの追加処理を行うことが必要です。偽のメッセージの数が多いが殺到しているルータは、これらのメッセージが廃棄されなければならないことを見つける前に、リソースを必要とします。
If the protocol is based on using interception for message delivery, this threat cannot be completely eliminated, but the protocol design should attempt to limit the processing that has to be done on the RAO-bearing packet so that it is as similar as possible to that for an arbitrary packet addressed directly to one of the router interfaces.
プロトコルは、メッセージ配信のための傍受を使用することに基づいている場合は、この脅威を完全に排除することはできないが、それはそれにできるだけ似ているように、プロトコルの設計は、RAOベアリングパケットに行われなければならない処理を制限することを試みるべきです任意のパケットのルータインターフェイスの1つに直接対処。
Attacks against the Transport Layer Protocol:
トランスポート層プロトコルに対する攻撃：
Certain attacks can be mounted against transport protocols by flooding a node with bogus requests, or even to finish the handshake phase to establish a transport layer association. These types of threats are also addressed in Section 4.11.
特定の攻撃は、偽のリクエストでノードをあふれさせることにより、トランスポートプロトコルに対して取り付けることができ、あるいはトランスポート層アソシエーションを確立するために、ハンドシェイク・フェーズを終了します。脅威のこれらのタイプは、4.11項で扱われています。
Force NTLP to Do More Processing:
NTLP力は、より多くの処理を実行します。
Some protocol fields might allow an adversary to force an NTLP node to perform more processing. Additionally it might be possible to interfere with the flow control or the congestion control procedure. These types of threats are also addressed in Section 4.11.
いくつかのプロトコルフィールドは、敵対者がより多くの処理を実行するためにNTLPノードを強制することが可能かもしれません。さらに、フロー制御や輻輳制御手順に干渉することは可能かもしれません。脅威のこれらのタイプは、4.11項で扱われています。
Furthermore, it might be possible to force the NTLP node to perform some computations or signaling message exchanges by injecting "trigger" events (which are unprotected).
また、（保護されていない）「トリガ」イベントを注入することによって、いくつかの計算又はシグナリングメッセージ交換を行うためにNTLPノードを強制することが可能かもしれません。
Force NSLP to Do More Processing:
NSLP力は、より多くの処理を実行します。
An adversary might benefit from flooding an NSLP node with messages that must be stored (e.g., due to fragmentation handling) before verifying the correctness of signaling messages.
敵対者は、シグナリングメッセージの正当性を検証する前に（これはフラグメンテーション処理に、例えば）保存しなければならないメッセージでNSLPノードがフラッディングの恩恵を受ける可能性があります。
Furthermore, causing memory allocation and computational efforts might allow an adversary to harm NSIS entities. If a signaling message contains, for example, a digital signature, then some additional processing is required for the cryptographic verification. An adversary can easily create a random bit sequence instead of a digital signature to force an NSIS node into heavy computation.
さらに、メモリ割り当ての原因と計算努力は敵がNSIS実体に害を与えることを可能かもしれません。シグナリングメッセージは、例えば、デジタル署名が含まれている場合、いくつかの追加の処理は、暗号化検証のために必要とされます。敵対者は、容易に重い計算にNSISノードを強制する代わりに、デジタル署名のランダムビットシーケンスを作成することができます。
Idempotent signaling messages are particularly vulnerable to this type of attack. The term "idempotent" refers to messages that contain the same amount of information as the original message. An example would be a refresh message that is equivalent to a create message. This property allows a refresh message to create state along a new path, where no previous state is available. For this to work, specific classes of cryptographic mechanisms supporting this behavior are needed. An example is a scheme based on digital signatures, which, however, should be used with care due to possible denial of service attacks.
べき等のシグナリングメッセージは、この種の攻撃を特に受けやすいです。用語「冪等」とは、元のメッセージと同じ量の情報を含むメッセージを指します。例では、作成したメッセージに相当しリフレッシュメッセージになります。このプロパティは、リフレッシュメッセージは、以前の状態が利用できない新しいパスに沿って状態を作成することができます。これが機能するためには、この動作をサポートする暗号化メカニズムの具体的なクラスが必要とされています。例では、しかしながら、サービス攻撃の拒否が可能に注意して使用すべきでデジタル署名に基づいた方式です。
Problems with the usage of public-key-based cryptosystems in protocols are described in [AN97] and in [ALN00].
プロトコルにおける公開鍵ベースの暗号の使用に伴う問題は、[AN97]および[ALN00]に記載されています。
In addition to the threat scenario described above, an incoming signaling message might trigger communication with third-party nodes such as policy servers, LDAP servers, or AAA servers. If an adversary is able to transmit a large number of signaling messages (for example, with QoS reservation requests) with invalid credentials, then the verifying node may not be able to process other reservation messages from legitimate users.
上述の脅威シナリオに加えて、着信シグナリング・メッセージは、ポリシーサーバ、LDAPサーバ、またはAAAサーバなどのサードパーティ・ノードとの通信をトリガする可能性があります。敵対者が無効な資格情報を使用して（QoS予約要求と、例えば）シグナリングメッセージの多数を送信することができる場合には、検証ノードは、正当なユーザーから他の予約メッセージを処理することができないかもしれません。
This section covers threats whereby an adversary is able to eavesdrop on signaling messages. The signaling packets collected may allow traffic analysis or be used later to mount replay attacks, as described in Section 3.2. The eavesdropper might learn QoS parameters, communication patterns, policy rules for firewall traversal, policy information, application identifiers, user identities, NAT bindings, authorization objects, network configuration and performance information, and more.
このセクションでは、敵がシグナリングメッセージを盗聴することができる脅威をカバーしています。収集シグナリング・パケットは、トラフィック分析を可能にするか、セクション3.2で説明したように、リプレイ攻撃をマウントするために後で使用することができます。盗聴者は、ファイアウォールトラバーサル、ポリシー情報、アプリケーション識別子、ユーザーID、NATバインディング、権限オブジェクト、ネットワーク構成やパフォーマンス情報、および多くのためのQoSパラメータ、通信パターン、ポリシールールを学習する可能性があります。
An adversary's capability to eavesdrop on signaling messages might violate a user's preference for privacy, particularly if unprotected authentication or authorization information (including policies and profile information) is exchanged.
シグナリングメッセージを盗聴する敵の能力は、保護されていない認証または（ポリシーおよびプロファイル情報を含む）、認可情報を交換する場合は特に、プライバシー保護のため、ユーザの嗜好に違反する可能性があります。
Because the NSIS protocol signals messages through a number of nodes, it is possible to differentiate between nodes actively participating in the NSIS protocol and those that do not. For certain objects or messages, it might be desirable to permit actively participating intermediate NSIS nodes to eavesdrop. On the other hand, it might be desirable that only the intended end points (NSIS Initiator and NSIS Responder) be able to read certain other objects.
NSISプロトコルは、ノードの数を介してメッセージを通知するので、積極的にNSISプロトコルに参加しているノードとそうでないものを区別することが可能です。特定のオブジェクトやメッセージの場合は、盗聴に積極的に参加し、中間NSISノードを許容することが望ましいかもしれません。一方、それだけ意図エンドポイント（NSISイニシエータとレスポンダNSIS）がある他のオブジェクトを読み取ることができることが望ましいかもしれません。
Identity spoofing relevant for NSIS occurs in three forms: First, identity spoofing can happen during the establishment of a security association based on a weak authentication mechanism. Second, an adversary can modify the flow identifier carried within a signaling message. Third, it can spoof data traffic.
NSISに関連するアイデンティティのなりすましは三つの形式で行われます。まず、身元詐称が弱い認証メカニズムに基づくセキュリティ・アソシエーションの確立時に発生する可能性があります。第二に、敵はシグナリングメッセージの中で運ばフロー識別子を変更することができます。第三に、それは、データトラフィックを偽装することができます。
In the first case, Eve, acting as an adversary, may claim to be the registered user Alice by spoofing Alice's identity. Eve thereby causes the network to charge Alice for the network resources consumed. This type of attack is possible if authentication is based on a simple username identifier (i.e., in absence of cryptographic authentication), or if authentication is provided for hosts, and multiple users have access to a single host. This attack could also be classified as theft of service.
最初のケースでは、イブは、敵として作用する、アリスのIDをスプーフィングすることにより登録されたユーザアリスであると主張することができます。イブは、それによって消費されるネットワークリソースのためのアリスを充電するためのネットワークの原因となります。認証が（すなわち、暗号化認証の不在下で）単純なユーザ名識別子に基づいている場合、または認証をホストするために設けられており、複数のユーザが単一のホストへのアクセス権を持っている場合、このタイプの攻撃が可能です。この攻撃は、サービスの盗難に分類することができます。
In the second case, an adversary may be able to exploit the established flow identifiers (required for QoS and NAT/FW NSLP). These identifiers are, among others, IP addresses, transport protocol type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and [RFC3697]). Modification of these flow identifiers allows adversaries to exploit or to render ineffective quality of service reservations or policy rules at middleboxes. An adversary could mount an attack by modifying the flow identifier of a signaling message.
後者の場合、敵対者は確立されたフロー識別子を利用することができる（QoSおよびNAT / FW NSLPのために必要）であってもよいです。これらの識別子は他、IPアドレス、トランスポートプロトコルタイプ（UDP、TCP）ポート番号、およびフローラベル（[RFC1809]及び[RFC3697]を参照）の間です。これらのフロー識別子の変更は、敵を悪用するか、ミドルボックスでサービスの予約またはポリシールールの無効品質をレンダリングすることができます。敵対者は、シグナリングメッセージのフロー識別子を変更することによって攻撃を仕掛けることができました。
In the third case, an adversary may spoof data traffic. NSIS signaling messages contain some sort of flow identifier that is associated with a specified behavior (e.g., a particular flow experiences QoS treatment or allows packets to traverse a firewall). An adversary might, therefore, use IP spoofing and inject data packets to benefit from previously installed flow identifiers.
第三の場合、敵対者は、データトラフィックを偽装することができます。 NSISシグナリングメッセージは、指定された動作に関連付けられた（例えば、特定のフロー体験のQoS処理又はパケットがファイアウォールを通過することを可能にする）されているフロー識別子のいくつかの並べ替えを含みます。敵は、それゆえ、IPスプーフィングを使用して、以前にインストールしたフロー識別子の恩恵を受けるためにデータ・パケットを挿入することがあります。
We will provide an example of the latter threat. After NSIS nodes along the path between the NSIS initiator and the NSIS receiver processes a properly protected reservation request, transmitted by the legitimate user Alice, a QoS reservation is installed at the corresponding NSIS nodes (for example, the edge router). The flow identifier is used for flow identification and allows data traffic originated from a given source to be assigned to this QoS reservation. The adversary Eve now spoofs Alice's IP address. In addition, Alice's host may be crashed by the adversary with a denial of service attack or may lose connectivity (for example, because of mobility). If Eve is able to perform address spoofing, then she is able to receive and transmit data (for example, RTP data traffic) that receives preferential QoS treatment based on the previous reservation. Depending on the installed flow identifier granularity, Eve might have more possibilities to exploit the QoS reservation or a pin-holed firewall. Assuming the soft state paradigm, whereby periodic refresh messages are required, Alice's absence will not be detected until a refresh message is required, forcing Eve to respond with a protected signaling message. Again, this attack is applicable not only to QoS traffic, but also to a Firewall control protocol, with a different consequence.
私たちは、後者の脅威の例を提供します。 NSISイニシエータとNSIS受信機との間の経路に沿ったNSISノードが正当なユーザ、アリスによって送信された適切に保護予約要求を処理した後、QoS予約は、対応するNSISノード（例えば、エッジルータ）に設置されています。フロー識別子は、フロー識別のために使用し、このQoS予約に割り当てる所与のソースから発信データトラフィックを可能にします。敵イブは今AliceのIPアドレスを偽装します。また、Aliceのホストは、サービス拒否攻撃で敵によってクラッシュしてもよく、あるいは（例えば、理由モビリティの）接続性を失う可能性があります。イブはアドレススプーフィングを実行することが可能であるならば、彼女が受け取ると、前の予約に基づいて優先QoS処理を受ける（たとえば、RTPデータトラフィックのための）データを送信することが可能です。インストールフロー識別子の粒度に応じて、イブは、QoS予約やピンホール化ファイアウォールを利用するより多くの可能性があるかもしれません。定期的なリフレッシュメッセージが必要とされることにより、リフレッシュメッセージが必要になるまで柔らかい状態のパラダイムを想定すると、アリスの不在は、保護されたシグナリングメッセージで応答するイブを強制的に、検出されません。ここでも、この攻撃は異なる結果で、QoSトラフィックに、だけでなく、ファイアウォール制御プロトコルに限らず適用されます。
The ability for an adversary to inject data traffic that matches a certain flow identifier established by a legitimate user and to get some benefit from injecting that traffic often also requires the ability to receive the data traffic or to have one's correspondent receive it. For example, an adversary in an unmanaged network observes a NAT/Firewall signaling message towards a corporate network. After the signaling message exchange was successful, the user Alice is allowed to traverse the company firewall based on the establish packet filter in order to contact her internal mail server. Now, the adversary Eve, who was monitoring the signaling exchange, is able to build a data packet towards this mail server that will pass the company firewall. The packet will hit the mail server and cause some actions, and the mail server will reply with some response messages. Depending on the exact location of the adversary and the degree of routing asymmetry, the adversary might even see the response messages. Note that for this attack to work, Alice does not need to participate in the exchange of signaling messages.
正当なユーザーによって確立された特定のフロー識別子に一致するデータトラフィックを注入すると、トラフィックは、多くの場合も、データトラフィックを受信するか、自分の特派員がそれを受け取る持っている能力を必要とすることを注入するからいくつかの利益を得るために敵のための能力。たとえば、非管理ネットワーク内の敵は、NAT /ファイアウォールは、企業ネットワークへのシグナリングメッセージを観察します。シグナリングメッセージ交換が成功した後、ユーザーアリスは彼女の内部メールサーバに接続するために、パケットフィルタを確立するに基づいて、企業のファイアウォールを通過することが許可されています。さて、シグナリング交換を監視していた敵イブは、企業のファイアウォールを通過します。このメールサーバへのデータパケットを構築することができます。パケットは、メールサーバーをヒットし、いくつかのアクションを起こして、メールサーバは、いくつかの応答メッセージで応答するだろう。敵の正確な位置とルーティングの非対称性の程度に応じて、敵にも応答メッセージが表示される場合があります。この攻撃が機能するために、アリスはシグナリングメッセージの交換に参加する必要はないことに注意してください。
We could imagine using attributes of a flow identifier that is not related to source and destination addresses. For example, we could think of a flow identifier for which only the 21-bit Flow ID is used (without source and destination IP address). Identity spoofing and injecting traffic is much easier since a packet only needs to be marked and an adversary can use a nearly arbitrary endpoint identifier to achieve the desired result. Obviously, though, the endpoint identifiers are not irrelevant, because the messages have to hit some nodes in the network where NSIS signaling messages installed state (in the above example, they would have to hit the same firewall).
私たちは、送信元アドレスと宛先アドレスに関連していないフロー識別子の属性を使用して想像できます。例えば、我々は、21ビットのフローIDは、（ソースおよび宛先IPアドレスなし）が使用されているフロー識別子と考えることができました。パケットのみをマークする必要があり、敵対者が所望の結果を達成することはほぼ任意のエンドポイント識別子を使用することができますので、アイデンティティスプーフィングやトラフィックを注入することがはるかに簡単です。メッセージは、（上記の例では、彼らは同じファイアウォールをヒットする必要があります）NSISシグナリングメッセージがインストールされたネットワークの状態でいくつかのノードをヒットする必要があるため明らかに、しかし、エンドポイント識別子は、無関係ではありません。
Data traffic marking based on DiffServ is such an example. Whenever an ingress router uses only marked incoming data traffic for admission control procedures, various attacks are possible. These problems have been known in the DiffServ community for a long time and have been documented in various DiffServ-related documents. The IPsec protection of DiffServ Code Points is described in Section 6.2 of [RFC2745]. Related security issues (for example denial of service attacks) are described in Section 6.1 of the same document.
DiffServのマーキングに基づいたデータトラフィックは、そのような例です。入口ルータは、アドミッション制御手順についてのみマークされ、着信データトラフィックを使用するたびに、様々な攻撃が可能です。これらの問題は、長い時間のためのDiffServコミュニティで知られており、様々なDiffServの関係書類に記載されています。 DiffServコードポイントのIPsec保護は、[RFC2745]のセクション6.2に記載されています。 （サービス攻撃の例を拒否用）関連のセキュリティ問題は、同じドキュメントのセクション6.1で説明されています。
Authorization is an important criterion for providing resources such as QoS reservations, NAT bindings, and pinholes through firewalls. Authorization information might be delivered to the NSIS-participating entities in a number of ways.
承認は、ファイアウォール経由のQoS予約、NATバインディング、およびピンホールなどのリソースを提供するための重要な基準です。認証情報は、いくつかの方法でNSIS-参加するエンティティに配信されることがあります。
Typically, the authenticated identity is used to assist during the authorization procedure (as described in [RFC3182], for example). Depending on the chosen authentication protocol, certain threats may exist. Section 3 discusses a number of issues related to this approach when the authentication and key exchange protocol is used to establish session keys for signaling message protection.
典型的には、認証されたアイデンティティは、（例えば、[RFC3182]に記載されているように）許可手順中に支援するために使用されます。選択された認証プロトコルに応じて、特定の脅威が存在してもよいです。第3節では、認証と鍵交換プロトコルがメッセージ保護をシグナリングするためのセッションキーを確立するために使用され、このアプローチに関連する問題の数について説明します。
Another approach is to use some sort of authorization token. The functionality and structure of such an authorization token for RSVP is described in [RFC3520] and [RFC3521].
別のアプローチは、許可トークンのいくつかの並べ替えを使用することです。 RSVPのためのこのような認証トークンの機能および構造は、[RFC3520]及び[RFC3521]に記載されています。
Achieving secure interaction between different protocols based on authorization tokens, however, requires some care. By using such an authorization token, it is possible to link state information between different protocols. Returning an unprotected authorization token to the end host might allow an adversary (for example, an eavesdropper) to steal resources. An adversary might also use the token to monitor communication patterns. Finally, an untrustworthy end host might also modify the token content.
認証トークンに基づいて、異なるプロトコル間の安全な相互作用を達成する、しかし、いくつかの注意が必要です。このような認証トークンを用いることにより、異なるプロトコル間の状態情報をリンクすることが可能です。エンドホストに保護されていない認証トークンを返すと（例えば、盗聴者）敵対者は資源を盗むことができるようになります。敵はまた、通信パターンを監視するためにトークンを使用する場合があります。最後に、信頼できないエンドホストもトークン内容を変更することがあります。
The Session/Reservation Ownership problem can also be regarded as an authorization problem. Details are described in Section 4.10. In enterprise networks, authorization is often coupled with membership in a particular class of users or groups. This type of information either can be delivered as part of the authentication and key agreement procedure or has to be retrieved via separate protocols from other entities. If an adversary manages to modify information relevant to determining authorization or the outcome of the authorization process itself, then theft of service might be possible.
セッション/予約所有権の問題は、許可の問題とみなすことができます。詳細は、セクション4.10で説明されています。企業ネットワークでは、認証は、多くの場合、ユーザーまたはグループの特定のクラスのメンバーと結合されています。このタイプの情報は、いずれかの認証及び鍵合意手順の一部として提供され得るか、または他のエンティティから別のプロトコルを介して取得しなければなりません。敵対者が承認または認可プロセス自体の結果を決定するに関連する情報を変更するために管理している場合、サービスの盗難の可能性が生じます。
Signaling for QoS often involves three parties: the user, a network that offers QoS reservations (referred to as "service provider") and a third party that guarantees that the party making the reservation actually receives a financial compensation (referred to as "trusted third party").
QoSのためのシグナル伝達は、多くの場合、三人の者が関与：ユーザー、QoS予約を提供していますネットワーク（「サービスプロバイダ」とも呼ばれる）と当事者が予約を行うことを保証し、第三者が実際に金銭的補償を受けるには（信頼できるサード」と呼ばれますパーティー"）。
In this context,"repudiation" refers to a problem where either the user or the service provider later deny the existence or some parameters (e.g., volume or price) of a QoS reservation towards the trusted third party. Problems stemming from a lack of non-repudiation appear in two forms:
この文脈において、「否認」は、ユーザまたはサービスプロバイダのいずれかが、後で信頼できるサードパーティに向けQoS予約の有無またはいくつかのパラメータ（例えば、容積または価格）を拒否問題を指します。否認防止の欠如に起因する問題は、2つの形式で表示されます。
Service provider's point-of-view: A user may deny having issued a reservation request for which it was charged. The service provider may then want to be able to prove that a particular user issued the reservation request in question.
サービスプロバイダのポイント・オブ・ビュー：ユーザーはそれが充電されたため、予約要求を発行した拒否することができます。サービスプロバイダは、特定のユーザが当該の予約要求を発行したことを証明できるようにしたいことがあります。
User's point-of-view: A service provider may claim to have received a number of reservation requests from a particular user. The user in question may want to show that such reservation requests have never been issued and may want to see correct service usage records for a given set of QoS parameters.
ユーザのポイント・オブ・ビュー：サービスプロバイダは、特定のユーザからの予約要求の数を受信したと主張することができます。問題のユーザーは、このような予約要求が発行されていなかったとQoSパラメータのセットに対して正しいサービス使用状況レコードを見たいと思っていることを示したいことがあります。
In today's networks, non-repudiation is not provided. Therefore, it might be difficult to introduce with NSIS signaling. The user has to trust the network operator to meter the traffic correctly, to collect and merge accounting data, and to ensure that no unforeseen problems occur. If a signaling protocol with the non-repudiation property is desired for establishing QoS reservations, then it certainly impacts the protocol design.
今日のネットワークでは、否認防止が提供されていません。したがって、NSISシグナリングを導入することは困難かもしれません。ユーザーは、正しくメートルへのトラフィックをネットワークオペレータを信頼するように会計データを収集し、マージする、と何の予期せぬ問題が発生しないことを保証しなければなりません。否認防止性を有するシグナリングプロトコルは、QoS予約を確立するために必要な場合は、それ確かに影響を与えるプロトコルの設計。
Non-repudiation functionality places additional requirements on the security mechanisms. Thus, a solution would normally increase the overhead of a security solution. Threats related to missing non-repudiation are only considered relevant in certain specific scenarios and for specific NSLPs.
否認防止機能は、セキュリティ・メカニズムに追加の要件を課します。したがって、解決策は、通常、セキュリティソリューションのオーバーヘッドが増加するであろう。否認防止の欠落に関連した脅威にのみ、特定の特定のシナリオでは、特定のNSLPsに関連すると考えられています。
Network elements within a domain (intra-domain) experience a different trust relationship with regard to the security protection of signaling messages from that of edge NSIS entities. It is assumed that edge NSIS entities are responsible for performing cryptographic processing (authentication, integrity and replay protection, authorization, and accounting) for signaling messages arriving from the outside. This prevents unprotected signaling messages from appearing within the internal network. If, however, an adversary manages to take over an edge router, then the security of the entire network is compromised. An adversary is then able to launch a number of attacks, including denial of service; integrity violations; replay and reordering of objects and messages; bundling of messages; deletion of data packets; and various others. A rogue firewall can harm other firewalls by modifying policy rules. The chain-of-trust principle applied in peer-to-peer security protection cannot protect against a malicious NSIS node. An adversary with access to an NSIS router is also able to get access to security associations and to transmit secured signaling messages. Note that even non-peer-to-peer security protection might not be able to prevent this problem fully. Because an NSIS node might issue signaling messages on behalf of someone else (by acting as a proxy), additional problems need to be considered.
ドメイン（ドメイン内）内のネットワーク要素は、エッジNSIS実体のことから、シグナリングメッセージのセキュリティ保護に関して異なる信頼関係を経験します。エッジNSISエンティティは、外部から着信シグナリングメッセージのための暗号処理（認証、完全性、リプレイ保護、許可、アカウンティング）を実行する責任を負うことが想定されます。これは、内部ネットワーク内に現れるから保護されていないシグナリングメッセージを防ぎます。しかし、敵はエッジルータを引き継ぐために管理している場合、ネットワーク全体のセキュリティが危険にさらされています。敵は、サービス拒否攻撃を含め、多数のを起動することができます。整合性違反。リプレイとオブジェクトとメッセージの並べ替え。メッセージのバンドル。データパケットの削除。様々な他の人。不正なファイアウォールポリシールールを変更することによって、他のファイアウォールに害を与えることができます。ピア・ツー・ピアのセキュリティ保護に適用されるチェーン・オブ・信頼の原則は、悪意のあるNSISノードから保護することはできません。 NSISルータへのアクセス権を持つ敵はまた、セキュリティアソシエーションへのアクセスを取得すると、セキュリティで保護されたシグナリングメッセージを送信することが可能です。でも非ピア・ツー・ピアのセキュリティ保護が完全にこの問題を回避することができない場合がありますので注意してください。 NSISノードが（プロキシとして機能することによって）他の誰かに代わってシグナリングメッセージを発行する可能性があるため、追加的な問題を考慮する必要があります。
An NSIS-aware edge router is a critical component that requires strong security protection. A strong security policy applied at the edge does not imply that other routers within an intra-domain network do not need to verify signaling messages cryptographically. If the chain-of-trust principle is deployed, then the security protection of the entire path (in this case, within the network of a single administrative domain) is only as strong as the weakest link. In the case under consideration, the edge router is the most critical component of this network, and it may also act as a security gateway or firewall for incoming and outgoing traffic. For outgoing traffic, this device has to implement the security policy of the local domain and to apply the appropriate security protection.
NSIS対応のエッジルータは、強力なセキュリティ保護を必要とする重要な要素です。エッジに適用される強力なセキュリティポリシーは、ドメイン内ネットワーク内の他のルータは、暗号シグナリングメッセージを確認する必要がないことを意味するものではありません。チェーン・オブ・信頼の原則が展開されている場合、（この場合は、単一の管理ドメインのネットワーク内の）パス全体のセキュリティ保護はのみのような強い最も弱いリンクとしてです。検討中の場合、エッジルータは、このネットワークの最も重要な成分であり、それはまた、着信および発信トラフィックのためのセキュリティゲートウェイまたはファイアウォールとして機能してもよいです。送信トラフィックの場合、このデバイスは、ローカルドメインのセキュリティポリシーを実装するために、適切なセキュリティ保護を適用する必要があります。
For an adversary to mount this attack, either an existing NSIS-aware node along the path has to be attacked successfully, or an adversary must succeed in convincing another NSIS node to make it the next NSIS peer (man-in-the-middle attack).
敵対者がこの攻撃をマウントするために、パスに沿って既存のNSIS認識ノードのいずれかが正常に攻撃されている、または敵はそれを次のNSISピア（man-in-the-middle攻撃をするために別のNSISノードを納得させることに成功しなければなりません）。
A number of denial of service (DoS) attacks can cause NSIS nodes to malfunction. Other attacks that could lead to DoS, such as man-in-the-middle attacks, replay attacks, and injection or modification of signaling messages, etc., are mentioned throughout this document.
サービス拒否（DoS）攻撃の拒否の数が誤動作にNSISノードを引き起こす可能性があります。などman-in-the-middle攻撃、リプレイ攻撃、および注射またはシグナリングメッセージの変更、などのDoSにつながる可能性が他の攻撃は、この文書全体に記載されています。
Path Finding:
パスの検索：
Some signaling protocols establish state (e.g., routing state) and perform some actions (e.g., querying resources) at a number of NSIS nodes without requiring authorization (or even proper authentication) based on a single message (e.g., PATH message in RSVP).
いくつかのシグナリングプロトコルは、状態（例えば、ルーティングの状態）を確立し、単一のメッセージに基づいて承認（または適切な認証）を必要とすることなく、NSISノードの数にいくつかのアクション（例えば、照会リソース）を行う（例えば、RSVPのPATHメッセージ）。
An adversary can utilize this fact to transmit a large number of signaling messages to allocate state at nodes along the path and to cause resource consumption.
敵対者は、パスに沿ったノードの状態を割り当てることとリソース消費を引き起こすためにシグナリングメッセージの多数を送信するためにこの事実を利用することができます。
An NSIS responder might not be able to determine the NSIS initiator and might even tend to respond to such a signaling message with a corresponding reservation message.
NSISレスポンダはNSISの開始を決定することができない可能性があり、さらに、対応する予約メッセージと、そのようなシグナリングメッセージに応答する傾向があるかもしれません。
Discovery Phase:
発見フェーズ：
Conveying signaling information to a large number of entities along a data path requires some sort of discovery. This discovery process is vulnerable to a number of attacks because it is difficult to secure. An adversary can use the discovery mechanisms to convince one entity to signal information to another entity that is not along the data path, or to cause the discovery process to fail. In the first case, the signaling protocol could appear to continue correctly, except that policy rules are installed at the incorrect firewalls or QoS resource reservations take place at the wrong entities. For an end host, this means that the protocol failed for unknown reasons.
データパスに沿って多数のエンティティにシグナリング情報を伝達することは発見のいくつかの並べ替えが必要です。確保することは困難であるので、この発見プロセスは、多くの攻撃に対して脆弱です。敵対者は、データパスに沿ってない、又は検出プロセスを失敗させるために別のエンティティに情報をシグナリングするために1つのエンティティを説得する発見メカニズムを使用することができます。最初のケースでは、シグナリングプロトコルは、そのポリシールールが間違ったファイアウォールやQoSリソース予約に設置されている以外、正しく継続間違ったエンティティで場所を取るように見えることができます。エンドホストの場合、これは、プロトコルが不明な理由で失敗したことを意味します。
Faked Error or Response Messages:
偽造エラーまたは応答メッセージ：
An adversary may be able to inject false error or response messages as part of a DoS attack. This could be at the signaling message protocol layer (NTLP), the layer of each client layer protocol (e.g., QoS NSLP or NAT/Firewall NSLP), or the transport protocol layer. An adversary might cause unexpected protocol behavior or might succeed with a DoS attack. The discovery protocol, especially, exhibits vulnerabilities with regard to this threat scenario (see the above discussion on discovery). If no separate discovery protocol is used and signaling messages are addressed to end hosts only (with a Router Alert Option to intercept message as NSIS aware nodes), an error message might be used to indicate a path change. Such a design combines a discovery protocol with a signaling message exchange protocol.
敵はDoS攻撃の一環として、偽のエラーまたは応答メッセージを注入することができるかもしれません。これは、シグナリングメッセージプロトコル層（NTLP）、各クライアント層プロトコル（例えば、のQoS NSLPまたはNAT /ファイアウォールNSLP）、あるいはトランスポートプロトコル層の層であってもよいです。敵は予想外のプロトコルの動作を引き起こす可能性があるか、DoS攻撃に成功するかもしれません。発見プロトコルは、特に、（発見に上記の考察を参照されたい）、この脅威シナリオに関して脆弱性を示します。別個発見プロトコルが使用されず、シグナリングメッセージは、（NSIS認識ノードとメッセージを傍受するように、ルータ警告オプションで）ホストのみを終了するアドレス指定される場合、エラーメッセージが経路変更を示すために使用されるかもしれません。このような設計は、シグナリングメッセージ交換プロトコルに発見プロトコルを組み合わせます。
In some organizations or enterprises there is a desire not to reveal internal network structure (or other related information) outside of a closed community. An adversary might be able to use NSIS messages for network mapping (e.g., discovering which nodes exist, which use NSIS, what version, what resources are allocated, what capabilities nodes along a path have, etc.). Discovery messages, traceroute, diagnostic messages (see [RFC2745] for a description of diagnostic message functionality for RSVP), and query messages, in addition to record route and route objects, provide potential assistance to an adversary. Thus, the requirement of not disclosing a network topology might conflict with other requirements to provide means for discovering NSIS-aware nodes automatically or to provide diagnostic facilities (used for network monitoring and administration).
いくつかの組織や企業に閉鎖コミュニティの外部、内部ネットワーク構造（または他の関連情報）を明らかにしないことが望まれています。敵対者は、（例えば、ノードは存在の検出、NSISを使用して、どのバージョン、どのようなリソースなど、経路に沿ったノードが持っているもの機能、割り当てられている）ネットワークマッピングのためのNSISメッセージを使用することができるかもしれません。レコードルートとルート・オブジェクトに加えて、発見メッセージ、トレースルート、診断メッセージ（RSVPの診断メッセージ機能の説明については、[RFC2745]を参照）、およびクエリメッセージは、敵対者への潜在的支援を提供します。このように、自動的にNSIS対応ノードを発見するための手段を提供するために、他の要件と競合する可能性があり、または診断機能を提供するネットワークトポロジーを開示しないの要件は、（ネットワーク監視および管理のために使用されます）。
Figure 4 shows an NSIS Initiator that has established state information at NSIS nodes along a path as part of the signaling procedure. As a result, Access Router 1, Router 3, and Router 4 (and other nodes) have stored session-state information, including the Session Identifier SID-x.
図4は、シグナリング手順の一部として、経路に沿ってNSISノードの状態情報を確立しているNSISイニシエータを示しています。結果として、アクセスルータ1、ルータ3及びルータ4（及び他のノード）は、セッション識別子SID-Xを含む、セッション状態情報を格納しています。
Session ID(SID-x)
+--------+
+-----------------+ Router +------------>
Session ID(SID-x)| | 4 |
+---+----+ +--------+
| Router |
+------+ 3 +*******
| +---+----+ *
| *
| Session ID(SID-x) * Session ID(SID-x)
+---+----+ +---+----+
| Access | | Access |
| Router | | Router |
| 1 | | 2 |
+---+----+ +---+----+
| *
| Session ID(SID-x) * Session ID(SID-x)
+----+------+ +----+------+
| NSIS | | Adversary |
| Initiator | | |
+-----------+ +-----------+
Figure 4: Session or Reservation Ownership
図4：セッションまたは予約の所有権
The Session Identifier is included in signaling messages to reference to the established state.
セッション識別子は、確立された状態に参照するためにシグナリングメッセージ内に含まれています。
If an adversary were able to obtain the Session Identifier (for example, by eavesdropping on signaling messages), it would be able to add the same Session Identifier SID-x to a new signaling message. When the new signaling message hits Router 3 (as shown in Figure 4), existing state information can be modified. The adversary can then modify or delete the established reservation and cause unexpected behavior for the legitimate user.
敵対者は、（例えば、シグナリングメッセージに盗聴することによって）セッション識別子を取得することができた場合、新たなシグナリングメッセージに同一のセッション識別子SID-Xを追加することができるであろう。 （図4に示すように）新たなシグナリングメッセージをルータ3に当たったとき、既存の状態情報を変更することができます。敵はその後、変更または確立した予約を削除し、正当なユーザーのために予期しない動作を引き起こす可能性があります。
The source of the problem is that Router 3 (a cross-over router) is unable to decide whether the new signaling message was initiated from the owner of the session or reservation.
問題の原因は、ルータ3（クロスオーバールータは）新たなシグナリングメッセージは、セッションまたは予約の所有者から開始されたかどうかを決定することができないことです。
In addition, nodes other than the initial signaling message originator are allowed to signal information during the lifetime of an established session. As part of the protocol, any NSIS-aware node along the path (and the path might change over time) could initiate a signaling message exchange. It might, for example, be necessary to provide mobility support or to trigger a local repair procedure. If only the initial signaling message originator were allowed to trigger signaling message exchanges, some protocol behavior would not be possible.
加えて、初期のシグナリングメッセージの発信元以外のノードは、確立されたセッションの存続期間中に情報を通知するために許可されています。プロトコルの一部として、経路に沿った任意のNSIS認識ノード（そしてパスが時間とともに変化する可能性がある）のシグナリングメッセージの交換を開始することができます。例えば、モビリティサポートを提供するために、またはローカル修理手順をトリガする必要がある場合があります。唯一の初期シグナリングメッセージの発信者がメッセージ交換をシグナリングをトリガさせた場合には、いくつかのプロトコルの動作は不可能であろう。
If this threat scenario is not addressed, an adversary can launch DoS, theft of service, and various other attacks.
この脅威シナリオに対処されていない場合、敵はDoS攻撃、サービスの盗難、および他のさまざまな攻撃を仕掛けることができます。
In [2LEVEL], a two-level architecture is proposed, that would split an NSIS protocol into layers: a signaling message transport-specific layer and an application-specific layer. This is further developed in the NSIS Framework [RFC4080]. Most of the threats described in this threat analysis are applicable to the NSLP application-specific part (e.g., QoS NSLP). There are, however, some threats that are applicable to the NTLP.
シグナリングメッセージのトランスポート固有層およびアプリケーション固有層：[2LEVEL]において、二つのレベルのアーキテクチャは層にNSISプロトコルを分割するであろうと、提案されています。これはさらにNSISフレームワーク[RFC4080]で開発されています。この脅威の分析で説明した脅威の大半は、NSLPアプリケーション固有の部分（例えば、QoSのNSLP）に適用されます。 NTLPに適用されるいくつかの脅威は、しかし、があります。
Network and transport layer protocols lacking protection mechanisms are vulnerable to certain attacks, such as header manipulation, DoS, spoofing of identities, session hijacking, unexpected aborts, etc. Malicious nodes can attack the congestion control mechanism to force NSIS nodes into a congestion avoidance state.
保護メカニズムを欠くネットワークおよびトランスポート層プロトコル等、そのような予期せぬがアボートヘッダ操作、DOS、アイデンティティのなりすまし、セッションハイジャック、などの特定の攻撃に対して脆弱である悪意のあるノードは、輻輳回避状態にNSISノードを強制的に輻輳制御機構を攻撃することができ。
Threats that address parts of the NTLP that are not related to attacks against the use of transport layer protocols are covered in various sections throughout this document, such as Section 4.2.
トランスポート層プロトコルの使用に対する攻撃に関連しないNTLPの一部に対処する脅威は、第4.2節、この文書全体を通して様々なセクションに覆われています。
If existing transport layer protocols are used for exchanging NSIS signaling messages, security vulnerabilities known for these protocols need to be considered. A detailed threat description of these protocols is outside the scope of this document.
既存のトランスポート層プロトコルはNSISシグナリングメッセージを交換するために使用されている場合は、これらのプロトコルのための既知のセキュリティ上の脆弱性を考慮する必要があります。これらのプロトコルの詳細な脅威の記述は、この文書の範囲外です。
This entire memo discusses security issues relevant for NSIS protocol design. It begins by identifying the components of a network running NSIS (Initiator, Responder, and different Administrative Domains between them). It then considers five cases in which communications take place between these components, and it examines the trust relationships presumed to exist in each case: First-Peer Communications, End-to-Middle Communications, Intra-Domain Communications, Inter-Domain Communications, and End-to-End Communications. This analysis helps determine the security needs and the relative seriousness of different threats in the different cases.
この全体のメモはNSISプロトコルの設計に関連するセキュリティの問題について説明します。これは、NSIS（イニシエータ、レスポンダ、およびそれらの間の異なる管理ドメイン）を実行しているネットワークの構成要素を識別することによって始まります。その後、通信は、これらのコンポーネント間で行われる5例を考慮し、それはそれぞれの場合に存在すると推定信頼関係を調べる：ファースト・ピア通信、エンド・ツー・ミドル・コミュニケーションズ、ドメイン内コミュニケーション、ドメイン間の通信を、そしてエンドツーエンドのコミュニケーション。この分析は、セキュリティニーズと異なる場合に異なる脅威の相対的な深刻さを判断するのに役立ちます。
The document points out the need for different protocol security measures: authentication, key exchange, message integrity, replay protection, confidentiality, authorization, and some precautions against denial of service. The threats are subdivided into generic ones (e.g., man-in-the-middle attacks, replay attacks, tampering and forgery, and attacks on security negotiation protocols) and eleven threat scenarios that are particularly applicable to the NSIS protocol. Denial of service, for example, is covered in the NSIS-specific section, not because it cannot be carried out against other protocols, but because the methods used to carry out denial of service attacks tend to be protocol specific. Numerous illustrative examples provide insight into what can happen if these threats are not mitigated.
認証、鍵交換、メッセージの完全性、再生保護、機密性、認証、およびサービス拒否に対するいくつかの注意事項：ドキュメントは、異なるプロトコルセキュリティ対策の必要性を指摘しています。脅威は、一般的なものに細分化されている（例えば、man-in-the-middle攻撃、リプレイ攻撃、改ざんや偽造、攻撃セキュリティネゴシエーションプロトコル上）NSISプロトコルに特に適用可能であり、11の脅威のシナリオ。サービスの拒否は、例えば、それは他のプロトコルに対して行うことができないではないので、NSIS固有のセクションで説明されていますが、サービス拒否攻撃を実行するために使用される方法は、プロトコル特異的である傾向があるため。多くの具体例としては、これらの脅威が軽減されていない場合は何が起こるかについての洞察を提供しています。
This document repeatedly points out that not all of the threats are equally serious in every context. It does attempt to identify the scenarios in which security failures may have the highest impact. However, it is difficult for the protocol designer to foresee all the ways in which NSIS protocols will be used or to anticipate the security concerns of a wide variety of likely users. Therefore, the protocol designer needs to offer a full range of security capabilities and ways for users to negotiate and select what they need, on a case-by-case basis. To counter these threats, security requirements have been listed in [RFC3726].
この文書では、繰り返していない脅威のすべてがあらゆる状況においても同様に深刻であることを指摘しています。これは、セキュリティ失敗は最高のインパクトを持っている可能性のあるシナリオを特定しようとしません。プロトコルの設計者はNSISプロトコルが使用されますまたはおそらく、ユーザーの多種多様のセキュリティ上の問題を予測するためにするすべての方法を予見することは難しいです。そのため、プロトコル設計者が交渉し、彼らはケースバイケースで、必要なものを選択するユーザーのためのセキュリティ機能と方法の完全な範囲を提供する必要があります。これらの脅威に対抗するために、セキュリティ要件は[RFC3726]に記載されています。
We especially thank Richard Graveman, who provided text for the security considerations section, as well as a detailed review of the document.
我々は、特にセキュリティ上の考慮事項のセクションだけでなく、文書の詳細なレビューのためのテキストを提供リチャードGravemanを、感謝します。
We would like to thank (in alphabetical order) Marcus Brunner, Jorge Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their comments on an initial version of this document. Jorge and Robert gave us an extensive list of comments and provided information on additional threats.
私たちは、このドキュメントの初期バージョンに彼らのコメントのために（アルファベット順）マーカスブルンナー、ホルヘクエリャル、メフメットErsue、暁明フー、そしてロバート・ハンコックに感謝したいと思います。ホルヘとロバートは私達にコメントの広範なリストを与え、追加の脅威に関する情報を提供しました。
Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia Kappler, Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy, and Andrew McDonald provided comments on more recent versions of this document. Their input helped improve the content of this document. Roland Bless, Michael Thomas, Joachim Kross, and Cornelia Kappler, in particular, provided good proposals for regrouping and restructuring the material.
ユッカマナー、マーティンBuechli、ローランド・ブレス、マーカスブルンナー、マイケル・トーマス、セドリックアウン、ジョンLoughney、ルネSoltwisch、コーネリアKappler、テッドWiederhold、ヴィシャルSankhla、モハンパルタサラティ、そしてアンドリュー・マクドナルドは、このドキュメントの最新バージョンでコメントを提供しました。彼らの入力は、この文書の内容を改善されました。ローランドは、祝福、マイケル・トーマス、ヨアヒムKrossを、とコルネリアKapplerは、具体的には、材料を再編成し、再構築のために良い提案を提供します。
A final review was given by Michael Richardson. We thank him for his detailed comments.
最終審査は、マイケル・リチャードソンによって与えられました。私たちは、彼の詳細なコメントのために彼に感謝します。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.バン・デン・ボッシュ、 "シグナル伝達における次のステップ（NSIS）：フレームワーク"、RFC 4080、2005年6月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]ブルナー、M.、 "シグナリングプロトコルのための要件"、RFC 3726、2004年4月。
[ALN00] Aura, T., Leiwo, J., and P. Nikander, "Towards Network Denial of Service Resistant Protocols, In Proceedings of the 15th International Information Security Conference (IFIP/SEC 2000), Beijing, China", August 2000.
"サービスのネットワークの妨害に対して耐性のプロトコル、第15回国際情報セキュリティ会議の議事録（IFIP 2000 / SEC）、北京、中国では" [ALN00]オーラ、T.、Leiwo、J.、およびP. Nikander、2000年8月。
[AN97] Aura, T. and P. Nikander, "Stateless Connections", In Proceedings of the International Conference on Information and Communications Security (ICICS'97), Lecture Notes in Computer Science 1334, Springer", 1997.
[AN97]オーラ、T.およびP. Nikander、「ステートレス接続」、情報通信セキュリティ（ICICS'97）、コンピュータサイエンス1334での講義ノート、スプリンガーに関する国際会議」、1997年の議事録。
[2LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture for Internet Signaling", Work in Progress, November 2002.
[2LEVEL]ブレーデン、R.とB.リンデル、「インターネットシグナリングのための二つのレベルのアーキテクチャ」、進歩、2002年11月に作業。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697] Rajahalme、J.、コンタ、A.、大工、B.、およびS.デアリング、 "IPv6のフローラベル仕様"、RFC 3697、2004年3月。
[NATFW-NSLP] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, February 2005.
[NATFW-NSLP] Stiemerling、M.、 "NAT /ファイアウォールNSISシグナリング層プロトコル（NSLP）"、進歩、2005年2月に作業。
[GIMPS] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", Work in Progress, February 2005.
[GIMPS] Schulzrinneと、H.、 "GIMPS：シグナリングのための一般的なインターネットメッセージングプロトコル"、進歩、2005年2月に作業。
[QOS-NSLP] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress, February 2005.
[QOS-NSLP]ボッシュ、S.、Karagiannis、G.、およびA.マクドナルド、 "サービス品質シグナリングのためのNSLP"、進歩、2005年2月に作業。
[RSVP-SEC] Tschofenig, H., "RSVP Security Properties", Work in Progress, February 2005.
[RSVP-SEC] Tschofenig、H.、 "RSVPセキュリティのプロパティ"、進歩、2005年2月に作業。
[SIG-ANAL] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service Signaling Protocols", RFC 4094, May 2005.
[SIG-ANAL]マナー、J.およびX.フー、 "既存のサービス品質シグナリングプロトコルの分析"、RFC 4094、2005年5月。
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809, June 1995.
[RFC1809]ウズラ、C.、 "IPv6ではフローラベルフィールドを使用して"、RFC 1809、1995年6月。
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC2745] Terzis、A.、ブレーデン、B.、ヴィンセント、S.、およびL.チャン、 "RSVP診断メッセージ"、RFC 2745、2000年1月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182] Yadavが、S.、Yavatkar、R.、Pabbati、R.、フォード、P.、ムーア、T.、ヘルツォーク、S.、およびR.ヘス、 "RSVPのID表現"、RFC 3182、2001年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520]ハマー、L-N。、ゲージ、B.、コジンスキー、B.、およびH. Shieh、 "セッション認可ポリシーの要素"、RFC 3520、2003年4月。
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
[RFC3521]ハマー、L-N。、RFC 3521、2003年4月、ゲージ、B.、およびH. Shieh、 "メディア認証とセッションのセットアップのためのフレームワーク"。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigシーメンスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
メールアドレス：Hannes.Tschofenig@siemens.com
Dirk Kroeselberg Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ミュンヘン、バイエルン81739ドイツディルクKröselbergシーメンスオットー・ハーンリング6
EMail: Dirk.Kroeselberg@siemens.com
メールアドレス：Dirk.Kroeselberg@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、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機能のための基金は現在、インターネット協会によって提供されます。