[要約] RFC 5978は、NSISプロトコルファミリーの使用と拡張に関するガイドラインです。このRFCの目的は、NSISプロトコルファミリーの機能と拡張性を理解し、効果的に使用するための指針を提供することです。
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
NSISプロトコルファミリを使用および拡張します
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）ワーキンググループの次のステップは、2001年11月に設立され、モビリティに関して、リソース予約プロトコル（RSVP）に基づいたソリューションの認知された欠点の一部を改善しようとするインターネットシグナリングプロトコルスイートを開発しました。およびサービス品質（QOS）の相互運用性。最初の憲章は、QoSシグナル伝達に最初のユースケースとして焦点を合わせており、RSVPを作業の背景としています。2003年5月、Middlebox Traversalが明示的な2番目のユースケースとして追加されました。新世代のシグナル伝達プロトコルの要件は[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層モデルに基づいています。このデザインは、「インターネットシグナル伝達のための2レベルのアーキテクチャ」[2レベル]というタイトルのボブブレーデンの文書の影響を受けました。
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.
このドキュメントは、執筆時（2010年）のNSISフレームワークとプロトコルスイートの概要を示し、NSISの現在のバージョンが設計されたユースケースの紹介を提供し、既存のネットワークにNSIを展開する方法を説明し、どのように要約するかを説明します。プロトコルスイートを強化して、新しいユースケースを満たすことができます。
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のアイデアと概念を再利用しますが、基本的に機能を2つのレイヤーに分割します。下層であるNSIS輸送層プロトコル（NTLP）は、パス上の次のシグナリングノードに高層プロトコルメッセージを輸送することを担当しています。これには、Next-Hop 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 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].
実際のシグナリングアプリケーションロジックは、NSISスタックの高層、NSISシグナリング層プロトコル（NSLP）に実装されます。GISTは、シグナリングノードのペア間でNSLPメッセージのホップバイホップを輸送することにのみ関係していますが、必要に応じてNSLPプロトコルによってエンドツーエンドのシグナリング機能が提供されます。すべてのNSLPプロトコルがエンドツーエンドのシグナル伝達を実行する必要があるわけではありません。現在のプロトコルには、シグナリングをパスの限られた部分（ドメインの内部など）に限定する機能があります。NSLPに代わってGISTによって送信されるメッセージは、NSLPに関連付けられた一意のNSLP識別子（NSLPID）によって識別されます。現在、2つのNSLPプロトコルが指定されています。1つはサービス品質シグナル伝達[RFC5974]と、NAT/ファイアウォールトラバーサル[RFC5973]を有効にする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
o 基本的なパスは、データフローが続くパスに沿って信号を駆動するように設計されたMRMを結合し、
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.
o データフローの目的地がこの種のミドルボックスの後ろにある場合、ファイアウォールとネットワークアドレス変換（NAT）ミドルボックスで状態を前処理するために適用される代替のルーズエンドMRM。前提条件なしでは、これらのミドルボックスは一般に、ミドルボックスによって「保護されている」地域の外側と目的地の位置にあるシグナリングメッセージを拒否します。
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）です。シグナリングアプリケーションの状態は、すべてのNSLPで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.
プロトコルスイートの第1フェーズには、次の設計制限が課されました。それらは将来解除される可能性があり、後の段階で新しい機能をプロトコルに追加することができます。
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.
o パス結合シグナリングのMRMSへの初期焦点：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]
o NSISのセキュリティの脅威[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] o Quality-of-Service NSLP (QoS NSLP) [RFC5974]
o 一般的なインターネットシグナリングトランスポートプロトコル[RFC5971] oサービス品質NSLP（QOS NSLP）[RFC5974]
o The QoS specification template [RFC5975]
o QOS仕様テンプレート[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は通常、UDPを使用し、信頼性が必要な場合はTCP、安全な（および信頼性の高い）シグナル伝達フローのために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メッセージの輸送に使用できるいくつかの可能なプロトコルを示しています。認証および/または整合性保護サポートを提供するには、TRANSTREMENT PROTOCOLを適切なセキュリティメカニズム、たとえばTLSを備えたTCP、またはDTLSとDatagram混雑制御プロトコル（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認識ピアノードのペア間の多くのセグメントに分割します。パス上のすべてのルーターまたはその他のミドルボックスがNSIを認識する必要があるわけではありません。信号パスの各セグメントには、いくつかのルーティングホップが組み込まれる場合があります。また、すべての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）を設定します。状態のセットアップは、シグナリングフローパラメーターの交渉を可能にする3方向の握手によって実行され、Cookieメカニズムと後期の状態設定オプションを使用して、いくつかの攻撃（サービス拒否など）に対する対策を提供します。
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などの信頼できるまたは安全なシグナリングを提供する必要があり、2つのピア間にメッセージング協会（MA）が確立されます。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認識ノードによって傍受されるように、クエリメッセージパケットにルーターアラートオプション（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の開発の後半で、IETFでは、Rao [Rao-Bad]の広範な使用のセキュリティリスクとパフォーマンスの影響について深刻な懸念が提起されました。さらに、RAOのいくつかの既存の実装が（意図の）基準と矛盾しており、NSISの使用をサポートしないことを示す証拠が発見されました。また、ハードウェアで頻繁に実装されるルーターの高速パスでRAO認識の必要性を拡大すると、NSIの実装と展開が遅れたり、展開されたりするという懸念がありました。最終的に、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状態は、シグナリングアプリケーション層と信号輸送層の両方に保持され、個別に維持されています。NSLPは、タイムアウトを設定し、他のメッセージが不要な場合はシグナリングパスに沿って定期的な「維持」メッセージを送信することにより、シグナリングアプリケーション層の状態の寿命を制御します。MASとルーティング状態は、輸送層によって半独立して維持されます。これは、MASが複数のNSLPセッションで使用される可能性があり、ノードがリソースを取り戻す必要がある場合は「オンデマンド」に再作成することもできるためです。輸送層は、NSLPメッセージが送信されていない場合、輸送層が現在使用されているMAを使用している場合でも、頻繁に使用されるMAを維持することを決定した場合、NSLPメッセージが送信されていない場合、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.
NSIが状態を作成したフローによって使用されるルートに変更がある場合、NSISは、新しいパスに状態インストールが必要な追加のNSISノードが含まれているかどうかを判断するために変更を検出する必要があります。GISTは、ルートの変更を検出するために、さまざまなトリガーを使用する場合があります。GISTクエリを送信することにより、次のピア用に定期的にプローブし、変更されたルートとGISTピアを検出します。GISTはルーティングテーブルとGISTピア状態を監視し、NSLPにルーティングの変更を通知します。必要に応じて、リフレッシュメッセージを発行することにより、必要に応じて適切に行動するのはNSLP次第です。定期的なクエリは、ルートが変更されていない限り、ソフトステートをノード内のソフトステートを維持するのにも役立ちます。
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ピア間のMASを介して通信を制御するソフトステートを確立し、維持します。
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の設計は、RSVP、RFC 2205 [RFC2205]に概念的に類似しており、ソフトステートピアツーピアリフレッシュメッセージをプライマリ状態管理メカニズムとして使用します（つまり、隣接するNSLPのペア間で状態のインストール/更新が実行されます。完全な信号パスに沿ったエンドツーエンドの方法ではなく、ノード）。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 NSLPは、ドメインで使用する必要があるQoSメカニズムとRMFを定義していないため、さまざまなQoSモデルをサポートしています。ドメインが特定のQSPECの入場制御を実行する方法を知っている限り、QoS NSLPは、たとえば、4つのdiffservクラスの最上位に関連するデータフローを配置するか、それを置くことにより、指定された制約がどのように施行され、満たされるかを実際に気にしません12のDiffServクラスの3番目に高い。使用される特定の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)
o シグナリングプロトコル（QOS NSLP）から切り離されたリソース要求（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.
また、プロトコルは、すべてのエンドホストがNSISシグナリングを処理できるようにすることなくQoSシグナリングを実装できるようにするプロキシモードを提供します。
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イニシエーター）で始まります。シグナリングメッセージは、NAT/ファイアウォールNSLP Aware（NSIS Forwarder）であるいくつかのミドルボックスを下流に渡し、通常はレシーバー（NSIS Responder）をヒットする場合があります。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.
また、プロトコルは、すべてのエンドホストをNSISシグナリングに処理できる必要なく、NAT/ファイアウォールシグナリングを実装できるようにするプロキシモードも提供します。
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サポートだけでなく、NSLPとそれぞれの制御機能（QoS入学制御などのリソース管理関数など）も実装する必要があります。NSISは増分展開が可能であり、初期展開はネットワークドメイン内のすべてのノードを関与させる必要はありません。これについては、セクション6.3でさらに説明します。RAOの実装が壊れているために遭遇する可能性のある障害物がいくつかあります（セクション6.1を参照）、およびNSISシグナリングパケットをドロップするファイアウォールまたはNAT（セクション6.2を参照）があります。
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.
もう1つの重要な問題は、アプリケーションを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を含むパケットに正しく認識し、作用する他のミドルボックスに依存します。NSIの展開を妨害できる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.
o NSISのRAOに関する主要なセキュリティ上の懸念は、データパスのルーターのコントロールプレーンに（分散型）サービス拒否（DDOS）攻撃をマウントするホストが新しいベクトルを提供することです。このような攻撃が発生しているため、サービスプロバイダーがRSVPやNSIなどの「ホストからルーターへの」シグナリングパケットが顧客ネットワークからネットワークに入ることを禁止することは普通です。これにより、DDOSの脅威の適切な緩和が見つかり、展開されない限り、NSIの展開を「壁に囲まれた庭園」に制限する傾向があります。
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を介してNSIを操作することはできない場合があります。状況と回避策については、[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を認識することは必須ではありません。NSIを使用するには、パス上の少なくとも2つのノードがNSIを認識する必要があります。ただし、データフローのイニシエーターと受信者がNSISが認識していることは不可欠ではありません。QOSとNAT/ファイアウォールNSLPの両方が、イニシエーターおよび/またはレシーバーに隣接するノードがプロキシシグナリングイニシエーターまたはレシーバーとして機能する「プロキシモード」を提供します。イニシエータープロキシは、トラフィックを監視し、NSISサポートが必要なタイプのデータフローがいつ開始されるかを検出できます。プロキシは、データフローイニシエーターおよび/または受信機に代わって多かれ少なかれ透過的に行動して、必要なNSIS状態を設定し、データフローが続く間にそれを維持することができます。この機能により、NSIが実行可能になる前に、すべてのデータフローエンドポイントを変更するための即時のニーズが減少します。
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に現在重点を置いていない攻撃手段を提供する可能性があることに注意してください。概念的には、パス結合されたMRMSを使用する場合、パス上の攻撃者と中間の攻撃から保護することは困難です。これは、要点の基本的な機能はまだ未知のシグナル伝達ピアを発見することであるためです。輸送セキュリティは、シグナリングアプリケーションによって要求され、シグナリングピア間でTLSを使用することで実現できます。つまり、シグナリングメッセージの信頼性と機密性をピア間で保証できます。GISTは、シグナリングピアの相互認証を可能にし（証明書などのTLS手段を使用）、GISTシグナル伝達に参加することを許可されたノードのデータベースに対して認証されたアイデンティティを検証できます。ただし、ピアのアイデンティティが安全な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.
将来、追加の信号要件が特定されることが期待されています。2層アプローチにより、NSLPシグナリングアプリケーションは、輸送プロトコルとは独立して開発されます。したがって、さらにNSLPを開発および展開して、同じ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プロトコルで運ばれるパラメーターオブジェクトの重要な機能の1つは、いわゆる「拡張フラグ（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が維持したレジストリに一意のコードポイント値の割り当てを必要とします。これと次のセクションでは、適用される可能性のある管理メカニズムの概要を説明します。以下に定義されている拡張性ルールは、IANAが「IESG承認」、「IETFレビュー」、「エキスパートレビュー」、および「プライベート使用」（[RFC5226]で指定）の値を割り当てる手順に基づいています。特定のタイプのコードポイントの適切な手順は、NSISプロトコルドキュメントの1つまたは他の手順で定義されています。これは、主に[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!
登録されたコードポイントに加えて、すべてのNSISプロトコルは、[RFC3692]で説明されているように、通常は閉じたネットワーク内で実験に使用できるコードポイントを提供します。独立した実験が同じコードポイントを使用しないという保証はありません！
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つのメッセージルーティングメソッドのみがサポートされています（PATH結合MRMとルーズエンドMRM）が、将来さらにMRMが定義される場合があります。GIST仕様[RFC5971]のセクション3.3および5.8を参照してください。開発中の追加のMRMの1つが[EST-MRM]に記録されています。このMRMは、（現在の）データフローの宛先以外の明示的なターゲットアドレスにシグナリングを向け、モバイルオペレーションでの「ブレイク前」のハンドオーバーシーケンス中に新しいパスでの状態のセットアップを支援することを目的としています。代替ルーティング方法には、GISTおよびNSLPが使用するファイアウォールトラバーサルテクニックの変更が必要になる場合があることに注意してください。
o New MRMs require allocation of a new MRM-ID either by IETF review of a specification or expert review [RFC5971].
o 新しいMRMSには、仕様または専門家のレビュー[RFC5971]のIETFレビューにより、新しいMRM-IDの割り当てが必要です。
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]を追加する提案が存在し、Stream Control Transmission Protocol（SCTP）[GIST-SCTP]がGISTに輸送されます。いずれの場合も、Datagram TLS（DTLS）を使用してセキュリティを提供します。GIST仕様[RFC5971]のセクション3.2および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 代替輸送プロトコルまたはセキュリティ機能を使用するには、仕様または専門家レビュー[RFC5971]のIETFレビューにより、新しいMA-Protocol-IDの割り当てが必要です。
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].
現在、MASで安全なチャネルを提供するためにTLSのみが指定されています。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 代替セキュリティサービスの使用には、仕様または専門家のレビュー[RFC5971]のIETFレビューにより、新しいMA-Protocol-IDの割り当てが必要です。
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は、RAOメカニズム[GIST-RAO]を使用してUDPパケットを使用してスキームを標準化しています。RAOスキームを展開することの難しさが特定の状況で克服できないことが証明された場合、代替傍受スキームを指定できます。パケットの傍受を促進するために（RAOメカニズムではなく）ルーターでUDPポート認識を使用したGISTについて調査された1つの提案。GIST仕様[RFC5971]のセクション5.3.2を参照してください。各NSLPは、GISTを介してメッセージを送信するたびに「インターセプトクラス」のメンバーシップを指定する必要があります。パケットインターセプトスキームは、1つ以上の傍受クラスをサポートできます。原則として、GISTインスタンスは複数のパケットインターセプトスキームをサポートできますが、各インターセプトクラスは、GISTインスタンスで正確に1つの傍受スキームに関連付けられる必要があり、同じインターセプトクラスに異なるパケットインターセプトスキームを使用する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.
o インターセプトメカニズムは実際にそれを必要とするルーターに展開する必要がありますが（おそらく新しいNSLP用）、メカニズムが関連するルーターのハードウェアの変更やルーターによるソフトウェアの変更を待つ必要がある場合、展開が制約される場合がありますベンダー。
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レジストリに配置する必要はありません。必要なのは、該当する各ノードのNSLPとGISTの間の一貫した解釈です。ただし、現在のRAOメカニズム[GIST-RAO]の場合と同様に、スキームは、ワイヤに掲載された値（GISTのRAOメカニズムのRAOパラメーターの異なる値）によって複数のパケット傍受クラスを区別します。[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]のセクション9および付録A.4.1 -A.4.3を参照してください。
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.
NSISプロトコルに搭載されている各信号オブジェクトのA/B（拡張性）フラグにより、コミュニティは、既存の実装を壊すことなくシグナリングセッション内で運ぶことができるGISTに適用可能な新しいオブジェクトを指定できます。GIST仕様[RFC5971]の付録A.2を参照してください。A/Bフラグを使用して、特定のオブジェクトがすべてのGISTノードによって理解される必要があることを制御された方法で示すこともできます。これにより、拡張機能のサポートのためにプローブできます。すでに設計されたそのようなオブジェクトの1つは、「Peering Information Object（PIO）」[Peering-Data]です。これにより、クエリメッセージがピーアリングの決定を下す際に追加のピアリングデータを受信者が使用できるようにします。
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メッセージタイプは、仕様またはエキスパートレビュー[RFC5971]のIETFレビューにより、新しい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は、使用される環境で必要なこれらのモデルの1つ以上で動作できます。将来、さまざまなインターネットシナリオに対処するために、追加の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拡張可能性フラグを使用して新しいオブジェクトを使用してNSLPを拡張する一般的な能力を除けば、新しいオブジェクトを新しい実装および古い実装で使用できるようにする一般的な能力を除けば、代替メッセージルーティングメソッド（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を拡張する作業がすでにあります。そのような提案の1つは、QoS NSLP [RESV-AGGR]の大規模な展開をサポートすることを目的としたドメイン間予約集約です。別の現在の提案は、NSISフレームワーク全体をパス分解シグナル伝達とQoS予約に向けて拡張しようとしています[Hypath]。
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制御の展開を可能にするように設計されています。そのような例の1つは、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要件と機能を記述するための共通言語のサポートです。これは、QoS NSLPを使用してトラフィックフローの要件を示すQoSモデルで再利用できます。QSPECパラメーターの共通性により、QoSモデルの一定レベルの相互運用性が保証され、QoSコントロールを実装する必要があるハードウェアに対する要求が減少します。オプションのQSPECパラメーターは、将来のQoS NSLPの他のQoSモデルへの拡張性をサポートしています。新しい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は、QSPECバージョン番号、QSPECオブジェクト、さらに多くのQoSモデルを構築するために使用できる処理と手順の仕様で構成されています。QSPECの定義は、変更が機能的に後方互換性がある場合、必ずしもバージョンを変更することなく修正できます。逆方向に互換性がない変更が行われた場合、新しいQSPECバージョン番号を割り当てる必要があります。追加のQSPECパラメーターが指定されているという理由だけで、新しいQSPECバージョン番号は必要ないことに注意してください。既存の機能が変更された場合にのみ、新しいバージョンが必要になります。テンプレートには、NSLPメッセージのオリジネーターが低いQSPECバージョンで再試行できるようにするバージョンネゴシエーション手順が含まれています。レシーバーがメッセージで信号を送信した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 完全に新しいQSPECも作成できます。このような新しいQSPECには、永続的で容易に利用可能な公開仕様で文書化される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.
関連するNSLPを使用した新しいシグナリングアプリケーションは、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の適応：GISTは、他の通知も送信します。たとえば、シグナリングピアがメッセージを更新するために返信しない場合、または特定のNSLPメッセージが受信者に正常に配信されなかった場合。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 シグナリングフローの寿命：NSLPは、SetStateLifetimeプリミティブを使用してフローが不要になった場合に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 IDS：NSLPメッセージは、GIST MASで多重化される場合があります。新しいNSLPは、一意のNSLPIDを使用して、そのメッセージがGISTによって正しいアプリケーションに配信されるようにする必要があります。単一のNSLPは、たとえば、複数のNSLPIDを使用して、リクエストまたは代替処理パスのさまざまなレベルの集約を処理する可能性のある異なるクラスのシグナリングノードを区別できます。GISTとは異なり、NSLPはプロトコルバージョン化メカニズムを提供しないことに注意してください。新しい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をすぐに実装することを期待することは非現実的です。新しいNSLPはこれを許可する必要があります。QOSおよびNAT/ファイアウォールNSLPは、データフローオリジターおよび/またはレシーバーが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アドレス：信号メッセージを発信するNSLPが、MRIで使用されるデータフローソースアドレスとは異なる可能性のあるシグナリングメッセージで使用する必要があるソースIPアドレスを決定することが困難な場合があります。この課題は、ノードに複数のインターフェイスがある場合、またはデータフローオリジターターのプロキシとして機能している場合に発生します（すべてのノードがNSIを有効にしているわけではない場合、NSIの導入中に発生すると予想されます）。プロキシシグナリングフローオリジネーターは、一般に、少なくとも最初は正しいデータフローソースIPアドレスを知り、使用する必要があります。[RFC5971]のセクション5.8.1.2で説明したように、Signaling Flow Originatorは、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 新しいMRMS：GISTは現在、2つのメッセージルーティング方法を定義しており、新しいアイデアのためにドアを開いたままにしています。したがって、新しいNSLPにも新しいMRMが必要である可能性があります。パス分離ルーティングは1つの例です。
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.
o 他のNSLPとの協力：一部のアプリケーションでは、2つ以上の異なるクラスのリソースが必要になる場合があります。これらのリソースを管理するNSLPは、シグナル伝達帯域幅を無駄にし、人種条件を防ぐために、そのような要求が調整されたことを確認するために協力的に動作する可能性があります。
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 NSLPは、ホストシステムと同様にルーターに展開されます。したがって、設計が不十分な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とNSLPの間のAPI（[RFC5971]の付録Bを参照）を理解することは非常に重要です。GIST仕様の抽象設計では、GISTとNSLPの間の正確なメッセージングを指定するのではなく、相互作用、特にNSLPが処理するために準備する必要がある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）によって識別されます。NSLPIDは、IANAによって管理され、GIST仕様[RFC5971]のセクション9で定義されているレジストリから取得した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値の割り当てを要求するために、登録手順「IESG承認」を使用する必要があります。GIST仕様のセクション3.8には、NSLPIDの追加の議論があります。
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]で文書化されたNSIに対するセキュリティの脅威の分析を確認するだけでなく、新しい拡張が軽減する必要がある新しい攻撃パスを開くかどうかを検討する必要があります。
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.
このドキュメントは、以前に公開された2つの別々のドキュメントとして公開された作品を組み合わせています。「とにかくシグナリングの次のステップ - NSISプロトコルファミリーへのユーザーガイド」とRoland BlessとJukka Matherによって書かれたもの、およびJohn Loughneyが書いた「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.
Max Laier、Nuutti Varis、Lauri Liuhtoは、「ユーザーガイド」と貴重な入力のレビューを提供しています。Teemu 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] Brunner、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] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「シグナルの次のステップ（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. Hancock、「Gist：General Internet Signaling Transport」、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.、Aoun、C。、およびE. Davies、「Nat/Firewall NSIS Signaling Layer Protocol（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] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のための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] Ash、G.、Bader、A.、Kappler、C。、およびD. Oran、「サービス品質NSISシグナリング層プロトコル（NSLP）のQSPECテンプレート」、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.、Fu、X。、およびB. Schloer、「NSISを使用したIntServ制御荷重サービスの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] Bless、R。、「一般的なインターネットシグナリング輸送（GIST）プロトコルの明示的なシグナリングターゲットメッセージルーティング方法（EST-MRM）」、2010年6月の作業。
[GIST-DCCP] Manner, J., "Generic Internet Signaling Transport over DCCP and DTLS", Work in Progress, June 2007.
[GIST-DCCP] MANER、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] Hancock、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] Fu、X.、Dickmann、C。、およびJ. Crowcroft、「一般的なインターネットシグナリングトランスポート（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.、Monteiro、E.、Bernardo、V.、Palma、D.、Racaru、F.、Diaz、M。、およびC. Chassot、「ハイブリッドのGIST拡張Path Off-Path Signaling（Hypath） "、2008年2月、進行中の作業。
[NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, "Authorization for NSIS Signaling Layer Protocols", Work in Progress, July 2008.
[NSIS-Auth] Mater、J.、Stiemerling、M.、Tschofenig、H。、およびR. Bless、「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.
[Peering-data] Mather、J.、Liuhto、L.、Varis、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] Rahman、R。およびD. Ward、「危険と見なされるIPルーターアラートの使用」、2008年10月の作業。
[RESV-AGGR] Doll, M. and R. Bless, "Inter-Domain Reservation Aggregation for QoS NSLP", Work in Progress, July 2007.
[RESV-AGGR] Doll、M。およびR. Bless、「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] Braden、B.、Clark、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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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. Lang、「リソース予約プロトコル（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] MANER、J。およびX. FU、「既存のサービス品質シグナル伝達プロトコルの分析」、RFC 4094、2005年5月。
[TWO-LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture for Internet Signaling", Work in Progress, November 2002.
[2レベル] Braden、R。およびB. Lindell、「インターネットシグナリングのための2レベルのアーキテクチャ」、2002年11月、進行中の作業。
Authors' Addresses
著者のアドレス
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
Jukka Mather Aalto University of Communications and Networking（COMNET）P.O。Box 13000 Fin-00076 Aalto Finland
Phone: +358 9 470 22481
EMail: 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
Roland Bless Institute of Telematics、Karlsruhe Institute of Technology（Kit）Zirkel 2、Building 20.20 P.O.Box 6980 Karlsruhe 76049ドイツ
Phone: +49 721 608 6413
EMail: bless@kit.edu
URI: http://tm.kit.edu/~bless
John Loughney Nokia 955 Page Mill Road Palo Alto, CA 94303 USA
ジョン・ラウニー・ノキア955ページ・ミル・ロード・パロ・アルト、カリフォルニア州94303 USA
Phone: +1 650 283 8068
EMail: john.loughney@nokia.com
Elwyn Davies (editor) Folly Consulting Soham UK
Elwyn Davies（編集者）Folly Consulting Soham UK
EMail: elwynd@folly.org.uk
URI: http://www.folly.org.uk