Internet Engineering Task Force (IETF) J. Manner
Request for Comments: 5978 Aalto University
Category: Informational R. Bless
ISSN: 2070-1721 KIT
J. Loughney
Nokia
E. Davies, Ed.
Folly Consulting
October 2010
Using and Extending the NSIS Protocol Family
Abstract
抽象
This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs.
この文書は、2001年から2010年の期間中、NSISワーキンググループによって作成された（NSIS）フレームワークとプロトコルスイートをシグナリングにおける次のステップの概要を説明します。また、業界が新しいプロトコルを利用することができますし、どのようにコミュニティが将来のシグナリングニーズに対応するためのフレームワークと既存のプロトコルの両方の拡張性を活用することができる方法についての提案を含んでいます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5978.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5978で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3
3. The General Internet Signaling Transport . . . . . . . . . . . 6
4. Quality-of-Service NSLP . . . . . . . . . . . . . . . . . . . 11
5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 12
6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 13
6.1. Deployment Issues Due to Use of RAO . . . . . . . . . . . 14
6.2. Deployment Issues with NATs and Firewalls . . . . . . . . 15
6.3. Incremental Deployment and Workarounds . . . . . . . . . . 15
7. Security Features . . . . . . . . . . . . . . . . . . . . . . 16
8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 16
8.1. Overview of Administrative Actions Needed When
Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 17
8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.1. Use of Different Message Routing Methods . . . . . . . 18
8.2.2. Use of Different Transport Protocols or Security
Capabilities . . . . . . . . . . . . . . . . . . . . . 18
8.2.3. Use of Alternative Security Services . . . . . . . . . 19
8.2.4. Query Mode Packet Interception Schemes . . . . . . . . 19
8.2.5. Use of Alternative NAT Traversal Mechanisms . . . . . 20
8.2.6. Additional Error Identifiers . . . . . . . . . . . . . 20
8.2.7. Defining New Objects To Be Carried in GIST . . . . . . 21
8.2.8. Adding New Message Types . . . . . . . . . . . . . . . 21
8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 22
8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 23
8.6. New NSLP Protocols . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 28
The Next Steps in Signaling (NSIS) Working Group was formed in November 2001 to develop an Internet signaling protocol suite that would attempt to remedy some of the perceived shortcomings of solutions based on the Resource ReSerVation Protocol (RSVP), e.g., with respect to mobility and Quality-of-Service (QoS) interoperability. The initial charter was focused on QoS signaling as the first use case, taking RSVP as the background for the work. In May 2003, middlebox traversal was added as an explicit second use case. The requirements for the new generation of signaling protocols are documented in [RFC3726], and an analysis of existing signaling protocols can be found in [RFC4094].
シグナリングにおける次のステップ（NSIS）ワーキンググループは、モビリティに関して、例えば、リソース予約プロトコル（RSVP）に基づくソリューションの知覚欠点のいくつかを改善しようと、インターネットシグナリングプロトコルスイートを開発するために2001年11月に結成されましたおよびサービス品質（QoS）の相互運用性。最初のチャーターは、仕事の背景としてRSVPを取って、最初のユースケースとして、QoSシグナリングに焦点を当てました。 2003年5月には、ミドル・トラバーサルは、明示的な第二のユースケースとして追加されました。シグナリングプロトコルの新しい世代のための要件は、[RFC3726]に記載されており、既存のシグナリングプロトコルの分析は、[RFC4094]に見出すことができます。
The design of NSIS is based on a two-layer model, where a general signaling transport layer provides services to an upper signaling application layer. The design was influenced by Bob Braden's document entitled "A Two-Level Architecture for Internet Signaling" [TWO-LEVEL].
NSISの設計は、一般的なシグナリング輸送層は、上部シグナリングアプリケーション層にサービスを提供する2層モデルに基づいています。デザインは「インターネットシグナリングのための二つのレベルのアーキテクチャ」[TWO-LEVEL]と題したボブブレーデンのドキュメントに影響を受けました。
This document gives an overview of the NSIS framework and protocol suite at the time of writing (2010), provides an introduction to the use cases for which the current version of NSIS was designed, describes how to deploy NSIS in existing networks, and summarizes how the protocol suite can be enhanced to satisfy new use cases.
この文書は、NSISの現在のバージョンが設計されたユースケースを紹介して既存のネットワークにNSISを展開する方法について説明し、どのようにまとめたもので、（2010）書き込み時NSISフレームワークとプロトコルスイートの概要を説明しますプロトコルスイートは、新しいユースケースを満たすために強化することができます。
The design of the NSIS protocol suite reuses ideas and concepts from RSVP but essentially divides the functionality into two layers. The lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge of transporting the higher-layer protocol messages to the next signaling node on the path. This includes discovery of the next-hop NSIS node, which may not be the next routing hop, and different transport and security services depending on the signaling application requirements. The General Internet Signaling Transport (GIST) [RFC5971] has been developed as the protocol that fulfills the role of the NTLP. The NSIS protocol suite supports both IP protocol versions, IPv4 and IPv6.
NSISプロトコル・スイートのデザインは、RSVPからアイデアやコンセプトを再利用しますが、基本的に二層に機能を分割します。下部層は、NSISトランスポート層プロトコル（NTLP）は、経路上の次のシグナリングノードに上位層プロトコルメッセージを輸送する電荷です。これは、次のルーティングホップではないかもしれない次ホップNSISノードの発見、およびシグナリングアプリケーションの要件に応じて異なるトランスポートおよびセキュリティサービスを含みます。一般的なインターネットシグナリングトランスポート（GIST）[RFC5971]はNTLPの役割を果たし、プロトコルとして開発されてきました。 NSISプロトコル・スイートは、両方のIPプロトコルのバージョン、IPv4とIPv6をサポートしています。
The actual signaling application logic is implemented in the higher layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). While GIST is only concerned with transporting NSLP messages hop-by-hop between pairs of signaling nodes, the end-to-end signaling functionality is provided by the NSLP protocols if needed. Not all NSLP protocols need to perform end-to-end signaling. The current protocols have features to confine the signaling to a limited part of the path (such as the interior of a domain). Messages transmitted by
実際のシグナリングアプリケーションロジックはNSISスタックの上位層に実装され、NSISシグナリング層プロトコル（NSLP）。 GISTはNSLPメッセージがホップバイホップシグナリングノードの対の間輸送の唯一の懸念であるが、必要に応じて、エンド・ツー・エンドのシグナリング機能はNSLPプロトコルによって提供されます。すべてではないNSLPプロトコルは、エンドツーエンドのシグナリングを実行する必要があります。現在のプロトコルは、（例えば、ドメインの内部のような）パスの限られた部分にシグナリングを閉じ込める機能を有します。メッセージが送信しました
GIST on behalf of an NSLP are identified by a unique NSLP identifier (NSLPID) associated with the NSLP. Two NSLP protocols are currently specified: one concerning Quality-of-Service signaling [RFC5974] and one to enable NAT/firewall traversal [RFC5973].
NSLPの代わりにGISTはNSLPに関連付けられた一意のNSLP識別子（NSLPID）によって識別されます。二NSLPプロトコルは、現在指定されている：1は、NAT /ファイアウォールトラバーサル[RFC5973]を有効にするために、[RFC5974]と1のシグナリングのサービス品質に関して。
NSIS is primarily designed to provide the signaling needed to install state on nodes that lie on the path that will be taken by some end-to-end flow of data packets; the state installed should facilitate or enhance some characteristic of the data flow. This is typically achieved by routing signaling messages along the same path (known as "path-coupled signaling") and intercepting the signaling message at NSIS-capable nodes. However, the NSIS architecture is designed to be flexible, and the routing of signaling messages is controlled by the Message Routing Method (MRM) that is applied to the signaling messages. The initial specifications define two MRMs:
NSISは、主に、データ・パケットの一部のエンド・ツー・エンドのフローによって取られる経路上にあるノードに状態をインストールするのに必要なシグナルを提供するように設計されています。インストール状態は、データフローのいくつかの特性を促進または増強する必要があります。これは、典型的には、（「パス結合シグナル」として知られている）と同じ経路に沿ってシグナリングメッセージをルーティングし、NSIS対応ノードにおけるシグナリングメッセージを傍受することによって達成されます。しかし、NSISアーキテクチャは柔軟であるように設計され、およびシグナリングメッセージのルーティングは、シグナリングメッセージに適用されるメッセージルーティング法（MRM）によって制御されます。初期の仕様は2つのMRMを定義します。
o the basic Path Coupled MRM designed to drive signaling along the path that will be followed by the data flow, and
データフローが続く経路に沿ってシグナリングを駆動するように設計された基本的なパス結合MRM O、及び
o an alternative Loose End MRM, which is applicable for preconditioning the state in firewalls and Network Address Translation (NAT) middleboxes when data flow destinations lie behind this sort of middlebox. Without preconditioning, these middleboxes will generally reject signaling messages originating outside the region 'protected' by the middlebox and where the destination is located.
データフローの宛先がミドル、この種の背後にあるとき、ファイアウォールやネットワークアドレス変換（NAT）ミドルボックスの状態を事前調整のために適用される代替ルースエンドMRM、O。前処理なしで、これらの中間装置は、一般的に先が位置するミドルボックスによって「保護」領域の外側発信シグナリングメッセージを拒否します。
Parameters carried by each signaling message drive the operation of the relevant transport or signaling application. In particular, the messages will carry Message Routing Information (MRI) that will allow the NSIS nodes to identify the data flow to which the signaling applies. Generally, the intercepted messages will be reinjected into the network after processing by the NSIS entities and will be routed further towards the destination, possibly being intercepted by additional NSIS-capable nodes before arriving at the flow endpoint.
各シグナリングメッセージによって運ばれるパラメータは、関連するトランスポートまたはシグナリングアプリケーションの動作を駆動します。具体的には、メッセージは、メッセージルーティング情報NSISノードは、シグナリングが適用されるデータ・フローを識別することを可能にする（MRI）を運びます。一般的に、傍受メッセージはNSISエンティティによって処理した後にネットワークに再注入され、おそらくフローエンドポイントに到達する前に追加のNSIS対応ノードによって傍受され、宛先に向けてさらにルーティングされます。
As with RSVP, it is expected that the signaling message will make a complete round trip either along the whole end-to-end path or a part of it if the scope of the signaling is limited. This implements a two-phase strategy in which capabilities are assessed and provisional reservations are made on the outbound leg; these provisional reservations are then confirmed and operational state is installed on the return leg. Unlike RSVP, signaling is normally initiated at the source of the data flow, making it easier to ensure that the signaling follows the expected path of the data flow, but can also be receiver initiated as in RSVP.
RSVPと同様に、シグナルの範囲は限られている場合、シグナリングメッセージは、いずれかの全体のエンドツーエンドパス又はその一部に沿って完全なラウンドトリップを行うことが期待されます。これは、能力が評価されると、仮予約がアウトバウンドの足の上に作られている二相戦略を実装します。これらの仮予約が、その後確認されており、動作状態は、第2戦にインストールされています。 RSVPは異なり、シグナリングは通常、それが簡単にシグナリングは、データフローの期待される経路に従うことを保証すること、データフローのソースで開始されるが、受信機RSVPのように開始することができます。
A central concept of NSIS is the Session Identifier (SID). Signaling application states are indexed and referred to through the SID in all the NSLPs. This decouples the state information from IP addresses, allowing dynamic IP address changes for signaling flows, e.g., due to mobility: changes in IP addresses do not force complete teardown and re-initiation of a signaling application state; they force merely an update of the state parameters in the NSLP(s), especially the MRI.
NSISの中心的な概念は、セッション識別子（SID）です。シグナリングアプリケーションの状態がインデックス化し、すべてのNSLPsにSIDを介して参照されています。これが原因移動性、例えばシグナリングフローのための動的IPアドレスの変更を可能にする、IPアドレスからの状態情報を分離：IPアドレスの変更が完了ティアダウンシグナリングアプリケーション状態の再起動を強制しません。彼らは単にNSLP（S）、特にMRIにおける状態パラメータの更新を強制します。
At the NTLP (GIST) layer, the SID is not meaningful by itself, but is used together with the NSLP identifier (NSLPID) and the Message Routing Information (MRI). This 3-tuple is used by GIST to index and manage the signaling flows. Changes of routing or dynamic IP address changes, e.g., due to mobility, will require GIST to modify already established Messaging Associations (MAs) that are used to channel NSLP messages between adjacent GIST peers in order to satisfy the NSLP MRI for each SID.
NTLP（GIST）層に、SIDは、それ自体で意味がありませんが、NSLP識別子（NSLPID）とメッセージルーティング情報（MRI）と一緒に使用されます。この3つ組は、インデックスにGISTで使用されるシグナリング・フローを管理しています。モビリティに起因例えばルーティングまたは動的IPアドレス変更の変化は、既に確立されたメッセージングアソシエーション各SIDのためのNSLP MRIを満たすために隣接GISTピア間NSLPメッセージチャネルのに使用される（MAS）を変更するGISTを必要とします。
The following design restrictions were imposed for the first phase of the protocol suite. They may be lifted in the future, and new functionality may be added into the protocols at some later stage.
以下の設計上の制約は、プロトコルスイートの最初の段階のために課されました。彼らは、将来的に解除することができる、新しい機能がいくつかの後の段階でのプロトコルの中に添加してもよいです。
o Initial focus on MRMs for path-coupled signaling: GIST transports messages towards an identified unicast data flow destination based on the signaling application request, and does not directly support path-decoupled signaling, e.g., QoS signaling to a bandwidth broker or other off-path resource manager. The framework also supports a Loose End MRM used to discover GIST nodes with particular properties in the direction of a given address; for example, the NAT/firewall NSLP uses this method to discover a NAT along the upstream data path.
パス結合シグナリングのためのMRMにO初期フォーカス：GISTはシグナリングアプリケーションの要求に基づいて特定のユニキャストデータフロー宛先に向けてメッセージを転送し、直接パス切り離さシグナリングをサポートしていない、例えば、QoSは帯域ブローカーまたは他のオフへのシグナリングパスリソースマネージャ。フレームワークはまた、所定のアドレスの方向に特定の特性を有するGISTノードを発見するために使用される自由端のMRMをサポートします。例えば、NAT /ファイアウォールNSLPは、アップストリームデータパスに沿ってNATを発見するためにこの方法を使用します。
o No multicast support: Introducing support for multicast was deemed too much overhead, considering the currently limited support for global IP multicast. Thus, the current GIST and the NSLP specifications consider unicast flows only.
Oノーマルチキャストサポート：マルチキャストのサポートを導入することグローバルIPマルチキャストのため、現在限定的なサポートを考慮すると、あまりにも多くのオーバーヘッドを考えられました。このように、現在のGISTとNSLP仕様は、ユニキャストのフローだけを考えます。
The key documents specifying the NSIS framework are:
NSISフレームワークを指定する重要な書類は以下のとおりです。
o Requirements for Signaling Protocols [RFC3726]
シグナリングプロトコルのためのO要件[RFC3726]
o Next Steps in Signaling: Framework [RFC4080]
シグナリングにおけるO次のステップ：フレームワーク[RFC4080]
o Security Threats for NSIS [RFC4081]
NSISのためのOのセキュリティの脅威[RFC4081]
The protocols making up the suite specified by the NSIS Working Group are documented in:
NSISワーキンググループによって指定されたスイートを構成するプロトコルがに記載されています：
o The General Internet Signaling Transport protocol [RFC5971]
一般的なインターネットシグナリングトランスポートプロトコル[RFC5971] O
o Quality-of-Service NSLP (QoS NSLP) [RFC5974]
Oサービス品質のNSLP（QoSのNSLP）[RFC5974]
o The QoS specification template [RFC5975]
QoSの仕様テンプレートO [RFC5975]
o NAT/firewall traversal NSLP [RFC5973]
O NAT /ファイアウォール越えNSLP [RFC5973]
The next three sections provide a brief survey of GIST, the QoS NSLP, and the NAT/firewall NSLP.
次の3つのセクションでは、GIST、QoSのNSLP、およびNAT /ファイアウォールNSLPの簡単な調査を提供しています。
The General Internet Signaling Transport (GIST) [RFC5971] provides signaling transport and security services to NSIS Signaling Layer Protocols (NSLP) and the associated signaling applications. GIST does not define new IP transport protocols or security mechanisms but rather makes use of existing protocols, such as TCP, UDP, TLS, and IPsec. Applications can indicate the desired transport attributes for the signaling flow, e.g., unreliable or reliable, and GIST then chooses the most appropriate transport protocol(s) to satisfy the requirements of the flow. GIST will normally use UDP if unreliable signaling is adequate, TCP if reliability is required, and TLS over TCP for secure (and reliable) signaling flows, but there exist extensibility provisions within GIST that will allow alternatives to be specified in the future. The NSIS layered protocol stack is shown in Figure 1.
一般的なインターネットシグナリングトランスポート（GIST）[RFC5971]はNSISシグナリング層プロトコル（NSLP）と関連するシグナリングアプリケーションへの輸送およびセキュリティサービスを提供していシグナル。 GISTは、新しいIPトランスポートプロトコルやセキュリティ・メカニズムを定義するのではなく、そのようなTCP、UDP、TLS、およびIPsecなどの既存のプロトコルを利用しますしません。アプリケーションは、例えば、信頼できない、または信頼性の高い、信号伝達の流れのための所望のトランスポート属性を示すことができ、及びGISTは、フローの要件を満たすために最も適切なトランスポートプロトコル（単数または複数）を選択します。 GISTは、通常、信頼性の低いシグナル伝達が十分であれば、信頼性が必要な場合は、TCPをUDPを使用し、安全な（かつ信頼性の高い）のためのTCP上のTLSフローのシグナリングが、代替案は、将来的に指定できるようになりますGIST内の拡張性の規定が存在します。 NSIS層状プロトコルスタックは、図1に示されています。
+-----+ +--------+ +-------+
| | | | | |
| QoS | | NAT/FW | | ... | NSLP
| | | | | |
+-----+ +--------+ +-------+
---------------------------------------------------------------------
+--------------------------+
| |
| GIST | NTLP
| |
+--------------------------+
---------------------------------------------------------------------
+------------+-------------+
| TLS | DTLS | Security Support*
+------------+-------------+
| TCP | SCTP | UDP | DCCP | Transport Protocol*
+--------------------------+
+--------------------------+
| IPsec |
+--------------------------+
+--------------------------+
| IPv4 | IPv6 |
+--------------------------+
* The Security Support and Transport Protocol layers show some possible protocols that could be used to transport NSIS messages. To provide authentication and/or integrity protection support, the transport protocol has to be paired with a suitable security mechanism, e.g., TCP with TLS, or Datagram Congestion Control Protocol (DCCP) with DTLS.
*セキュリティサポートおよびトランスポートプロトコル層は、NSISメッセージを転送するために使用することができ、いくつかの可能なプロトコルを示しています。認証および/または完全性保護サポートを提供するために、トランスポートプロトコルは、DTLSと適切なセキュリティメカニズム、TLSと例えば、TCP、またはデータグラム輻輳制御プロトコル（DCCP）と対にされなければなりません。
Figure 1: The NSIS protocol stack
図1：NSISプロトコルスタック
GIST divides up the data flow's end-to-end path into a number of segments between pairs of NSIS-aware peer nodes located along the path. Not every router or other middlebox on the path needs to be NSIS aware: each segment of the signaling path may incorporate several routing hops. Also not every NSIS-aware node necessarily implements every possible signaling application. If the signaling for a flow requests services from a subset of the applications, then only nodes that implement those services are expected to participate as peers, and even some of these nodes can decline to operate on a particular flow if, for example, the additional load might overload the processing capability of the node. These characteristics mean that incremental deployment of NSIS capabilities is possible both with the initial protocol suite, and for any future NSLP applications that might be developed. The following paragraphs describe how a signaling segment is set up to offer the transport and security characteristics needed by a single NSLP.
GISTは、経路に沿って配置されたNSIS認識ピア・ノードの対の間のセグメントの数にデータフローのエンドツーエンドパスを分割します。パス上にないすべてのルータまたは他のミドルは、NSIS認識する必要がある：シグナル伝達経路の各セグメントは、いくつかのルーティングホップを組み込むことができます。また、すべてのNSIS認識ノードは、必ずしもすべての可能なシグナリングアプリケーションを実装していません。アプリケーションのサブセットからの流れを要求サービスのためのシグナリングは、それらのサービスを実装するだけのノードがピアとして参加する、とさえこれらのノードのいくつかは、例えば、もし特定のフロー上で動作させるために、追加を拒否することができ期待されている場合負荷は、ノードの処理能力をオーバーロードすることがあります。これらの特性は、NSIS機能の増分の展開が可能に両方の最初のプロトコル・スイートで、そして開発される可能性のある将来のNSLPアプリケーションであることを意味します。次の段落では、シグナリング・セグメントは、単一のNSLPが必要とするトランスポートとセキュリティ特性を提供するように設定されている方法について説明します。
When an NSLP application wants to send a message towards a flow endpoint, GIST starts the process of discovering the next signaling node by sending a Query message towards the destination of the related data flow. This Query carries the NSLP identifier (NSLPID) and Message Routing Information (MRI), among others. The MRI contains enough information to control the routing of the signaling message and to identify the associated data flow. The next GIST node on the path receives the message, and if it is running the same NSLP, it provides the MRI to the NSLP application and requests it to make a decision on whether to peer with the querying node. If the NSLP application chooses to peer, GIST sets up a Message Routing State (MRS) between the two nodes for the future exchange of NSLP data. State setup is performed by a three-way handshake that allows for negotiation of signaling flow parameters and provides counter-measures against several attacks (like denial-of-service) by using cookie mechanisms and a late state installation option.
NSLPアプリケーションはフローエンドポイントに向かってメッセージを送信したい場合、GISTは、関連するデータ・フローの宛先に向けてクエリメッセージを送信することによって、次のシグナリングノードを発見するプロセスを開始します。このクエリは、とりわけ、NSLP識別子（NSLPID）とメッセージルーティング情報（MRI）を運びます。 MRIは、シグナリングメッセージのルーティングを制御し、関連するデータフローを識別するのに十分な情報を含んでいます。経路上の次のGISTノードがメッセージを受信し、それが同じNSLPを実行している場合、それはNSLPアプリケーションにMRIを提供し、クエリノードとピアするか否かの決定を行うことを要求します。 NSLPアプリケーションはピアを選択した場合、GISTはNSLPデータの将来の交換のために2つのノード間のメッセージルーティング状態（MRS）を設定します。状態の設定は、シグナリングフローパラメータの交渉を可能にし、クッキーのメカニズムと後期状態のインストールオプションを使用することにより、（サービス拒否のように）いくつかの攻撃に対する対策を提供してスリーウェイハンドシェイクによって行われます。
If a transport connection is required and needs to provide for reliable or secure signaling, like TCP or TLS/TCP, a Messaging Association (MA) is established between the two peers. An MA can be reused for signaling messages concerning several different data flows, i.e., signaling messages between two nodes are multiplexed over the same transport connection. This can be done when the transport requirements (reliability, security) of a new flow can be met with an existing MA, i.e., the security and transport properties of an existing MA are equivalent or better than what is requested for a potential new MA.
トランスポート接続が必要とTCPまたはTLS / TCPのように、信頼性や安全なシグナルを提供するために必要がある場合、メッセージング協会（MA）は、2つのピア間で確立されています。 MAは、すなわち、2つのノード間のシグナリングメッセージは、同じトランスポート接続を介して多重化され、いくつかの異なるデータフローに関するメッセージをシグナリングするために再利用することができます。新しいフローの輸送要件（信頼性、セキュリティが）既存のMAと会ったことができたときにこれが行うことができ、すなわち、既存のMAのセキュリティおよび輸送特性は同等または潜在的な新しいMAのために要求されるものよりも優れています。
For path-coupled signaling, we need to find the nodes on the data path that should take part in the signaling of an NSLP and invoke them to act on the arrival of such NSLP signaling messages. The basic concept is that such nodes along a flow's data path intercept the corresponding signaling packets and are thus discovered automatically. GIST places a Router Alert Option (RAO) in Query message packets to ensure that they are intercepted by relevant NSIS-aware nodes, as in RSVP.
パス結合のシグナル伝達のために、私たちはNSLPのシグナリングに参加すると、このようなNSLPシグナリングメッセージの到着時に作用するためにそれらを呼び出す必要があり、データパス上のノードを見つける必要があります。基本概念は、対応するシグナリングパケットインターセプトフローのデータパスに沿ったノードとは、このように自動的に検出されることです。 GISTは、それらがRSVPのように、関連するNSIS認識ノードによって傍受されることを保証するためにQueryメッセージパケットにルータアラートオプション（RAO）を配置します。
Late in the development of GIST, serious concerns were raised in the IETF about the security risks and performance implications of extensive usage of the RAO [RAO-BAD]. Additionally, evidence was discovered indicating that several existing implementations of RAO were inconsistent with the (intention of the) standards and would not support the NSIS usage. There were also concerns that extending the need for RAO recognition in the fast path of routers that are frequently implemented in hardware would delay or deter implementation and deployment of NSIS. Eventually, it was decided that NSIS would continue to specify RAO as its primary means for triggering interception of signaling messages in intermediate nodes on the data path, but the protocol suite would be published with Experimental status rather than on the Standards Track while deployment experience was gathered. More information about the use of RAO in GIST can be found in [GIST-RAO]. Also, the deployment issues that arise from the use of RAO are discussed in Section 6.1.
後期GISTの開発においては、深刻な懸念をRAO [RAO-BAD]の広範囲の使用のセキュリティリスクとパフォーマンスへの影響についてIETFで提起されました。さらに、証拠はRAOのいくつかの既存の実装は、標準規格（のつもり）と矛盾しており、NSISの使用をサポートしていないことを示す発見されました。頻繁にハードウェアに実装されているルータのファストパスでRAO認識の必要性を拡張することは遅らせたり、NSISの実装と展開を抑止することを懸念もありました。結局、それはNSISは、データパス上の中間ノードにおけるシグナリングメッセージの傍受をトリガするための主要な手段として、RAOを指定するために継続することを決定しましたが、展開の経験があったが、プロトコル・スイートは、実験的なステータスではなく、標準化過程に公開されるだろう集まりました。 GISTにおけるRAOの使用の詳細については、[GIST-RAO]に見出すことができます。また、RAOの使用から発生する展開の問題は、6.1節で議論されています。
Alternative mechanisms have been considered to allow nodes to recognize NSIS signaling packets that should be intercepted. For example, NSIS nodes could recognize UDP packets directed to a specific destination port as Query messages that need to be intercepted even though they are not addressed to the intercepting node. GIST provides for the use of such alternatives as a part of its extensibility design. NSIS recognizes that the workload imposed by intercepting signaling packets could be considerable relative to the work needed just to forward such packets. To keep the necessary load to a minimum, NSIS provides mechanisms to limit the number of interceptions needed by constraining the rate of generation and allowing for intentional bypassing of signaling nodes that are not affected by particular signaling requests. This can be accomplished either in GIST or in the NSLP.
代替的なメカニズムは、ノードが傍受されるべきであるNSISシグナリングパケットを認識できるように考えられてきました。例えば、NSISノードは、それらが傍受ノード宛でない場合であっても、傍受する必要があるクエリメッセージなどの特定の宛先ポートに向かうUDPパケットを認識することができます。 GISTは、その拡張性設計の一部として、そのような代替の使用を提供します。 NSISはシグナリングパケットを傍受することによって課されるワークロードは、まさにこのようなパケットを転送するために必要な作業にかなりの相対的な可能性があることを認識しています。最小限に必要な負荷を維持するために、NSISは、発生速度を制約及び特定のシグナリング要求に影響されないシグナリングノードの意図的なバイパスを可能にすることによって必要なインターセプトの数を制限するためのメカニズムを提供します。これはGISTやNSLPのいずれかで行うことができます。
Since GIST carries information about the data flow inside its messages (in the MRI), NAT gateways must be aware of GIST in order to let it work correctly. GIST provides a special object for NAT traversal so that the actual translation is disclosed if a GIST-aware NAT gateway provides this object.
GISTは（MRIで）そのメッセージ内のデータの流れについての情報を運ぶので、NATゲートウェイは、それが正常に動作させるためにGISTを認識する必要があります。 GIST対応のNATゲートウェイは、このオブジェクトを提供する場合、実際の翻訳が開示されているように、GISTは、NATトラバーサルのための特別なオブジェクトを提供します。
As with RSVP, all the state installed by NSIS protocols is "soft-state" that will expire and be automatically removed unless it is periodically refreshed. NSIS state is held both at the signaling application layer and in the signaling transport layer, and is maintained separately. NSLPs control the lifetime of the state in the signaling application layer by setting a timeout and sending periodic "keep alive" messages along the signaling path if no other messages are required. The MAs and the routing state are maintained semi-independently by the transport layer, because MAs may be used by multiple NSLP sessions, and can also be recreated "on demand" if the node needs to reclaim resources. The transport layer can send its own "keep alive" messages across a MA if no NSLP messages have been sent, for example, if the transport layer decides to maintain a heavily used MA even though there is no current NSLP session using it. Local state can also be deleted explicitly when no longer needed.
RSVPと同様に、NSISプロトコルによってインストールされたすべての状態が期限切れになり、それが定期的に更新されていない限り、自動的に削除され、「ソフト状態」です。 NSIS状態がシグナリングアプリケーションレイヤでシグナリングトランスポート層の両方に保持され、別々に維持されます。 NSLPsタイムアウトを設定し、他のメッセージが必要とされない場合、シグナリング経路に沿ってメッセージ「キープアライブ」の周期的送信することにより、シグナリングアプリケーション層における状態の寿命を制御します。 MAルーティング状態がMASは複数NSLPセッションによって使用されてもよいので、半独立のトランスポート層によって維持され、ノードがリソースを解放する必要がある場合も、「オンデマンド」で再現することができます。何のNSLPメッセージが送信されていない場合は、トランスポート層は、それを使用しても電流NSLPセッションが存在しないにもかかわらず、頻繁に使用されるMAを維持することを決定した場合、トランスポート層は、例えば、MA間で独自の「キープアライブ」メッセージを送信することができます。必要なときに、もはやローカル状態も明示的に削除することができます。
If there is a change in the route used by a flow for which NSIS has created state, NSIS needs to detect the change in order to determine if the new path contains additional NSIS nodes that should have state installed. GIST may use a range of triggers in order to detect a route change. It probes periodically for the next peer by sending a GIST Query, thereby detecting a changed route and GIST peer. GIST monitors routing tables and the GIST peer states, and it notifies NSLPs of any routing changes. It is then up to the NSLPs to act appropriately, if needed, e.g., by issuing a refresh message. The periodic queries also serve to maintain the soft-state in nodes as long as the route is unchanged.
NSISは状態を作成しているため、フローが使用するルートに変更がある場合は、NSISは、新しいパスが状態がインストールされている必要があり、追加のNSISノードが含まれているかどうかを判断するために、変化を検出する必要があります。 GISTは、経路変更を検出するためにトリガーの範囲を使用してもよいです。それにより、変更ルートとGISTピアを検出し、GISTクエリを送信することによって、次のピアのために定期的にプローブ。 GISTは、ルーティングテーブルとGISTピアの状態を監視し、それが任意のルーティング変更のNSLPsに通知します。これは、必要に応じてリフレッシュメッセージを発行することにより、例えば、適切に行動することNSLPsまで続いています。定期的なクエリはまた、長いルートが変更されないように、ノードにおけるソフトステートを維持するのに役立ちます。
In summary, GIST provides several services in one package to the upper-layer signaling protocols:
要約すると、GISTは、上位レイヤのシグナリングプロトコルに1つのパッケージに複数のサービスを提供します。
o Signaling peer discovery: GIST is able to find the next-hop node that runs the NSLP being signaled for.
ピア発見シグナリングO：GISTはの合図さNSLPを実行する次ホップノードを見つけることができます。
o Multiplexing: GIST reuses already established signaling relationships and messaging associations to next-hop peers if the signaling flows require the same transport attributes.
Oの多重化：シグナリングフローが同じトランスポート属性を必要とする場合GISTは、ネクストホップピアにすでに確立されたシグナリング関係およびメッセージングの関連付けを再利用します。
o Transport: GIST provides transport with different attributes -- namely, reliable/unreliable and secure/unsecure.
交通O： - つまり、信頼性/信頼性が低く、安全でない/安全なGISTは、異なる属性を持つトランスポートを提供します。
o Security: If security is requested, GIST uses TLS to provide an encrypted and integrity-protected message transport to the next signaling peer.
Oセキュリティ：セキュリティが要求された場合、GISTは、次のシグナリングピアへの暗号化と完全性保護されたメッセージトランスポートを提供するために、TLSを使用しています。
o Routing changes: GIST detects routing changes, but instead of acting on its own, it merely sends a notification to the local NSLP. It is then up to the NSLP to act.
Oルーティングの変更：GISTは、ルーティングの変更を検出したが、その代わりに、独自に作用するのではなく、単にローカルNSLPに通知を送信します。それは行動するNSLPまで続いています。
o Fragmentation: GIST uses either a known Path MTU for the next hop or limits its message size to 576 bytes when using UDP or Query mode. If fragmentation is required, it automatically establishes an MA and sends the signaling traffic over a reliable protocol, e.g., TCP.
Oフラグメンテーション：GISTは次のホップのためにいずれかの既知の経路MTUを使用するか、またはUDPまたはクエリモードを使用して576バイトに、そのメッセージのサイズを制限します。フラグメンテーションが必要な場合、それは自動的にMAを確立し、信頼性の高いプロトコル、例えば、TCP上のシグナリングトラフィックを送信します。
o State maintenance: GIST establishes and then maintains the soft-state that controls communications through MAs between GIST peers along the signaling path, according to usage parameters supplied by NSLPs and local policies.
O状態維持：GISTが確立した後NSLPsとローカルポリシーによって供給された使用パラメータに応じて、シグナリングパスに沿ってGISTピア間のMAを介した通信を制御するソフト状態を維持します。
The Quality-of-Service (QoS) NSIS Signaling Layer Protocol (NSLP) establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. It is intended to satisfy the QoS-related requirements of RFC 3726 [RFC3726]. No support for QoS architectures based on bandwidth brokers or other off-path resource managers is currently included.
サービス品質（QoS）のNSISシグナリング層プロトコル（NSLP）を確立し、そのフローのためにいくつかの転送リソースを提供する目的のためのデータフローのパスに沿ったノードの状態を維持します。 RFC 3726 [RFC3726]のQoS関連の要件を満たすことを目的としています。帯域幅ブローカーまたはその他のオフパスのリソースマネージャに基づいたQoSアーキテクチャのサポートは現在含まれていません。
The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 [RFC2205], and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path). The QoS NSLP extends the set of reservation mechanisms to meet the requirements of RFC 3726 [RFC3726], in particular, support of sender- or receiver-initiated reservations, as well as, a type of bidirectional reservation and support of reservations between arbitrary nodes, e.g., edge-to-edge, end-to-access, etc. On the other hand, there is currently no support for IP multicast.
QoS NSLPの設計（すなわち、状態のインストール/更新を隣接NSLPの対の間に行われる、RFC 2205 [RFC2205]をRSVPに概念的に類似しており、一次状態管理機構としてソフトステートピア・ツー・ピア・リフレッシュ・メッセージを使用しではなく）完全なシグナリング経路に沿ってエンドツーエンド方式でノード。 QoS NSLPは、RFC 3726の要件を満たすために予約メカニズムのセット特に[RFC3726]、センダまたはレシーバが開始予約のサポート、ならびに、任意のノード間の予約の双方向予約とサポートの種類を拡張します例えば、端から端まで、エンド・ツー・アクセスなど一方、IPマルチキャストのサポートは現在ありません。
A distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). RMF-related information is carried in the QSPEC (QoS Specification) object in QoS NSLP messages. This is similar to the decoupling between RSVP and the IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries information on resources available, resources required, traffic descriptions, and other information required by the RMF. A template for QSPEC objects is defined in [RFC5975]. This provides a number of basic parameter objects that can be used as a common language to specify components of concrete QoS models. The objects defined in [RFC5975] provide the building blocks for many existing QoS models such as those associated with RSVP and Differentiated Services. The extensibility of the template allows new QoS model specifications to extend the template language as necessary to support these specifications.
区別は、シグナリングプロトコルとリソース管理機能（RMF）の動作に必要な情報の操作の間に行われます。 RMF関連情報は、QoS NSLPメッセージ内QSPEC（QOS仕様）オブジェクトに行われます。これは、RSVPとのIntServアーキテクチャ、RFC 1633 [RFC1633]の間のデカップリングに類似しています。 QSPECは利用可能なリソース、必要なリソース、トラフィックの説明、およびRMFで必要なその他の情報についての情報を運びます。 QSPECオブジェクトのテンプレートは、[RFC5975]で定義されています。これは、コンクリートのQoSモデルのコンポーネントを指定するための共通言語として使用することができ、基本的なパラメータオブジェクトの数を提供します。 [RFC5975]で定義されたオブジェクトは、RSVPと差別化サービスに関連するものなど、多くの既存のQoSモデルのためのビルディングブロックを提供します。テンプレートの拡張は、新しいQoSモデルの仕様は、これらの仕様をサポートするために、必要に応じてテンプレート言語を拡張することができます。
The QoS NSLP supports different QoS models because it does not define the QoS mechanisms and RMF that have to be used in a domain. As long as a domain knows how to perform admission control for a given QSPEC, QoS NSLP actually does not care how the specified constraints are enforced and met, e.g., by putting the related data flow in the topmost of four Diffserv classes or by putting it into the third highest of twelve Diffserv classes. The particular QoS configuration used is up to the network provider of the domain. The QSPEC can be seen as a common language to express QoS requirements between different domains and QoS models.
それは、ドメインで使用する必要があるQoSメカニズムとRMFを定義していないので、QoS NSLPは異なるQoSモデルをサポートしています。限りドメインが与えられたQSPECのためにアドミッション制御を実行する方法を知っているとして、QoSのNSLPは、実際には4つのDiffservクラスの最上位に関連するデータの流れを置くことによって、またはそれを置くことによって、例えば、指定された制約が適用されている方法を気にして会っていません12個のDiffservクラスの三番目に。使用される特定のQoS設定は、ドメインのネットワークプロバイダ次第です。 QSPECは異なるドメインとQoSモデルとの間のQoS要件を表現するための共通言語として見ることができます。
In short, the functionality of the QoS NSLP includes:
要するに、QoSのNSLPの機能が含まれています：
o Conveying resource requests for unicast flows
ユニキャストフローのリソース要求を伝えるO
o Resource requests (QSPEC) that are decoupled from the signaling protocol (QoS NSLP)
シグナリングプロトコル（のQoS NSLP）から分離されたOリソース要求（QSPEC）
o Sender- and receiver-initiated reservations, as well as bidirectional
Oセンダとレシーバが開始予約、ならびに双方向
o Soft-state and reduced refresh (keep-alive) signaling
Oソフト状態と減少リフレッシュ（キープアライブ）シグナリング
o Session binding, i.e., session X can be valid only if session Y is also valid
セッションは、結合、O、すなわち、セッションXセッションYも有効である場合のみ有効であることができます
o Message scoping, end-to-end, edge-to-edge, or end-to-edge (proxy mode)
Oメッセージスコープ、エンドツーエンドの、端から端まで、またはエンド・ツー・エッジ（プロキシモード）
o Protection against message re-ordering and duplication
メッセージの再順序付けと重複に対するO保護
o Group tear, tearing down several sessions with a single message
Oグループの涙、単一のメッセージで複数のセッションを切断
o Support for rerouting, e.g., due to mobility
モビリティに、例えば、再ルーティングのためのOサポート
o Support for request priorities and preemption
要求の優先順位とプリエンプションのためのOサポート
o Stateful and stateless nodes: stateless operation is particularly relevant in core networks where large amounts of QoS state could easily overwhelm a node
ステートフルとステートレスノード（O）ステートレス動作は、QoS状態大量の容易ノードを圧倒する可能性がコアネットワークに特に関連します
o Reservation aggregation
O予約集約
The protocol also provides for a proxy mode to allow the QoS signaling to be implemented without needing all end-hosts to be capable of handling NSIS signaling.
プロトコルは、すべてのエンドホストを必要とせずに実装するQoSシグナリングは、NSISシグナリングを処理できるようにするプロキシモードを提供します。
The QSPEC template supports situations where the QoS parameters need to be fine-grained, specifically targeted to an individual flow in one part of the network (typically the edge or access part) but might need to be more coarse-grained, where the flow is part of an aggregate (typically in the core of the network).
QSPECテンプレートは、フローはQoSパラメータは、具体的には、ネットワーク（典型的には、エッジまたはアクセス部）の一部に個々の流れを標的とするが、より粗いことが必要になる場合があり、きめの細かいことが必要な状況をサポート（典型的には、ネットワークのコア内の）集合の一部。
The NAT/firewall traversal NSLP [RFC5973] lets end-hosts interact with NAT and firewall devices in the data path. Basically, it allows for a dynamic configuration of NATs and/or firewalls along the data path in order to enable data flows to traverse these devices without being obstructed. For instance, firewall pinholes could be opened on demand by authorized hosts. Furthermore, it is possible to block unwanted incoming traffic on demand, e.g., if an end-host is under attack.
NAT /ファイアウォール越えNSLP [RFC5973]は、エンドホストがデータパスでNATやファイアウォールデバイスと対話することができます。基本的に、それはデータを有効にするために、データパスに沿ってのNAT及び/又はファイアウォールの動的な構成を可能にすることは妨げられることなく、これらのデバイスを横断するように流れます。例えば、ファイアウォールピンホールは、許可ホストによってオンデマンドで開くことができます。また、エンドホストが攻撃を受けている場合、例えば、必要に応じて不要な着信トラフィックをブロックすることが可能です。
Configurations to be implemented in NAT and firewall devices signaled by the NAT/firewall NSLP take the form of a (pattern, action) pair, where the pattern specifies a template for packet header fields to be matched. The device is then expected to apply the specified action to any passing packet that matches the template. Actions are currently limited to ALLOW (forward the packet) and DENY (drop the packet). The template specification allows for a greater range of packet fields to be matched than those allowed for in the GIST MRI.
NAT /ファイアウォールNSLPによってシグナリングNATに実装される構成とファイアウォールデバイスは、パターンが一致するパケットヘッダフィールドのテンプレートを指定する（パターン、アクション）の対の形を取ります。デバイスは、テンプレートに一致する任意の通過パケットに指定されたアクションを適用することが期待されています。アクションは現在、（パケットをドロップ）を許可（パケットを転送）し、拒否するように制限されています。テンプレート仕様はGISTのMRI内で許可されるものよりも、一致するパケットフィールドのより大きな範囲を可能にします。
Basically, NAT/firewall signaling starts at the data sender (NSIS Initiator) before any actual application data packets are sent. Signaling messages may pass several middleboxes that are NAT/firewall NSLP aware (NSIS Forwarder) on their way downstream and usually hit the receiver (being the NSIS Responder). A proxy mode is also available for cases where the NAT/firewall NSLP is not fully supported along the complete data path. NAT/firewall NSLP is based on a soft-state concept, i.e., the sender must periodically repeat its request in order to keep it active.
実際のアプリケーションデータパケットが送信される前に、基本的には、NAT /ファイアウォールシグナリングは、データ送信側（NSISイニシエータ）から始まります。シグナリングメッセージは下流と通常の受信機（NSIS Responderのであるが）ヒット彼らの方法で認識してNAT /ファイアウォールNSLP（NSISフォワーダ）をしているいくつかのミドルボックスを渡すことができます。プロキシモードはまた、NAT /ファイアウォールNSLPが完全に完全なデータ・パスに沿ってサポートされていない場合のために利用可能です。 NAT /ファイアウォールNSLPが柔らかい状態の概念に基づいて、すなわち、送信側は定期的にアクティブな、それを維持するために、その要求を繰り返す必要があります。
Additionally, the protocol also provides functions for receivers behind NATs. The receiver may request an external address that is reachable from outside. The reserved external address must, however, be communicated to the sender out-of-band by other means, e.g., by application level signaling. After this step the data sender may initiate a normal NAT/firewall signaling in order to create firewall pinholes.
さらに、プロトコルは、NATの背後にある受信機のための機能を提供します。受信機は、外部から到達可能である外部アドレスを要求することができます。予約された外部アドレスは、しかし、アプリケーション・レベルのシグナリングによって、例えば、他の手段によって帯域外送信者に伝えなければなりません。このステップの後、データ送信側は、ファイアウォールピンホールを作成するために、通常のNAT /ファイアウォールのシグナル伝達を開始することができます。
The protocol also provides for a proxy mode to allow the NAT/firewall signaling to be implemented without needing all end-hosts to be capable of handling NSIS signaling.
プロトコルは、NAT /ファイアウォールシグナリングはNSISシグナリングを処理することができるように、すべてのエンドホストを必要とせずに実現することを可能にするプロキシモードを提供します。
The initial version of the NSIS protocol suite is being published with the status of Experimental in order to gain deployment experience. Concerns over the security, implementation, and administrative issues surrounding the use of RAO are likely to mean that initial deployments occur in "walled gardens" where the characteristics of hardware in use are well-known, and there is a high level of trust and control over the end nodes that use the protocols. This section addresses issues that need to be considered in a deployment of the NSIS protocol suite.
NSISプロトコル・スイートの最初のバージョンは、展開の経験を積むために、実験の状態で公開されています。 RAOの使用を取り巻くセキュリティ、実装に対する懸念、および管理上の問題は、初期導入は、使用中のハードウェアの特性がよく知られている「壁に囲まれた庭園」で発生していることを意味する可能性があり、かつ信頼と高レベルの制御がありますプロトコルを使用するエンドノードを超えます。このセクションでは、NSISプロトコル・スイートの展開に検討する必要がある問題に対処します。
First of all, NSIS implementations must be available in at least some of the corresponding network nodes (i.e., routers, firewalls, or NAT gateways) and end-hosts. That means not only GIST support, but also the NSLPs and their respective control functions (such as a resource management function for QoS admission control, etc.) must be implemented. NSIS is capable of incremental deployment and an initial deployment does not need to involve every node in a network domain. This is discussed further in Section 6.3. There are a number of obstacles that may be encountered due to broken implementations of RAO (see Section 6.1) and due to firewalls or NATs that drop NSIS signaling packets (see Section 6.2).
まず、NSIS実装は、対応するネットワークノード（すなわち、ルータ、ファイアウォール、NATゲートウェイ）とエンドホストのうちの少なくともいくつかで利用可能でなければなりません。それだけでなく、GISTサポートを意味するだけでなく、NSLPsと（例えば、QoS受付制御のためのリソース管理機能、など）、それぞれの制御機能を実装しなければなりません。 NSISは、増分の展開が可能であり、初期の展開は、ネットワークドメイン内のすべてのノードが関与する必要はありません。これは、6.3節で詳しく説明されています。 RAOの破壊実装（セクション6.1を参照）に起因するとによるファイアウォールまたはNSISシグナリングパケット（セクション6.2を参照）ドロップのNATに遭遇する可能性がある障害物は多数存在します。
Another important issue is that applications may need to be made NSIS-aware, thereby requiring some effort from the applications' programmers. Alternatively, it may be possible to implement separate applications to control, e.g., the network QoS requests or firewall pinholes, without needing to update the actual applications that will take advantage of NSIS capabilities.
もう一つの重要な問題は、アプリケーションが、それによってアプリケーションのプログラマからのいくつかの努力を必要とし、NSIS-認識させる必要があるかもしれませんということです。あるいは、NSISの機能を利用する実際のアプリケーションを更新することなく、制御するアプリケーション、例えば、ネットワークQoS要求またはファイアウォールピンホール別個を実装することも可能です。
The standardized version of GIST depends on routers and other middleboxes correctly recognizing and acting on packets containing RAO. There are a number of problems related to RAO that can obstruct a deployment of NSIS:
GISTの標準化されたバージョンを正しく認識し、RAOを含むパケットに作用するルータや他のミドルボックスによって異なります。 NSISの展開を妨害することができますRAOに関連する多くの問題があります。
o Some implementations do not respond to RAO at all.
Oいくつかの実装はまったくRAOに応答しません。
o Some implementations respond but do not distinguish between the RAO parameter values in IPv4 packets or reject anything except 0 (in which case, only the value 0 can be used).
Oいくつかの実装は、応答が、IPv4パケットにRAOパラメータ値を区別しないか、0以外のものを拒絶する（この場合、唯一の値0を使用することができます）。
o The response to RAO in a GIST Query mode packet, which is sent using the UDP transport, is to dispatch the packet to the UDP stack in the intercepting node rather than to a function associated with the RAO parameter. Since the node will not normally have a regular UDP receiver for these packets they are dropped.
O UDPトランスポートを使用して送信されたGISTクエリモードパケットでRAOに対する応答は、インターセプトするノードではなく、RAOパラメータに関連付けられた機能にUDPスタックにパケットを送出することです。ノードは、通常、それらが廃棄され、これらのパケットのための定期的なUDP受信機を持っていないので。
o The major security concern with RAO in NSIS is that it provides a new vector for hosts to mount a (distributed) denial-of-service (DDoS) attack on the control plane of routers on the data path. Such attacks have occurred, and it is therefore normal for service providers to prohibit "host-to-router" signaling packets such as RSVP or NSIS from entering their networks from customer networks. This will tend to limit the deployment of NSIS to "walled gardens" unless a suitable mitigation of the DDoS threat can be found and deployed.
NSISでRAOの主要なセキュリティ上の問題oを、データ経路上のルータの制御プレーン上の（分散）サービス妨害（DDoS攻撃）攻撃をマウントするホストのための新規ベクターを提供することです。このような攻撃が発生していると、サービスプロバイダーは、「ホストツールーター」など、顧客のネットワークから自社のネットワークに入るのRSVPまたはNSISなどのシグナリングパケットを禁止することは、したがって、正常です。これは、DDoS攻撃の脅威を適切に緩和が見つかり、展開することができない限り、「壁に囲まれた庭園」にNSISの展開を制限する傾向があります。
In order to deploy NSIS effectively, routers and other hardware need to be selected and correctly configured to respond to RAO and dispatch intercepted packets to the NSIS function.
効果的にNSISを展開するためには、ルータや他のハードウェアを選択し、正しくRAOに応答するように構成し、発送はNSIS機能にパケットを傍受する必要があります。
A further obstacle results from the likelihood that IPv4 packets with IP options of any kind will be filtered and dropped by firewalls and NATs. In many cases, this is the default behavior so that explicit configuration is needed to allow packets carrying the RAO to pass through. The general inclination of domain administrators is to deny access to packets carrying IP options because of the security risks and the additional load on the routers in the domain. The situation with IPv6 may be easier, as the RAO option in IPv6 is better defined, but the security concerns remain.
任意の種類のIPオプションを持つIPv4パケットがファイアウォールとのNATによって濾過し、ドロップされる可能性から、さらに障害をもたらします。明示的な設定はRAOを運ぶパケットを通過させるために必要とされるように、多くの場合、これはデフォルトの動作です。ドメイン管理者の一般的な傾斜があるため、セキュリティ上のリスクやドメイン内のルータ上の追加の負荷のIPオプションを運ぶパケットへのアクセスを拒否することです。 IPv6におけるRAOオプションが良く定義されているIPv6での状況は、より簡単かもしれないが、セキュリティ上の懸念は残ります。
Deployment issues are discussed at more length in Appendix C of the GIST specification [RFC5971].
デプロイメントの問題はGISTの仕様[RFC5971]の付録Cでより詳細に論じています。
NAT gateways and firewalls may also hinder initial deployment of NSIS protocols for several reasons:
NATゲートウェイやファイアウォールはまた、いくつかの理由でNSISプロトコルの初期導入を妨げることがあります。
o They may filter and drop signaling traffic (as described in Section 6.1) to deny access to packets containing IP options.
Oそれらは、IPオプションを含むパケットへのアクセスを拒否するように（セクション6.1で説明したように）フィルタとトラフィックシグナリングドロップしてもよいです。
o They may not permit "unsolicited" incoming GIST Query mode packets. This behavior has been anticipated in the design of the protocols but requires additional support to ensure that the middleboxes are primed to accept the incoming queries (see [RFC5974] and [RFC5973]).
O彼らは「迷惑」の着信GISTのクエリモードパケットを許可することはできません。この動作は、プロトコルの設計に予想されるが、ミドルボックスは、着信クエリを受け入れるためにプライミングされていることを確認するために、追加のサポートを必要とされています（[RFC5974]と[RFC5973]を参照）。
o NATs that are not aware of the NSIS protocols will generally perform address translations that are not coordinated with the NSIS protocols. Since NSIS signaling messages may be carrying embedded IP addresses affected by these translations, it may not be possible to operate NSIS through such legacy NATs. The situation and workarounds are discussed in Section 7.2.1 of [RFC5971].
O NSISプロトコルを認識していないNATは、一般的にNSISプロトコルと調整されていないアドレス変換を実行します。 NSISシグナリングメッセージは、これらの翻訳によって影響埋め込まれたIPアドレスを運ぶかもしれないので、このような従来のNATを介してNSISを操作することが可能ではないかもしれません。状況や回避策は、[RFC5971]のセクション7.2.1で議論されています。
NSIS is specifically designed to be incrementally deployable. It is not required that all nodes on the signaling and data path are NSIS aware. To make any use of NSIS, at least two nodes on the path need to be NSIS aware. However, it is not essential that the initiator and receiver of the data flow are NSIS aware. Both the QoS and NAT/ firewall NSLPs provide "proxy modes" in which nodes adjacent to the initiator and/or receiver can act as proxy signaling initiator or receiver. An initiator proxy can monitor traffic and, hopefully, detect when a data flow of a type needing NSIS support is being initiated. The proxies can act more or less transparently on behalf of the data flow initiator and/or receiver to set up the required NSIS state and maintain it while the data flow continues. This capability reduces the immediate need to modify all the data flow endpoints before NSIS is viable.
NSISは、特にインクリメンタルに展開できるように設計されています。シグナリングおよびデータパス上のすべてのノードがNSIS認識していることを必要とされていません。 NSISのいずれかを使用するようにするには、パス上の少なくとも2つのノードはNSISを認識する必要があります。しかし、データフローのイニシエータと受信機がNSIS認識していることは必須ではありません。 QoSおよびNAT /ファイアウォールNSLPs両方は、イニシエータ及び/又は受信機に隣接するノードた「プロキシモードは」イニシエータまたは受信シグナリングプロキシとして動作することができる提供します。イニシエータプロキシはトラフィックを監視し、うまくいけば、NSISのサポートを必要とするタイプのデータフローが開始されているときに検出することができます。プロキシは、必要NSIS状態を設定し、データ・フローが継続している間、それを維持するために、データフローの開始および/または受信機の代わりに、多かれ少なかれ透過的に作用することができます。この機能は、NSISが実行可能である前に、すべてのデータフローのエンドポイントを変更する即時の必要性を低減します。
Basic security functions are provided at the GIST layer, e.g., protection against some blind or denial-of-service attacks, but note that introduction of alternative MRMs may provide attack avenues that are not present with the current emphasis on the path-coupled MRM. Conceptually, it is difficult to protect against an on-path attacker and man-in-the-middle attacks when using path-coupled MRMs, because a basic functionality of GIST is to discover as yet unknown signaling peers. Transport security can be requested by signaling applications and is realized by using TLS between signaling peers, i.e., authenticity and confidentiality of signaling messages can be assured between peers. GIST allows for mutual authentication of the signaling peers (using TLS means such as certificates) and can verify the authenticated identity against a database of nodes authorized to take part in GIST signaling. It is, however, a matter of policy that the identity of peers is verified and accepted upon establishment of the secure TLS connection.
基本的なセキュリティ機能は、GIST層において提供されている、例えば、いくつかのブラインドやサービス拒否攻撃に対する保護が、パス結合MRMの現在の重点を置いて存在しない攻撃手段を提供することができ、代替のMRMの導入に注意してください。 GISTの基本的な機能が未知のシグナリングピアを発見することであるため、概念的には、パス結合のMRMを使用したときに、パス攻撃やman-in-the-middle攻撃から保護することは困難です。トランスポート・セキュリティは、シグナリングアプリケーションによって要求することができ、シグナリングピア、即ち、真正とピアとの間で確保することができるシグナリングメッセージの機密性との間にTLSを使用することによって実現されます。 GISTは、シグナリングピアの相互認証を可能にする（TLSを使用してそのような証明書などを意味する）とGISTシグナリングに参加することを許可ノードのデータベースに対して認証IDを確認することができます。それは、しかし、ピアのアイデンティティは安全なTLSコネクションの確立時に検証され、受け入れられている政策の問題です。
While GIST is handling authentication of peer nodes, more fine-grained authorization may be required in the NSLP protocols. There is currently an ongoing work to specify common authorization mechanisms to be used in NSLP protocols [NSIS-AUTH], thus allowing, e.g., per-user and per-service authorization.
GISTは、ピア・ノードの認証を処理している間、よりきめ細かな認可はNSLPプロトコルで必要とされ得ます。従って、例えば、ユーザ単位およびサービス承認、許可、NSLPプロトコル[NSIS-AUTH]で使用される一般的な認証機構を指定する進行中の作業が現在存在します。
This section discusses the ways that are available to extend the NSIS protocol suite. The Next Steps in Signaling (NSIS) Framework [RFC4080] describes a two-layer framework for signaling on the Internet, comprising a generic transport layer with specific signaling-layer protocols to address particular applications running over this transport layer. The model is designed to be highly extensible so that it can be adapted for different signaling needs.
このセクションでは、NSISプロトコル・スイートを拡張するために利用されている方法について説明します。シグナリングにおける次のステップ（NSIS）フレームワーク[RFC4080]は、このトランスポート層の上で動作する特定のアプリケーションに対応する特定のシグナリング層プロトコルを用いて、一般的なトランスポート層を含む、インターネット上のシグナリングのための2つの層のフレームワークを記述する。モデルは、異なるシグナリングのニーズに適合させることができるように、高度に拡張可能であるように設計されています。
It is expected that additional signaling requirements will be identified in the future. The two-layer approach allows for NSLP signaling applications to be developed independently of the transport protocol. Further NSLPs can therefore be developed and deployed to meet these new needs using the same GIST infrastructure, thereby providing a level of macro-extensibility. However, the GIST protocol and the two signaling applications have been designed so that additional capabilities can be incorporated into the design should additional requirements within the general scope of these protocols need to be accommodated.
追加のシグナリング要件が将来同定されることが期待されます。 NSLPシグナリングアプリケーションは、独立して、トランスポート・プロトコルを開発するための2層アプローチが可能となります。さらにNSLPsしたがって、開発し、それによってマクロ拡張のレベルを提供し、同じGISTインフラストラクチャを使用して、これらの新たなニーズを満たすために展開することができます。追加機能は、設計に組み込むことができるようにしかし、GISTプロトコルと2つの信号のアプリケーションは、これらのプロトコルの一般的な範囲内で追加の要件を収容する必要がある必要があるように設計されています。
The NSIS framework is also highly supportive of incremental deployment. A new NSLP need not be available on every NSIS-aware node in a network or along a signaling path in order to start using it. Nodes that do not (yet) support the application will forward its signaling messages without complaint until it reaches a node where the new NSLP application is deployed.
NSISフレームワークはまた、増分展開の非常に協力的です。新しいNSLPネットワークまたはそれを使用して起動するために、シグナリングパスに沿ってすべてのNSIS認識ノード上で利用可能である必要はありません。それは新しいNSLPアプリケーションがデプロイされているノードに到達するまでは（まだ）アプリケーションをサポートしていないノードは文句なしにそのシグナリングメッセージを転送します。
One key functionality of parameter objects carried in NSIS protocols is the so-called "Extensibility flags (A/B)". All the existing protocols (and any future ones conforming to the standards) can carry new experimental objects, where the A/B flags can indicate whether a receiving node must interpret the object, or whether it can just drop them or pass them along in subsequent messages sent out further on the path. This functionality allows defining new objects without forcing all network entities to understand them.
NSISプロトコルで運ばれるパラメータオブジェクトの一つのキーの機能は、いわゆる「拡張フラグ（A / B）」です。すべての既存のプロトコル（および規格に準拠した任意の将来のもの）A / Bフラグが受信ノードは、オブジェクトを解釈しなければならないかどうかを示すことができる場所、新しい実験的なオブジェクトを運ぶことができ、またはそれはちょうどそれらを落としたり、後続に沿ってそれらを渡すことができるかどうかメッセージは、パス上にさらに送り出されました。この機能は、それらを理解するために、すべてのネットワークエンティティを強制することなく新しいオブジェクトを定義することができます。
Generally, NSIS protocols can be extended in multiple ways, many of which require the allocation of unique code point values in registries maintained by IANA on behalf of the IETF. This and the following sections provide an overview of the administrative mechanisms that might apply. The extensibility rules defined below are based upon the procedures by which IANA assigns values: "IESG Approval", "IETF Review", "Expert Review", and "Private Use" (as specified in [RFC5226]). The appropriate procedure for a particular type of code point is defined in one or other of the NSIS protocol documents, mostly [RFC5971].
一般に、NSISプロトコルはIETFの代わりにIANAによって維持レジストリに固有のコードポイント値の割り当てを必要とする多くが複数の方法で拡張することができます。これと次のセクションでは、適用される場合があります管理メカニズムの概要を説明します。 「IESG承認」、「IETFレビュー」、「エキスパートレビュー」、および（[RFC5226]で指定されるように）「私用」：以下に定義される拡張ルールは、IANAに値を割り当てることにより、手順に基づいています。コードポイントの特定の型の適切な手順は、NSISプロトコル文書、主に[RFC5971]のどちらか一方で定義されています。
In addition to registered code points, all NSIS protocols provide code points that can be used for experimentation, usually within closed networks, as explained in [RFC3692]. There is no guarantee that independent experiments will not be using the same code point!
[RFC3692]で説明したように登録されたコード・ポイントに加えて、すべてのNSISプロトコルは、通常閉じたネットワーク内で、実験のために使用することができるコード・ポイントを提供します。独立した実験は、同じコードポイントを使用しないという保証はありません！
GIST is extensible in several aspects covered in the subsections below. In these subsections, there are references to document sections in the GIST specification [RFC5971] where more information can be found. The bullet points at the end of each subsection specify the formal administrative actions that would need to be carried out when a new extension is standardized.
GISTは、以下のサブセクションで取り上げいくつかの局面で拡張可能です。これらのサブセクションでは、より多くの情報を見つけることができるGIST仕様[RFC5971]のドキュメントセクションへの参照があります。各サブセクションの終わりに箇条書きは、新しい拡張機能が標準化されたときに実行される必要があるであろう、正式な管理アクションを指定します。
More generally, as asserted in Section 1 of the GIST specification, the GIST design could be extended to cater for multicast flows and for situations where the signaling is not tied to an end-to-end data flow. However, it is not clear whether this could be done in a totally backwards-compatible way, and this is not considered within the extensibility model of NSIS.
GIST仕様のセクション1でアサートとしてより一般的には、GIST設計は、マルチキャストフローのためのシグナリングは、エンドツーエンドデータフローに関連付けられていない状況に対応するために拡張することができます。しかし、完全に後方互換性のある方法で行うことができ、そしてこれはNSISの拡張性モデル内で考慮されていないかどうかは明らかではありません。
Currently, only two message routing methods are supported (Path Coupled MRM and Loose End MRM), but further MRMs may be defined in the future. See Sections 3.3 and 5.8 of the GIST specification [RFC5971]. One possible additional MRM under development is documented in [EST-MRM]. This MRM would direct signaling towards an explicit target address other than the (current) data flow destination and is intended to assist setting up of state on a new path during "make-before-break" handover sequences in mobile operations. Note that alternative routing methods may require modifications to the firewall traversal techniques used by GIST and NSLPs.
現在、2つだけのメッセージのルーティング方法は（パス結合MRM及び自由端MRM）サポートされているが、更なるのMRMは、将来的に定義されてもよいです。セクション3.3およびGIST仕様[RFC5971]の5.8を参照。開発中の一つの可能性のある追加のMRMは、[EST-MRM]に記述されています。このMRMは、（現在の）データフローの宛先以外の明示的なターゲットアドレスに向けてシグナリングとモバイル事業における「メイクの前にブレイク」ハンドオーバシーケンス中に新しいパス上の状態の設定を支援することを目的として指示します。代替ルーティング方法がGISTとNSLPsによって使用されるファイアウォールトラバーサル技法への変更を必要とし得ることに留意されたいです。
o New MRMs require allocation of a new MRM-ID either by IETF review of a specification or expert review [RFC5971].
新しいのMRMは、仕様書や専門家レビューのIETFレビュー[RFC5971]のいずれかによって新しいMRM-IDの割り当てを必要とoを。
The initial handshake between GIST peers allows a negotiation of the transport protocols to be used. Currently, proposals exist to add DCCP [GIST-DCCP] and the Stream Control Transmission Protocol (SCTP) [GIST-SCTP] transports to GIST; in each case, using Datagram TLS (DTLS) to provide security. See Sections 3.2 and 5.7 of the GIST specification [RFC5971]. GIST expects alternative capabilities to be treated as selection of an alternative protocol stack. Within the protocol stack, the individual protocols used are specified by MA Protocol IDs that are allocated from an IANA registry if new protocols are to be used. See Sections 5.7 and 9 of the GIST specification [RFC5971].
GISTピア間の最初のハンドシェイクは、トランスポートプロトコルの交渉を使用することができます。現在、提案はDCCP [GIST-DCCP]およびストリーム制御伝送プロトコル（SCTP）GIST-SCTP] GISTに搬送を追加するために存在します。それぞれの場合に、セキュリティを提供するために、データグラムTLS（DTLS）を使用。セクション3.2およびGIST仕様[RFC5971]の5.7を参照してください。 GISTは、代替機能は、代替プロトコルスタックの選択として処理されることを期待します。プロトコル・スタック内で、使用される個々のプロトコルは、新しいプロトコルが使用されるならば、IANAレジストリから割り当てられたMAプロトコルIDによって特定されます。切片をGIST仕様[RFC5971]の5.7および9を参照。
o Use of an alternative transport protocol or security capability requires allocation of a new MA-Protocol-ID either by IETF review of a specification or expert review [RFC5971].
O代替トランスポート・プロトコルやセキュリティ機能を使用すると、新しいMA-プロトコル-IDのいずれかの仕様や専門家レビューのIETFレビュー[RFC5971]によって割り当てが必要です。
Currently, only TLS is specified for providing secure channels with MAs. Section 3.9 of the GIST specification [RFC5971] suggests that alternative protocols could be used, but the interactions with GIST functions would need to be carefully specified. See also Section 4.4.2 of the GIST specification [RFC5971].
現在のところ、TLSはのMAで安全なチャンネルを提供するために指定されています。 GIST仕様[RFC5971]の3.9節では、代替のプロトコルを使用することができることを示唆しているが、GISTの機能との相互作用を慎重に指定する必要があります。また、GIST仕様[RFC5971]のセクション4.4.2を参照してください。
o Use of an alternative security service requires allocation of a new MA-Protocol-ID either by IETF review of a specification or expert review [RFC5971].
O代替セキュリティサービスの利用には、新しいMA-プロトコル-IDのいずれかの仕様や専門家レビューのIETFレビュー[RFC5971]によって割り当てが必要です。
GIST has standardized a scheme using RAO mechanisms [GIST-RAO] with UDP packets. If the difficulties of deploying the RAO scheme prove insuperable in particular circumstances, alternative interception schemes can be specified. One proposal that was explored for GIST used UDP port recognition in routers (rather than RAO mechanisms) to drive the interception of packets. See Section 5.3.2 of the GIST specification [RFC5971]. Each NSLP needs to specify membership of an "interception class" whenever it sends a message through GIST. A packet interception scheme can support one or more interception classes. In principle, a GIST instance can support multiple packet interception schemes, but each interception class needs to be associated with exactly one interception scheme in a GIST instance, and GIST instances that use different packet interception schemes for the same interception class will not be interoperable.
GISTは、UDPパケットとRAOメカニズム[GIST-RAO]を使用してスキームを標準化しました。 RAOスキームを導入することの難しさは、特定の状況では克服できないことを証明した場合、代替傍受スキームを指定することができます。 GISTのために調査した一つの提案は、パケットの傍受を駆動するためにUDPルータのポート認識（というよりもRAOメカニズム）を使用しました。 GIST仕様[RFC5971]のセクション5.3.2を参照してください。各NSLPは、GISTを介してメッセージを送信するとき、「傍受クラス」のメンバーシップを指定する必要があります。パケット傍受方式は、一つ以上の傍受クラスをサポートすることができます。原則として、GISTのインスタンスは、複数のパケット傍受スキームをサポートすることができますが、各傍受クラスは、1つのGISTのインスタンスで傍受スキーム、および相互運用可能ではありません同じ傍受クラスの異なるパケット傍受スキームを使用するGISTインスタンスに関連付けする必要があります。
Defining an alternative interception class mechanism for incorporation into GIST should be considered as a very radical step, and all alternatives should be considered before taking this path. The main reason for this is that the mechanism will necessarily require additional operations on every packet passing through the affected router interfaces. A number of considerations should be taken into account:
GISTに組み込むための代替傍受クラスのメカニズムを定義することは非常に過激ステップとして考慮されるべきであり、すべての選択肢がこのパスを取る前に考慮すべきです。この主な理由は、メカニズムは必ずしも影響を受けるルータインターフェイスを通過するすべてのパケットに対して追加の操作を必要とするということです。検討事項の数を考慮すべきです。
o Although the interception mechanism need only be deployed on routers that actually need it (probably for a new NSLP), deployment may be constrained if the mechanism requires modification to the hardware of relevant routers and/or needs to await modification of the software by the router vendor.
インターセプションメカニズムは唯一の実際（新NSLPのために、おそらく）それを必要とするルータ上で展開される必要があるが、Oメカニズムは、関連するルータのハードウェアへの変更を必要とする、および/またはによりソフトウェアの修正を待つ必要がある場合、展開が制約される可能性がありますルーターのベンダー。
o Typically, any packet fields to be examined should be near the header of the packet so that additional memory accesses are not needed to retrieve the values needed for examination.
追加のメモリアクセスが検査のために必要な値を取得するために必要とされないようにO典型的には、検査されるべき任意のパケットフィールドは、パケットのヘッダの近くにあるべきです。
o The logic required to determine if a packet should be intercepted needs to be kept simple to minimize the extra per-packet processing.
パケットを傍受する必要があるかどうかを判断するために必要なロジックoを余分なパケット単位の処理を最小限にするために、簡単な維持する必要があります。
o The mechanism should be applicable to both IPv4 and IPv6 packets.
O機構は、IPv4とIPv6の両方のパケットに適用すべきです。
o Packet interception mechanisms potentially provide an attack path for denial-of-service attacks on routers, in that packets are diverted into the "slow path" and hence can significantly increase the load on the general processing capability of the router. Any new interception mechanism needs to be carefully designed to minimize the attack surface.
Oパケット傍受機構は、潜在的にルータのサービス拒否攻撃の攻撃経路を提供し、そのパケットに「低速経路」に分流され、従って有意ルータの一般的な処理能力の負荷を増大させることができます。すべての新しいインターセプションメカニズムは慎重に攻撃面を最小限に抑えるように設計する必要があります。
Packet interception mechanisms are identified by an "interception class" which is supplied to GIST through the Application Programming Interface for each message sent.
パケット傍受機構が送信される各メッセージのアプリケーション・プログラミング・インタフェースを介してGISTに供給される「傍受クラス」によって識別されます。
o New packet interception mechanisms will generally require allocation of one or more new Interception-class-IDs. This does not necessarily need to be placed in an IANA registry as it is primarily used as a parameter in the API between the NSLPs and GIST and may never appear on the wire, depending on the mechanism employed; all that is required is consistent interpretation between the NSLPs and GIST in each applicable node. However, if, as is the case with the current RAO mechanism [GIST-RAO], the scheme distinguishes between multiple packet interception classes by a value carried on the wire (different values of RAO parameter for the RAO mechanism in GIST), an IANA registry may be required to provide a mapping between interception classes and on-the-wire values as discussed in Section 6 of [GIST-RAO].
O新しいパケット傍受メカニズムは、一般的に、1つまたは複数の新しい傍受クラス-IDの割り当てが必要になります。それは主にNSLPsとGISTの間のAPIのパラメータとして使用され、使用する機構に応じて、ワイヤ上に表示されないかもしれないので、これは必ずしもIANAレジストリに配置する必要がありません。必要とされるすべてのことは、該当する各ノードにおけるNSLPsとGISTの間の一貫性の解釈です。しかし、[GIST-RAO]現在RAO機構の場合のように、場合、スキームは、ワイヤ上に担持された値によって、複数のパケット傍受クラスを区別する（GISTにおけるRAOメカニズムのRAOパラメータの異なる値）、IANAレジストリは[GIST-RAO]のセクション6で説明したように傍受クラスとオン・ザ・ワイヤ値の間のマッピングを提供するために必要とされ得ます。
The mechanisms proposed for both legacy NAT traversal (Section 7.2.1 of the GIST specification [RFC5971]) and GIST-aware NAT traversal (Section 7.2.2 of the GIST specification [RFC5971]) can be extended or replaced. As discussed above, extension of NAT traversal may be needed if a new MRM is deployed. Note that there is extensive discussion of NAT traversal in the NAT/firewall NSLP specification [RFC5973].
両方の従来のNATトラバーサル（GIST仕様のセクション7.2.1 [RFC5971]）とGIST対応NATトラバーサル（GIST仕様のセクション7.2.2 [RFC5971]）のために提案されたメカニズムは、拡張または置換することができます。上述のように新たなMRMが配備されている場合、NATトラバーサルの拡張が必要とされ得ます。 NAT /ファイアウォールNSLP仕様[RFC5973]にNATトラバーサルの広範な議論があることに留意されたいです。
Making extensions to any of the above items may result in having to create new error modes. See Section 9 and Appendix A.4.1 - A.4.3 of the GIST specification [RFC5971].
上記項目のいずれかにエクステンションを作ることは新しいエラーモードを作成することになることがあります。 GIST仕様[RFC5971]のA.4.3 - 第9章および付録A.4.1を参照してください。
o Additional error identifiers require allocation of new error code(s) and/or subcode(s) and may also require allocation of Additional Information types. These are all allocated on a first-come, first-served basis by IANA [RFC5971].
O追加のエラー識別子は新しいエラーコード（単数または複数）および/またはサブコード（単数または複数）の割り当てを必要とし、追加情報タイプの割当てを必要とするかもしれません。これらはすべて、IANA [RFC5971]によって、先着順に割り当てられます。
The A/B (extensibility) flags in each signaling object carried in NSIS protocols enable the community to specify new objects applicable to GIST that can be carried inside a signaling session without breaking existing implementations. See Appendix A.2 of the GIST specification [RFC5971]. The A/B flags can also be used to indicate in a controlled fashion that a certain object must be understood by all GIST nodes, which makes it possible to probe for the support of an extension. One such object already designed is the "Peering Information Object (PIO)" [PEERING-DATA] that allows a Query message to carry additional peering data to be used by the recipient in making the peering decision.
A / B（拡張）NSISプロトコルで運ばれる各シグナルオブジェクトのフラグは、既存の実装を壊すことなく、シグナリングセッション内で実行することができるGISTに適用新しいオブジェクトを指定するためにコミュニティを可能にします。 GIST仕様[RFC5971]の付録A.2を参照してください。 A / Bフラグも拡張をサポートするためにプローブすることができる特定のオブジェクトが全てGISTノードによって理解されなければならない制御された様式で示すことができます。既に設計されたそのようなオブジェクトは、ピアリング決定を行う際に受信者によって使用される追加のピアリングデータを搬送するためにクエリメッセージを可能にする[-DATAピアリング「ピアリング情報オブジェクト（PIO）」です。
o New objects require allocation of a new Object Type ID either by IETF review of a specification or through another acceptable published specification [RFC5971].
O新しい目的は、明細書のIETFレビューにより、または他の許容可能な公開された仕様[RFC5971]のいずれかを介して新しいオブジェクトタイプIDの割り当てを要求します。
Major modifications could be made by adding additional GIST message types and defining appropriate processing. It might be necessary to define this as a new version of the protocol. A field is provided in the GIST Common Header containing the version number. GIST currently has no provision for version or capability negotiation that might be needed if a new version was defined.
主要な変更は、追加のGISTメッセージタイプを追加し、適切な処理を定義することによって行うことができます。プロトコルの新バージョンとしてこれを定義する必要がある場合があります。フィールドは、バージョン番号を含むGIST共通ヘッダで提供されています。 GISTは現在、バージョンまたは新しいバージョンが定義されていた場合に必要とされるかもしれない能力交渉のための規定を持っていません。
o New GIST Message Types require allocation of a new GIST Message Type ID either by IETF review of a specification or expert review [RFC5971].
oを新GISTメッセージタイプは、仕様書や専門家レビューのIETFレビュー[RFC5971]のいずれかによって、新たなGISTのメッセージタイプIDの割り当てを要求します。
The QoS NSLP provides signaling for QoS reservations on the Internet. The QoS NSLP decouples the resource reservation model or architecture (QoS model) from the signaling. The signaling protocol is defined in Quality-of-Service NSLP (QoS NSLP) [RFC5974]. The QoS models are defined in separate specifications, and the QoS NSLP can operate with one or more of these models as required by the environment where it is used. It is anticipated that additional QoS models will be developed to address various Internet scenarios in the future. Extensibility of QoS models is considered in Section 8.4.
QoSのNSLPは、インターネット上のQoS予約のためのシグナリングを提供します。 QoS NSLPシグナリングからリソース予約モデルまたはアーキテクチャ（QoSモデル）を切り離します。シグナリングプロトコルは、クオリティ・オブ・サービスNSLP（のQoS NSLP）[RFC5974]で定義されています。 QoSのモデルは、別の仕様で定義されている、それが使用されている環境で必要とされるようなQoS NSLPは、これらのモデルの一つ以上で動作することができます。追加のQoSモデルは、将来的に様々なインターネットのシナリオに対処するために開発されることが予想されます。 QoSのモデルの拡張性は、セクション8.4で考えられています。
The QoS NSLP specifically mentions the possibility of using alternative Message Routing Methods (MRMs), apart from the general ability to extend NSLPs using new objects with the standard A/B extensibility flags to allow them to be used in new and old implementations.
QoS NSLPは、具体的には離れて、それらは新旧の実装に使用することができるように、標準的なA / Bの拡張フラグと新しいオブジェクトを使用してNSLPsを拡張する一般的な能力から、別のメッセージルーティング方法（のMRM）を使用する可能性に言及しています。
There is already work to extend the base QoS NSLP and GIST to enable new QoS signaling scenarios. One such proposal is the Inter-Domain Reservation Aggregation aiming to support large-scale deployment of the QoS NSLP [RESV-AGGR]. Another current proposal seeks to extend the whole NSIS framework towards path-decoupled signaling and QoS reservations [HYPATH].
シナリオのシグナリング新しいQoSを有効にするために、ベースのQoS NSLPとGISTを拡張するために働くすでにあります。そのような提案は、QoS NSLP [RESV-AGGR]の大規模な展開をサポートすることを目指しドメイン間の予約アグリゲーションです。別の現在の提案は、パス切り離さシグナリングおよびQoS予約[HYPATH]に向かって全体NSISフレームワークを拡張することを目的とします。
The QoS Specification template (QSPEC) is defined in [RFC5975]. This provides the language in which the requirements of specific QoS models are described. Introduction of a new QoS model involves defining a new QSPEC. In order to have a new QSPEC allocated by IANA, there must be an acceptable published specification that defines the specific elements within the QSPEC used in the new model. See [RFC5975] for details.
QoSの仕様テンプレート（QSPEC）は[RFC5975]で定義されています。これは、特定のQoSモデルの要件が記載された言語を提供します。新しいQoSモデルの導入は、新しいQSPECの定義が含まれます。 IANAによって割り当てられた新しいQSPECを有するために、新しいモデルで使用QSPEC内の特定の要素を定義許容される公開された仕様が存在しなければなりません。詳細については、[RFC5975]を参照してください。
The introduction of new QoS models is designed to enable deployment of NSIS-based QoS control in specific scenarios. One such example is the Integrated Services Controlled Load Service for NSIS [CL].
新たなQoSモデルの導入は、特定のシナリオでNSISベースのQoS制御の導入を可能にするために設計されています。その一例がNSIS [CL]のための統合サービス制御負荷サービスです。
A key feature provided by defining the QSPEC template is support of a common language for describing QoS requirements and capabilities, which can be reused by any QoS models intending to use the QoS NSLP to signal their requirements for traffic flows. The commonality of the QSPEC parameters ensures a certain level of interoperability of QoS models and reduces the demands on hardware that has to implement the QoS control. Optional QSPEC parameters support the extensibility of the QoS NSLP to other QoS models in the future; new QSPEC parameters can be defined in the document that specifies a new QoS model. See Sections 4.4 and 7 of [RFC5975].
QSPECテンプレートを定義することにより提供重要な特徴は、トラフィックフローのための要件を合図するQoSのNSLPを使用しようとするすべてのQoSのモデルで再利用できるQoS要件や能力を、記述するための共通言語のサポートです。 QSPECパラメータの共通点は、QoSモデルの相互運用性のあるレベルを確保し、QoS制御を実装する必要があり、ハードウェア上の需要を低減します。オプションのQSPECパラメータは、将来的には他のQoSモデルにQoS NSLPの拡張をサポートしています。新しいQSPECパラメータは、新たなQoSモデルを指定したドキュメントで定義することができます。切片を、[RFC5975]の4.4および7を参照。
The QSPEC consists of a QSPEC version number, QSPEC objects, plus specification of processing and procedures that can be used to build many QoS models. The definition of a QSPEC can be revised without necessarily changing the version if the changes are functionally backwards compatible. If changes are made that are not backwards compatible, then a new QSPEC version number has to be assigned. Note that a new QSPEC version number is not needed just because additional QSPEC parameters are specified; new versions will be needed only if the existing functionality is modified. The template includes version negotiation procedures that allow the originator of an NSLP message to retry with a lower QSPEC version if the receiver rejects a message because it does not support the QSPEC version signaled in the message. See Section 3.2 of [RFC5975].
QSPECは、多くのQoSモデルを構築するために使用することができQSPECのバージョン番号、QSPECオブジェクト、プラス処理および手続きの仕様で構成されています。 QSPECの定義は変化が機能的に下位互換性がある場合は必ずバージョンを変更することなしに変更することができます。変更は後方互換性がありませんが作製されている場合は、新しいQSPECのバージョン番号が割り当てられている必要があります。新しいQSPECのバージョン番号が追加QSPECパラメータが指定されているという理由だけで必要とされていないことに注意してください。新バージョンでは、既存の機能が変更された場合にのみ必要になります。テンプレートは、メッセージでシグナリングQSPECバージョンをサポートしていないため、受信機がメッセージを拒否した場合NSLPメッセージの発信者が下部QSPECバージョンで再試行することを可能にするバージョンネゴシエーション手順を含みます。 [RFC5975]の3.2節を参照してください。
o Creation of a new, incompatible version of an existing QSPEC requires allocation of a new QSPEC version number that is documented in a permanent and readily available public specification. See [RFC5975].
O既存QSPECの新しい、互換性のないバージョンの作成は永久的で容易に入手可能な公開された仕様に記載されている新しいQSPECバージョン番号の割り当てを必要とします。 [RFC5975]を参照してください。
o Completely new QSPECs can also be created. Such new QSPECs require allocation of a QSPEC type that is documented in a permanent and readily available public specification. Values are also available for local or experimental use during development. See [RFC5975].
O完全に新しいQSPECsも作成することができます。このような新しいQSPECsは永久的かつ容易に入手可能な公開された仕様に記載されてQSPECタイプの割り当てを必要としています。値は、開発中のローカルまたは実験的な使用のために用意されています。 [RFC5975]を参照してください。
o Additional QSPEC procedures can be defined requiring allocation of a new QSPEC procedure number that is documented in a permanent and readily available public specification. Values are also available for local or experimental use during development. See [RFC5975].
O追加QSPEC手順は、永久的で容易に入手可能な公開された仕様に記載されている新たなQSPEC手順番号の割り当てを必要と定義することができます。値は、開発中のローカルまたは実験的な使用のために用意されています。 [RFC5975]を参照してください。
o Additional QSPEC parameters and associated error codes can be defined requiring a permanent and readily available public specification document. Values are also available for local or experimental use during development. See [RFC5975].
O追加QSPECパラメータと関連付けられたエラーコードは永久的で容易に入手可能な公開された仕様書を必要と定義することができます。値は、開発中のローカルまたは実験的な使用のために用意されています。 [RFC5975]を参照してください。
The NAT/firewall signaling can be extended broadly in the same way as the QoS NSLP by defining new parameters to be carried in NAT/firewall NSLP messages. See Section 7 of [RFC5973]. No proposals currently exist to fulfill new use cases for the protocol.
NAT /ファイアウォールのシグナル伝達は、NAT /ファイアウォールNSLPメッセージで運ばれる新しいパラメータを定義することによって、QoSのNSLPと同じように広く拡張することができます。 [RFC5973]のセクション7を参照してください。いかなる提案は、現在のプロトコルのための新しいユースケースを満たすために存在しません。
Designing a new NSLP is both challenging and easy.
新しいNSLPを設計することに挑戦し、簡単でもあります。
New signaling applications with associated NSLPs can be defined to work in parallel or replace the applications already defined by the NSIS working group. Applications that fit into the NSIS framework will be expected to use GIST to provide transport of signaling messages and appropriate security facilities that relieve the application designer of many "lower-level" problems. GIST provides many important functions through the API that it exposes to the code of the signaling application layer, and allows the signaling application programmer to offload various tasks to GIST, e.g., the channel security, transport characteristics, and signaling node discovery.
関連するNSLPsと新しいシグナリングアプリケーションは、並行して作業したり、すでにNSISワーキンググループによって定義されたアプリケーションを置き換えるために定義することができます。 NSISフレームワークにフィットするアプリケーションは、多くの「低レベル」の問題のアプリケーション設計を緩和シグナリングメッセージと適切なセキュリティ機能の輸送を提供するために、GISTを使用することが期待されます。 GISTは、シグナリングアプリケーション層のコードに公開されるAPIを介して多くの重要な機能を提供し、例えば、チャネルのセキュリティ、輸送特性、および信号ノード発見、GISTに様々なタスクをオフロードするために、シグナリングアプリケーションプログラマが可能になります。
Yet, on the other hand, the signaling application designer must take into account that the network environment can be dynamic, both in terms of routing and node availability. The new NSLP designer must take into account at least the following issues:
しかし、一方で、シグナリングアプリケーションの設計者は、ルーティングおよびノードの可用性の両方の観点から、ネットワーク環境が動的であることができることを考慮に入れる必要があります。新しいNSLP設計者は、アカウントに少なくとも以下の問題を取る必要があります。
o Routing changes, e.g., due to mobility: GIST sends network notifications when something happens in the network, e.g., peers or routing paths change. All signaling applications must be able to handle these notifications and act appropriately. GIST does not include logic to figure out what the NSLP would want to do due to a certain network event. Therefore, GIST gives the notification to the application, and lets it make the right decision.
Oルーティングが原因モビリティに、例えば、変更：GISTは何かがネットワークで発生したとき、例えば、ピアまたはルーティングパスが変更ネットワーク通知を送信します。すべてのシグナリングアプリケーションは、これらの通知を処理し、適切に行動することができなければなりません。 GISTはNSLPが原因特定のネットワークイベントにしたいと思うかを把握するためのロジックが含まれていません。したがって、GISTは、アプリケーションへの通知を与え、それが正しい決定を下すことができます。
o GIST indications: GIST will also send other notifications, e.g., if a signaling peer does not reply to refresh messages, or a certain NSLP message was not successfully delivered to the recipient. NSLP applications must also be able to handle these events. Appendix B in the GIST specification discusses the GIST-NSLP API and the various functionality required, but implementing this interface can be quite challenging; the multitude of asynchronous notifications that can arrive from GIST increases the implementation complexity of the NSLP.
O GIST適応症：シグナリングピアがメッセージをリフレッシュするために応答しない、または特定のNSLPメッセージが正常に受信者に配信されなかった場合GISTはまた、例えば、他の通知を送信します。 NSLPアプリケーションは、これらのイベントを処理できなければなりません。 GIST仕様の付録Bは、GIST-NSLPのAPIと必要なさまざまな機能について説明しますが、このインターフェイスを実装することは非常に困難な場合があります。 GISTから到着する非同期通知の多くはNSLPの実装の複雑さを増大させます。
o Lifetime of the signaling flow: NSLPs should inform GIST when a flow is no longer needed using the SetStateLifetime primitive. This reduces bandwidth demands in the network.
Oシグナリングフローの寿命：流れがもはやSetStateLifetimeプリミティブを使用して必要なときNSLPsはGISTを知らせるべきではありません。これは、ネットワークの帯域幅要求を低減します。
o NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new NSLP needs to use a unique NSLPID to ensure that its messages are delivered to the correct application by GIST. A single NSLP could use multiple NSLPIDs, for example, to distinguish different classes of signaling nodes that might handle different levels of aggregation of requests or alternative processing paths. Note that unlike GIST, the NSLPs do not provide a protocol versioning mechanism. If the new NSLP is an upgraded version of an existing NSLP, then it should be distinguished by a different NSLPID.
O NSLP IDが：NSLPメッセージはGISTのMAの上に多重化することができます。新しいNSLPは、そのメッセージがGISTによって適切なアプリケーションに配信されることを保証するために、独自のNSLPIDを使用する必要があります。単一NSLPは、要求または別の処理経路の集合の異なるレベルを扱う可能性があるノードのシグナリングの異なるクラスを区別するために、例えば、複数NSLPIDsを使用することができます。 GISTとは異なり、NSLPsは、プロトコルのバージョン管理メカニズムを提供しないことに注意してください。新しいNSLPは、既存のNSLPのアップグレード版である場合、それは異なるNSLPIDによって区別されるべきです。
* A new generally available NSLP requires IESG approval for the allocation of a new NSLP ID [RFC5971]
*新しい一般的に利用可能なNSLPは新しいNSLP ID [RFC5971]の割り当てのためのIESGの承認が必要です
o Incremental deployment: It would generally be unrealistic to expect every node on the signaling path to have a new NSLP implemented immediately. New NSLPs need to allow for this. The QoS and NAT/firewall NSLPs provide examples of techniques such as proxy modes that cater for cases where the data flow originator and/or receiver does not implement the NSLP.
Oインクリメンタル展開：一般的には、新しいNSLPが直ちに実施持っているシグナリングパス上のすべてのノードを期待するのは非現実的だろう。新NSLPsはこのために許可する必要があります。 QoSおよびNAT /ファイアウォールNSLPsは、データフローの発信及び/又は受信機はNSLPを実装していない場合に応えるプロキシモードのような技術の例を提供します。
o Signaling Message Source IP Address: It is sometimes challenging for an NSLP originating a signaling message to determine the source IP address that should be used in the signaling messages, which may be different from the data flow source address used in the MRI. This challenge occurs either when a node has multiple interfaces or is acting as a proxy for the data flow originator (typically expected to occur during the introduction of NSIS when not all nodes are NSIS enabled). A proxy signaling flow originator generally needs to know and use the correct data flow source IP address, at least initially. As discussed in Section 5.8.1.2 of [RFC5971], the signaling flow originator may choose to alter the source IP address after the initial Query message has established the flow path in order that ICMP messages are directed to the most appropriate node. In the proxy case, the data flow originator would be unaware of the signaling flow, and ICMP messages relating to the signaling would be meaningless if passed on to the data flow originator. Hence, it is essential that an NSLP is aware of the position and role of the node on which it is instantiated and has means of determining the appropriate source address to be used and ensuring that it is used on signaling packets.
OシグナリングメッセージのソースIPアドレス：これは時々MRIで使用されるデータ・フロー・ソース・アドレスと異なっていてもよいシグナリングメッセージに使用されるべき送信元IPアドレスを決定するためのシグナリングメッセージを発信NSLPために挑戦されています。この課題は、ノードが複数のインタフェースを有しているか、（典型的にはすべてのノードがNSISを有効になっているNSISの導入時に発生することが予想される）データフロー元のプロキシとして機能している場合のいずれかで起こります。プロキシ・シグナリングフロー発信元は、一般に、少なくとも最初は、知っている正しいデータフローの送信元IPアドレスを使用する必要があります。 [RFC5971]のセクション5.8.1.2で論じたように、信号フローの発信者は、最初のクエリメッセージは、ICMPメッセージが最も適切なノードに向けられるようにするために流路を確立した後にソースIPアドレスを変更することを選択することができます。プロキシ場合には、データ・フロー・オリジネータは、シグナリングフローを知らないであろう、そしてデータフロー発信者に渡された場合のシグナリングに関連するICMPメッセージは無意味であろう。したがって、NSLPは、それがインスタンス化して使用するための適切な送信元アドレスを決定し、それがシグナリングパケットに使用されることを保証する手段を有するされているノードの位置と役割を認識していることが必須です。
o New MRMs: GIST currently defines two Message Routing Methods, and leaves the door open for new ideas. Thus, it is possible that a new NSLP also requires a new MRM; path-decoupled routing being one example.
O新のMRM：GISTは現在、2つのメッセージのルーティング方法を定義し、新しいアイデアのためのオープンドアを残します。したがって、新しいNSLPも新しいMRMを必要とすることが可能です。パス切り離さルーティングは一例です。
o Cooperation with other NSLPs: Some applications might need resources from two or more different classes in order to operate successfully. The NSLPs managing these resources could operate cooperatively to ensure that such requests were coordinated to avoid wasting signaling bandwidth and prevent race conditions.
他のNSLPsとの連携○：一部のアプリケーションが正常に動作するために、2つの以上の異なるクラスからのリソースが必要になる場合があります。これらのリソースを管理NSLPsは、そのような要求は、シグナリング帯域幅の浪費を回避し、競合状態を防ぐために調整されたことを確認するために、協働して動作することができます。
It is essential that the security considerations of a new NSLP are carefully analyzed. NSIS NSLPs are deployed in routers as well as host systems; a poorly designed NSLP could therefore provide an attack vector for network resources as well as end systems. The NSLP must also support authorization of users and must allow the use of the GIST authentication and integrity protection mechanisms where users deem them to be necessary.
新しいNSLPのセキュリティの考慮事項を慎重に分析していることが不可欠です。 NSIS NSLPsは、ルータなどのホストシステムに配備されています。設計が不十分なNSLPは、したがって、ネットワークリソースの攻撃ベクトルだけでなく、エンドシステムを提供することができます。 NSLPは、ユーザーの認証をサポートしている必要がありますし、ユーザーが必要になるためにそれらを考えるGIST認証と完全性保護機構の使用を許可する必要があります。
The API between GIST and NSLPs (see Appendix B in [RFC5971]) is very important to understand. The abstract design in the GIST specification does not specify the exact messaging between GIST and the NSLPs but gives an understanding of the interactions, especially what kinds of asynchronous notifications from GIST the NSLP must be prepared to handle: the actual interface will be dependent on each implementation of GIST.
GISTとNSLPs間のAPIは（[RFC5971]の付録Bを参照）を理解することが非常に重要です。 GIST仕様の抽象的なデザインは、GISTとNSLPs間の正確なメッセージングを指定し、相互作用、NSLPを処理するために準備しなければならないGISTからの非同期通知の、特にどのような種類の理解を得られていません：実際のインタフェースは、各依存することになりますGISTの実装。
Messages transmitted by GIST on behalf of an NSLP are identified by a unique NSLP identifier (NSLPID). NSLPIDs are 16-bit unsigned numbers taken from a registry managed by IANA and defined in Section 9 of the GIST specification [RFC5971].
NSLPの代わりにGISTによって送信されたメッセージは、固有NSLP識別子（NSLPID）によって識別されます。 NSLPIDsレジストリIANAによって管理され、GIST仕様のセクション9で定義された[RFC5971]から採取した16ビット符号なし数です。
A range of values (32704-32767) is available for Private and Experimental use during development. Any new signaling application that expects to be deployed generally on the Internet needs to use the registration procedure "IESG Approval" in order to request allocation of unique NSLPID value(s) from the IANA registry. There is additional discussion of NSLPIDs in Section 3.8 of the GIST specification.
値の範囲（32704から32767）は、開発中の民間および実験的使用のために利用可能です。インターネット上で一般的に展開されることを想定して、任意の新しいシグナリングアプリケーションは、IANAレジストリからユニークNSLPID値（S）の割り当てを要求するために、登録手続き「IESG承認」を使用する必要があります。 GIST仕様の3.8節でNSLPIDsの追加の議論があります。
This document provides information to the community. It does not itself raise new security concerns.
この文書は、コミュニティに情報を提供します。それ自体は、新たなセキュリティ上の問題を提起しません。
However, any extensions that are made to the NSIS protocol suite will need to be carefully assessed for any security implications. This is particularly important because NSIS messages are intended to be actively processed by NSIS-capable routers that they pass through, rather than simply forwarded as is the case with most IP packets. It is essential that extensions provide means to authorize usage of capabilities that might allocate resources and recommend the use of appropriate authentication and integrity protection measures in order to exclude or adequately mitigate any security issues that are identified.
しかし、NSISプロトコル・スイートに行われたすべての拡張機能を十分に行い、セキュリティへの影響を評価する必要があります。 NSISメッセージは積極的に、ほとんどのIPパケットの場合のように単純に転送するのではなく、彼らが通過するNSIS対応ルータによって処理されることが意図されているので、これは特に重要です。拡張子がリソースを割り当て、除外または適切に識別されたすべてのセキュリティ上の問題を軽減するために、適切な認証と完全性保護措置の利用をお勧めかもしれない機能の使用を認可するための手段を提供することが不可欠です。
Authors of new extensions for NSIS should review the analysis of security threats to NSIS documented in [RFC4081] as well as considering whether the new extension opens any new attack paths that need to be mitigated.
NSISのための新しい拡張機能の作成者は、[RFC4081]に記載さNSISにセキュリティ上の脅威の分析を見直すだけでなく、新しい拡張機能を軽減する必要のある新しい攻撃パスを開くかどうかを検討すべきです。
GIST offers facilities to authenticate NSIS messages and to ensure that they are delivered reliably. Extensions must allow these capabilities to be used in an appropriate manner to minimize the risks of NSIS messages being misused and must recommend their appropriate usage.
GISTは、NSISメッセージを認証するために、それらが確実に配信されることを保証するために施設を提供しています。拡張機能は、これらの機能が誤用されているNSISメッセージのリスクを最小限に抑えるために、その適切な使用法をお勧めしなければならない適切な方法で使用できるようにする必要があります。
If additional transport protocols are proposed for use in association with GIST, an appropriate set of compatible security functions must be made available in conjunction with the transport protocol to support the authentication and integrity functions expected to be available through GIST.
追加のトランスポートプロトコルは、GISTに関連して使用することが提案されている場合、互換性のあるセキュリティ機能の適切なセットがGISTを介して利用可能であると予想認証および完全性機能をサポートするトランスポート・プロトコルと連動して利用可能にされなければなりません。
This document combines work previously published as two separate documents: "What is Next Steps in Signaling anyway - A User's Guide to the NSIS Protocol Family" written by Roland Bless and Jukka Manner, and "NSIS Extensibility Model" written by John Loughney.
ローランドによって書かれたマナーを祝福し、ユッカ、ジョンLoughneyによって書かれた「NSIS拡張モデル」 - 「NSISプロトコルファミリへのユーザーズガイドは何とにかくシグナリングに次のステップであること」：この文書は、以前に二つの別々の文書として公表された研究を兼ね備えています。
Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of the "User's Guide" and valuable input. Teemu Huovila also provided valuable input on the later versions.
マックスLaier、NuuttiヴァリスとラウリLiuhtoは、「ユーザーズ・ガイド」のレビューと貴重な入力を提供してきました。テームHuovilaも、それ以降のバージョンの貴重な入力を提供します。
The "Extensibility Model" borrowed some ideas and some text from RFC 3936 [RFC3936], "Procedures for Modifying the Resource ReSerVation Protocol (RSVP)". Robert Hancock provided text for the original GIST section, since much modified, and Claudia Keppler has provided feedback on this document, while Allison Mankin and Bob Braden suggested that this document be worked on.
「拡張性モデルは」いくつかのアイデアとRFC 3936 [RFC3936]からいくつかのテキスト、「リソース予約プロトコル（RSVP）を変更するための手順」を借りました。ロバート・ハンコックは、多くの変更以来、オリジナルのGISTのセクションのためのテキストを提供し、アリソンマンキンとボブブレーデンは、この文書が上に働いたことがあることを示唆しながら、クラウディア・ケプラーは、このドキュメントに関するフィードバックを提供してきました。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]ブルナー、M.、 "シグナリングプロトコルのための要件"、RFC 3726、2004年4月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（NSIS）：フレームワーク"、RFC 4080、2005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081] Tschofenig、H.およびD. Kroeselberg、 "シグナリングにおける次のステップのためのセキュリティの脅威（NSIS）"、RFC 4081、2005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、RFC 5971、2010年10月。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
[RFC5973] Stiemerling、M.、Tschofenig、H.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（NSLP）"、RFC 5973、2010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "NSISシグナリング層プロトコルクオリティ・オブ・サービスシグナリングのための（NSLP）"、RFC 5974、2010年10月。
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975]アッシュ、G.、ベイダー、A.、Kappler、C.、およびD.オラン、 "サービス品質NSISシグナリング層プロトコルのためのQSPECテンプレート（NSLP）"、RFC 5975、2010年10月。
[CL] Kappler, C., Fu, X., and B. Schloer, "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Work in Progress, April 2010.
[CL] Kappler、C.、フー、X.、及びB. Schloer、 "NSISとシグナリングイントサーブ制御・ロード・サービスのためのQoSモデル"、進歩、2010年4月の作業。
[EST-MRM] Bless, R., "An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol", Work in Progress, June 2010.
[EST-MRM]は、進歩、2010年6月に仕事をR.、 "一般的なインターネットシグナリングトランスポート（GIST）プロトコルのための明示的なシグナリングのターゲットメッセージルーティング方式（EST-MRM）" を祝福します。
[GIST-DCCP] Manner, J., "Generic Internet Signaling Transport over DCCP and DTLS", Work in Progress, June 2007.
[GIST-DCCP]マナー、J.、 "DCCPおよびDTLSを超える一般的なインターネットシグナリング交通"、進歩、2007年6月に作業。
[GIST-RAO] Hancock, R., "Using the Router Alert Option for Packet Interception in GIST", Work in Progress, November 2008.
[GIST-RAO]ハンコック、R.、「GISTにおけるパケット傍受のためのルータアラートオプションの使用」、進歩、2008年11月の作業。
[GIST-SCTP] Fu, X., Dickmann, C., and J. Crowcroft, "General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)", Work in Progress, May 2010.
[GIST-SCTP]フー、X.、Dickmann、C.、およびJ.クロウクロフト、 "一般的なインターネットシグナリングトランスポート（GIST）ストリーム制御伝送プロトコル（SCTP）およびデータグラムトランスポート層セキュリティ（DTLS）を超える" が進行中で働いて、 2010年5月。
[HYPATH] Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., Palma, D., Racaru, F., Diaz, M., and C. Chassot, "GIST Extension for Hybrid On-path Off-path Signaling (HyPath)", Work in Progress, February 2008.
【HYPATH] Cordeiro、L.、Curado、M.、モンテイロ、E.、ベルナルド、V.、パルマ、D.、Racaru、F.、ディアス、M.、およびC. Chassot、「ハイブリッド用GIST拡張オンオフパス進歩、2008年2月（HyPath）」、仕事をシグナリングパス。
[NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, "Authorization for NSIS Signaling Layer Protocols", Work in Progress, July 2008.
[NSIS-AUTH]マナー、J.、Stiemerling、M.、Tschofenig、H.、及びR.が祝福、 "NSISシグナリング層プロトコルの許可"、進歩、2008年7月に作業。
[PEERING-DATA] Manner, J., Liuhto, L., Varis, N., and T. Huovila, "Peering Data for NSIS Signaling Layer Protocols", Work in Progress, February 2008.
[ピアリング-DATA]マナー、J.、Liuhto、L.、ヴァリス、N.、およびT. Huovila、 "NSISシグナリング層プロトコルのためのピアリングデータ"、進歩、2008年2月に作業。
[RAO-BAD] Rahman, R. and D. Ward, "Use of IP Router Alert Considered Dangerous", Work in Progress, October 2008.
[RAO-BAD]ラーマン、R.およびD.区、進歩、2008年10月に作品、 "IPルータアラートの使用は危険な考慮しました"。
[RESV-AGGR] Doll, M. and R. Bless, "Inter-Domain Reservation Aggregation for QoS NSLP", Work in Progress, July 2007.
[RESV-AGGR】ドール、M.とR.は、 "QoSのNSLPのためのドメイン間の予約集約"、進歩、2007年7月の作業を祝福します。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、B.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004.
[RFC3936] Kompella、K.およびJ.ラング、 "リソース予約プロトコル（RSVP）を変更するための手順"、BCP 96、RFC 3936、2004年10月。
[RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service Signaling Protocols", RFC 4094, May 2005.
[RFC4094]マナー、J.およびX.フー、「既存のサービス品質シグナリングプロトコルの分析」、RFC 4094、2005年5月。
[TWO-LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture for Internet Signaling", Work in Progress, November 2002.
[TWO-LEVEL]ブレーデン、R.とB.リンデル、 "インターネットシグナリングのための二つのレベルのアーキテクチャ"、進歩、2002年11月に作業。
Authors' Addresses
著者のアドレス
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
コミュニケーションのアアルト大学学部およびネットワーキング（Comnet）私書箱からユッカマナー13000 FIN-00076アアルトフィンランド箱
Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi URI: http://www.netlab.tkk.fi/~jmanner/
電話：+358 9 470 22481 Eメール：jukka.manner@tkk.fi URI：http://www.netlab.tkk.fi/~jmanner/
Roland Bless Institute of Telematics, Karlsruhe Institute of Technology (KIT) Zirkel 2, Building 20.20 P.O. Box 6980 Karlsruhe 76049 Germany
ローランドは、テレマティクス研究所、カールスルーエ工科大学（KIT）Zirkel 2、20：20私書箱の構築を祝福しますボックス6980 76049カールスルーエドイツ
Phone: +49 721 608 6413 EMail: bless@kit.edu URI: http://tm.kit.edu/~bless
電話：+49 721 608 6413 Eメール：bless@kit.edu URI：http://tm.kit.edu/~bless
John Loughney Nokia 955 Page Mill Road Palo Alto, CA 94303 USA
ジョンLoughneyノキア955ページミルロードパロアルト、CA 94303 USA
Phone: +1 650 283 8068 EMail: john.loughney@nokia.com
電話：+1 650 283 8068 Eメール：john.loughney@nokia.com
Elwyn Davies (editor) Folly Consulting Soham UK
エルウィン・デイヴィス（エディタ）フォリーコンサルティングソーハム英国
EMail: elwynd@folly.org.uk URI: http://www.folly.org.uk
電子メール：elwynd@folly.org.uk URI：http://www.folly.org.uk