RFC4081 日本語訳
4081 Security Threats for Next Steps in Signaling (NSIS). H.Tschofenig, D. Kroeselberg. June 2005. (Format: TXT=67786 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Tschofenig
Request for Comments: 4081 D. Kroeselberg
Category: Informational Siemens
June 2005
Tschofenigがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4081年のD.Kroeselbergカテゴリ: 情報のジーメンス2005年6月
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)インターネット協会(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.
この脅威ドキュメントはSignaling(NSIS)プロトコル群のNext Stepsに関連している軍事的脅威の詳細に渡る分析を提供します。 理解で注意を促して、助ける、NSIS Requirements、Framework、およびプロトコル提案における様々なセキュリティ問題。 このドキュメントは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
1. 序論…2 2. コミュニケーションモデル…3 3. ジェネリックの脅威…7 3.1. 中央の男性は攻撃します…8 3.2. シグナリングメッセージの再生…11 3.3. メッセージを注入するか、または変更します…11 3.4. 不安定なパラメータ変換と交渉…12 4. NSIS特有の脅威シナリオ…12 4.1. NSIS SA用法の間の脅威…13 4.2. 氾濫…13 4.3. 盗聴とトラフィック分析…15 4.4. アイデンティティスプーフィング…15 4.5. 保護のない承認情報…17 4.6. なくなった非拒否…18 4.7. 悪意があるNSIS実体…19 4.8. サービス妨害は攻撃されます…20 4.9. ネットワーク形態を明らかにします…21 4.10. 保護のないセッションか予約所有権…21 4.11. NTLPに対する攻撃…23
Tschofenig & Kroeselberg Informational [Page 1] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[1ページ]のRFC4081軍事的脅威
5. Security Considerations ........................................23
6. Contributors ...................................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
5. セキュリティ問題…23 6. 貢献者…24 7. 承認…24 8. 参照…25 8.1. 標準の参照…25 8.2. 有益な参照…25
1. Introduction
1. 序論
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肛門]で、見ます)
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プロトコル群(ギンプ[ギンプ]、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 Signaling Layerプロトコル(NSLPs)に詳細な脅威を提供できません。 QoS[QOS-NSLP]、NAT/ファイアウォール[NATFW-NSLP]、および他のNSLPドキュメントは、彼らの信頼モデルと脅威査定の記述を彼らの特定のアプリケーションドメインに提供する必要があります。 このドキュメントは、NSISプロトコル群のその後のデザインのための何らかの助けを提供することを目指します。 このドキュメントの範囲の外に特定のアーキテクチャか文脈における、軍事的脅威の調査があります。
We use the NSIS terms defined in [RFC3726] and in [RFC4080].
私たちは[RFC3726]と[RFC4080]で定義されたNSIS用語を使用します。
Tschofenig & Kroeselberg Informational [Page 2] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[2ページ]のRFC4081軍事的脅威
2. Communications Models
2. コミュニケーションモデル
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 InitiatorとNSIS Responderの間の経路に沿った中間的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 Initiatorとして機能する)と最初のNSISノード(付属ネットワークか多くのネットワークでさえ遠くにあるかもしれない)とのコミュニケーションを保証するのに影響を与えます。 企業ネットワーク環境では、信頼の非管理されたネットワークより強い度合いは通常存在しています。
Figure 1 introduces convenient abbreviations for network parts with similar properties: first-peer, last-peer, intra-domain, or inter-domain.
図1は同様の特性でネットワーク一部に便利な略語を紹介します: 最初に、同輩、最後の同輩、イントラドメイン、または相互ドメイン。
Tschofenig & Kroeselberg Informational [Page 3] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[3ページ]のRFC4081軍事的脅威
+------------------+ +---------------+ +------------------+
| | | | | |
| 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 |
+-----------+ +-----------+
+------------------+ +---------------+ +------------------+ | | | | | | | 管理| | 中間的| | 管理| | ドメインA| | ドメイン| | ドメインB| | | | | | | | (相互ドメインコミュニケーション) | | +-------->+---+ <。------------->+---+ <。--------+ | | (イントラドメイン| | | | (イントラドメイン| | コミュニケーション)| | | | コミュニケーション) | | | | | | | | | | v| | | | v| +--------+---------+ +---------------+ +---------+--------+ ^ ^ | | まず最初に、同輩コミュニケーションは同輩コミュニケーションを持続します。| | v対+-----+-----+ +-----+-----+ | NSIS| | NSIS| | 創始者| | 応答者| +-----------+ +-----------+
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 Initiator(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
ローミング環境でこれを例証するために、プレ設立されたセキュリティ協会の存在が直接最初に、同輩コミュニケーションにかかわるNSIS同輩に利用可能であると仮定するのは難しいです、これらの同輩には互いとのどんな先在の関係もあると思うことができないので。 対照的に、企業網には、同輩の間には、通常、かなり強い(あらかじめ設立される)信頼関係があります。 企業網の管理者には、通常、適切な機密保持を選択して、それを実施するいくらかの自由があります。 したがって、セキュリティー対策を選択することの選択はしばしばインフラストラクチャによって既に影響を及ぼされます。
Tschofenig & Kroeselberg Informational [Page 4] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[4ページ]のRFC4081軍事的脅威
available, and per-session negotiation of security mechanisms is
often not required (although, in contrast, it is required in a
roaming environment).
利用可能である、そして、セキュリティー対策の交渉がしばしば必要であるというわけではない(それがaローミング環境で対照的に、必要ですが)セッション。
Last-Peer communication is a variation of First-Peer communication
in which the roles are reversed.
最後の同輩コミュニケーションは役割が逆にされるFirst-同輩コミュニケーションの変化です。
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.
相互Domainコミュニケーションは管理ドメインの間の相互作用に対処します。 いくつかのNSLPs(例えば、QoS NSLP)に関しては、コアネットワークは通常他のNSLPs(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プロトコル群にかかわる実体の間の可能な関係を例証します。
Tschofenig & Kroeselberg Informational [Page 5] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[5ページ]のRFC4081軍事的脅威
****************************************
* *
+----+-----+ +----------+ +----+-----+
+-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+
| | Node 1 | | Node 2 | | Node 3 | |
| +----------+ +----+-----+ +----------+ |
| ~ |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| ~ |
+--+--+-----+ +---------+-+
| NSIS +//////////////////////////////////////////+ NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
**************************************** * * +----+-----+ +----------+ +----+-----+ +-----+ NSIS+-------+ NSIS+--------+ NSIS+-----+ | | ノード1| | ノード2| | ノード3| | | +----------+ +----+-----+ +----------+ | | ~ | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | ~ | +--+--+-----+ +---------+-+ | NSIS+//////////////////////////////////////////+NSIS| | 創始者| | 応答者| +-----------+ +-----------+
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].
実体がかかわったNSISが終わり実体(創始者かResponder)であり、もう片方の実体がすぐに隣接している同輩以外のあらゆる中間的ホップであるシナリオは通常終わりから中央へのシナリオと呼ばれます(図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 Initiatorから中間的何らかのノードまで終わりから中央への相互作用に関する例は明白な承認であるかもしれません。 あるオブジェクトを盗み聞くことができないか、変更できないいくつかの中間的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 InitiatorかNSIS Responderにかかわらない特定の軍事的脅威に対処しなければならないかもしれません。
Tschofenig & Kroeselberg Informational [Page 6] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[6ページ]のRFC4081軍事的脅威
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 Responderです、それがデータ受信装置であるので。NSISは、経路に沿ってInitiatorからいくつかの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 InitiatorとNSIS Responderの間に暗号でNSISメッセージを保護するのに通常、必要ではありません。 中間的NSISノードが、シグナリングメッセージからオブジェクトを加えるか、点検するか、変更するか、または削除する必要があるので、全体のシグナリングのメッセージの終わりから終わりを保護するのは可能でないかもしれません。
3. Generic Threats
3. ジェネリックの脅威
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番目より高価である傾向があります。(2番目は分離の主な理由です)。 メッセージがまれに送られるなら、これらの2ステップは単一の、そして、通常かなり高価なものまで潰されるかもしれません。 その一例はS/MIMEを通した電子メール保護です。 2ステップは、TLSのようにしっかりただ一つのプロトコルに向かっているか、または別々のプロトコルで定義されるかもしれません、IKEとIPsecのように。 私たちは、さらに詳細に異なった脅威をカバーするのにこの分離を使用します。
Tschofenig & Kroeselberg Informational [Page 7] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[7ページ]のRFC4081軍事的脅威
3.1. Man-in-the-Middle Attacks
3.1. 介入者攻撃
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:
セキュリティ協会を設立している間、敵は実体に関してそれが認証しなければならないものにシグナリングメッセージInitiatorをだまします。 Initiatorが中の男性に認証する、-、-、中央、敵。(次に、その敵はDoS攻撃を仕掛けるか、またはInitiatorに請求されるサービスを横取りするシグナリングメッセージを変更できます)。 さらに、敵は、InitiatorのNSISメッセージを終えて、同輩自身にメッセージを注入できるかもしれません、その結果、Initiatorへの同輩としてInitiatorとして同輩に機能します。 その結果、Initiatorは、それが「本当」のネットワークと話していると誤って信じていますが、それは実際に敵に愛着しています。 この攻撃がうまくいっているために、以下の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つが未知であるなら、いくつかのセキュリティー対策に、適切な機密保持を適用するのは、不可能であるか、または非実用的です。 時々、ネットワーク管理者は適切なセキュリティなしでイントラドメインシグナリングメッセージを使用します。 この構成が感染されるaに敵を許容する、非NSIS意識する、NSISシグナリングプロトコルを実行しながらノードを妨げるノード。 このタイプの脅威が悪意があるNSISノード(セクション4.7では、説明される)によって引き起こされたものを越えることに注意してください。
Tschofenig & Kroeselberg Informational [Page 8] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[8ページ]のRFC4081軍事的脅威
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.
最終的に、シグナリングプロトコルがピアツーピアプロトコルであると考えられるべきであることに注意してください。(そこでは、いつでも、InitiatorとResponderの役割を逆にすることができます)。 したがって、一方的な認証は特にそのようなプロトコルの役に立ちません。 しかしながら、何らかのフォームの非対称が認証過程で必要であるかもしれません。(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設立プロセスの間に伝えられた情報がパスワードを漏らすか、またはオフライン辞書攻撃を許容するかもしれないので、脅威を行うことができます。 あるセキュリティー対策を選択するプロセスに、この脅威は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
最終的に、私たちは発見段階の間、中央の男性(MITM)攻撃の記述で締めくくります。 この攻撃はNSISノードがネットワークに気づかない傾向があるという事実の利益を得ます。
Tschofenig & Kroeselberg Informational [Page 9] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[9ページ]のRFC4081軍事的脅威
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.
トポロジー。 その上、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
+-----------+ メッセージング協会メッセージ| 敵| 設立協会+--->++<。----------------+は設立します。| +----+------+ |(4) ment| IPx| | (3)| |発見Reply v| | (IPx) +---+-------+ v| (2) | NSIS| +------+-----+ | /----------->+ノードB+-------- | NSIS+<--+/発見+-----------+ | ノードは+です。---------/要求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ノードは再び発見されるでしょう。 ピンポンの振舞いは結果であるかもしれません。
Tschofenig & Kroeselberg Informational [Page 10] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[10ページ]のRFC4081軍事的脅威
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 Node Aに経路に沿ってない別のNSISノードとのメッセージング協会を設立させるディスカバリーReplyメッセージを変更するかもしれないことに注意してください。 そして、敵はこれを利用できます。 特にNSIS気づかないNATsとの織り込むのは追加万一の事態を引き起こすかもしれません。
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攻撃は可能です。
3.2. Replay of Signaling Messages
3.2. シグナリングメッセージの再生
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意識しているノードを墜落させるのを必要とします、州の情報(一連番号、セキュリティ協会など)を失って、次に、古いシグナリングメッセージを再演することを引き起こして。 この攻撃は再同期欠乏を利用します。
3.3. Injecting or Modifying Messages
3.3. メッセージを注入するか、または変更します。
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
敵は多量のリソースを要求するシグナリングメッセージを注入するかもしれません(ことによると異なったユーザのアイデンティティを使用して)。 そして、他の資源要求は拒絶されるかもしれません。 アイデンティティと組み合わせて
Tschofenig & Kroeselberg Informational [Page 11] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[11ページ]のRFC4081軍事的脅威
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で説明されます。
3.4. Insecure Parameter Exchange and Negotiation
3.4. 不安定なパラメータ変換と交渉
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.
まず最初に、プロトコルは異なったセキュリティ要件によってさまざまなシナリオで役に立つかもしれません。 2番目に、異なったユーザ(例えば、大学、病院、営利事業、または政府省)には、本来異なったセキュリティ要件があります。 3番目に、ネットワーク(例えば、パブリックキャリアのネットワーク、または、ビルか、個人的なマイクロ波中継装置の上の)の異なった部分は異なったレベルの保護を必要とするかもしれません。 しばしばメカニズムとパラメタの品揃えを提供して、ただ一つのセキュリティー対策か固定セットのセキュリティパラメタでこれらの(時々闘争しています)の必要条件を満たすのはしばしば難しいです。 したがって、プロトコルが、あるセキュリティー対策とパラメタに同意するのに必要です。 不安定なパラメータ変換かセキュリティ交渉プロトコルが、敵がそれらより弱いメカニズムの品揃えを互いに必要に強制するために格下げ攻撃を仕掛けるのを助けることができます。 したがって、正統のパーティーに交渉プロセスを縛って、それを保護しないで、NSISプロトコル群は単に最も弱いメカニズムが(例えば、弱い認証)を提供したのと同じくらい安全であるかもしれません、そして、設定パラメータを定義する利益と交渉プロトコルは無くなっています。
4. NSIS-Specific Threat Scenarios
4. 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つ以上の欠乏によって可能にされます。
Tschofenig & Kroeselberg Informational [Page 12] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[12ページ]のRFC4081軍事的脅威
4.1. Threats during NSIS SA Usage
4.1. NSIS SA用法の間の脅威
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ノードが州の再建を墜落して、再開して、実行するとき、反射攻撃は可能であるかもしれません。 したがって、このその問題を訴えるためにセキュリティー対策の適切な再同期を提供しなければなりません。
4.2. Flooding
4.2. 氾濫
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.
Router Alert Option(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.
プロトコルがメッセージ配送に妨害を使用するのに基づいているなら、完全にこの脅威を排除できるというわけではありませんが、プロトコルデザインは、直接ルータインタフェースの1つに扱われた任意のパケットには、それができるだけそれと同様であるようにRAO-ベアリングパケットでしなければならない処理を制限するのを試みるべきです。
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で扱われます。
Tschofenig & Kroeselberg Informational [Page 13] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[13ページ]のRFC4081軍事的脅威
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.
ベキ等元シグナリングメッセージは特にこのタイプの攻撃に被害を受け易いです。 「ベキ等元」という用語はオリジナルのメッセージと同じ情報量を含むメッセージを示します。 例はaがメッセージをリフレッシュするということでしょう、すなわち、aと同等物がメッセージを作成します。 特性がaを許容するこれは新しい経路に沿って状態を創設するメッセージをリフレッシュします。そこでは、前のないのが利用可能です。 これが働くように、この振舞いをサポートする特定のクラスの暗号のメカニズムが必要です。 例はしかしながら、可能なサービス不能攻撃のため慎重に使用されるべきであるデジタル署名に基づく体系です。
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予約の要請で)を送ることができるなら、検証ノードは正統のユーザから他の予約メッセージを処理できないかもしれません。
Tschofenig & Kroeselberg Informational [Page 14] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[14ページ]のRFC4081軍事的脅威
4.3. Eavesdropping and Traffic Analysis
4.3. 盗聴とトラヒック分析
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パラメタ、コミュニケーションパターン、ファイアウォール縦断、方針情報、アプリケーション識別子、ユーザアイデンティティ、NAT結合、承認オブジェクト、ネットワーク・コンフィギュレーション、および性能情報のための政策ルール、およびその他を学ぶかもしれません。
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 InitiatorとNSIS Responder)だけが他のあるオブジェクトを読むことができるのは、望ましいかもしれません。
4.4. Identity Spoofing
4.4. アイデンティティスプーフィング
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つのフォームに起こります: まず最初に、アイデンティティスプーフィングは弱い認証機構に基づくセキュリティ協会の設立の間、起こることができます。 2番目に、敵はシグナリングメッセージの中で運ばれた流れ識別子を変更できます。 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
2番目の場合では、敵は確立した流れ識別子(QoSとNAT/FW NSLPのために、必要である)を利用できるかもしれません。 これらの識別子は、特にIPアドレスと、トランスポート・プロトコルタイプ(UDP、TCP)と、ポートナンバーと、流れラベル([RFC1809]と[RFC3697]を見る)です。 これらの流れ識別子の変更は利用するか、または効果がないサービスの質をする敵を許容します。
Tschofenig & Kroeselberg Informational [Page 15] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[15ページ]のRFC4081軍事的脅威
reservations or policy rules at middleboxes. An adversary could mount an attack by modifying the flow identifier of a signaling message.
middleboxesの予約か政策ルール。 敵は、シグナリングメッセージに関する流れ識別子を変更することによって、攻撃を開始できるでしょう。
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アドレスを偽造します。 さらに、アリスのホストは、サービス不能攻撃に従って敵が墜落するか、または接続性(例えば移動性のために)を失うかもしれません。 イブがアドレススプーフィングを実行できるなら、彼女は、前の予約に基づく優先のQoS処理を受けるデータ(例えば、RTPデータ通信量)を、受け取って、送ることができます。 インストールされた流れ識別子粒状によって、イブにはQoSの予約を利用するより多くの可能性かピンで掘られたファイアウォールがあるかもしれません。 軟性国家パラダイムを仮定する、どうして、周期的である、必要であることで、アリスの不在がaがリフレッシュするまで検出されて、メッセージが必要であるということでないということであり、イブをaで応じさせているのがシグナリングメッセージを保護したというメッセージをリフレッシュしてください。 一方、この攻撃は単にQoSトラフィックに適切であるのではなく、Firewall制御プロトコルにも適切です、異なった結果で。
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
また、敵が正統のユーザによって確立されたある流れ識別子に合っているデータ通信量を注入して、そのトラフィックを注入するのから何らかの利益を得る能力はしばしばデータ通信量を受けるか、または人の通信員にそれを受けさせる能力を必要とします。 例えば、非管理されたネットワークにおける敵はNAT/ファイアウォールシグナリングメッセージを企業ネットワークに向かって観測します。 彼女の内部のメールサーバに連絡するためにパケットフィルタを設立してください。後に、シグナリング交換処理はうまくいきました、アリスがベースの会社のファイアウォールを横断できるユーザ、現在、敵のイブ(シグナリング交換をモニターしていた)は会社のファイアウォールを通り過ぎるこのメールサーバに向かってデータ・パケットを建てることができます。 パケットは、メールサーバを打って、いくつかの動作を引き起こすでしょう、そして、メールサーバはいくつかの応答メッセージで返答するでしょう。 そして敵の正確な位置による。
Tschofenig & Kroeselberg Informational [Page 16] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[16ページ]のRFC4081軍事的脅威
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.
ルーティング非対称の度合い、敵は応答メッセージを見さえするかもしれません。 この攻撃が働くように、アリスがシグナリングメッセージの交換に参加する必要はないことに注意してください。
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ビットのFlow 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 Code PointsのIPsec保護は[RFC2745]のセクション6.2で説明されます。 関連安全保障問題(例えば、サービス不能攻撃)は同じドキュメントのセクション6.1で説明されます。
4.5. Unprotected Authorization Information
4.5. 保護のない承認情報
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)
しかしながら、承認トークンに基づく異なったプロトコルの間の安全な相互作用を達成するのは何らかの注意を必要とします。 そのような承認トークンを使用することによって、異なったプロトコルの間の州の情報をリンクするのは可能です。 保護のない承認トークンを終わりのホストに返すと、敵は許容されるかもしれません。(例えば、立ち聞きする者)
Tschofenig & Kroeselberg Informational [Page 17] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[17ページ]のRFC4081軍事的脅威
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.
また、Session/予約Ownership問題を承認問題と見なすことができます。 詳細はセクション4.10で説明されます。 企業網では、承認は、しばしば特定のクラスのユーザの会員資格に結びつけられるか、または分類されます。 この情報の種類は、認証と主要な協定手順の一部として提供できなければならないか、または他の実体からの別々のプロトコルで救済されなければなりません。 敵が何とか承認を決定すると関連している情報か承認プロセス自体の結果を変更するなら、サービスの窃盗は可能であるかもしれません。
4.6. Missing Non-Repudiation
4.6. なくなった非拒否
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のために合図するのはしばしば3回のパーティーにかかわります: ユーザ、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
今日のネットワークには、非拒否は提供されません。 したがって、NSISと共にシグナリングを導入するのは難しいかもしれません。 ユーザは、ネットワーク・オペレータが正しくトラフィックを計量して、会計データを集めて、合併して、そのノーに予期せぬ問題を保証すると信じなければなりません。
Tschofenig & Kroeselberg Informational [Page 18] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[18ページ]のRFC4081軍事的脅威
occur. If a signaling protocol with the non-repudiation property is desired for establishing QoS reservations, then it certainly impacts the protocol design.
起こってください。 非拒否の特性があるシグナリングプロトコルが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において関連していると考えられるだけです。
4.7. Malicious NSIS Entity
4.7. 悪意があるNSIS実体
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意識している縁のルータは強い機密保持を必要とする重要な要素です。 縁で適用された強い安全保障政策はイントラドメインネットワークの中の他のルータが暗号でシグナリングメッセージについて確かめる必要はないつもりです。 原則が信頼のチェーンであるなら配布されて、次に、セキュリティが全体の経路の保護である、(この場合、ただ一つの管理ドメインのネットワーク、)、単に最も弱いリンクと同じくらい強いです。 考慮している場合では、縁のルータはこのネットワークの最も重大な成分です、そして、また、それは送受信のトラフィックのためのセキュリティゲートウェイかファイアウォールとして機能するかもしれません。 外向的なトラフィックのために、このデバイスは、局所領域の安全保障政策を実装して、適切な機密保持を適用しなければなりません。
Tschofenig & Kroeselberg Informational [Page 19] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[19ページ]のRFC4081軍事的脅威
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ノードに納得させるのに成功しなければなりません。
4.8. Denial of Service Attacks
4.8. サービス不能攻撃
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のPATHメッセージ)に基づく承認(または、適切な認証さえ)を必要としないで、いくつかのシグナリングプロトコルが、状態(例えば、ルーティング状態)を設置して、多くのNSISノードでいくつかの動作を実行します(例えば、リソースについて質問します)。
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資源予約が間違った実体で行われるのを除いて。 終わりのホストに関しては、これは、プロトコルが未知の理由で失敗したことを意味します。
Tschofenig & Kroeselberg Informational [Page 20] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[20ページ]のRFC4081軍事的脅威
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攻撃で成功するかもしれません。 発見プロトコルはこの脅威シナリオに関して脆弱性を特に示します(発見についての上の議論を見てください)。 どんな別々の発見プロトコルも使用されていなくて、シグナリングメッセージがホストだけを終わらせるために扱われるなら、エラーメッセージは、経路変化を示すのに使用されるかもしれません。 そのようなデザインはシグナリング交換処理プロトコルに発見プロトコルを結合します。
4.9. Disclosing the Network Topology
4.9. ネットワーク形態を明らかにします。
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意識しているノードを発見するための手段を提供するか、または診断施設(ネットワーク監視と管理のために、使用される)を提供するという他の要件と衝突するかもしれません。
4.10. Unprotected Session or Reservation Ownership
4.10. 保護のないセッションか予約所有権
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 Initiatorにノードを示しています。 その結果、Access Router1、Router3、およびRouter4(そして、他のノード)はセッション州の情報を保存しました、Session Identifier SID-xを含んでいて。
Tschofenig & Kroeselberg Informational [Page 21] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[21ページ]のRFC4081軍事的脅威
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 | | |
+-----------+ +-----------+
セッションID(SID-x)+--------+ +-----------------+ ルータ+------------>Session ID(SID-x)| | 4 | +---+----+ +--------+ | ルータ| +------+ 3 +******* | +---+----+ * | * | セッションID(SID-x)*Session ID(SID-x)+---+----+ +---+----+ | アクセス| | アクセス| | ルータ| | ルータ| | 1 | | 2 | +---+----+ +---+----+ | * | セッションID(SID-x)*Session ID(SID-x)+----+------+ +----+------+ | NSIS| | 敵| | 創始者| | | +-----------+ +-----------+
Figure 4: Session or Reservation Ownership
図4: セッションか予約所有権
The Session Identifier is included in signaling messages to reference to the established state.
Session Identifierはシグナリングメッセージで設立された状態の参照に含められています。
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.
敵がSession Identifier(例えばシグナリングメッセージを立ち聞きすることによって)を入手できるなら、新しいシグナリングメッセージに同じSession Identifier SID-xを追加できるでしょうに。 新しいシグナリングメッセージがRouter3を打つと(図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.
問題の源はRouter3(クロスオーバールータ)が、新しいシグナリングメッセージがセッションか予約の所有者から開始されたかどうか決めることができないということです。
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意識しているノードもシグナリング交換処理に着手するかもしれません。 例えば、移動性サポートを提供するか、または局部的修繕手順の引き金となるのが必要であるかもしれません。 何らかのプロトコルの振舞いは初期のシグナリングメッセージ創始者がシグナリング交換処理の引き金となることさえできるならよいのが可能でないでしょう。
Tschofenig & Kroeselberg Informational [Page 22] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[22ページ]のRFC4081軍事的脅威
If this threat scenario is not addressed, an adversary can launch DoS, theft of service, and various other attacks.
この脅威シナリオが扱われないなら、敵はDoS、サービスの窃盗、および他の様々な攻撃に着手できます。
4.11. Attacks against the NTLP
4.11. NTLPに対する攻撃
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 Framework[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.
脅威は関連されないで、トランスポート層プロトコルの使用に対する攻撃がこのドキュメント中の様々なセクションでカバーされています、セクション4.2などのようにことであるNTLPのそのアドレス部です。
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シグナリングメッセージを交換するのに使用されるなら、これらのプロトコルで知られているセキュリティの脆弱性は、考えられる必要があります。 このドキュメントの範囲の外にこれらのプロトコルの詳細な脅威記述があります。
5. Security Considerations
5. セキュリティ問題
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(創始者、Responder、および彼らの間の異なったAdministrative Domains)の部品を特定することによって、始まります。 次に、それはコミュニケーションがこれらのコンポーネントの間の場所を取る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
ドキュメントは異なったプロトコル安全策の必要性を指摘します: 認証、主要な交換、メッセージの保全はサービスの否定に対して保護、秘密性、承認、およびいくつかの注意を再演します。 脅威は特にNSISに適切なジェネリックもの(セキュリティ交渉プロトコルに対する例えば、介入者攻撃、反射攻撃、改ざん、偽造、および攻撃)と11の脅威シナリオに細分されます。
Tschofenig & Kroeselberg Informational [Page 23] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[23ページ]のRFC4081軍事的脅威
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特有のセクションでカバーされていますが、方法が以前はよくサービス不能攻撃を行っていたので、プロトコル特有である傾向があってください。 多数の説明に役立つ実例はこれらの脅威が緩和されないなら起こることができることに関する洞察を提供します。
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]にリストアップされています。
6. Contributors
6. 貢献者
We especially thank Richard Graveman, who provided text for the security considerations section, as well as a detailed review of the document.
私たちはリチャードGravemanに特に感謝します、ドキュメントの詳細なレビューと同様に。(Gravemanはセキュリティ問題部にテキストを提供しました)。
7. Acknowledgements
7. 承認
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.
このドキュメントの初期のバージョンの彼らのコメントについてMarcusブルンナー、ホルヘ・クエリャル、メーメトErsue、Xiaomingフー、およびロバートハンコックに感謝申し上げます(アルファベット順に)。 ホルヘとロバートは、コメントの大規模なリストを私たちに与えて、追加脅威の情報を提供しました。
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.
ユッカManner、マーチンBuechli、ローランドBless、Marcusブルンナー、マイケル・トーマス、セドリックAoun、ジョンLoughney、レネイSoltwisch、コルネリアKappler、テッドWiederhold、Vishal Sankhla、モハンパルタサラティ、およびアンドリュー・マクドナルドはこのドキュメントの、より最近のバージョンのコメントを提供しました。 彼らの入力は、このドキュメントの中身を改良するのを助けました。 リグルーピングと材料を再構築するためのローランドBlessとマイケル・トーマス、ヨアヒムKrossとコルネリアKappler、特に提供された良い提案。
A final review was given by Michael Richardson. We thank him for his detailed comments.
最終審査はマイケル・リチャードソンによって与えられました。 私たちは彼の詳細なコメントについて彼に感謝します。
Tschofenig & Kroeselberg Informational [Page 24] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[24ページ]のRFC4081軍事的脅威
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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)中へ入ります」。 「枠組み」、RFC4080、2005年6月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC3726] ブルンナー、M.、「シグナリングプロトコルのための要件」、RFC3726、2004年4月。
8.2. Informative References
8.2. 有益な参照
[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] 香気とT.とLeiwo、J.と「(IFIP/SEC2000)、第15国際的知識セキュリティConference北京(中国)の議事におけるネットワークのサービス妨害の抵抗力があるプロトコル」への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.
1997「情報と通信秘密保全(ICICS97年)における国際会議の議事における「国がないコネクションズ」という[AN97]香気、T.、およびP.Nikanderはコンピュータサイエンス1334での注意について講義します、よりバネです」。
[2LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture
for Internet Signaling", Work in Progress,
November 2002.
[2LEVEL] 「インターネットシグナリングのための2レベルの構造」というブレーデン、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流れラベル仕様」、RFC3697、2004年3月。
[NATFW-NSLP] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", Work in Progress, February 2005.
M.、「NAT/ファイアウォールNSISシグナリングプロトコル(NSLP)層」という[NATFW-NSLP]Stiemerlingは進歩、2005年2月に働いています。
[GIMPS] Schulzrinne, H., "GIMPS: General Internet Messaging
Protocol for Signaling", Work in Progress,
February 2005.
[ギンプ]Schulzrinne、H.、「ギンプ:」 「一般インターネットはシグナリングのためにプロトコルを通信し」て、進歩、2005年2月に働いてください。
[QOS-NSLP] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", Work in Progress,
February 2005.
Progress、2005年2月の[QOS-NSLP]ボッシュ、S.、Karagiannis、G.、およびA.マクドナルド、「サービスのQualityシグナリングのためのNSLP」Work。
[RSVP-SEC] Tschofenig, H., "RSVP Security Properties", Work in
Progress, February 2005.
H.、「RSVPセキュリティの特性」という[RSVP-SEC]Tschofenigは進歩、2005年2月に働いています。
Tschofenig & Kroeselberg Informational [Page 25] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[25ページ]のRFC4081軍事的脅威
[SIG-ANAL] Manner, J. and X. Fu, "Analysis of Existing Quality-
of-Service Signaling Protocols", RFC 4094, May 2005.
[SIG肛門の] 方法、J.、およびX.フー(「サービスの既存の品質シグナリングプロトコルの分析」、RFC4094)は2005がそうするかもしれません。
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6",
RFC 1809, June 1995.
[RFC1809]ヤマウズラ、「1995年6月にIPv6"、RFC1809の流れラベルフィールドを使用する」C.。
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang,
"RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC2745] TerzisとA.とブレーデンとB.とヴィンセント、S.とL.チャン、「RSVP診断メッセージ」、RFC2745、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のアイデンティティ表現」RFC3182(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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「セッション認可方針要素」、RFC3520、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.、ゲージ、B.、およびH.Shieh、「メディア認可とのセッションセットアップのための枠組み」、RFC3521、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.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信用モデルと脅威」(RFC3756)は2004がそうするかもしれません。
Tschofenig & Kroeselberg Informational [Page 26] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[26ページ]のRFC4081軍事的脅威
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
ミュンヘン、短剣Kroeselbergジーメンスオットーハーン一味6バイエルン81739ドイツ
EMail: Dirk.Kroeselberg@siemens.com
メール: Dirk.Kroeselberg@siemens.com
Tschofenig & Kroeselberg Informational [Page 27] RFC 4081 Security Threats for NSIS June 2005
NSIS2005年6月のためのTschofenig&Kroeselbergの情報[27ページ]のRFC4081軍事的脅威
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Tschofenig & Kroeselberg Informational [Page 28]
Tschofenig&Kroeselberg情報です。[28ページ]
一覧
スポンサーリンク
