[要約] RFC 4081は、Next Steps in Signaling（NSIS）におけるセキュリティ脅威についての要約です。このRFCの目的は、NSISプロトコルのセキュリティ上の問題を特定し、対策を提案することです。
Network Working Group H. Tschofenig
Request for Comments: 4081 D. Kroeselberg
Category: Informational Siemens
June 2005
Security Threats for Next Steps in Signaling (NSIS)
シグナリングの次のステップのセキュリティの脅威（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).
Copyright（c）The Internet Society（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
NSIのセキュリティの脅威
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/FIRWALL 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シグナル層プロトコル（NSLP）に対して詳細な脅威を提供することはできません。QOS [QOS-NSLP]、NAT/FIREWALL [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.
NTLP、NSLP（QOS 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）、および最初の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.
最終的なコミュニケーションは、役割が逆転するファーストピアコミュニケーションのバリエーションです。
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.
ドメイン間通信は、管理ドメイン間の相互作用を扱います。一部のNSLP（QoS NSLPなど）の場合、この相互作用は隣接するドメイン間で行われる可能性がありますが、他のNSLP（NAT/ファイアウォールNSLPなど）では、コアネットワークは通常関与していません。
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エンティティがエンドエンティティ（イニシエーターまたはレスポンダー）であり、もう1つのエンティティは、すぐに隣接するピア以外の中間ホップであり、通常はミドルへのエンドツーミドルシナリオと呼ばれます（図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レスポンダーに直接関与しない特定のセキュリティの脅威に対処する必要がある場合があります。
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レスポンダーの間で暗号化された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、Kerberos、または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番目のステップよりも高価になる傾向があります。これが分離の主な理由です。メッセージが頻繁に送信されない場合、これらの2つのステップは単一の、通常はかなり高価なステップに崩壊する可能性があります。そのような例の1つは、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:
セキュリティ協会を確立する際、敵は、認証しなければならないエンティティに関して信号メッセージの開始者をだまします。イニシエーターは、中間者の敵に認証され、敵は敵対者をマウントするためにシグナリングメッセージを変更したり、イニシエーターに請求されるサービスを盗むことができます。さらに、敵はイニシエーターの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は敵を検出できません。ただし、いくつかの実際の場合、ネットワークの一部に誤った信頼関係があるため、または適切なセキュリティ保護を確立できないために、次のピアが不明であるため、認証を達成するのが難しい場合があります。、セキュリティ協会の動的確立など）。通信エンドポイントの1つが不明な場合、一部のセキュリティメカニズムでは、適切なセキュリティ保護を適用することは不可能または非現実的です。ネットワーク管理者は、適切なセキュリティなしでドメイン内のシグナリングメッセージを使用する場合があります。この構成により、侵害された非NSIS認識ノードの敵がNSISシグナリングプロトコルを実行するノードを妨害することができます。このタイプの脅威は、悪意のあるNSISノードによって引き起こされる脅威を超えていることに注意してください（セクション4.7で説明）。
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エンティティは、中間の敵を発見することができません。シグナリングメッセージの相互認証は、プロトコル操作に参加する各ピアの間に行われるべきですが、ここではファーストピア通信に特別な注意が払われています。エンドホストと最初のピア（エンドホストを認証するだけ）の間の一方的な認証は、今日でも一般的ですが、エンドホストまたは（に代表される管理ドメインになりすましている中間の攻撃者に多くの可能性が開かれます。）最初のピア。
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.
最後に、シグナリングプロトコルはピアツーピアプロトコルと見なされるべきであり、イニシエーターとレスポンダーの役割をいつでも逆転させることができることに注意してください。したがって、一方的な認証は、このようなプロトコルにとって特に役立ちません。ただし、認証プロセスでは何らかの形の非対称性が必要になる場合があり、1つのエンティティは他のエンティティとは異なる認証メカニズムを使用します。例として、対称的な暗号と非対称の暗号化の組み合わせが言及されるべきです。
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の確立プロセス中に送信された情報がパスワードを漏らしたり、オフライン辞書攻撃を許可する可能性があるため、脅威を実行できます。この脅威は、特定のセキュリティメカニズムを選択するプロセスのためにNSIに適用できます。
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.
最後に、発見段階での中間（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は、発見メカニズムを備えたピアツーピアアドレス指定されたメッセージの攻撃をより詳細に説明しています。エンドツーエンドのアドレス指定されたメッセージの場合、特に敵がパスに沿って配置され、敵を横断する発見メッセージを傍受できる場合、攻撃も適用されます。中間の敵は、別の正当な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-HOPの用語で）非常に近い場合、いくつかの人種状態の特性を表します。発見プロセスが定期的に繰り返されるため、問題は自己修正であることに注意してください。敵がすべてのディスカバリーメッセージでこの攻撃を取り付けることができない場合、パスに沿った正しい次の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アドレスを含むディスカバリー応答メッセージを返します。追加情報がなければ、Discoveryメッセージイニシエーターはこの情報を信頼する必要があります。次に、特定のIPアドレスIPX（すなわち、敵）のエンティティとステップ（3）のメッセージング協会が確立されます。敵は、さらなる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.
この攻撃のバリアントとして、送信されたディスカバリーリクエストを盗聴することができない敵は、偽のディスカバリー応答メッセージでノードにあふれる可能性があります。ディスカバリーメッセージ送信者がこれらの偽のメッセージの1つを誤って受け入れる場合、図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.
この脅威シナリオは、敵が盗聴し、シグナル伝達メッセージを収集し、後でそれらを再生する場合（または別の場所で、または別の場所または別の方法でそれらの一部を使用するケースをカバーしています。 - 攻撃攻撃）。適切なリプレイ保護がなければ、敵は中間に、サービスの拒否、およびサービス攻撃の盗難をマウントする可能性があります。
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.
このタイプの脅威には整合性違反が含まれます。これにより、敵は、予期しないネットワーク動作を引き起こすために、シグナリングメッセージ（たとえば、中間の男として行動することによって）を変更します。攻撃のために敵が考慮する可能性のある行動は、メッセージの並取り、遅延、落下、注入、切り捨て、およびその他の方法でメッセージを変更します。
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.
セキュリティ協会が確立される（および使用されている）シグナリングメッセージを保護すると、多くの基本的な攻撃が防止されます。ただし、セクション4.7で説明されているように、悪意のあるNSISノードは依然としてさまざまな攻撃を実行できます。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.
iDempotentシグナル伝達メッセージは、このタイプの攻撃に対して特に脆弱です。「idempotent」という用語は、元のメッセージと同じ量の情報を含むメッセージを指します。例は、作成メッセージに相当する更新メッセージです。このプロパティにより、更新メッセージは、以前の状態が利用できない新しいパスに沿って状態を作成できます。これが機能するには、この動作をサポートする特定のクラスの暗号化メカニズムが必要です。例は、デジタル署名に基づいたスキームですが、サービス攻撃の拒否の可能性があるため、注意して使用する必要があります。
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で説明されているように、トラフィック分析を許可するか、後でリプレイ攻撃を取り付けるために使用する場合があります。盗聴者は、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に関連するアイデンティティスプーフィングは、3つの形式で発生します。まず、アイデンティティスプーフィングは、弱い認証メカニズムに基づいてセキュリティ協会の確立中に発生する可能性があります。第二に、敵は信号メッセージ内で運ばれるフロー識別子を変更できます。第三に、データトラフィックを広げることができます。
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.
最初のケースでは、敵として行動するイブは、アリスのアイデンティティをスプーフィングすることにより、登録されたユーザーアリスであると主張する場合があります。それにより、イブはネットワークに消費されたネットワークリソースに対してアリスを請求します。認証が単純なユーザー名識別子（つまり、暗号化認証がない場合）に基づいている場合、またはホストに認証が提供され、複数のユーザーが単一のホストにアクセスできる場合、このタイプの攻撃は可能です。この攻撃は、サービスの盗難として分類することもできます。
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.
2番目のケースでは、敵が確立されたフロー識別子（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.
3番目のケースでは、敵がデータトラフィックを広げる可能性があります。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予約に割り当てることができます。敵イブは現在、アリスのIPアドレスを押し上げています。さらに、アリスのホストは、サービス攻撃の拒否で敵によってクラッシュするか、接続性を失う可能性があります（たとえば、モビリティのため）。Eveがアドレススプーフィングを実行できる場合、彼女は以前の予約に基づいて優先QoS処理を受けるデータ（たとえば、RTPデータトラフィック）を受信および送信することができます。インストールされているフロー識別子の粒度に応じて、イブはQoS予約またはピン留めのファイアウォールを活用する可能性が増える可能性があります。定期的な更新メッセージが必要なソフト状態のパラダイムを仮定すると、アリスの不在は更新メッセージが必要になるまで検出されず、Eveに保護されたシグナル伝達メッセージで応答します。繰り返しますが、この攻撃は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予約（「サービスプロバイダー」と呼ばれる）を提供するネットワーク、および予約を作成する当事者が実際に財務補償を受け取ることを保証する第三者の3つの関係者が含まれます。パーティー"）。
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予約の存在またはいくつかのパラメーター（量や価格）を拒否する問題を指します。非repudiationの欠如に起因する問題は、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予約を確立するために非repudiationプロパティを使用したシグナリングプロトコルが望まれる場合、それは確かにプロトコル設計に影響を与えます。
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.
非和解機能は、セキュリティメカニズムに追加の要件を置きます。したがって、ソリューションは通常、セキュリティソリューションのオーバーヘッドを増加させます。不正行為の欠落に関連する脅威は、特定の特定のシナリオおよび特定のNSLPでのみ関連すると見なされます。
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.
ドメイン内のネットワーク要素（ドメイン内）は、Edge NSISエンティティのシグナリングメッセージのセキュリティ保護に関して、異なる信頼関係を経験します。EDGE 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ピアにするために別の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ノードが誤動作を引き起こす可能性があります。中間の攻撃、リプレイ攻撃、信号メッセージの注入または修正など、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).
一部のシグナリングプロトコルは、状態（例えば、ルーティング状態）を確立し、単一のメッセージ（RSVPのパスメッセージ）に基づいて許可（または適切な認証）を必要とせずに、いくつかのアクション（例：リソースをクエリするリソース）を実行します（または適切な認証）を実行します。
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.
データパスに沿って多数のエンティティに信号情報を伝えるには、何らかの発見が必要です。この発見プロセスは、保護が困難であるため、多くの攻撃に対して脆弱です。敵は、発見メカニズムを使用して、あるエンティティにデータパスに沿っていない別のエンティティに情報を通知するよう説得したり、発見プロセスを失敗させたりすることができます。最初のケースでは、シグナリングプロトコルは正しく続くように見える可能性がありますが、ポリシールールが間違ったファイアウォールにインストールされているか、間違ったエンティティで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メッセージを使用できる可能性があります（たとえば、どのノードが存在するか、どのバージョン、どのリソース、割り当てられているか、パスに沿ったノードがあるなどを発見します。Discoveryメッセージ、Traceroute、診断メッセージ（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を新しいシグナリングメッセージに追加できます。新しい信号メッセージがルーター3にヒットすると（図4を参照）、既存の状態情報を変更できます。敵は、確立された予約を変更または削除し、合法的なユーザーに予期しない動作を引き起こすことができます。
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.
問題の原因は、Router 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]では、2レベルのアーキテクチャが提案されており、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.
このドキュメントは、認証、キー交換、メッセージの整合性、リプレイ保護、機密性、承認、サービス拒否に対するいくつかの予防措置など、さまざまなプロトコルセキュリティ対策の必要性を指摘しています。脅威は、一般的なもの（例：中間攻撃、リプレイ攻撃、改ざんと偽造、セキュリティ交渉プロトコルの攻撃）および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.
特に、セキュリティに関する考慮事項セクションのテキストを提供してくれたリチャードグレイグマンと、ドキュメントの詳細なレビューに感謝します。
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.
この文書の初期バージョンに関するコメントについて、（アルファベット順の順序で）マーカスブルナー、ホルヘクエラー、メフメットアース、Xiaoming Fu、およびロバートハンコックに感謝します。ホルヘとロバートは、コメントの広範なリストを提供し、追加の脅威に関する情報を提供しました。
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.
ジュッカマナー、マーティンブックリ、ローランドブレッシング、マーカスブルナー、マイケルトーマス、セドリックアウン、ジョンラフニー、レネソルヴィシュ、コーネリアカプラー、テッドウィーダーホールド、ヴィシャルサンクラ、モハンパルタサラシー、アンドリューマクドナルドは、この文書のコメントを提供しました。彼らの入力は、このドキュメントのコンテンツを改善するのに役立ちました。特に、ローランド・ブレス、マイケル・トーマス、ヨアヒム・クロス、コーネリア・カプラーは、資料を再編成し、再構築するための良い提案を提供しました。
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] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「シグナリングの次のステップ（NSIS）：フレームワーク」、RFC 4080、2005年6月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726] Brunner、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.
[ALN00] Aura、T.、Leiwo、J。、およびP. Nikander、「第15回国際情報セキュリティ会議（IFIP/SEC 2000）の議事録、中国北京の議事録に向けて」。
[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] Aura、T。およびP. Nikander、「Stateless Connections」、情報通信セキュリティに関する国際会議（ICICS'97）の議事録、コンピューターサイエンス1334、Springerの講義ノート」、1997年。
[2LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture for Internet Signaling", Work in Progress, November 2002.
[2レベル] Braden、R。およびB. Lindell、「インターネットシグナル伝達のための2レベルのアーキテクチャ」、2002年11月、進行中の作業。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697] Rajahalme、J.、Conta、A.、Carpenter、B。、およびS. Deering、「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/Firewall NSIS Signaling Layer Protocol（NSLP）」、2005年2月の作業。
[GIMPS] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", Work in Progress, February 2005.
[Gimps] Schulzrinne、H。、「Gimps：Signalingの一般的なインターネットメッセージングプロトコル」、2005年2月の作業。
[QOS-NSLP] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress, February 2005.
[QOS-NSLP] Bosch、S.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のための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] MANER、J。およびX. FU、「既存のサービス品質シグナル伝達プロトコルの分析」、RFC 4094、2005年5月。
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809, June 1995.
[RFC1809] Partridge、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.、Braden、B.、Vincent、S。、およびL. Zhang、「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.、Ford、P.、Moore、T.、Herzog、S。、およびR. Hess、「RSVPのアイデンティティ表現」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520] Hamer、L-N。、Gage、B.、Kosinski、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] Hamer、L-N。、Gage、B。、およびH. Shieh、「メディア認可とのセットアップのフレームワーク」、RFC 3521、2003年4月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Dirk Kroeselberg Siemens Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Dirk.Kroeselberg@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。