[要約] RFC 5973は、NSISフレームワークにおいて、パス上のファイアウォールやNATデバイスを動的に制御するためのプロトコル「NAT/FW NSLP」の仕様を定義しています。アプリケーションが自身の通信パケットを透過させるために、中継機器に対してピンホールの開放やアドレス変換のルールを安全に要求・管理するためのシグナリング手順を提供します。
Internet Engineering Task Force (IETF) M. Stiemerling
Request for Comments: 5973 NEC
Category: Experimental H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
C. Aoun
Consultant
E. Davies
Folly Consulting
October 2010
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
NAT/Firewall NSIS Signaling Layer Protocol（NSLP）
Abstract
概要
This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.
本メモでは、ネットワークアドレス変換器（NAT）およびファイアウォール向けのNSIS Signaling Layer Protocol（NSLP）を定義します。このNSLPを使うと、ホストはデータ経路上でシグナリングし、アプリケーションのデータフローに応じてNATやファイアウォールを設定できます。たとえば、NAT配下のホストがインターネットから到達可能なアドレスを取得したり、ファイアウォール配下のホストがデータトラフィックを受信したりできます。全体のアーキテクチャは、Next Steps in Signaling（NSIS）ワーキンググループが定めたフレームワークと要件に基づきます。本メモでは、ネットワークシナリオ、プロトコル、およびパス結合シグナリングの例を示します。
Status of This Memo
本書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本書はインターネット標準化過程の仕様ではありません。検討、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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.
本書はインターネットコミュニティ向けの実験プロトコルを定義します。本書はInternet Engineering Task Force（IETF）の成果であり、IETFコミュニティの合意を示しています。公開レビューを受け、Internet Engineering Steering Group（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/rfc5973.
本書の現在の状態、正誤表、およびフィードバックの送付方法については、http://www.rfc-editor.org/info/rfc5973 を参照してください。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
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文書に関するIETF Trustの法的規定（http://trustee.ietf.org/license-info）の対象です。これらの文書には本書に関する権利と制限が記載されているため、内容をよく確認してください。本書から抜き出したコードコンポーネントには、Trustの法的規定4.e節に記載されたSimplified BSD Licenseの文面を含める必要があります。また、Simplified BSD Licenseに記載されたとおり、保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本書には、2008年11月10日より前に公開または一般公開されたIETF文書やIETF寄稿物の内容が含まれている場合があります。その一部の著作権者は、IETF Trustに対し、IETF標準化過程の外でその内容を変更する許可を与えていない可能性があります。著作権者から適切なライセンスを得ない限り、IETF標準化過程の外で本書を変更したり、その派生物を作成したりすることはできません。ただし、RFCとして公開するための書式調整、および英語以外の言語への翻訳は除きます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8 1.3. Notes on the Experimental Status . . . . . . . . . . . . . 10 1.4. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 1.5. General Scenario for NATFW Traversal . . . . . . . . . . . 11 2. Network Deployment Scenarios Using the NATFW NSLP . . . . . . 13 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 2.2. NAT with Two Private Networks . . . . . . . . . . . . . . 14 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 2.4. NAT with Private Network on Receiver Side Scenario . . . . 15 2.5. Both End Hosts behind Twice-NATs . . . . . . . . . . . . . 16 2.6. Both End Hosts behind Same NAT . . . . . . . . . . . . . . 17 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 18 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 19 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 20 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 20 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 24 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 24 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 25 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 25 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 27 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31 3.6. Authentication, Authorization, and Policy Decisions . . . 32 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 35 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 45 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 48 3.8. Demultiplexing at NATs . . . . . . . . . . . . . . . . . . 53 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 54 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 55 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 56 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 58 4.2.2. External Address Object . . . . . . . . . . . . . . . 58 4.2.3. External Binding Address Object . . . . . . . . . . . 59 4.2.4. Extended Flow Information Object . . . . . . . . . . . 59 4.2.5. Information Code Object . . . . . . . . . . . . . . . 60 4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 64 4.2.7. Message Sequence Number Object . . . . . . . . . . . . 64 4.2.8. Data Terminal Information Object . . . . . . . . . . . 64 4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 66 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 67 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 67 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 69 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 70 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 70 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 71 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 72 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 73 5.2.1. Security Protection between Neighboring NATFW NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.2. Security Protection between Non-Neighboring NATFW NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 74 5.3. Implementation of NATFW NSLP Security . . . . . . . . . . 75 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 7.1. NATFW NSLP Message Type Registry . . . . . . . . . . . . . 77 7.2. NATFW NSLP Header Flag Registry . . . . . . . . . . . . . 77 7.3. NSLP Message Object Registry . . . . . . . . . . . . . . . 78 7.4. NSLP Response Code Registry . . . . . . . . . . . . . . . 78 7.5. NSLP IDs and Router Alert Option Values . . . . . . . . . 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 79 Appendix A. Selecting Signaling Destination Addresses for EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 81 Appendix B. Usage of External Binding Addresses . . . . . . . . . 82 Appendix C. Applicability Statement on Data Receivers behind Firewalls . . . . . . . . . . . . . . . . . . . . . . 83 Appendix D. Firewall and NAT Resources . . . . . . . . . . . . . 84 D.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 84 D.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 84 D.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 85 D.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 85 Appendix E. Example for Receiver Proxy Case . . . . . . . . . . . 86
Firewalls and Network Address Translators (NATs) have both been used throughout the Internet for many years, and they will remain present for the foreseeable future. Firewalls are used to protect networks against certain types of attacks from internal networks and the Internet, whereas NATs provide a virtual extension of the IP address space. Both types of devices may be obstacles to some applications, since they only allow traffic created by a limited set of applications to traverse them, typically those that use protocols with relatively predetermined and static properties (e.g., most HTTP traffic, and other client/server applications). Other applications, such as IP telephony and most other peer-to-peer applications, which have more dynamic properties, create traffic that is unable to traverse NATs and firewalls without assistance. In practice, the traffic of many applications cannot traverse autonomous firewalls or NATs, even when they have additional functionality that attempts to restore the transparency of the network.
ファイアウォールとネットワークアドレス変換器（NAT）は、長年にわたってインターネットで使われており、今後も使われ続ける見込みです。ファイアウォールは内部ネットワークやインターネットからの特定の攻撃からネットワークを保護し、NATはIPアドレス空間を仮想的に拡張します。どちらも、一部のアプリケーションにとって通信の障害になり得ます。通常、比較的予測しやすく静的な性質を持つプロトコル（大半のHTTP通信など）を使う限られたアプリケーションのトラフィックだけを通過させるためです。一方、IP電話や他の多くのピアツーピアアプリケーションのように通信の性質が動的なアプリケーションは、支援がなければNATやファイアウォールを通過できないトラフィックを生成します。実際には、ネットワークの透過性を回復する追加機能を備えていても、多くのアプリケーションのトラフィックは自律的に動作するファイアウォールやNATを通過できません。
Several solutions to enable applications to traverse such entities have been proposed and are currently in use. Typically, application-level gateways (ALGs) have been integrated with the firewall or NAT to configure the firewall or NAT dynamically. Another approach is middlebox communication (MIDCOM). In this approach, ALGs external to the firewall or NAT configure the corresponding entity via the MIDCOM protocol [RFC3303]. Several other work-around solutions are available, such as Session Traversal Utilities for NAT (STUN) [RFC5389]. However, all of these approaches introduce other problems that are generally hard to solve, such as dependencies on the type of NAT implementation (full-cone, symmetric, etc.), or dependencies on certain network topologies.
こうした装置をアプリケーションが通過できるようにする解決策がいくつか提案され、現在も使われています。一般には、アプリケーションレベルゲートウェイ（ALG）をファイアウォールまたはNATに組み込み、装置を動的に設定します。別の方式にMiddlebox Communication（MIDCOM）があります。この方式では、ファイアウォールやNATの外部にあるALGが、MIDCOMプロトコル[RFC3303]を介して対象装置を設定します。Session Traversal Utilities for NAT（STUN）[RFC5389]など、他の回避策もあります。しかし、これらの方式には、NATの実装方式（フルコーン型、対称型など）や特定のネットワークトポロジーへの依存など、一般に解決が難しい別の問題が伴います。
NAT and firewall (NATFW) signaling shares a property with Quality-of-Service (QoS) signaling -- each must reach any device that is on the data path and is involved in (respectively) NATFW or QoS treatment of data packets. This means that for both NATFW and QoS it is convenient if signaling travels path-coupled, i.e., the signaling messages follow exactly the same path that the data packets take. The Resource Reservation Protocol (RSVP) [RFC2205] is an example of a current QoS signaling protocol that is path-coupled. [rsvp-firewall] proposes the use of RSVP as a firewall signaling protocol but does not include NATs.
NATおよびファイアウォール（NATFW）のシグナリングは、Quality of Service（QoS）シグナリングと共通の性質を持ちます。どちらも、データ経路上にあり、データパケットに対するNATFWまたはQoS処理を行うすべての装置に到達する必要があります。そのため、NATFWとQoSのどちらでも、シグナリングをパス結合型にする、つまりシグナリングメッセージをデータパケットとまったく同じ経路に沿って送ると都合がよいです。Resource Reservation Protocol（RSVP）[RFC2205]は、パス結合型のQoSシグナリングプロトコルの例です。[rsvp-firewall]はRSVPをファイアウォールのシグナリングプロトコルとして使うことを提案していますが、NATは対象にしていません。
This memo defines a path-coupled signaling protocol for NAT and firewall configuration within the framework of NSIS, called the NATFW NSIS Signaling Layer Protocol (NSLP). The general requirements for NSIS are defined in [RFC3726] and the general framework of NSIS is outlined in [RFC4080]. It introduces the split between an NSIS transport layer and an NSIS signaling layer. The transport of NSLP messages is handled by an NSIS Network Transport Layer Protocol (NTLP, with General Internet Signaling Transport (GIST) [RFC5971] being the implementation of the abstract NTLP). The signaling logic for QoS and NATFW signaling is implemented in the different NSLPs. The QoS NSLP is defined in [RFC5974].
本メモでは、NSISフレームワーク内でNATやファイアウォールを設定するパス結合型シグナリングプロトコルとして、NATFW NSIS Signaling Layer Protocol（NSLP）を定義します。NSISの一般要件は[RFC3726]で定義され、一般フレームワークは[RFC4080]で概要が示されています。NSISでは、トランスポート層とシグナリング層を分けています。NSLPメッセージの転送はNSIS Network Transport Layer Protocol（NTLP）が担い、General Internet Signaling Transport（GIST）[RFC5971]は抽象NTLPの実装です。QoSおよびNATFWのシグナリングロジックは、それぞれのNSLPで実装されます。QoS NSLPは[RFC5974]で定義されています。
The NATFW NSLP is designed to request the dynamic configuration of NATs and/or firewalls along the data path. Dynamic configuration includes enabling data flows to traverse these devices without being obstructed, as well as blocking of particular data flows at inbound firewalls. Enabling data flows requires the loading of firewall rules with an action that allows the data flow packets to be forwarded and NAT bindings to be created. The blocking of data flows requires the loading of firewall rules with an action that will deny forwarding of the data flow packets. A simplified example for enabling data flows: a source host sends a NATFW NSLP signaling message towards its data destination. This message follows the data path. Every NATFW NSLP-enabled NAT/firewall along the data path intercepts this message, processes it, and configures itself accordingly. Thereafter, the actual data flow can traverse all these configured firewalls/NATs.
NATFW NSLPは、データ経路上のNATやファイアウォールを動的に設定するよう要求するために設計されています。動的設定では、データフローが装置を妨げられずに通過できるようにするほか、受信側ファイアウォールで特定のデータフローを遮断できます。データフローを許可するには、パケット転送を許可するファイアウォールルールを読み込み、NATバインディングを作成します。遮断するには、データフローパケットの転送を拒否するファイアウォールルールを読み込みます。許可する場合の簡単な例では、送信元ホストがデータ宛先に向けてNATFW NSLPシグナリングメッセージを送ります。このメッセージはデータ経路をたどります。経路上のNATFW NSLP対応NATおよびファイアウォールは、それぞれメッセージを捕捉して処理し、自身を設定します。その後、実際のデータフローは設定済みのファイアウォールやNATを通過できます。
It is necessary to distinguish between two different basic scenarios when operating the NATFW NSLP, independent of the type of the middleboxes to be configured.
設定対象となるミドルボックスの種類にかかわらず、NATFW NSLPを使う際には次の2つの基本シナリオを区別する必要があります。
1. Both the data sender and data receiver are NSIS NATFW NSLP aware. This includes the cases in which the data sender is logically decomposed from the initiator of the NSIS signaling (the so-called NSIS initiator) or the data receiver logically decomposed from the receiver of the NSIS signaling (the so-called NSIS receiver), but both sides support NSIS. This scenario assumes deployment of NSIS all over the Internet, or at least at all NATs and firewalls. This scenario is used as a base assumption, if not otherwise noted.
1. データ送信者とデータ受信者の両方がNSIS NATFW NSLPに対応するシナリオです。データ送信者がNSISシグナリングの開始主体（NSIS initiator）とは論理的に分離されている場合や、データ受信者がNSISシグナリングの受信主体（NSIS receiver）とは論理的に分離されている場合も含みますが、両端はNSISをサポートします。このシナリオでは、インターネット全体、または少なくともすべてのNATとファイアウォールにNSISが導入されていると想定します。特に断りがない限り、このシナリオを基本の前提とします。
2. Only one end host or region of the network is NSIS NATFW NSLP aware, either the data receiver or data sender. This scenario is referred to as proxy mode.
2. データ受信者またはデータ送信者のどちらか一方のエンドホスト、あるいはネットワーク領域だけがNSIS NATFW NSLPに対応するシナリオです。このシナリオをプロキシモードと呼びます。
The NATFW NSLP has two basic signaling messages that are sufficient to cope with the various possible scenarios likely to be encountered before and after widespread deployment of NSIS:
NATFW NSLPには、NSISが広く導入される前後に想定されるさまざまな状況に対処できる、次の2種類の基本シグナリングメッセージがあります。
CREATE message: Sent by the data sender for configuring a path outbound from a data sender to a data receiver.
CREATE Message：データ送信者からデータ受信者へ向かう送信方向の経路を設定するため、データ送信者が送信します。
EXTERNAL message: Used by a data receiver to locate inbound NATs/ firewalls and prime them to expect inbound signaling and used at NATs to pre-allocate a public address. This is used for data receivers behind these devices to enable their reachability.
EXTERNAL Message：データ受信者が受信方向のNATやファイアウォールを特定し、受信シグナリングに備えさせるために使います。また、NATではパブリックアドレスの事前割り当てに使います。これにより、そのような装置の背後にいるデータ受信者が外部から到達可能になります。
CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) towards the NSIS responder (NR). Both types of message are acknowledged by a subsequent RESPONSE message. This RESPONSE message is generated by the NR if the requested configuration can be established; otherwise, the NR or any of the NSLP forwarders (NFs) can also generate such a message if an error occurs. NFs and the NR can also generate asynchronous messages to notify the NI, the so-called NOTIFY messages.
CREATE MessageとEXTERNAL MessageはNSIS initiator（NI）からNSIS responder（NR）へ送信されます。どちらのメッセージにも後続のRESPONSE Messageで応答します。要求された設定を確立できる場合、NRがRESPONSE Messageを生成します。エラーが発生した場合は、NRまたはいずれかのNSLP forwarder（NF）もこのメッセージを生成できます。NFとNRは、NIに非同期イベントを通知するNOTIFY Messageも生成できます。
If the data receiver resides in a private addressing realm or behind a firewall, and it needs to preconfigure the edge-NAT/edge-firewall to provide a (publicly) reachable address for use by the data sender, a combination of EXTERNAL and CREATE messages is used.
データ受信者がプライベートアドレス領域またはファイアウォールの背後にあり、データ送信者が使う外部到達可能なアドレスを提供するためにEdge-NATまたはEdge-firewallを事前設定する必要がある場合、EXTERNAL MessageとCREATE Messageを組み合わせて使います。
During the introduction of NSIS, it is likely that one or the other of the data sender and receiver will not be NSIS aware. In these cases, the NATFW NSLP can utilize NSIS-aware middleboxes on the path between the data sender and data receiver to provide proxy NATFW NSLP services (i.e., the proxy mode). Typically, these boxes will be at the boundaries of the realms in which the end hosts are located.
NSISの導入過程では、データ送信者またはデータ受信者の一方がNSISに対応していないことが想定されます。この場合、NATFW NSLPは両者間の経路にあるNSIS対応ミドルボックスを利用し、プロキシモードでNATFW NSLPサービスを提供できます。通常、これらのミドルボックスはエンドホストが属するアドレス領域の境界にあります。
The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in NSIS entities. NTLP state allows signaling messages to travel in the forward (outbound) and the reverse (inbound) direction along the path between a NAT/firewall NSLP sender and a corresponding receiver. This state is managed using a soft-state mechanism, i.e., it expires unless it is refreshed from time to time. The NAT bindings and firewall rules being installed during the state setup are bound to the particular signaling session. However, the exact local implementation of the NAT bindings and firewall rules are NAT/ firewall specific and it is out of the scope of this memo.
CREATE MessageとEXTERNAL Messageは、NSISエンティティにNATFW NSLP状態とNTLP状態を作ります。NTLP状態により、シグナリングメッセージはNAT/firewall NSLP送信者と対応する受信者の間の経路を、順方向（送信方向）と逆方向（受信方向）に移動できます。この状態はソフトステート方式で管理され、定期的に更新されなければ期限切れになります。状態設定時に導入されるNATバインディングとファイアウォールルールは、特定のシグナリングセッションに関連付けられます。ただし、NATバインディングとファイアウォールルールの具体的な実装はNATまたはファイアウォールごとに異なり、本メモの範囲外です。
This memo is structured as follows. Section 2 describes the network environment for NATFW NSLP signaling. Section 3 defines the NATFW signaling protocol and Section 4 defines the message components and the overall messages used in the protocol. The remaining parts of the main body of the document cover security considerations Section 5, IAB considerations on UNilateral Self-Address Fixing (UNSAF) [RFC3424] in Section 6, and IANA considerations in Section 7. Please note that readers familiar with firewalls and NATs and their possible location within networks can safely skip Section 2.
本メモの構成は次のとおりです。2節ではNATFW NSLPシグナリングのネットワーク環境を説明します。3節ではNATFWシグナリングプロトコルを定義し、4節ではメッセージ構成要素とプロトコルで使うメッセージ全体を定義します。本文の残りでは、5節でセキュリティ、6節で一方向自己アドレス修正（UNSAF）[RFC3424]に関するIABの考慮事項、7節でIANAの考慮事項を扱います。ファイアウォールやNAT、およびネットワーク内での配置場所をよく知っている読者は、2節を読み飛ばしてもかまいません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、[RFC2119]に記載された意味で解釈します。
o Policy rule: A policy rule is "a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed" [RFC3198]. In the context of NSIS NATFW NSLP, the conditions are the specification of a set of packets to which the rule is applied. The set of actions always contains just a single element per rule, and is limited to either action "deny" or action "allow".
o ポリシールール：ポリシールールとは、「ポリシーベースシステムの基本的な構成要素であり、一連の条件に一連の動作を結び付けたものです。条件を評価し、その動作を実行するかどうかを判断します」[RFC3198]。NSIS NATFW NSLPでは、条件はルールを適用するパケット集合を指定します。各ルールに含まれる動作は1つだけで、「deny」または「allow」のいずれかです。
o Reserved policy rule: A policy rule stored at NATs or firewalls for activation by a later, different signaling exchange. This type of policy rule is kept in the NATFW NSLP and is not loaded into the firewall or NAT engine, i.e., it does not affect the data flow handling.
o 予約済みポリシールール：後続する別のシグナリング交換で有効化するため、NATまたはファイアウォールに保存されるポリシールールです。この種のルールはNATFW NSLP内に保持され、ファイアウォールやNATのエンジンには読み込まれません。つまり、データフローの処理には影響しません。
o Installed policy rule: A policy rule in operation at NATs or firewalls. This type of rule is kept in the NATFW NSLP and is loaded into the firewall or NAT engine, i.e., it is affecting the data flow.
o インストール済みポリシールール：NATまたはファイアウォールで動作中のポリシールールです。この種のルールはNATFW NSLP内に保持され、ファイアウォールやNATのエンジンにも読み込まれます。つまり、データフローに影響します。
o Remembered policy rule: A policy rule stored at NATs and firewalls for immediate use, as soon as the signaling exchange is successfully completed.
o 記憶済みポリシールール：シグナリング交換が正常に完了した直後から使用できるよう、NATやファイアウォールに保存されるポリシールールです。
o Firewall: A packet filtering device that matches packets against a set of policy rules and applies the actions.
o ファイアウォール：パケットをポリシールール集合と照合し、そのルールに定められた動作を適用するパケットフィルタリング装置です。
o Network Address Translator: Network Address Translation is a method by which IP addresses are mapped from one IP address realm to another, in an attempt to provide transparent routing between hosts (see [RFC2663]). Network Address Translators are devices that perform this work by modifying packets passing through them.
o Network Address Translator（ネットワークアドレス変換器）：Network Address Translation（ネットワークアドレス変換）は、ホスト間の透過的なルーティングを可能にするため、IPアドレスをあるIPアドレス領域から別の領域へ対応付ける方式です（[RFC2663]参照）。Network Address Translatorは、通過するパケットを書き換えてこの処理を行う装置です。
o Data Receiver (DR): The node in the network that is receiving the data packets of a flow.
o データ受信者（DR）：フローのデータパケットを受信するネットワーク上のノードです。
o Data Sender (DS): The node in the network that is sending the data packets of a flow.
o データ送信者（DS）：フローのデータパケットを送信するネットワーク上のノードです。
o NATFW NSLP peer (or simply "peer"): An NSIS NATFW NSLP node with which an NTLP adjacency has been created as defined in [RFC5971].
o NATFW NSLPピア（または単に「ピア」）：[RFC5971]で定義されるNTLP隣接関係が確立されたNSIS NATFW NSLPノードです。
o NATFW NSLP signaling session (or simply "signaling session"): A signaling session defines an association between the NI, NFs, and the NR related to a data flow. All the NATFW NSLP peers on the path, including the NI and the NR, use the same identifier to refer to the state stored for the association. The same NI and NR may have more than one signaling session active at any time. The state for the NATFW NSLP consists of NSLP state and associated policy rules at a middlebox.
o NATFW NSLPシグナリングセッション（または単に「シグナリングセッション」）：データフローに関連するNI、NF、およびNRの間の関連付けを定義します。NIとNRを含む経路上のすべてのNATFW NSLPピアは、関連付けについて保存した状態を参照するために同じ識別子を使います。同じNIとNRの間で、複数のシグナリングセッションが同時に有効になることがあります。NATFW NSLPの状態は、NSLP状態とミドルボックスに関連付けられたポリシールールで構成されます。
o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP address that is reachable from the public Internet.
o Edge-NAT：パブリックインターネットから到達可能な、グローバルにルーティング可能なIPアドレスを持つNAT装置です。
o Edge-firewall: An edge-firewall is a firewall device that is located on the borderline of an administrative domain.
o Edge-firewall：管理ドメインの境界に位置するファイアウォール装置です。
o Public Network: "A Global or Public Network is an address realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as external network during NAT discussions" [RFC2663].
o パブリックネットワーク：「Global NetworkまたはPublic Networkは、Internet Assigned Numbers Authority（IANA）または同等のアドレス登録機関によって一意のネットワークアドレスが割り当てられたアドレス領域です。NATに関する議論では、このネットワークを外部ネットワークとも呼びます」[RFC2663]。
o Private/Local Network: "A private network is an address realm independent of external network addresses. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT router" [RFC2663].
o プライベート／ローカルネットワーク：「プライベートネットワークは外部ネットワークのアドレスとは独立したアドレス領域です。プライベートネットワークはローカルネットワークとも呼ばれます。NATルーターによって、プライベート領域と外部領域のホスト間の透過的なルーティングが可能になります」[RFC2663]。
o Public/Global IP address: An IP address located in the public network according to Section 2.7 of [RFC2663].
o パブリック／グローバルIPアドレス：[RFC2663]の2.7節に従い、パブリックネットワークに属するIPアドレスです。
o Private/Local IP address: An IP address located in the private network according to Section 2.8 of [RFC2663].
o プライベート／ローカルIPアドレス：[RFC2663]の2.8節で定義されるプライベートネットワーク内のIPアドレスです。
o Signaling Destination Address (SDA): An IP address generally taken from the public/global IP address range, although, the SDA may, in certain circumstances, be part of the private/local IP address range. This address is used in EXTERNAL signaling message exchanges, if the data receiver's IP address is unknown.
o Signaling Destination Address（SDA）：通常はパブリック／グローバルIPアドレス範囲から選ぶIPアドレスです。ただし、状況によってはプライベート／ローカルIPアドレス範囲に属することもあります。データ受信者のIPアドレスが不明な場合、EXTERNAL signaling messageの交換にこのアドレスを使います。
The term "middlebox" covers a range of devices and is well-defined in [RFC3234]: "A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and a destination host". As such, middleboxes fall into a number of categories with a wide range of functionality, not all of which is pertinent to the NATFW NSLP. Middlebox categories in the scope of this memo are firewalls that filter data packets against a set of filter rules, and NATs that translate packet addresses from one address realm to another address realm. Other categories of middleboxes, such as QoS traffic shapers, are out of the scope of this memo.
「ミドルボックス」という用語はさまざまな装置を含み、その定義は[RFC3234]に示されています。「送信元ホストと宛先ホストの間のデータグラム経路上で、IPルーターの通常の標準機能以外の機能を実行する中間装置」です。ミドルボックスは幅広い機能を持つ複数のカテゴリに分かれますが、そのすべてがNATFW NSLPに関係するわけではありません。本メモの対象は、フィルタールール集合に基づいてデータパケットをフィルタリングするファイアウォールと、パケットのアドレスをあるアドレス領域から別の領域へ変換するNATです。QoSトラフィックシェーパーなど、他のカテゴリのミドルボックスは本メモの対象外です。
The term "NAT" used in this document is a placeholder for a range of different NAT flavors. We consider the following types of NATs:
本書の「NAT」は、さまざまな種類のNATをまとめて指す用語です。対象とするNATの種類を以下に示します。
o Traditional NAT (basic NAT and NAPT)
o 従来型NAT（基本NATおよびNAPT）
o Bi-directional NAT
o 双方向NAT
o Twice-NAT
o 二重NAT（Twice-NAT）
o Multihomed NAT
o マルチホームNAT
For definitions and a detailed discussion about the characteristics of each NAT type, please see [RFC2663].
各NATタイプの定義と特性の詳細については[RFC2663]を参照してください。
All types of middleboxes under consideration here use policy rules to make a decision on data packet treatment. Policy rules consist of a flow identifier that selects the packets to which the policy applies and an associated action; data packets matching the flow identifier are subjected to the policy rule action. A typical flow identifier is the 5-tuple selector that matches the following fields of a packet to configured values:
ここで扱うすべての種類のミドルボックスは、ポリシールールに基づいてデータパケットの処理方法を決めます。ポリシールールは、適用対象のパケットを選ぶフロー識別子と、それに関連付けられた動作で構成されます。フロー識別子に一致するデータパケットには、そのルールの動作が適用されます。一般的なフロー識別子は5タプルセレクターで、パケットの次のフィールドを設定値と照合します。
o Source and destination IP addresses
o 送信元および宛先IPアドレス
o Transport protocol number
o トランスポートプロトコル番号
o Transport source and destination port numbers Actions for firewalls are usually one or more of:
o トランスポート層の送信元および宛先ポート番号。ファイアウォールの動作には、通常、次の1つ以上を使います。
o Allow: forward data packet
o Allow：データパケットを転送します。
o Deny: block data packet and discard it
o Deny：データパケットを遮断して破棄します。
o Other actions such as logging, diverting, duplicating, etc.
o ログ記録、迂回、複製などのその他の動作。
Actions for NATs include (amongst many others):
NATの動作には、次のもの（およびその他多数）が含まれます。
o Change source IP address and transport port number to a globally routable IP address and associated port number.
o 送信元IPアドレスとトランスポートポート番号を、グローバルにルーティング可能なIPアドレスと対応するポート番号に変更します。
o Change destination IP address and transport port number to a private IP address and associated port number.
o 宛先IPアドレスとトランスポートポート番号を、プライベートIPアドレスと対応するポート番号に変更します。
It should be noted that a middlebox may contain two logical representations of the policy rule. The policy rule has a representation within the NATFW NSLP, comprising the message routing information (MRI) of the NTLP and NSLP information (such as the rule action). The other representation is the implementation of the NATFW NSLP policy rule within the NAT and firewall engine of the particular device. Refer to Appendix D for further details.
ミドルボックス内では、ポリシールールが2つの論理表現を持つ場合があります。1つはNATFW NSLP内の表現で、NTLPのMessage Routing Information（MRI）とNSLP情報（ルール動作など）から構成されます。もう1つは、個々の装置のNATまたはファイアウォールエンジンに実装されたポリシールールです。詳しくは付録Dを参照してください。
The purpose of NSIS NATFW signaling is to enable communication between endpoints across networks, even in the presence of NAT and firewall middleboxes that have not been specially engineered to facilitate communication with the application protocols used. This removes the need to create and maintain application layer gateways for specific protocols that have been commonly used to provide transparency in previous generations of NAT and firewall middleboxes. It is assumed that these middleboxes will be statically configured in such a way that NSIS NATFW signaling messages themselves are allowed to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP signaling is used to dynamically install additional policy rules in all NATFW middleboxes along the data path that will allow transmission of the application data flow(s). Firewalls are configured to forward data packets matching the policy rule provided by the NSLP signaling. NATs are configured to translate data packets matching the policy rule provided by the NSLP signaling. An additional capability, that is an exception to the primary goal of NSIS NATFW signaling, is that the NATFW nodes can request blocking of particular data flows instead of enabling these flows at inbound firewalls.
NSIS NATFWシグナリングの目的は、使用するアプリケーションプロトコルとの通信を支援するよう特別に設計されていないNATやファイアウォールのミドルボックスが存在しても、ネットワークをまたぐエンドポイント間の通信を可能にすることです。これにより、従来の世代のNATやファイアウォールでネットワークの透過性を実現するために使われてきた、特定プロトコル向けのアプリケーション層ゲートウェイを作成・維持する必要がなくなります。NSIS NATFWシグナリングメッセージが各装置にインストールされたNATFW NSLPデーモンへ到達できるよう、ミドルボックスは静的に設定されていると想定します。NSIS NATFW NSLPシグナリングは、アプリケーションのデータフローを通過させるため、データ経路上のすべてのNATFWミドルボックスに追加のポリシールールを動的にインストールします。ファイアウォールは、シグナリングで指定されたルールに一致するパケットを転送するよう設定され、NATは同じルールに一致するパケットを変換するよう設定されます。主目的とは逆の追加機能として、NATFWノードは受信側ファイアウォールで特定のデータフローを許可する代わりに遮断するよう要求することもできます。
The basic high-level picture of NSIS usage is that end hosts are located behind middleboxes, meaning that there is at least one middlebox on the data path from the end host in a private network to the external network (NATFW in Figure 1). Applications located at these end hosts try to establish communication with corresponding applications on other such end hosts. This communication establishment may require that the applications contact an application server that serves as a rendezvous point between both parties to exchange their IP address and port(s). The local applications trigger the NSIS entity at the local host to control provisioning for middlebox traversal along the prospective data path (e.g., via an API call). The NSIS entity, in turn, uses NSIS NATFW NSLP signaling to establish policy rules along the data path, allowing the data to travel from the sender to the receiver without obstruction.
NSIS使用量の基本的な高レベルの画像は、エンドホストがミドルボックスの後ろにあることです。つまり、プライベートネットワークのエンドホストから外部ネットワークまでのデータパスに少なくとも1つのミドルボックスがあることを意味します（図1のNATFW）。これらのエンドホストにあるアプリケーションは、他のそのようなエンドホストで対応するアプリケーションとのコミュニケーションを確立しようとします。この通信確立は、アプリケーションが両当事者間のランデブーポイントとして機能するアプリケーションサーバーに連絡して、IPアドレスとポートを交換することを要求する場合があります。ローカルアプリケーションは、ローカルホストのNSISエンティティをトリガーし、前向きデータパスに沿ったミドルボックストラバーサルのプロビジョニングを制御します（たとえば、API呼び出しを介して）。NSISエンティティは、NSIS NATFW NSLPシグナル伝達を使用してデータパスに沿ってポリシールールを確立し、データが閉塞せずに送信者から受信機に移動できるようにします。
Application Application Server (0, 1, or more) Application
Application Application Server (0, 1, or more) Application
+----+ +----+ +----+
| +------------------------+ +------------------------+ |
+-+--+ +----+ +-+--+
| |
| NSIS Entities NSIS Entities |
+-+--+ +----+ +-----+ +-+--+
| +--------+ +----------------------------+ +-----+ |
+-+--+ +-+--+ +--+--+ +-+--+
| | ------ | |
| | //// \\\\\ | |
+-+--+ +-+--+ |/ | +-+--+ +-+--+
| | | | | Internet | | | | |
| +--------+ +-----+ +----+ +-----+ |
+----+ +----+ |\ | +----+ +----+
\\\\ /////
sender NATFW (1+) ------ NATFW (1+) receiver
Note that 1+ refers to one or more NATFW nodes.
「1+」は、NATFWノードが1つ以上あることを示します。
Figure 1: Generic View of NSIS with NATs and/or Firewalls
図1：NATやファイアウォールを含むNSISの一般構成
For end-to-end NATFW signaling, it is necessary that each firewall and each NAT along the path between the data sender and the data receiver implements the NSIS NATFW NSLP. There might be several NATs and FWs in various possible combinations on a path between two hosts. Section 2 presents a number of likely scenarios with different combinations of NATs and firewalls. However, the scenarios given in the following sections are only examples and should not be treated as limiting the scope of the NATFW NSLP.
エンドツーエンドのNATFWシグナリングを行うには、データ送信者とデータ受信者の間の経路上にある各ファイアウォールおよび各NATがNSIS NATFW NSLPを実装する必要があります。2つのホスト間には、さまざまな組み合わせで複数のNATやファイアウォールが存在する場合があります。2節では、NATとファイアウォールの組み合わせとして想定されるシナリオをいくつか示します。ただし、以下のシナリオは例であり、NATFW NSLPの適用範囲を限定するものではありません。
This section introduces several scenarios for middlebox placement within IP networks. Middleboxes are typically found at various different locations, including at enterprise network borders, within enterprise networks, as mobile phone network gateways, etc. Usually, middleboxes are placed more towards the edge of networks than in network cores. Firewalls and NATs may be found at these locations either alone or combined; other categories of middleboxes may also be found at such locations, possibly combined with the NATs and/or firewalls.
この節では、IPネットワーク内でミドルボックスを配置するシナリオをいくつか紹介します。ミドルボックスは、企業ネットワークの境界や内部、携帯電話網のゲートウェイなど、さまざまな場所に設置されます。通常はネットワークコアよりもネットワークの端に配置されます。ファイアウォールとNATは、これらの場所に単独または組み合わせて設置され、他の種類のミドルボックスもNATやファイアウォールとともに設置されることがあります。
NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the regular data path to the NSIS responder (NR). On the data path, NATFW NSLP signaling messages reach different NSIS nodes that implement the NATFW NSLP. Each NATFW NSLP node processes the signaling messages according to Section 3 and, if necessary, installs policy rules for subsequent data packets.
NSIS initiator（NI）は、通常のデータ経路を通じてNSIS NATFW NSLP signaling messageをNSIS responder（NR）へ送ります。経路上では、これらのメッセージはNATFW NSLPを実装する複数のNSISノードに到達します。各NATFW NSLPノードは3節に従ってメッセージを処理し、必要であれば後続データパケット用のポリシールールを設定します。
Each of the following sub-sections introduces a different scenario for a different set of middleboxes and their ordering within the topology. It is assumed that each middlebox implements the NSIS NATFW NSLP signaling protocol.
以下の各節では、トポロジー内での配置順序を含め、異なるミドルボックス構成のシナリオを紹介します。各ミドルボックスはNSIS NATFW NSLPシグナリングプロトコルを実装すると想定します。
This section describes a scenario with firewalls only; NATs are not involved. Each end host is behind a firewall. The firewalls are connected via the public Internet. Figure 2 shows the topology. The part labeled "public" is the Internet connecting both firewalls.
この節ではNATを含まず、ファイアウォールだけを使うシナリオを説明します。各エンドホストはファイアウォールの背後にあり、両ファイアウォールはパブリックインターネットを介して接続されています。トポロジーを図2に示します。「public」と記された部分が、2つのファイアウォールを接続するインターネットです。
+----+ //----\\ +----+
NI -----| FW |---| |------| FW |--- NR
+----+ \\----// +----+
private public private
private public private
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
Figure 2: Firewall Traversal Scenario
図2：ファイアウォール通過のシナリオ
Each firewall on the data path must provide traversal service for NATFW NSLP in order to permit the NSIS message to reach the other end host. All firewalls process NSIS signaling and establish appropriate policy rules, so that the required data packet flow can traverse them.
データ経路上の各ファイアウォールは、NSISメッセージが反対側のエンドホストまで届くよう、NATFW NSLPの通過サービスを提供する必要があります。すべてのファイアウォールがNSISシグナリングを処理して適切なポリシールールを設定し、必要なデータパケットフローが通過できるようにします。
There are several very different ways to place firewalls in a network topology. To distinguish firewalls located at network borders, such as administrative domains, from others located internally, the term edge-firewall is used. A similar distinction can be made for NATs, with an edge-NAT fulfilling the equivalent role.
ファイアウォールはネットワークトポロジー内のさまざまな場所に配置できます。管理ドメインなどのネットワーク境界にあるファイアウォールと、内部にあるファイアウォールを区別するため、「Edge-firewall」という用語を使います。NATについても同様に区別でき、Edge-NATが対応する役割を担います。
Figure 3 shows a scenario with NATs at both ends of the network. Therefore, each application instance, the NSIS initiator and the NSIS responder, are behind NATs. The outermost NAT, known as the edge-NAT (MB2 and MB3), at each side is connected to the public Internet. The NATs are generically labeled as MBX (for middlebox No. X), since those devices certainly implement NAT functionality, but can implement firewall functionality as well.
図3は、ネットワークの両端にNATがあるシナリオを示します。つまり、各アプリケーションインスタンス、NSIS initiator、およびNSIS responderはNATの背後にあります。各側の最も外側にあるNAT（MB2およびMB3）はEdge-NATと呼ばれ、パブリックインターネットに接続します。これらの装置はNAT機能を必ず備え、ファイアウォール機能も備える場合があるため、NATを一般化してMBX（middlebox X）と表記します。
Only two middleboxes (MBs) are shown in Figure 3 at each side, but in general, any number of MBs on each side must be considered.
図3では各側に2つのミドルボックス（MB）を示していますが、一般には各側に任意の数のMBが存在することを考慮する必要があります。
+----+ +----+ //----\\ +----+ +----+
NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR
+----+ +----+ \\----// +----+ +----+
private public private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
Figure 3: NAT with two Private Networks Scenario
図3：2つのプライベートネットワークを接続するNATのシナリオ
Signaling traffic from the NI to the NR has to traverse all the middleboxes on the path (MB1 to MB4, in this order), and all the middleboxes must be configured properly to allow NSIS signaling to traverse them. The NATFW signaling must configure all middleboxes and consider any address translation that will result from this configuration in further signaling. The sender (NI) has to know the IP address of the receiver (NR) in advance, otherwise it will not be possible to send any NSIS signaling messages towards the responder. Note that this IP address is not the private IP address of the responder but the NAT's public IP address (here MB3's IP address). Instead, a NAT binding (including a public IP address) has to be previously installed on the NAT MB3. This NAT binding subsequently allows packets reaching the NAT to be forwarded to the receiver within the private address realm. The receiver might have a number of ways to learn its public IP address and port number (including the NATFW NSLP) and might need to signal this information to the sender using an application-level signaling protocol.
NIからNRへ向かうシグナリングトラフィックは、経路上のすべてのミドルボックス（MB1からMB4まで、この順序）を通過する必要があります。NSISシグナリングが通過できるよう、各ミドルボックスを適切に設定する必要があります。NATFWシグナリングではすべてのミドルボックスを設定し、後続のシグナリングで必要になる、この設定によるアドレス変換も考慮します。送信者（NI）は受信者（NR）のIPアドレスを事前に知っていなければなりません。知らなければ、レスポンダー宛てにNSISシグナリングメッセージを送れません。このIPアドレスはレスポンダーのプライベートIPアドレスではなく、NATのパブリックIPアドレス（ここではMB3のIPアドレス）です。そのため、NAT MB3にはパブリックIPアドレスを含むNATバインディングが事前に設定されている必要があります。このNATバインディングにより、NATに到着したパケットをプライベートアドレス領域内の受信者へ転送できます。受信者はNATFW NSLPなどを使って自身のパブリックIPアドレスとポート番号を知ることができ、その情報をアプリケーション層のシグナリングプロトコルで送信者に通知する必要がある場合もあります。
This scenario shows an application instance at the sending node that is behind one or more NATs (shown as generic MB, see discussion in Section 2.2). The receiver is located in the public Internet.
このシナリオでは、送信側ノードのアプリケーションが1つ以上のNATの背後にあります（一般化したMBとして図示。2.2節参照）。受信者はパブリックインターネット上にいます。
+----+ +----+ //----\\
NI --| MB |-----| MB |---| |--- NR
+----+ +----+ \\----//
private public
private public
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
Figure 4: NAT with Private Network on Sender Side
図4：送信側のプライベートネットワークに設置されたNAT
The traffic from NI to NR has to traverse middleboxes only on the sender's side. The receiver has a public IP address. The NI sends its signaling message directly to the address of the NSIS responder. Middleboxes along the path intercept the signaling messages and configure accordingly.
NIからNRへのトラフィックは、送信側にあるミドルボックスだけを通過する必要があります。受信者はパブリックIPアドレスを持ちます。NIはNSIS signaling messageをNRのアドレスへ直接送ります。経路上のミドルボックスはこのメッセージを捕捉し、それに応じて自身を設定します。
The data sender does not necessarily know whether or not the receiver is behind a NAT; hence, it is the receiving side that has to detect whether or not it is behind a NAT.
データ送信者は、受信者がNATの背後にいるかどうかを必ずしも把握していません。そのため、受信側でNATの背後にいるかどうかを検出する必要があります。
The application instance receiving data is behind one or more NATs shown as MB (see discussion in Section 2.2).
データを受信するアプリケーションは、MBとして示す1つ以上のNATの背後にあります（2.2節参照）。
//----\\ +----+ +----+
NI ---| |---| MB |-----| MB |--- NR
\\----// +----+ +----+
public private
public private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
Figure 5: NAT with Private Network on Receiver Scenario
図5：受信側のプライベートネットワークに設置されたNATのシナリオ
Initially, the NSIS responder must determine its publicly reachable IP address at the external middlebox and notify the NSIS initiator about this address. One possibility is that an application-level protocol is used, meaning that the public IP address is signaled via this protocol to the NI. Afterwards, the NI can start its signaling towards the NR and therefore establish the path via the middleboxes in the receiver side private network.
まず、NSIS responderは外部ミドルボックスで自身に割り当てられた到達可能なパブリックIPアドレスを特定し、そのアドレスをNSIS initiatorに通知する必要があります。たとえば、アプリケーション層のプロトコルを使って、パブリックIPアドレスをNIに通知できます。その後、NIはNRに向けてシグナリングを開始し、受信側のプライベートネットワーク内にあるミドルボックスを通る経路を確立できます。
This scenario describes the use case for the EXTERNAL message of the NATFW NSLP.
このシナリオは、NATFW NSLPのEXTERNAL Messageを使うケースを示します。
This is a special case, where the main problem arises from the need to detect that both end hosts are logically within the same address space, but are also in two partitions of the address realm on either side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT functionality).
これは特殊なケースです。主な課題は、両エンドホストが論理的には同じアドレス空間に属しながら、Twice-NATを挟んだアドレス領域の別々の区画にいることを検出する必要がある点です。Twice-NATの機能については[RFC2663]を参照してください。
Sender and receiver are both within a single private address realm, but the two partitions potentially have overlapping IP address ranges. Figure 6 shows the arrangement of NATs.
送信者と受信者はいずれも1つのプライベートアドレス領域に属しますが、2つの区画でIPアドレス範囲が重複している場合があります。図6にNATの配置を示します。
public
public
+----+ +----+ //----\\
NI --| MB |--+--| MB |---| |
+----+ | +----+ \\----//
|
| +----+
+--| MB |------------ NR
+----+
private
private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
Figure 6: NAT to Public, Sender and Receiver on Either Side of a Twice-NAT Scenario
図6：パブリック側へのNATと、Twice-NATの両側にいる送信者および受信者
The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP addresses and port numbers on both sides, meaning the mapping of source and destination IP addresses at the private and public interfaces.
図6のミドルボックスはTwice-NATです。つまり、プライベート側とパブリック側の両方のインターフェイスで、IPアドレスとポート番号を対応付けます。
This scenario requires the assistance of application-level entities, such as a DNS server. The application-level entities must handle requests that are based on symbolic names and configure the middleboxes so that data packets are correctly forwarded from NI to NR. The configuration of those middleboxes may require other middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS signaling is not required in the twice-NAT only case, since middleboxes of the twice-NAT type are normally configured by other means. Nevertheless, NSIS signaling might be useful when there are also firewalls on the path. In this case, NSIS will not configure any policy rule at twice-NATs, but will configure policy rules at the firewalls on the path. The NSIS signaling protocol must be at least robust enough to survive this scenario. This requires that twice-NATs must implement the NATFW NSLP also and participate in NATFW signaling sessions, but they do not change the configuration of the NAT, i.e., they only read the address mapping information out of the NAT and translate the Message Routing Information (MRI, [RFC5971]) within the NSLP and NTLP accordingly. For more information, see Appendix D.4.
このシナリオでは、DNSサーバーなどのアプリケーション層エンティティによる支援が必要です。これらのエンティティはシンボリック名に基づく要求を処理し、データパケットがNIからNRへ正しく転送されるようミドルボックスを設定する必要があります。設定にはMIDCOM [RFC3303]など、別のミドルボックス通信プロトコルが必要な場合があります。Twice-NATだけのケースでは、Twice-NAT型のミドルボックスは通常ほかの方法で設定されるため、NSISシグナリングは不要です。ただし、経路上にファイアウォールもある場合はNSISシグナリングが役立つことがあります。この場合、NSISはTwice-NATにポリシールールを設定せず、経路上のファイアウォールにポリシールールを設定します。NSISシグナリングプロトコルは、このシナリオでも動作できるだけの堅牢性を備える必要があります。そのため、Twice-NATもNATFW NSLPを実装し、NATFWシグナリングセッションに参加する必要があります。ただしNATの設定は変更しません。NATからアドレス対応情報を読み取り、NSLP内およびNTLP内のMessage Routing Information（MRI、[RFC5971]）をそれに応じて変換するだけです。詳しくは付録D.4を参照してください。
When the NSIS initiator and NSIS responder are behind the same NAT (thus, being in the same address realm, see Figure 7), they are most likely not aware of this fact. As in Section 2.4, the NSIS responder must determine its public IP address in advance and transfer it to the NSIS initiator. Afterwards, the NSIS initiator can start sending the signaling messages to the responder's public IP address. During this process, a public IP address will be allocated for the NSIS initiator at the same middlebox as for the responder. Now, the NSIS signaling and the subsequent data packets will traverse the NAT twice: from initiator to public IP address of responder (first time) and from public IP address of responder to responder (second time).
NSIS initiatorとNSIS responderが同じNATの背後、すなわち同じアドレス領域内にいる場合（図7参照）、両者はその事実を把握していない可能性が高いです。2.4節と同様に、NSIS responderは事前に自身のパブリックIPアドレスを特定し、NSIS initiatorに伝える必要があります。その後、NSIS initiatorはレスポンダーのパブリックIPアドレス宛てにシグナリングメッセージを送り始めます。この間に、レスポンダーと同じミドルボックスで、NSIS initiatorにもパブリックIPアドレスが割り当てられます。これによりNSISシグナリングと後続のデータパケットは、NATを2回通過します。1回目はinitiatorからresponderのパブリックIPアドレスへ、2回目はそのパブリックIPアドレスからresponderへ向かいます。
NI public
\ +----+ //----\\
+-| MB |----| |
/ +----+ \\----//
NR
private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
Figure 7: NAT to Public, Both Hosts behind Same NAT
図7：同じNATの背後にある両ホストとパブリック側へのNAT
The previous sub-sections sketched network topologies where several NATs and/or firewalls are ordered sequentially on the path. This section describes a multihomed scenario with two NATs placed on alternative paths to the public network.
これまでの節では、複数のNATやファイアウォールを経路上に順に配置するトポロジーを示しました。この節では、パブリックネットワークへの代替経路に2つのNATを配置するマルチホームのシナリオを説明します。
+----+ //---\\
NI -------| MB |---| |
\ +----+ \\-+-//
\ |
\ +----- NR
\ |
\ +----+ //-+-\\
--| MB |---| |
+----+ \\---//
private public
private public
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
Figure 8: Multihomed Network with Two NATs
図8：2つのNATを持つマルチホームネットワーク
Depending on the destination, either one or the other middlebox is used for the data flow. Which middlebox is used, depends on local policy or routing decisions. NATFW NSLP must be able to handle this situation properly, see Section 3.7.2 for an extended discussion of this topic with respect to NATs.
宛先に応じて、どちらか一方のミドルボックスがデータフローに使われます。どちらを使うかはローカルポリシーまたはルーティング判断で決まります。NATFW NSLPはこの状況を適切に処理できる必要があります。NATに関する詳しい説明は3.7.2節を参照してください。
This section describes a multihomed scenario with two firewalls placed on alternative paths to the public network (Figure 9). The routing in the private and public networks decides which firewall is being taken for data flows. Depending on the data flow's direction, either outbound or inbound, a different firewall could be traversed. This is a challenge for the EXTERNAL message of the NATFW NSLP where the NSIS responder is located behind these firewalls within the private network. The EXTERNAL message is used to block a particular data flow on an inbound firewall. NSIS must route the EXTERNAL message inbound from NR to NI probably without knowing which path the data traffic will take from NI to NR (see also Appendix C).
この節では、パブリックネットワークへの代替経路に2つのファイアウォールを配置するマルチホームのシナリオを説明します（図9）。プライベートネットワークとパブリックネットワークのルーティングによって、データフローが通過するファイアウォールが決まります。データフローの方向が送信方向か受信方向かによって、通過するファイアウォールが異なることもあります。NSIS responderがプライベートネットワーク内のこれらのファイアウォールの背後にある場合、これはNATFW NSLPのEXTERNAL Messageにとって課題になります。EXTERNAL Messageは、受信側ファイアウォールで特定のデータフローを遮断するために使われます。NIからNRへのデータがどの経路を通るか分からない可能性がある中で、NSISはNRからNIへ向かう受信方向のEXTERNAL Messageをルーティングする必要があります（付録Cも参照）。
+----+
NR -------| FW |\
\ +----+ \ //---\\
\ -| |-- NI
\ \\---//
\ +----+ |
--| FW |-------+
+----+
private
private public
private public
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
Figure 9: Multihomed Network with Two Firewalls
図9：2つのファイアウォールを持つマルチホームネットワーク
This section defines messages, objects, and protocol semantics for the NATFW NSLP.
この節では、NATFW NSLPのメッセージ、オブジェクト、およびプロトコルの意味を定義します。
Policy rules, bound to a NATFW NSLP signaling session, are the building blocks of middlebox devices considered in the NATFW NSLP. For firewalls, the policy rule usually consists of a 5-tuple and an action such as allow or deny. The information contained in the tuple includes source/destination IP addresses, transport protocol, and source/destination port numbers. For NATs, the policy rule consists of the action 'translate this address' and further mapping information, that might be, in the simplest case, internal IP address and external IP address.
NATFW NSLPのシグナリングセッションに関連付けられたポリシールールは、NATFW NSLPが扱うミドルボックスの基本要素です。ファイアウォールの場合、通常は5タプルと、allowやdenyなどの動作で構成されます。5タプルには送信元／宛先IPアドレス、トランスポートプロトコル、送信元／宛先ポート番号が含まれます。NATの場合、ポリシールールは「このアドレスを変換する」という動作と追加の対応付け情報から構成されます。最も単純な場合、対応付け情報は内部IPアドレスと外部IPアドレスです。
The NATFW NSLP carries, in conjunction with the NTLP's Message Routing Information (MRI), the policy rules to be installed at NATFW peers. This policy rule is an abstraction with respect to the real policy rule to be installed at the respective firewall or NAT. It conveys the initiator's request and must be mapped to the possible configuration on the particular used NAT and/or firewall in use. For pure firewalls, one or more filter rules must be created, and for pure NATs, one or more NAT bindings must be created. In mixed firewall and NAT boxes, the policy rule must be mapped to filter rules and bindings observing the ordering of the firewall and NAT engine. Depending on the ordering, NAT before firewall or vice versa, the firewall rules must carry public or private IP addresses. However, the exact mapping depends on the implementation of the firewall or NAT that is possibly different for each implementation.
NATFW NSLPは、NTLPのMessage Routing Information（MRI）とともに、NATFWピアに設定するポリシールールを運びます。このルールは、各ファイアウォールまたはNATに実際に設定するルールを抽象化したものです。イニシエーターの要求を伝え、使用する個々のNATやファイアウォールで可能な設定に対応付ける必要があります。ファイアウォールだけの場合は1つ以上のフィルタールールを作成し、NATだけの場合は1つ以上のNATバインディングを作成する必要があります。ファイアウォール機能とNAT機能を併せ持つ装置では、両エンジンの処理順序を考慮して、ポリシールールをフィルタールールとバインディングに対応付ける必要があります。NATとファイアウォールのどちらが先かによって、ファイアウォールルールにパブリックIPアドレスとプライベートIPアドレスのどちらを指定するかが変わります。正確な対応付けはファイアウォールやNATの実装に依存し、実装ごとに異なる場合があります。
The policy rule at the NATFW NSLP level comprises the message routing information (MRI) part, carried in the NTLP, and the information available in the NATFW NSLP. The information provided by the NSLP is stored in the 'extend flow information' (NATFW_EFI) and 'data terminal information' (NATFW_DTINFO) objects, and the message type. Additional information, such as the external IP address and port number, stored in the NAT or firewall, will be used as well. The MRI carries the filter part of the NAT/firewall-level policy rule that is to be installed.
NATFW NSLPレベルのポリシールールは、NTLPで運ばれるメッセージルーティング情報（MRI）と、NATFW NSLPで利用できる情報から成ります。NSLPが提供する情報は、「拡張フロー情報」（NATFW_EFI）オブジェクト、「データ端末情報」（NATFW_DTINFO）オブジェクト、およびメッセージタイプに含まれます。NATまたはファイアウォールに保存される外部IPアドレスやポート番号などの追加情報も使用します。MRIには、NAT／ファイアウォールレベルで設定するポリシールールのフィルター部分が含まれます。
The NATFW NSLP specifies two actions for the policy rules: deny and allow. A policy rule with action set to deny will result in all packets matching this rule to be dropped. A policy rule with action set to allow will result in all packets matching this rule to be forwarded.
NATFW NSLPは、ポリシールールに対してdenyとallowの2つの動作を定義します。動作がdenyに設定されたポリシールールに一致するパケットは、すべて破棄されます。動作がallowに設定されたポリシールールに一致するパケットは、すべて転送されます。
The NSIS NATFW NSLP is carried over the General Internet Signaling Transport (GIST, the implementation of the NTLP) defined in [RFC5971]. NATFW NSLP messages are initiated by the NSIS initiator (NI), handled by NSLP forwarders (NFs) and received by the NSIS responder (NR). It is required that at least NI and NR implement this NSLP, intermediate NFs only implement this NSLP when they provide relevant middlebox functions. NSLP forwarders that do not have any NATFW NSLP functions just forward these packets as they have no interest in them.
NSIS NATFW NSLPは、[RFC5971]で定義されているGeneral Internet Signaling Transport（GIST、NTLPの実装）上で伝送されます。NATFW NSLPメッセージはNSISイニシエーター（NI）が開始し、NSLPフォワーダー（NF）が処理し、NSISレスポンダー（NR）が受信します。少なくともNIとNRはこのNSLPを実装する必要があります。中間のNFがこのNSLPを実装するのは、関連するミドルボックス機能を提供する場合に限られます。NATFW NSLPの機能を持たないNSLPフォワーダーは、これらのパケットに関与しないため、そのまま転送します。
A data sender (DS), intending to send data to a data receiver (DR), has to start NATFW NSLP signaling. This causes the NI associated with the DS to launch NSLP signaling towards the address of the DR (see Figure 10). Although it is expected that the DS and the NATFW NSLP NI will usually reside on the same host, this specification does not rule out scenarios where the DS and NI reside on different hosts, the so-called proxy mode (see Section 3.7.6).
データ送信者（DS）は、データ受信者（DR）へデータを送る際にNATFW NSLPシグナリングを開始します。これにより、DSに対応するNIがDRのアドレスに向けてNSLPシグナリングを開始します（図10参照）。通常、DSとNATFW NSLPのNIは同じホスト上にあると想定されますが、この仕様は両者が別々のホスト上にある構成、いわゆるプロキシモード（セクション3.7.6参照）も排除しません。
+-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
| |--->| NF1 |--->| NF2 |--->| |
+-------+ +-------+ +-------+ +-------+
========================================>
Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP forwarder 2
Figure 10: General NSIS Signaling
図10：NSISシグナリングの概要
The following list shows the normal sequence of NSLP events without detailing the interaction with the NTLP and the interactions on the NTLP level.
次の箇条書きは、NTLPとのやり取りやNTLPレベルの処理の詳細を省いた、NSLPイベントの通常の順序を示します。
o NSIS initiators generate request messages (which are either CREATE or EXTERNAL messages) and send these towards the NSIS responder. This request message is the initial message that creates a new NATFW NSLP signaling session. The NI and the NR will most likely already share an application session before they start the NATFW NSLP signaling session. Note well the difference between both sessions.
o NSISイニシエーターは要求メッセージ（CREATEメッセージまたはEXTERNALメッセージ）を生成し、NSISレスポンダーに向けて送信します。この要求メッセージは、新しいNATFW NSLPシグナリングセッションを確立する最初のメッセージです。NIとNRは、NATFW NSLPシグナリングセッションを開始する前から、アプリケーションセッションを確立している可能性が高いです。この2つのセッションを混同しないでください。
o NSLP request messages are processed each time an NF with NATFW NSLP support is traversed. Each NF that is intercepting a request message and is accepting it for further treatment is joining the particular NATFW NSLP signaling session. These nodes process the message, check local policies for authorization and authentication, possibly create policy rules, and forward the signaling message to the next NSIS node. The request message is forwarded until it reaches the NSIS responder.
o NATFW NSLPに対応するNFを通過するたびに、NSLP要求メッセージが処理されます。要求メッセージを捕捉し、その後の処理を受け入れる各NFは、該当するNATFW NSLPシグナリングセッションに参加します。これらのノードはメッセージを処理し、認可と認証に関するローカルポリシーを確認し、必要に応じてポリシールールを作成したうえで、シグナリングメッセージを次のNSISノードへ転送します。要求メッセージはNSISレスポンダーに届くまで転送されます。
o NSIS responders will check received messages and process them if applicable. NSIS responders generate RESPONSE messages and send them hop-by-hop back to the NI via the same chain of NFs (traversal of the same NF chain is guaranteed through the established reverse message routing state in the NTLP). The NR is also joining the NATFW NSLP signaling session if the request message is accepted.
o NSISレスポンダーは受信したメッセージを確認し、該当する場合に処理します。NSISレスポンダーはRESPONSEメッセージを生成し、同じNFの連鎖を経由してNIへホップごとに返送します（NTLPで確立された逆方向のメッセージルーティング状態により、同じNFの連鎖を通ることが保証されます）。要求メッセージが受け入れられた場合、NRもNATFW NSLPシグナリングセッションに参加します。
o The RESPONSE message is processed at each NF that has been included in the prior NATFW NSLP signaling session setup.
o RESPONSEメッセージは、先行するNATFW NSLPシグナリングセッションの確立に参加した各NFで処理されます。
o If the NI has received a successful RESPONSE message and if the signaling NATFW NSLP session started with a CREATE message, the data sender can start sending its data flow to the data receiver. If the NI has received a successful RESPONSE message and if the signaling NATFW NSLP session started with an EXTERNAL message, the data receiver is ready to receive further CREATE messages.
o NIが成功を示すRESPONSEメッセージを受信し、シグナリングセッションがCREATEメッセージで開始されていた場合、データ送信者はデータフローをデータ受信者へ送り始めることができます。セッションがEXTERNALメッセージで開始されていた場合、データ受信者は続くCREATEメッセージを受信できる状態になります。
Because NATFW NSLP signaling follows the data path from DS to DR, this immediately enables communication between both hosts for scenarios with only firewalls on the data path or NATs on the sender side. For scenarios with NATs on the receiver side, certain problems arise, as described in Section 2.4.
NATFW NSLPシグナリングはDSからDRへのデータパスをたどるため、データパス上にファイアウォールだけがある場合や、NATが送信者側にある場合は、両ホスト間の通信を直ちに可能にします。NATが受信者側にある場合には、セクション2.4で説明した問題が生じます。
When the NR and the NI are located in different address realms and the NR is located behind a NAT, the NI cannot signal to the NR address directly. The DR/NR is not reachable from other NIs using the private address of the NR and thus NATFW signaling messages cannot be sent to the NR/DR's address. Therefore, the NR must first obtain a NAT binding that provides an address that is reachable for the NI. Once the NR has acquired a public IP address, it forwards this information to the DS via a separate protocol. This application-layer signaling, which is out of the scope of the NATFW NSLP, may involve third parties that assist in exchanging these messages.
NRとNIが異なるアドレス領域にあり、NRがNATの背後にある場合、NIはNRのアドレスへ直接シグナリングできません。NRのプライベートアドレスでは、他のNIからDR/NRに到達できないため、NATFWシグナリングメッセージをNR/DRのアドレスへ送信できません。したがってNRは、まずNIから到達可能なアドレスを提供するNATバインディングを取得する必要があります。NRはパブリックIPアドレスを取得すると、別のプロトコルを使ってその情報をDSへ伝えます。NATFW NSLPの範囲外であるこのアプリケーション層のシグナリングでは、メッセージ交換を支援する第三者が関与することもあります。
The same holds partially true for NRs located behind firewalls that block all traffic by default. In this case, NR must tell its inbound firewalls of inbound NATFW NSLP signaling and corresponding data traffic. Once the NR has informed the inbound firewalls, it can start its application-level signaling to initiate communication with the NI. This mechanism can be used by machines hosting services behind firewalls as well. In this case, the NR informs the inbound firewalls as described, but does not need to communicate this to the NIs.
同様のことは、既定ですべてのトラフィックを遮断するファイアウォールの背後にあるNRにも部分的に当てはまります。この場合、NRは受信側のファイアウォールに対し、受信するNATFW NSLPシグナリングと対応するデータトラフィックを許可するよう通知する必要があります。通知後、NRはアプリケーション層のシグナリングを開始してNIとの通信を始められます。この仕組みは、ファイアウォールの背後でサービスを提供するホストにも使えます。その場合、NRは前述のとおり受信側ファイアウォールに通知しますが、NIには通知する必要はありません。
NATFW NSLP signaling supports this scenario by using the EXTERNAL message.
NATFW NSLPは、EXTERNALメッセージを使ってこのシナリオをサポートします。
1. The DR acquires a public address by signaling on the reverse path (DR towards DS) and thus making itself available to other hosts. This process of acquiring public addresses is called reservation. During this process the DR reserves publicly reachable addresses and ports suitable for further usage in application-level signaling and the publicly reachable address for further NATFW NSLP signaling. However, the data traffic will not be allowed to use this address/port initially (see next point). In the process of reservation, the DR becomes the NI for the messages necessary to obtain the publicly reachable IP address, i.e., the NI for this specific NATFW NSLP signaling session.
1. DRは逆方向の経路（DRからDSへ）でシグナリングし、パブリックアドレスを取得することで、他のホストから到達可能になります。このパブリックアドレスの取得手順を予約と呼びます。予約中、DRはアプリケーション層のシグナリングで後から使う、外部から到達可能なアドレスとポート、およびNATFW NSLPシグナリングで後から使う、外部から到達可能なアドレスを確保します。ただし、最初の時点ではデータトラフィックにこのアドレス／ポートを使うことは許可されません（次の項を参照）。予約では、外部から到達可能なIPアドレスを取得するために必要なメッセージについて、DRがNIとなります。つまり、この特定のNATFW NSLPシグナリングセッションではDRがNIの役割を担います。
2. Now on the side of the DS, the NI creates a new NATFW NSLP signaling session and signals directly to the public IP address of the DR. This public IP address is used as NR's address, as the NI would do if there is no NAT in between, and creates policy rules at middleboxes. Note, that the reservation will only allow forwarding of signaling messages, but not data flow packets. Policy rules allowing forwarding of data flow packets set up by the prior EXTERNAL message signaling will be activated when the signaling from NI towards NR is confirmed with a positive RESPONSE message. The EXTERNAL message is described in Section 3.7.2.
2. 次にDS側でNIが新しいNATFW NSLPシグナリングセッションを作成し、DRのパブリックIPアドレスへ直接シグナリングします。NATが介在しない場合にNRのアドレスを使うのと同様に、このパブリックIPアドレスをNRのアドレスとして使い、ミドルボックスにポリシールールを作成します。予約で転送が許可されるのはシグナリングメッセージだけであり、データフローパケットは許可されない点に注意してください。先行するEXTERNALメッセージのシグナリングで設定された、データフローパケットの転送を許可するポリシールールは、NIからNRへのシグナリングが肯定的なRESPONSEメッセージで確認された時点で有効になります。EXTERNALメッセージについてはセクション3.7.2で説明します。
administrative domain
----------------------------------\
|
+-------+ +-------+ +-------+ | +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR |
| |--->| NF1 |--->| NR | | | |
+-------+ +-------+ +-------+ | +-------+
|
----------------------------------/
========================================>
Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP responder
Figure 11: Proxy Mode Signaling for Data Sender
図11：データ送信者側のプロキシモードのシグナリング
The above usage assumes that both ends of a communication support NSIS, but fails when NSIS is only deployed at one end of the path. In this case, only one of the sending side (see Figure 11) or receiving side (see Figure 12) is NSIS aware and not both at the same time. NATFW NSLP supports both scenarios (i.e., either the DS or DR does not support NSIS) by using a proxy mode, as described in Section 3.7.6.
前述の使い方では、通信する両端がNSISに対応していることを前提としています。そのため、経路の一端だけにNSISが導入されている場合には機能しません。この場合、送信側（図11参照）か受信側（図12参照）のどちらか一方だけがNSISに対応し、両側が同時に対応することはありません。NATFW NSLPは、セクション3.7.6で説明するプロキシモードを使い、どちらか一方（DSまたはDR）がNSISに対応していない両方のシナリオをサポートします。
administrative domain
/ ----------------------------------
|
+-------+ | +-------+ +-------+ +-------+
| DS | | | MB2/ |~~~>| MB1/ |~~~>| DR |
| | | | NR |<---| NF1 |<---| |
+-------+ | +-------+ +-------+ +-------+
|
\----------------------------------
========================================>
Data Traffic Direction (inbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP responder
Figure 12: Proxy Mode Signaling for Data Receiver
図12：データ受信者側のプロキシモードのシグナリング
The basic functionality of the NATFW NSLP provides for opening firewall pin holes and creating NAT bindings to enable data flows to traverse these devices. Firewalls are normally expected to work on a "deny-all" policy, meaning that traffic not explicitly matching any firewall filter rule will be blocked. Similarly, the normal behavior of NATs is to block all traffic that does not match any already configured/installed binding or NATFW NSLP session. However, some scenarios require support of firewalls having "allow-all" policies, allowing data traffic to traverse the firewall unless it is blocked explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message with action set to "deny" to install policy rules at inbound firewalls to block unwanted traffic.
NATFW NSLPの基本機能は、ファイアウォールにピンホールを開き、NATバインディングを作成して、データフローがこれらの装置を通過できるようにします。通常、ファイアウォールは「すべて拒否」ポリシーで動作します。つまり、ファイアウォールのフィルタールールに明示的に一致しないトラフィックは遮断されます。同様に、NATは通常、すでに設定またはインストールされたバインディングやNATFW NSLPセッションに一致しないトラフィックをすべて遮断します。一方、明示的に遮断されない限りデータトラフィックを通過させる「すべて許可」ポリシーのファイアウォールを扱う必要があるシナリオもあります。データ受信者は、actionを「deny」に設定したNATFW NSLPのEXTERNALメッセージを使って、不要なトラフィックを遮断するポリシールールを受信側ファイアウォールに設定できます。
The protocol works on a soft-state basis, meaning that whatever state is installed or reserved on a middlebox will expire, and thus be uninstalled or forgotten after a certain period of time. To prevent premature removal of state that is needed for ongoing communication, the NATFW NI involved will have to specifically request a NATFW NSLP signaling session extension. An explicit NATFW NSLP state deletion capability is also provided by the protocol.
このプロトコルはソフトステート方式で動作します。つまり、ミドルボックスに設定または予約された状態は期限が切れると削除され、ミドルボックスから破棄されます。進行中の通信に必要な状態が早期に削除されないようにするには、該当するNATFW NIがNATFW NSLPシグナリングセッションの延長を明示的に要求する必要があります。このプロトコルは、NATFW NSLPの状態を明示的に削除する機能も提供します。
If the actions requested by a NATFW NSLP message cannot be carried out, NFs and the NR must return a failure, such that appropriate actions can be taken. They can do this either during the request message handling (synchronously) by sending an error RESPONSE message or at any time (asynchronously) by sending a NOTIFY notification message.
NATFW NSLPメッセージで要求された処理を実行できない場合、NFとNRは失敗を通知し、適切な対処ができるようにしなければなりません。要求メッセージの処理中にエラーを示すRESPONSEメッセージを送信して同期的に通知する方法と、NOTIFY通知メッセージを送信して任意の時点で非同期に通知する方法があります。
The next sections define the NATFW NSLP message types and formats, protocol operations, and policy rule operations.
次の各節では、NATFW NSLPのメッセージタイプと形式、プロトコルの処理、およびポリシールールの処理を定義します。
The protocol uses four messages types:
このプロトコルでは、次の4種類のメッセージを使用します。
o CREATE: a request message used for creating, changing, refreshing, and deleting NATFW NSLP signaling sessions, i.e., open the data path from DS to DR.
o CREATE: NATFW NSLPシグナリングセッションの作成、変更、更新、削除に使う要求メッセージです。つまり、DSからDRへのデータパスを開きます。
o EXTERNAL: a request message used for reserving, changing, refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. EXTERNAL messages are forwarded to the edge-NAT or edge-firewall and allow inbound CREATE messages to be forwarded to the NR. Additionally, EXTERNAL messages reserve an external address and, if applicable, port number at an edge-NAT.
o EXTERNAL: EXTERNAL NATFW NSLPシグナリングセッションの予約、変更、更新、削除に使う要求メッセージです。EXTERNALメッセージはedge-NATまたはedge-firewallへ転送され、受信したCREATEメッセージをNRへ転送できるようにします。また、EXTERNALメッセージはedge-NATで外部アドレスと、該当する場合はポート番号を予約します。
o NOTIFY: an asynchronous message used by NATFW peers to alert other NATFW peers about specific events (especially failures).
o NOTIFY: NATFWピアが特定のイベント（特に失敗）を他のNATFWピアに知らせるために使う非同期メッセージです。
o RESPONSE: used as a response to CREATE and EXTERNAL request messages.
o RESPONSE: CREATE要求メッセージとEXTERNAL要求メッセージへの応答として使います。
RESPONSE messages will be generated synchronously to CREATE and EXTERNAL messages by NSLP forwarders and responders to report success or failure of operations or some information relating to the NATFW NSLP signaling session or a node. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE.
NSLPフォワーダーとレスポンダーは、CREATEメッセージおよびEXTERNALメッセージへの応答として、操作の成功または失敗や、NATFW NSLPシグナリングセッションまたはノードに関する情報を報告するRESPONSEメッセージを同期的に生成します。NOTIFYやRESPONSEなど、その他のメッセージに対してRESPONSEメッセージを生成してはなりません (MUST NOT)。
All RESPONSE messages MUST carry a NATFW_INFO object that contains an error class code and a response code (see Section 4.2.5). This section defines terms for groups of RESPONSE messages depending on the error class.
すべてのRESPONSEメッセージは、エラークラスコードと応答コードを含むNATFW_INFOオブジェクトを含まなければなりません (MUST)（セクション4.2.5参照）。この節では、エラークラスに応じたRESPONSEメッセージ群の名称を定義します。
o Successful RESPONSE: Messages carrying NATFW_INFO with error class 'Success' (2).
o Successful RESPONSE: エラークラスが「Success」（2）のNATFW_INFOを含むメッセージです。
o Informational RESPONSE: Messages carrying NATFW_INFO with error class 'Informational' (1) (only used with NOTIFY messages).
o Informational RESPONSE: error classが「Informational」（1）のNATFW_INFOを含むメッセージです（NOTIFYメッセージでのみ使用します）。
o Error RESPONSE: Messages carrying NATFW_INFO with error class other than 'Success' or 'Informational'.
o Error RESPONSE: error classが「Success」でも「Informational」でもないNATFW_INFOを含むメッセージです。
A NATFW NSLP signaling session defines an association between the NI, NFs, and the NR related to a data flow. This association is created when the initial CREATE or EXTERNAL message is successfully received at the NFs or the NR. There is signaling NATFW NSLP session state stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP signaling session state for the NATFW NSLP comprises NSLP state and the associated policy rules at a middlebox.
NATFW NSLPシグナリングセッションは、データフローに関係するNI、NF、およびNRの間の関連付けを定義します。この関連付けは、最初のCREATEメッセージまたはEXTERNALメッセージがNFまたはNRで正常に受信されたときに作られます。シグナリングセッションの状態は、NTLP層とNATFW NSLP層の両方に保存されます。NATFW NSLPにおけるシグナリングセッションの状態は、NSLPの状態と、ミドルボックスに関連付けられたポリシールールから成ります。
The NATFW NSLP signaling session is identified by the session ID (plus other information at the NTLP level). The session ID is generated by the NI before the initial CREATE or EXTERNAL message is sent. The value of the session ID MUST be generated as a cryptographically random number (see [RFC4086]) by the NI, i.e., the output MUST NOT be easily guessable by third parties. The session ID is not stored in any NATFW NSLP message but passed on to the NTLP.
NATFW NSLPシグナリングセッションは、セッションID（およびNTLP層のその他の情報）によって識別されます。NIは最初のCREATEメッセージまたはEXTERNALメッセージを送信する前に、セッションIDを生成します。NIはセッションIDの値を暗号学的にランダムな数値として生成しなければなりません (MUST)（[RFC4086]参照）。つまり、その出力は第三者が容易に推測できてはなりません (MUST NOT)。セッションIDはNATFW NSLPメッセージには格納せず、NTLPに渡します。
A NATFW NSLP signaling session has several conceptual states that describe in what state a signaling session is at a given time. The signaling session can have these states at a node:
NATFW NSLPシグナリングセッションには、その時点でのセッションの状態を表す概念上の状態がいくつかあります。ノード上のシグナリングセッションは、次のいずれかの状態になります。
o Pending: The NATFW NSLP signaling session has been created and the node is waiting for a RESPONSE message to the CREATE or EXTERNAL message. A NATFW NSLP signaling session in state 'Pending' MUST be marked as 'Dead' if no corresponding RESPONSE message has been received within the time of the locally granted NATFW NSLP signaling session lifetime of the forwarded CREATE or EXTERNAL message (as described in Section 3.4).
o Pending: NATFW NSLPシグナリングセッションが作成され、ノードがCREATEメッセージまたはEXTERNALメッセージに対するRESPONSEメッセージを待っている状態です。転送したCREATEメッセージまたはEXTERNALメッセージについて、ノードがローカルに許可したシグナリングセッションの有効期間内に対応するRESPONSEメッセージを受信しなかった場合、状態がPendingのセッションはDeadとマークしなければなりません (MUST)（セクション3.4参照）。
o Established: The NATFW NSLP signaling session is established, i.e, the signaling has been successfully performed and the lifetime of NATFW NSLP signaling session is counted from now on. A NATFW NSLP signaling session in state 'Established' MUST be marked as 'Dead' if no refresh message has been received within the time of the locally granted NATFW NSLP signaling session lifetime of the RESPONSE message (as described in Section 3.4).
o Established: NATFW NSLPシグナリングセッションが確立され、シグナリングが正常に完了した状態です。この時点からシグナリングセッションの有効期間が計時されます。RESPONSEメッセージに対してノードがローカルに許可したシグナリングセッションの有効期間内に更新メッセージを受信しなかった場合、状態がEstablishedのセッションはDeadとマークしなければなりません (MUST)（セクション3.4参照）。
o Dead: Either the NATFW NSLP signaling session is timed out or the node has received an error RESPONSE message for the NATFW NSLP signaling session and the NATFW NSLP signaling session can be deleted.
o Dead: NATFW NSLPシグナリングセッションがタイムアウトしたか、ノードがそのセッションに対するエラーRESPONSEメッセージを受信した状態です。この状態のシグナリングセッションは削除できます。
o Transitory: The node has received an asynchronous message, i.e., a NOTIFY, and can delete the NATFW NSLP signaling session if needed after some time. When a node has received a NOTIFY message, it marks the signaling session as 'Transitory'. This signaling session SHOULD NOT be deleted before a minimum hold time of 30 seconds, i.e., it can be removed after 30 seconds or more. This hold time ensures that the existing signaling session can be reused by the NI, e.g., a part of a signaling session that is not affected by the route change can be reused once the updating request message is received.
o Transitory: ノードが非同期メッセージ、つまりNOTIFYを受信し、しばらく経過した後に必要に応じてNATFW NSLPシグナリングセッションを削除できる状態です。NOTIFYメッセージを受信したノードは、シグナリングセッションをTransitoryとマークします。このシグナリングセッションは、最短30秒の保持時間が経過する前に削除すべきではありません (SHOULD NOT)。つまり、削除できるのは30秒以上経過した後です。この保持時間により、NIは既存のシグナリングセッションを再利用できます。たとえば、経路変更の影響を受けない部分は、更新要求メッセージを受信した後に再利用できます。
All NATFW messages are subject to some basic message processing when received at a node, independent of the message type. Initially, the syntax of the NSLP message is checked and a RESPONSE message with an appropriate error of class 'Protocol error' (3) code is generated if a non-recoverable syntax error is detected. A recoverable error is, for instance, when a node receives a message with reserved flags set to values other than zero. This also refers to unknown NSLP objects and their handling, according to Section 4.2. If a message is delivered to the NATFW NSLP, this implies that the NTLP layer has been able to correlate it with the session ID (SID) and MRI entries in its database. There is therefore enough information to identify the source of the message and routing information to route the message back to the NI through an established chain of NTLP messaging associations. The message is not further forwarded if any error in the syntax is detected. The specific response codes stemming from the processing of objects are described in the respective object definition section (see Section 4). After passing this check, the NATFW NSLP node performs authentication- and authorization-related checks, described in Section 3.6. Further processing is executed only if these tests have been successfully passed; otherwise, the processing stops and an error RESPONSE is returned.
すべてのNATFWメッセージは、種類にかかわらず、ノードで受信した際に基本的なメッセージ処理を受けます。まずNSLPメッセージの構文を検査します。回復不能な構文エラーが見つかった場合は、「Protocol error」（3）クラスの適切なエラーコードを含むRESPONSEメッセージを生成します。回復可能なエラーの例として、予約済みフラグが0以外に設定されたメッセージをノードが受信する場合があります。未知のNSLPオブジェクトとその処理についても、セクション4.2に従って扱います。メッセージがNATFW NSLPに渡されたことは、NTLP層がデータベース内のセッションID（SID）およびMRIの項目とメッセージを対応付けられたことを意味します。そのため、メッセージの送信元を特定し、確立済みのNTLPメッセージング関連付けの連鎖を通じてNIへ返送するための経路情報も得られています。構文エラーが見つかった場合、メッセージをそれ以上転送しません。オブジェクト処理から生じる個別の応答コードは、各オブジェクトの定義（セクション4参照）で説明します。この検査に通った後、NATFW NSLPノードはセクション3.6で説明する認証および認可に関する検査を行います。これらの検査にすべて成功した場合に限り処理を続けます。それ以外の場合は処理を停止し、エラーRESPONSEを返します。
Further message processing stops whenever an error RESPONSE message is generated, and the EXTERNAL or CREATE message is discarded.
エラーRESPONSEメッセージを生成した場合、それ以上のメッセージ処理を停止し、EXTERNALメッセージまたはCREATEメッセージを破棄します。
NATFW NSLP signaling sessions, and the corresponding policy rules that may have been installed, are maintained via a soft-state mechanism. Each signaling session is assigned a signaling session lifetime and the signaling session is kept alive as long as the lifetime is valid. After the expiration of the signaling session lifetime, signaling sessions and policy rules MUST be removed automatically and resources bound to them MUST be freed as well. Signaling session lifetime is handled at every NATFW NSLP node. The NSLP forwarders and NSLP responder MUST NOT trigger signaling session lifetime extension refresh messages (see Section 3.7.3): this is the task of the NSIS initiator.
NATFW NSLPシグナリングセッションと、設定されている場合は対応するポリシールールを、ソフトステート機構によって維持します。各シグナリングセッションには有効期間が割り当てられ、その有効期間中はセッションが維持されます。有効期間が切れた後は、シグナリングセッションとポリシールールを自動的に削除しなければならず (MUST)、それらに割り当てられたリソースも解放しなければなりません (MUST)。有効期間はすべてのNATFW NSLPノードで管理します。NSLPフォワーダーとNSLPレスポンダーは、シグナリングセッションの有効期間を延長する更新メッセージを開始してはなりません (MUST NOT)（セクション3.7.3参照）。これはNSISイニシエーターの役割です。
The NSIS initiator MUST choose a NATFW NSLP signaling session lifetime value (expressed in seconds) before sending any message, including the initial message that creates the NATFW NSLP signaling session, to other NSLP nodes. It is RECOMMENDED that the NATFW NSLP signaling session lifetime value is calculated based on:
NSISイニシエーターは、NATFW NSLPシグナリングセッションを作成する最初のメッセージを含め、他のNSLPノードへメッセージを送信する前に、NATFW NSLPシグナリングセッションの有効期間（秒単位）を選ばなければなりません (MUST)。有効期間は、次の要素に基づいて算出することが推奨されます (SHOULD)：
o the number of lost refresh messages with which NFs should cope;
o NFが許容すべき更新メッセージの損失数。
o the end-to-end delay between the NI and NR;
o NIとNRの間のエンドツーエンド遅延。
o network vulnerability due to NATFW NSLP signaling session hijacking ([RFC4081]), NATFW NSLP signaling session hijacking is made easier when the NI does not explicitly remove the NATFW NSLP signaling session;
o NATFW NSLPシグナリングセッションの乗っ取り（[RFC4081]）によるネットワークの脆弱性。NIがNATFW NSLPシグナリングセッションを明示的に削除しないと、セッションを乗っ取りやすくなります。
o the user application's data exchange duration, in terms of time and networking needs. This duration is modeled as R, with R the message refresh period (in seconds);
o 時間およびネットワーク上の要件で表した、ユーザーアプリケーションのデータ交換時間。この時間をRとし、Rはメッセージの更新間隔（秒単位）です。
o the load on the signaling plane. Short lifetimes imply more frequent signaling messages;
o シグナリングプレーンの負荷。有効期間が短いほど、シグナリングメッセージの送信頻度が高くなります。
o the acceptable time for a NATFW NSLP signaling session to be present after it is no longer actually needed. For example, if the existence of the NATFW NSLP signaling session implies a monetary cost and teardown cannot be guaranteed, shorter lifetimes would be preferable;
o NATFW NSLPシグナリングセッションが実際に不要になった後も残存してよい時間。たとえば、シグナリングセッションの存在によって料金が発生し、確実に切断できるとは限らない場合は、より短い有効期間が望ましいです。
o the lease time of the NI's IP address. The lease time of the IP address must be longer than the chosen NATFW NSLP signaling session lifetime; otherwise, the IP address can be re-assigned to a different node. This node may receive unwanted traffic, although it never has requested a NAT/firewall configuration, which might be an issue in environments with mobile hosts.
o NIのIPアドレスのリース期間。IPアドレスのリース期間は、選択したNATFW NSLPシグナリングセッションの有効期間より長くなければなりません。そうでないと、IPアドレスが別のノードに再割り当てされる可能性があります。そのノードはNAT／ファイアウォールの設定を要求したことがないにもかかわらず、意図しないトラフィックを受信するおそれがあります。これはモバイルホストの環境で問題になる可能性があります。
The RSVP specification [RFC2205] provides an appropriate algorithm for calculating the NATFW NSLP signaling session lifetime as well as a means to avoid refresh message synchronization between NATFW NSLP signaling sessions. [RFC2205] recommends: 1. The refresh message timer to be randomly set to a value in the range [0.5R, 1.5R].
2. To avoid premature loss of state, lt (with lt being the NATFW NSLP signaling session lifetime) must satisfy lt >= (K + 0.5)*1.5*R, where K is a small integer. Then, in the worst case, K-1 successive messages may be lost without state being deleted. Currently, K = 3 is suggested as the default. However, it may be necessary to set a larger K value for hops with high loss rate. Other algorithms could be used to define the relation between the NATFW NSLP signaling session lifetime and the refresh message period; the algorithm provided is only given as an example.
2. 状態が早期に失われないようにするには、lt（NATFW NSLPシグナリングセッションの有効期間）が lt >= (K + 0.5)*1.5*R を満たす必要があります。ここでKは小さな整数です。この場合、最悪でも、K-1個のメッセージが連続して失われるまでは状態が削除されません。現在、既定値としてK = 3が提案されています。ただし、損失率の高いホップでは、Kをさらに大きくする必要がある場合があります。有効期間と更新メッセージ間隔の関係を定める別のアルゴリズムを使ってもかまいません。ここに示したアルゴリズムは一例です。
It is RECOMMENDED to use a refresh timer of 300 s (5 minutes), unless the NI or the requesting application at the NI has other requirements (e.g., flows lasting a very short time).
NIまたはNI上の要求元アプリケーションに別の要件がない限り、更新タイマーは300秒（5分）にすることが推奨されます (SHOULD)。たとえば、フローの継続時間が非常に短い場合は別の要件がありえます。
This requested NATFW NSLP signaling session lifetime value lt is stored in the NATFW_LT object of the NSLP message.
要求されたNATFW NSLPシグナリングセッションの有効期間ltは、NSLPメッセージのNATFW_LTオブジェクトに格納されます。
NSLP forwarders and the NSLP responder can execute the following behavior with respect to the requested lifetime handling:
要求された有効期間の扱いについて、NSLPフォワーダーとNSLPレスポンダーは次のいずれかの処理を行えます。
Requested signaling session lifetime acceptable:
要求されたシグナリングセッションの有効期間が許容範囲内の場合：
No changes to the NATFW NSLP signaling session lifetime values are needed. The CREATE or EXTERNAL message is forwarded, if applicable.
NATFW NSLPシグナリングセッションの有効期間を変更する必要はありません。該当する場合、CREATEメッセージまたはEXTERNALメッセージを転送します。
Signaling session lifetime can be lowered:
シグナリングセッションの有効期間を短縮できる場合：
An NSLP forwarded or the NSLP responder MAY also lower the requested NATFW NSLP signaling session lifetime to an acceptable value (based on its local policies). If an NF changes the NATFW NSLP signaling session lifetime value, it MUST store the new value in the NATFW_LT object. The CREATE or EXTERNAL message is forwarded.
NSLPフォワーダーまたはNSLPレスポンダーは、ローカルポリシーに基づく許容値まで、要求されたNATFW NSLPシグナリングセッションの有効期間を短縮してもかまいません (MAY)。NFが有効期間を変更する場合は、新しい値をNATFW_LTオブジェクトに格納しなければなりません (MUST)。CREATEメッセージまたはEXTERNALメッセージを転送します。
Requested signaling session lifetime is too big:
要求されたシグナリングセッションの有効期間が長すぎる場合：
An NSLP forwarded or the NSLP responder MAY reject the requested NATFW NSLP signaling session lifetime value as being too big and MUST generate an error RESPONSE message of class 'Signaling session failure' (7) with response code 'Requested lifetime is too big' (0x02) upon rejection. Lowering the lifetime is preferred instead of generating an error message.
NSLPフォワーダーまたはNSLPレスポンダーは、要求されたNATFW NSLPシグナリングセッションの有効期間が長すぎるとして拒否してもかまいません (MAY)。拒否する場合は、error classを'Signaling session failure'（7）、response codeを'Requested lifetime is too big'（0x02）とするエラーRESPONSEメッセージを生成しなければなりません (MUST)。エラーメッセージを生成するより、有効期間を短縮することが望ましいです。
Requested signaling session lifetime is too small:
要求されたシグナリングセッションの有効期間が短すぎる場合：
An NSLP forwarded or the NSLP responder MAY reject the requested NATFW NSLP signaling session lifetime value as being to small and MUST generate an error RESPONSE message of class 'Signaling session failure' (7) with response code 'Requested lifetime is too small' (0x10) upon rejection.
NSLPフォワーダーまたはNSLPレスポンダーは、要求されたNATFW NSLPシグナリングセッションの有効期間が短すぎるとして拒否してもかまいません (MAY)。拒否する場合は、error classを'Signaling session failure'（7）、response codeを'Requested lifetime is too small'（0x10）とするエラーRESPONSEメッセージを生成しなければなりません (MUST)。
NFs or the NR MUST NOT increase the NATFW NSLP signaling session lifetime value. Messages can be rejected on the basis of the NATFW NSLP signaling session lifetime being too long when a NATFW NSLP signaling session is first created and also on refreshes.
NFとNRは、NATFW NSLPシグナリングセッションの有効期間を延長してはなりません (MUST NOT)。NATFW NSLPシグナリングセッションの作成時にも更新時にも、有効期間が長すぎることを理由にメッセージを拒否できます。
The NSLP responder generates a successful RESPONSE for the received CREATE or EXTERNAL message, sets the NATFW NSLP signaling session lifetime value in the NATFW_LT object to the above granted lifetime and sends the message back towards NSLP initiator.
NSLPレスポンダーは、受信したCREATEメッセージまたはEXTERNALメッセージに対する成功RESPONSEを生成し、NATFW_LTオブジェクト内の有効期間を前述の許可した値に設定して、そのメッセージをNSLPイニシエーターへ返送します。
Each NSLP forwarder processes the RESPONSE message and reads and stores the granted NATFW NSLP signaling session lifetime value. The forwarders MUST accept the granted NATFW NSLP signaling session lifetime, if the lifetime value is within the acceptable range. The acceptable value refers to the value accepted by the NSLP forwarder when processing the CREATE or EXTERNAL message. For received values greater than the acceptable value, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too big' (0x11), including a Signaling Session Lifetime object that carries the maximum acceptable signaling session lifetime for this node. For received values lower than the values acceptable by the node local policy, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too small' (0x12), including a Signaling Session Lifetime object that carries the minimum acceptable signaling session lifetime for this node. In both cases, either 'Modified lifetime is too big' (0x11) or 'Modified lifetime is too small' (0x12), the NF MUST generate a NOTIFY message and send it outbound with the error class set to 'Informational' (1) and with the response code set to 'NATFW signaling session terminated' (0x05).
各NSLPフォワーダーはRESPONSEメッセージを処理し、許可されたNATFW NSLPシグナリングセッションの有効期間を読み取って保存します。有効期間が許容範囲内なら、フォワーダーは許可された有効期間を受け入れなければなりません (MUST)。許容値とは、CREATEメッセージまたはEXTERNALメッセージを処理した際にNSLPフォワーダーが受け入れた値です。受信した値が許容値を上回る場合、NSLPフォワーダーはerror classを'Signaling session failure'（7）、response codeを'Modified lifetime is too big'（0x11）とするRESPONSEメッセージを生成しなければなりません (MUST)。このメッセージには、このノードで許容される最大有効期間を格納したSignaling Session Lifetimeオブジェクトを含めます。受信した値がノードのローカルポリシーで許容される値を下回る場合、NSLPフォワーダーはerror classを'Signaling session failure'（7）、response codeを'Modified lifetime is too small'（0x12）とするRESPONSEメッセージを生成しなければなりません (MUST)。このメッセージには、このノードで許容される最小有効期間を格納したSignaling Session Lifetimeオブジェクトを含めます。どちらの場合も、NFはerror classを'Informational'（1）、response codeを'NATFW signaling session terminated'（0x05）とするNOTIFYメッセージを生成し、送信方向へ送らなければなりません (MUST)。
Figure 13 shows the procedure with an example, where an initiator requests 60 seconds lifetime in the CREATE message and the lifetime is shortened along the path by the forwarder to 20 seconds and by the responder to 15 seconds. When the NSLP forwarder receives the RESPONSE message with a NATFW NSLP signaling session lifetime value of 15 seconds it checks whether this value is lower or equal to the acceptable value.
図13は、イニシエーターがCREATEメッセージで60秒を要求し、経路上でフォワーダーが20秒に、レスポンダーが15秒に有効期間を短縮する例を示します。NSLPフォワーダーは、有効期間が15秒のRESPONSEメッセージを受信すると、その値が許容値以下かどうかを確認します。
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+
| |---------------->| NSLP |---------------->| |
| NI | | forwarder | | NR |
| |<----------------| check 15<20 |<----------------| |
+-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+
lt = lifetime
Figure 13: Signaling Session Lifetime Setting Example
図13：シグナリングセッションの有効期間を設定する例
NATFW NSLP messages need to carry an identifier so that all nodes along the path can distinguish messages sent at different points in time. Messages can be lost along the path or duplicated. So, all NATFW NSLP nodes should be able to identify messages that have been received before (duplicated) or lost before (loss). For message replay protection, it is necessary to keep information about messages that have already been received and requires every NATFW NSLP message to carry a message sequence number (MSN), see also Section 4.2.7.
NATFW NSLPメッセージには識別子が必要です。これにより、経路上のすべてのノードが異なる時点に送信されたメッセージを区別できます。経路上でメッセージが失われたり、重複したりすることがあります。そのため、すべてのNATFW NSLPノードは、以前に受信したメッセージ（重複）や、失われたメッセージ（損失）を識別できるようにする必要があります。メッセージのリプレイを防ぐには、受信済みメッセージの情報を保持する必要があります。このため、すべてのNATFW NSLPメッセージにメッセージシーケンス番号（MSN）が必要です。セクション4.2.7も参照してください。
The MSN MUST be set by the NI and MUST NOT be set or modified by any other node. The initial value for the MSN MUST be generated randomly and MUST be unique only within the NATFW NSLP signaling session for which it is used. The NI MUST increment the MSN by one for every message sent. Once the MSN has reached the maximum value, the next value it takes is zero. All NATFW NSLP nodes MUST use the algorithm defined in [RFC1982] to detect MSN wrap-arounds.
MSNはNIが設定しなければならず (MUST)、他のノードが設定または変更してはなりません (MUST NOT)。MSNの初期値はランダムに生成しなければなりません (MUST)。また、その値は使用するNATFW NSLPシグナリングセッション内でのみ一意でなければなりません (MUST)。NIは送信するメッセージごとにMSNを1ずつ増やさなければなりません (MUST)。MSNが最大値に達した後の値は0です。すべてのNATFW NSLPノードは、MSNの周回を検出するために[RFC1982]で定義されたアルゴリズムを使用しなければなりません (MUST)。
NSLP forwarders and the responder store the MSN from the initial CREATE or EXTERNAL packet that creates the NATFW NSLP signaling session as the start value for the NATFW NSLP signaling session. NFs and NRs MUST include the received MSN value in the corresponding RESPONSE message that they generate.
NSLPフォワーダーとレスポンダーは、NATFW NSLPシグナリングセッションを作成した最初のCREATEメッセージまたはEXTERNALメッセージに含まれるMSNを、そのセッションの開始値として保存します。NFとNRは、生成する対応するRESPONSEメッセージに受信したMSNの値を含めなければなりません (MUST)。
When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses the MSN given in the message to determine whether the state being requested is different from the state already installed. The message MUST be discarded if the received MSN value is equal to or lower than the stored MSN value. Such a received MSN value can indicate a duplicated and delayed message or replayed message. If the received MSN value is greater than the already stored MSN value, the NATFW NSLP MUST update its stored state accordingly, if permitted by all security checks (see Section 3.6), and store the updated MSN value accordingly.
CREATEメッセージまたはEXTERNALメッセージを受信したNATFW NSLPノードは、メッセージ内のMSNを使って、要求された状態がすでに設定されている状態と異なるかどうかを判断します。受信したMSNが保存済みのMSN以下の場合、メッセージを破棄しなければなりません (MUST)。このようなMSNは、重複して遅れて届いたメッセージ、またはリプレイされたメッセージを示す場合があります。受信したMSNが保存済みの値より大きい場合、すべてのセキュリティ検査（セクション3.6参照）で許可されることを条件に、NATFW NSLPは保存状態を更新し、新しいMSNも保存しなければなりません (MUST)。
NATFW NSLP nodes receiving signaling messages MUST first check whether this message is authenticated and authorized to perform the requested action. NATFW NSLP nodes requiring more information than provided MUST generate an error RESPONSE of class 'Permanent failure' (0x5) with response code 'Authentication failed' (0x01) or with response code 'Authorization failed' (0x02).
シグナリングメッセージを受信したNATFW NSLPノードは、まず、そのメッセージが認証済みであり、要求された処理を実行する権限があるかを確認しなければなりません (MUST)。与えられた情報だけでは判断できないNATFW NSLPノードは、error classを'Permanent failure'（0x5）とし、response codeを'Authentication failed'（0x01）または'Authorization failed'（0x02）とするエラーRESPONSEを生成しなければなりません (MUST)。
The NATFW NSLP is expected to run in various environments, such as IP-based telephone systems, enterprise networks, home networks, etc. The requirements on authentication and authorization are quite different between these use cases. While a home gateway, or an Internet cafe, using NSIS may well be happy with a "NATFW signaling coming from inside the network" policy for authorization of signaling, enterprise networks are likely to require more strongly authenticated/authorized signaling. This enterprise scenario may require the use of an infrastructure and administratively assigned identities to operate the NATFW NSLP.
NATFW NSLPは、IPベースの電話システム、企業ネットワーク、家庭内ネットワークなど、さまざまな環境で動作することを想定しています。認証と認可の要件は、用途によって大きく異なります。NSISを使うホームゲートウェイやインターネットカフェでは、シグナリングの認可に「ネットワーク内部から届いたNATFWシグナリングを許可する」というポリシーで十分な場合があります。一方、企業ネットワークでは、より強固な認証・認可を求める可能性があります。そのような企業環境では、NATFW NSLPを運用するための基盤と、管理者が割り当てる識別子が必要になることがあります。
Once the NI is authenticated and authorized, another step is performed. The requested policy rule for the NATFW NSLP signaling session is checked against a set of policy rules, i.e., whether the requesting NI is allowed to request the policy rule to be loaded in the device. If this fails, the NF or NR must send an error RESPONSE of class 'Permanent failure' (5) and with response code 'Authorization failed' (0x02).
NIの認証と認可が済むと、次の確認を行います。NATFW NSLPシグナリングセッションで要求されたポリシールールを一連のポリシールールと照合し、要求元のNIがその装置に当該ルールを設定するよう要求できるか確認します。この確認に失敗した場合、NFまたはNRは、error classを'Permanent failure'（5）、response codeを'Authorization failed'（0x02）とするエラーRESPONSEを送信しなければなりません。
This section defines the protocol operations including how to create NATFW NSLP signaling sessions, maintain them, delete them, and how to reserve addresses.
この節では、NATFW NSLPシグナリングセッションの作成、維持、削除、およびアドレスの予約を含むプロトコル処理を定義します。
This section requires a good knowledge of the NTLP [RFC5971] and the message routing method mechanism and the associated message routing information (MRI). The NATFW NSLP uses information from the MRI, e.g., the destination and source ports, and the NATFW NSLP to construct the policy rules used on the NATFW NSLP level. See also Appendix D for further information about this.
この節を理解するには、NTLP [RFC5971]、メッセージルーティング機構、および関連するメッセージルーティング情報（MRI）について理解している必要があります。NATFW NSLPはMRIの情報（宛先ポートや送信元ポートなど）とNATFW NSLPの情報を使って、NATFW NSLPレベルで使うポリシールールを構成します。詳細は付録Dも参照してください。
Allowing two hosts to exchange data even in the presence of middleboxes is realized in the NATFW NSLP by the use of the CREATE message. The NI (either the data sender or a proxy) generates a CREATE message as defined in Section 4.3.1 and hands it to the NTLP. The NTLP forwards the whole message on the basis of the message routing information (MRI) towards the NR. Each NSLP forwarder along the path that implements NATFW NSLP processes the NSLP message. Forwarding is done hop-by-hop but may pass transparently through NSLP forwarders that do not contain NATFW NSLP functionality and non-NSIS-aware routers between NSLP hop way points. When the message reaches the NR, the NR can accept the request or reject it. The NR generates a response to CREATE and this response is transported hop-by-hop towards the NI. NATFW NSLP forwarders may reject requests at any time. Figure 14 sketches the message flow between the NI (DS in this example), an NF (e.g., NAT), and an NR (DR in this example).
ミドルボックスが存在する環境でも2つのホストがデータを交換できるようにするため、NATFW NSLPではCREATEメッセージを使います。NI（データ送信者またはプロキシ）は、セクション4.3.1に従ってCREATEメッセージを生成し、NTLPに渡します。NTLPは、メッセージルーティング情報（MRI）に基づいてメッセージ全体をNRへ転送します。経路上でNATFW NSLPを実装する各NSLPフォワーダーは、NSLPメッセージを処理します。転送はホップごとに行われますが、NATFW NSLP機能を持たないNSLPフォワーダーや、NSLPのホップ間にあるNSIS非対応ルーターは、メッセージを透過的に通過させることがあります。メッセージを受信したNRは要求を受け入れるか拒否します。NRはCREATEへの応答を生成し、その応答をNIへホップごとに返送します。NATFW NSLPフォワーダーはいつでも要求を拒否できます。図14は、NI（この例ではDS）、NF（たとえばNAT）、NR（この例ではDR）の間のメッセージフローを示します。
NI Private Network NF Public Internet NR
| | |
| CREATE | |
|----------------------------->| |
| | |
| | |
| | CREATE |
| |--------------------------->|
| | |
| | RESPONSE |
| RESPONSE |<---------------------------|
|<-----------------------------| |
| | |
| | |
Figure 14: CREATE Message Flow with Success RESPONSE
図14：成功RESPONSEを伴うCREATEメッセージの流れ
There are several processing rules for a NATFW peer when generating and receiving CREATE messages, since this message type is used for creating new NATFW NSLP signaling sessions, updating existing ones, and extending the lifetime and deleting NATFW NSLP signaling sessions. The three latter functions operate in the same way for all kinds of CREATE messages, and are therefore described in separate sections:
CREATEメッセージは、新しいNATFW NSLPシグナリングセッションの作成、既存セッションの更新、有効期間の延長、およびシグナリングセッションの削除に使われます。そのため、NATFWピアがCREATEメッセージを生成・受信する際には複数の処理規則があります。後半の3つの処理は、すべての種類のCREATEメッセージで同様に行われるため、別の節で説明します。
o Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
o NATFW NSLPシグナリングセッションの有効期間の延長については、セクション3.7.3で説明します。
o Deleting NATFW NSLP signaling sessions is described in Section 3.7.4.
o NATFW NSLPシグナリングセッションの削除については、セクション3.7.4で説明します。
o Updating policy rules is described in Section 3.10.
o ポリシールールの更新については、セクション3.10で説明します。
For an initial CREATE message creating a new NATFW NSLP signaling session, the processing of CREATE messages is different for every NATFW node type: o NSLP initiator: An NI only generates CREATE messages and hands them over to the NTLP. The NI should never receive CREATE messages and MUST discard them.
新しいNATFW NSLPシグナリングセッションを作成する最初のCREATEメッセージについて、処理はNATFWノードの種類ごとに異なります。o NSLPイニシエーター：NIはCREATEメッセージを生成してNTLPに渡すだけです。NIがCREATEメッセージを受信することは想定されていません。受信した場合は破棄しなければなりません (MUST)。
o NATFW NSLP forwarder: NFs that are unable to forward the CREATE message to the next hop MUST generate an error RESPONSE of class 'Permanent failure' (5) with response code 'Did not reach the NR' (0x07). This case may occur if the NTLP layer cannot find a NATFW NSLP peer, either another NF or the NR, and returns an error via the GIST API (a timeout error reported by GIST). The NSLP message processing at the NFs depends on the middlebox type:
o NATFW NSLPフォワーダー：CREATEメッセージを次のホップへ転送できないNFは、error classを'Permanent failure'（5）、response codeを'Did not reach the NR'（0x07）とするエラーRESPONSEを生成しなければなりません (MUST)。NTLP層が別のNFまたはNRであるNATFW NSLPピアを見つけられず、GIST APIを通じてエラー（GISTが報告するタイムアウトエラー）を返した場合などに、この状況が起こります。NFでのNSLPメッセージ処理は、ミドルボックスの種類によって異なります。
* NAT: When the initial CREATE message is received at the public side of the NAT, it looks for a reservation made in advance, by using an EXTERNAL message (see Section 3.7.2). The matching process considers the received MRI information and the stored MRI information, as described in Section 3.8. If no matching reservation can be found, i.e., no reservation has been made in advance, the NSLP MUST return an error RESPONSE of class 'Signaling session failure' (7) with response code 'No reservation found matching the MRI of the CREATE request' (0x03). If there is a matching reservation, the NSLP stores the data sender's address (and if applicable port number) as part of the source IP address of the policy rule ('the remembered policy rule') to be loaded, and forwards the message with the destination IP address set to the internal (private in most cases) address of the NR. When the initial CREATE message is received at the private side, the NAT binding is allocated, but not activated (see also Appendix D.3). An error RESPONSE message is generated, if the requested policy rule cannot be reserved right away, of class 'Signaling session failure' (7) with response code 'Requested policy rule denied due to policy conflict' (0x4). The MRI information is updated to reflect the address, and if applicable port, translation. The NSLP message is forwarded towards the NR with source IP address set to the NAT's external address from the newly remembered binding.
* NAT：NATのパブリック側で最初のCREATEメッセージを受信すると、EXTERNALメッセージで事前に行われた予約を検索します（セクション3.7.2参照）。照合では、セクション3.8で説明するように、受信したMRI情報と保存済みのMRI情報を比較します。一致する予約がない、つまり事前に予約されていない場合、NSLPはerror classを'Signaling session failure'（7）、response codeを'No reservation found matching the MRI of the CREATE request'（0x03）とするエラーRESPONSEを返さなければなりません (MUST)。一致する予約がある場合、NSLPはロードするポリシールール（「記憶済みポリシールール」）の送信元IPアドレスの一部として、データ送信者のアドレスと、該当する場合はポート番号を保存します。その後、宛先IPアドレスをNRの内部アドレス（多くの場合はプライベートアドレス）に設定してメッセージを転送します。最初のCREATEメッセージをプライベート側で受信すると、NATバインディングを割り当てますが、有効化はしません（付録D.3参照）。要求されたポリシールールを直ちに予約できない場合は、error classを'Signaling session failure'（7）、response codeを'Requested policy rule denied due to policy conflict'（0x04）とするエラーRESPONSEメッセージを生成します。MRI情報は、アドレス変換と、該当する場合はポート変換を反映するよう更新します。新たに記憶したバインディングのNAT外部アドレスを送信元IPアドレスに設定し、NSLPメッセージをNRへ転送します。
* Firewall: When the initial CREATE message is received, the NSLP just remembers the requested policy rule, but does not install any policy rule. Afterwards, the message is forwarded towards the NR. If the requested policy rule cannot be reserved right away, an error RESPONSE message is generated, of class 'Signaling session failure' (7) with response code 'Requested policy rule denied due to policy conflict' (0x4).
* ファイアウォール：最初のCREATEメッセージを受信した時点では、NSLPは要求されたポリシールールを記憶するだけで、ルール自体は設定しません。その後、メッセージをNRへ転送します。要求されたポリシールールを直ちに予約できない場合は、error classを'Signaling session failure'（7）、response codeを'Requested policy rule denied due to policy conflict'（0x04）とするエラーRESPONSEメッセージを生成します。
* Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the NAT case. No policy rules are installed. Implementations MUST take into account the order of packet processing in the firewall and NAT functions within the device. This will be referred to as "order of functions" and is generally different depending on whether the packet arrives at the external or internal side of the middlebox.
* NATとファイアウォールの複合装置：両方の機能を持つミドルボックスでの処理は、NATの場合と同じです。ここではポリシールールを設定しません。実装では、装置内のファイアウォール機能とNAT機能におけるパケット処理の順序を考慮しなければなりません (MUST)。この順序を「機能の処理順」と呼び、パケットがミドルボックスの外側から到着するか内側から到着するかによって、一般に異なります。
o NSLP receiver: NRs receiving initial CREATE messages MUST reply with a success RESPONSE of class 'Success' (2) with response code set to 'All successfully processed' (0x01), if they accept the CREATE message. Otherwise, they MUST generate a RESPONSE message with a suitable response code. RESPONSE messages are sent back NSLP hop-by-hop towards the NI, irrespective of the response codes, either success or error.
o NSLPレスポンダー：最初のCREATEメッセージを受信したNRは、そのメッセージを受け入れる場合、response codeを'All successfully processed'（0x01）とする、error class 'Success'（2）の成功RESPONSEを返さなければなりません (MUST)。受け入れない場合は、適切なresponse codeを含むRESPONSEメッセージを生成しなければなりません (MUST)。成功・エラーのいずれであっても、RESPONSEメッセージをNSLPの各ホップを経由してNIへ返送します。
Remembered policy rules at middleboxes MUST be only installed upon receiving a corresponding successful RESPONSE message with the same SID as the CREATE message that caused them to be remembered. This is a countermeasure to several problems, for example, wastage of resources due to loading policy rules at intermediate NFs when the CREATE message does not reach the final NR for some reason.
ミドルボックスが記憶済みポリシールールを設定してよいのは、そのルールを記憶する原因となったCREATEメッセージと同じSIDを持つ、対応する成功RESPONSEメッセージを受信した後に限られます (MUST)。これは、たとえばCREATEメッセージが何らかの理由で最終的なNRに届かなかった場合に、中間NFでポリシールールを設定してリソースを浪費する問題などへの対策です。
Processing of a RESPONSE message is different for every NSIS node type:
RESPONSEメッセージの処理は、NSISノードの種類ごとに異なります。
o NSLP initiator: After receiving a successful RESPONSE, the data path is configured and the DS can start sending its data to the DR. After receiving an error RESPONSE message, the NI MAY try to generate the CREATE message again or give up and report the failure to the application, depending on the error condition.
o NSLPイニシエーター：成功RESPONSEを受信するとデータパスが設定され、DSはDRへのデータ送信を開始できます。エラーRESPONSEメッセージを受信した場合、NIはエラーの内容に応じて、CREATEメッセージの再生成を試みるか、処理を断念して失敗をアプリケーションに通知できます (MAY)。
o NSLP forwarder: NFs install the remembered policy rules, if a successful RESPONSE message with matching SID is received. If an ERROR RESPONSE message with matching SID is received, the NATFW NSLP session is marked as 'Dead', no policy rule is installed and the remembered rule is discarded.
o NSLPフォワーダー：一致するSIDを持つ成功RESPONSEメッセージを受信した場合、NFは記憶済みポリシールールを設定します。一致するSIDを持つERROR RESPONSEメッセージを受信した場合、NATFW NSLPセッションをDeadとマークし、ポリシールールを設定せず、記憶済みルールを破棄します。
o NSIS responder: The NR should never receive RESPONSE messages and MUST silently drop any such messages received.
o NSISレスポンダー：NRがRESPONSEメッセージを受信することは想定されていません。受信した場合は、何も応答せずに破棄しなければなりません (MUST)。
NFs and the NR can also tear down the CREATE session at any time by generating a NOTIFY message with the appropriate response code set.
NFとNRは、適切なresponse codeを設定したNOTIFYメッセージを生成することで、いつでもCREATEセッションを終了させることもできます。
NSIS signaling is intended to travel end-to-end, even in the presence of NATs and firewalls on-path. This works well in cases where the data sender is itself behind a NAT or a firewall as described in Section 3.7.1. For scenarios where the data receiver is located behind a NAT or a firewall and it needs to receive data flows from outside its own network (usually referred to as inbound flows, see Figure 5), the problem is more troublesome.
NSISシグナリングは、経路上にNATやファイアウォールがあってもエンドツーエンドで届くことを意図しています。セクション3.7.1で説明したように、データ送信者自身がNATやファイアウォールの背後にある場合は、問題なく動作します。一方、データ受信者がNATまたはファイアウォールの背後にあり、自身のネットワーク外からデータフローを受信する必要がある場合（通常、受信フローと呼びます。図5参照）は、より難しい問題になります。
NSIS signaling, as well as subsequent data flows, are directed to a particular destination IP address that must be known in advance and reachable. Data receivers must tell the local NSIS infrastructure (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP signaling and data flows before they can receive these flows. It is necessary to differentiate between data receivers behind NATs and behind firewalls to understand the further NATFW procedures. Data receivers that are only behind firewalls already have a public IP address and they need only to be reachable for NATFW signaling. Unlike data receivers that are only behind firewalls, data receivers behind NATs do not have public IP addresses; consequently, they are not reachable for NATFW signaling by entities outside their addressing realm.
NSISシグナリングと後続のデータフローは、事前に把握され、到達可能な特定の宛先IPアドレスに向けられます。データ受信者は、これらのフローを受信できるようになる前に、着信するNATFW NSLPシグナリングとデータフローについて、ローカルのNSIS基盤（受信側ファイアウォールやNAT）に知らせる必要があります。以降のNATFW手順を理解するには、NATの背後にいるデータ受信者とファイアウォールの背後にいるデータ受信者を区別する必要があります。ファイアウォールだけの背後にいるデータ受信者はすでにパブリックIPアドレスを持ち、NATFWシグナリングで到達可能であれば足ります。これに対して、NATの背後にいるデータ受信者はパブリックIPアドレスを持たないため、別のアドレス領域にいる相手からNATFWシグナリングで到達できません。
The preceding discussion addresses the situation where a DR node that wants to be reachable is unreachable because the NAT lacks a suitable rule with the 'allow' action that would forward inbound data. However, in certain scenarios, a node situated behind inbound firewalls that do not block inbound data traffic (firewalls with "default to allow") unless requested might wish to prevent traffic being sent to it from specified addresses. In this case, NSIS NATFW signaling can be used to achieve this by installing a policy rule with its action set to 'deny' using the same mechanisms as for 'allow' rules.
前述の説明では、NATに受信データを転送するallow動作の適切なルールがないため、到達可能であるべきDRノードに到達できない状況を扱いました。一方、受信側ファイアウォールが受信データを既定で許可している場合でも、特定のアドレスからのトラフィックを遮断したいことがあります。この場合、NSIS NATFWシグナリングを使い、allowルールと同じ仕組みでactionをdenyに設定したポリシールールを設定できます。
The required result is obtained by sending an EXTERNAL message in the inbound direction of the intended data flow. When using this functionality, the NSIS initiator for the 'Reserve External Address' signaling is typically the node that will become the DR for the eventual data flow. To distinguish this initiator from the usual case where the NI is associated with the DS, the NI is denoted by NI+ and the NSIS responder is similarly denoted by NR+.
必要な状態を作るには、意図するデータフローの受信方向にEXTERNALメッセージを送信します。この機能を使う場合、「Reserve External Address」シグナリングを開始するNSISイニシエーターは、通常、最終的なデータフローのDRになるノードです。NIがDSに対応する通常のケースと区別するため、このイニシエーターをNI+、NSISレスポンダーをNR+と表記します。
Public Internet Private Address Space
Public Internet Private Address Space
Edge
NI(DS) NAT/FW NAT NR(DR)
NR+ NI+
| | | |
| | | |
| | | |
| | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] |
| |<----------------------|<----------------------|
| | | |
| |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
| |---------------------->|---------------------->|
| | | |
| | | |
============================================================>
Data Traffic Direction
Figure 15: Reservation Message Flow for DR behind NAT or Firewall
図15：NATまたはファイアウォールの背後にいるDRの予約メッセージフロー
Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW NSLP signaling messages. In this case, the roles of the different NSIS entities are:
図15は、受信するNATFW NSLPシグナリングメッセージを可能にするEXTERNALメッセージの流れを示しています。この場合、各NSISエンティティは次の役割を担います。
o The data receiver (DR) for the anticipated data traffic is the NSIS initiator (NI+) for the EXTERNAL message, but becomes the NSIS responder (NR) for following CREATE messages.
o 想定されるデータトラフィックのデータ受信者（DR）は、EXTERNALメッセージのNSISイニシエーター（NI+）です。その後のCREATEメッセージに対しては、NSISレスポンダー（NR+）になります。
o The actual data sender (DS) will be the NSIS initiator (NI) for later CREATE messages and may be the NSIS target of the signaling (NR+).
o 実際のデータ送信者（DS）は、後続のCREATEメッセージのNSISイニシエーター（NI）となり、シグナリングのNSIS宛先（NR+）になる場合もあります。
o It may be necessary to use a signaling destination address (SDA) as the actual target of the EXTERNAL message (NR+) if the DR is located behind a NAT and the address of the DS is unknown. The SDA is an arbitrary address in the outermost address realm on the other side of the NAT from the DR. Typically, this will be a suitable public IP address when the 'outside' realm is the public Internet. This choice of address causes the EXTERNAL message to be routed through the NATs towards the outermost realm and would force interception of the message by the outermost NAT in the network at the boundary between the private address and the public address realm (the edge-NAT). It may also be intercepted by other NATs and firewalls on the path to the edge-NAT.
o DRがNATの背後にいてDSのアドレスが事前に分からない場合は、EXTERNALメッセージの実際の宛先（NR+）としてシグナリング宛先アドレス（SDA）を使う必要があることがあります。SDAは、DR側のNATを越えた最も外側のアドレス領域にある任意のアドレスです。「外側」の領域がパブリックインターネットなら、通常は適切なパブリックIPアドレスを選びます。このアドレスを選ぶとEXTERNALメッセージはNATを通って最も外側の領域へルーティングされ、プライベートアドレス領域とパブリックアドレス領域の境界にある最外縁のNAT（edge-NAT）がメッセージを捕捉します。edge-NATまでの経路上にある他のNATやファイアウォールが捕捉することもあります。
Basically, there are two different signaling scenarios. Either
シグナリングには、次の2つの場合があります。
1. the DR behind the NAT/firewall knows the IP address of the DS in advance, or
1. NAT／ファイアウォールの背後にいるDRが、DSのIPアドレスを事前に知っている場合。
2. the address of the DS is not known in advance.
2. DSのアドレスを事前に把握していない場合。
Case 1 requires the NATFW NSLP to request the path-coupled message routing method (PC-MRM) from the NTLP. The EXTERNAL message MUST be sent with PC-MRM (see Section 5.8.1 in [RFC5971]) with the direction set to 'upstream' (inbound). The handling of case 2 depends on the situation of the DR: if the DR is solely located behind a firewall, the EXTERNAL message MUST be sent with the PC-MRM, direction 'upstream' (inbound), and the data flow source IP address set to 'wildcard'. If the DR is located behind a NAT, the EXTERNAL message MUST be sent with the loose-end message routing method (LE-MRM, see Section 5.8.2 in [RFC5971]), the destination-address set to the signaling destination IP address (SDA, see also Appendix A). For scenarios with the DR behind a firewall, special conditions apply (see applicability statement in Appendix C). The data receiver is challenged to determine whether it is solely located behind firewalls or NATs in order to choose the right message routing method. This decision can depend on a local configuration parameter, possibly given through DHCP, or it could be discovered through other non-NSLP related testing of the network configuration. The use of the PC-MRM with the known data sender's IP address is RECOMMENDED. This gives GIST the best possible handle to route the message 'upstream' (outbound). The use of the LE-MRM, if and only if the data sender's IP address is not known and the data receiver is behind a NAT, is RECOMMENDED.
ケース1では、NATFW NSLPはNTLPに対して、パス結合型メッセージルーティング方式（PC-MRM）を要求する必要があります。EXTERNALメッセージは、方向を'upstream'（受信方向）に設定し、PC-MRMで送信しなければなりません (MUST)（[RFC5971]のセクション5.8.1参照）。ケース2の処理はDRの状況によって異なります。DRがファイアウォールだけの背後にある場合、EXTERNALメッセージはPC-MRMを使い、方向を'upstream'（受信方向）に設定し、データフローの送信元IPアドレスを'wildcard'にして送信しなければなりません (MUST)。DRがNATの背後にある場合、EXTERNALメッセージはルーズエンド型メッセージルーティング方式（LE-MRM、[RFC5971]のセクション5.8.2参照）で送信し、destination-addressをシグナリング宛先IPアドレス（SDA、付録Aも参照）に設定しなければなりません (MUST)。DRがファイアウォールの背後にいる場合には、特別な条件が適用されます（付録Cの適用範囲に関する記述参照）。データ受信者は、適切なメッセージルーティング方式を選ぶため、自身がファイアウォールだけの背後にいるのか、それともNATの背後にもいるのかを判断する必要があります。この判断は、DHCPで渡される場合もあるローカル設定に基づくか、NSLP以外の方法でネットワーク構成を検査して行えます。データ送信者のIPアドレスが既知の場合はPC-MRMの使用が推奨されます (SHOULD)。この方式により、GISTはメッセージを「upstream」（外向き）にルーティングするための最も有効な情報を得られます。データ送信者のIPアドレスが不明で、かつデータ受信者がNATの背後にいる場合に限り、LE-MRMの使用が推奨されます (SHOULD)。
For case 2 with NAT, the NI+ (which could be on the data receiver DR or on any other host within the private network) sends the EXTERNAL message targeted to the signaling destination IP address. The message routing for the EXTERNAL message is in the reverse direction of the normal message routing used for path-coupled signaling where the signaling is sent outbound (as opposed to inbound in this case). When establishing NAT bindings (and a NATFW NSLP signaling session), the signaling direction does not matter since the data path is modified through route pinning due to the external IP address at the NAT. Subsequent NSIS messages (and also data traffic) will travel through the same NAT boxes. However, this is only valid for the NAT boxes, but not for any intermediate firewall. That is the reason for having a separate CREATE message enabling the reservations made with EXTERNAL at the NATs and either enabling prior reservations or creating new pinholes at the firewalls that are encountered on the outbound path depending on whether the inbound and outbound routes coincide.
NATのあるケース2では、NI+（データ受信者DR上のノードでも、プライベートネットワーク内の別のホストでもかまいません）が、シグナリング宛先IPアドレスを宛先としてEXTERNALメッセージを送信します。このEXTERNALメッセージの経路は、シグナリングを外向きに送る通常のパス結合型メッセージルーティングとは逆方向です（このケースのシグナリングは内向きです）。NATバインディングとNATFW NSLPシグナリングセッションを確立する際、NATの外部IPアドレスによって経路が固定されるため、シグナリングの方向は重要ではありません。その後のNSISメッセージとデータトラフィックは、同じNAT装置を通ります。ただし、これはNAT装置に当てはまりますが、中間ファイアウォールには当てはまりません。そのため、別途CREATEメッセージが必要です。このメッセージにより、NATではEXTERNALで行った予約を有効にし、ファイアウォールでは、受信経路と送信経路が一致するかどうかに応じて、事前の予約を有効にするか、経路上の新しいピンホールを作成します。
The EXTERNAL signaling message creates an NSIS NATFW signaling session at any intermediate NSIS NATFW peer(s) encountered, independent of the message routing method used. Furthermore, it has to be ensured that the edge-NAT or edge-firewall device is discovered as part of this process. The end host cannot be assumed to know this device -- instead the NAT or firewall box itself is assumed to know that it is located at the outer perimeter of the network. Forwarding of the EXTERNAL message beyond this entity is not necessary, and MUST be prohibited as it may provide information on the capabilities of internal hosts. It should be noted, that it is the outermost NAT or firewall that is the edge-device that must be found during this discovery process. For instance, when there are a NAT and (afterwards) a firewall on the outbound path at the network border, the firewall is the edge-firewall. All messages must be forwarded to the topology-wise outermost edge-device to ensure that this device knows about the NATFW NSLP signaling sessions for incoming CREATE messages. However, the NAT is still the edge-NAT because it has a public globally routable IP address on its public side: this is not affected by any firewall between the edge-NAT and the public network.
EXTERNALシグナリングメッセージは、使用するメッセージルーティング方式にかかわらず、経路上で遭遇した中間のNSIS NATFWピアにNSIS NATFWシグナリングセッションを作成します。また、この処理の中でedge-NATまたはedge-firewall装置を特定できるようにする必要があります。エンドホストがその装置を把握しているとは限りません。装置自身、つまりNATまたはファイアウォールが、ネットワークの外縁に位置することを把握していると想定します。内部ホストの機能に関する情報が漏れるおそれがあるため、EXTERNALメッセージをこの装置より先へ転送する必要はなく、内部ホストの機能に関する情報が漏れるおそれがあるため、禁止しなければなりません (MUST)。特定処理で見つけるべきedge装置は、最外縁のNATまたはファイアウォールである点に注意してください。たとえば、ネットワーク境界の送信経路上にNATの後ろにファイアウォールがある場合、ファイアウォールがedge-firewallです。着信CREATEメッセージに備えて、この装置がNATFW NSLPシグナリングセッションを把握できるよう、すべてのメッセージをトポロジー上の最外縁のedge装置まで転送しなければなりません。NATのパブリック側にはグローバルにルーティング可能なIPアドレスがあるため、NATは引き続きedge-NATです。edge-NATとパブリックネットワークの間にファイアウォールがあっても、この点は変わりません。
Possible edge arrangements are:
edge装置の配置例を次に示します。
Public Net ----------------- Private net --------------
| Public Net|--|Edge-FW|--|FW|...|FW|--|DR|
| Public Net|--|Edge-FW|--|FW|...|FW|--|DR|
| Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|
| Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|
| Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|
| Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|
The edge-NAT or edge-firewall device closest to the public realm responds to the EXTERNAL request message with a successful RESPONSE message. An edge-NAT includes a NATFW_EXTERNAL_IP object (see Section 4.2.2), carrying the publicly reachable IP address, and if applicable, a port number.
パブリック側に最も近いedge-NATまたはedge-firewall装置は、EXTERNAL要求メッセージに成功RESPONSEメッセージで応答します。edge-NATはNATFW_EXTERNAL_IPオブジェクト（セクション4.2.2参照）を含め、外部から到達可能なIPアドレスと、該当する場合はポート番号を格納します。
The NI+ can request each intermediate NAT (i.e., a NAT that is not the edge-NAT) to include the external binding address (and if applicable port number) in the external binding address object. The external binding address object stores the external IP address (and port) at the particular NAT. The NI+ has to include the external binding address (see Section 4.2.3) object in the request message, if it wishes to obtain the information.
NI+は各中間NAT（edge-NAT以外のNAT）に対し、外部バインディングアドレス（該当する場合はポート番号も）を外部バインディングアドレスオブジェクトに含めるよう要求できます。このオブジェクトには、各NATの外部IPアドレスとポートが格納されます。情報の取得を希望するNI+は、要求メッセージに外部バインディングアドレスオブジェクト（セクション4.2.3参照）を含める必要があります。
There are several processing rules for a NATFW peer when generating and receiving EXTERNAL messages, since this message type is used for creating new reserve NATFW NSLP signaling sessions, updating existing, extending the lifetime, and deleting NATFW NSLP signaling session. The three latter functions operate in the same way for all kinds of CREATE and EXTERNAL messages, and are therefore described in separate sections:
EXTERNALメッセージは、新しい予約用NATFW NSLPシグナリングセッションの作成、既存セッションの更新、有効期間の延長、およびセッションの削除に使われます。そのため、NATFWピアがEXTERNALメッセージを生成・受信する際には複数の処理規則があります。後半の3つの処理は、CREATEメッセージとEXTERNALメッセージのどちらでも同様に行われるため、別の節で説明します。
o Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
o NATFW NSLPシグナリングセッションの有効期間の延長については、セクション3.7.3で説明します。
o Deleting NATFW NSLP signaling sessions is described in Section 3.7.4.
o NATFW NSLPシグナリングセッションの削除については、セクション3.7.4で説明します。
o Updating policy rules is described in Section 3.10.
o ポリシールールの更新については、セクション3.10で説明します。
The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL message. Especially, the LE-MRM does not include enough information for some types of NATs (basically, those NATs that also translate port numbers) to perform the address translation. This information is provided in the NATFW_DTINFO (see Section 4.2.8). This information MUST include at least the 'dst port number' and 'protocol' fields, in the NATFW_DTINFO object as these may be required by NATs that are en route, depending on the type of the NAT. All other fields MAY be set by the NI+ to restrict the set of possible NIs. An edge-NAT will use the information provided in the NATFW_DTINFO object to allow only a NATFW CREATE message with a matching MRI to be forwarded. The MRI of the NATFW CREATE message has to use the parameters set in NATFW_DTINFO object ('src IPv4/v6 address', 'src port number', 'protocol') as the source IP address/ port of the flow from DS to DR. A NAT requiring information carried in the NATFW_DTINFO can generate a number of error RESPONSE messages of class 'Signaling session failure' (7):
NI+はEXTERNALメッセージに必ずNATFW_DTINFOオブジェクトを含めなければなりません (MUST)。特にLE-MRMだけでは、一部の種類のNAT（基本的にポート番号も変換するNAT）がアドレス変換を行うための情報が不足します。この情報はNATFW_DTINFOで提供します（セクション4.2.8参照）。NATFW_DTINFOオブジェクトには、少なくとも'dst port number'と'protocol'の各フィールドを含めなければなりません (MUST)。NATの種類によっては、経路上のNATがこれらを必要とするためです。NI+は、可能なNIの範囲を絞るため、他のすべてのフィールドを設定してもかまいません (MAY)。edge-NATはNATFW_DTINFOオブジェクトの情報を使い、MRIが一致するNATFW CREATEメッセージだけを転送します。NATFW CREATEメッセージのMRIでは、NATFW_DTINFOオブジェクトの'src IPv4/v6 address'、'src port number'、'protocol'に設定された値を、DSからDRへのフローの送信元IPアドレスおよびポートとして使う必要があります。NATFW_DTINFO内の情報を必要とするNATは、error classが'Signaling session failure'（7）の次のエラーRESPONSEを生成できます。
o 'Requested policy rule denied due to policy conflict' (0x04)
o 'Requested policy rule denied due to policy conflict' (0x04)
o 'Unknown policy rule action' (0x05)
o 'Unknown policy rule action' (0x05)
o 'Requested rule action not applicable' (0x06)
o 'Requested rule action not applicable' (0x06)
o 'NATFW_DTINFO object is required' (0x07)
o 'NATFW_DTINFO object is required' (0x07)
o 'Requested value in sub_ports field in NATFW_EFI not permitted' (0x08)
o 'Requested value in sub_ports field in NATFW_EFI not permitted' (0x08)
o 'Requested IP protocol not supported' (0x09)
o 'Requested IP protocol not supported' (0x09)
o 'Plain IP policy rules not permitted -- need transport layer information' (0x0A)
o 'Plain IP policy rules not permitted -- need transport layer information' (0x0A)
o 'Source IP address range is too large' (0x0C) o 'Destination IP address range is too large' (0x0D)
o 'Source IP address range is too large' (0x0C) o 'Destination IP address range is too large' (0x0D)
o 'Source L4-port range is too large' (0x0E)
o 'Source L4-port range is too large' (0x0E)
o 'Destination L4-port range is too large' (0x0F)
o 'Destination L4-port range is too large' (0x0F)
Processing of EXTERNAL messages is specific to the NSIS node type:
EXTERNALメッセージの処理は、NSISノードの種類ごとに異なります。
o NSLP initiator: NI+ only generate EXTERNAL messages. When the data sender's address information is known in advance, the NI+ can include a NATFW_DTINFO object in the EXTERNAL message, if not anyway required to do so (see above). When the data sender's IP address is not known, the NI+ MUST NOT include an IP address in the NATFW_DTINFO object. The NI should never receive EXTERNAL messages and MUST silently discard it.
o NSLPイニシエーター：NI+はEXTERNALメッセージだけを生成します。データ送信者のアドレス情報が事前に分かっている場合、上記の理由で必須でない場合でも、NI+はEXTERNALメッセージにNATFW_DTINFOオブジェクトを含められます。データ送信者のIPアドレスが不明な場合、NI+はNATFW_DTINFOオブジェクトにIPアドレスを含めてはなりません (MUST NOT)。NIがEXTERNALメッセージを受信することは想定されていません。受信した場合は、応答せずに破棄しなければなりません (MUST)。
o NSLP forwarder: The NSLP message processing at NFs depends on the middlebox type:
o NSLPフォワーダー：NFでのNSLPメッセージ処理は、ミドルボックスの種類によって異なります。
* NAT: NATs check whether the message is received at the external (public in most cases) address or at the internal (private) address. If received at the external address, an NF MUST generate an error RESPONSE of class 'Protocol error' (3) with response code 'Received EXTERNAL request message on external side' (0x0B). If received at the internal (private address) and the NATFW_EFI object contains the action 'deny', an error RESPONSE of class 'Protocol error' (3) with response code 'Requested rule action not applicable' (0x06) MUST be generated. If received at the internal address, an IP address, and if applicable, one or more ports, are reserved. If the NATFW_EXTERNAL_BINDING object is present in the message, any NAT that is not an edge-NAT MUST include the allocated external IP address, and if applicable one or more ports, (the external binding address) in the NATFW_EXTERNAL_BINDING object. If it is an edge-NAT and there is no edge-firewall beyond, the NSLP message is not forwarded any further and a successful RESPONSE message is generated containing a NATFW_EXTERNAL_IP object holding the translated address, and if applicable, port information from the binding reserved as a result of the EXTERNAL message. The edge-NAT MUST copy the NATFW_EXTERNAL_BINDING object to response message, if the object is included in the EXTERNAL message. The RESPONSE message is sent back towards the NI+. If it is not an edge-NAT, the NSLP message is forwarded further using the translated IP address as signaling source IP address in the LE-MRM and translated port in the NATFW_DTINFO object in the field 'DR port number', i.e., the NATFW_DTINFO object is updated to reflect the translated port number. The edge-NAT or any other NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO object or if the address information within this object is invalid or is not compliant with local policies (e.g., the information provided relates to a range of addresses ('wildcarded') but the edge-NAT requires exact information about DS's IP address and port) with the above mentioned response codes.
* NAT：NATは、メッセージを外部（多くの場合はパブリック）アドレスで受信したか、内部（プライベート）アドレスで受信したかを判定します。外部アドレスで受信した場合、NFはerror classを'Protocol error'（3）、response codeを'Received EXTERNAL request message on external side'（0x0B）とするエラーRESPONSEを生成しなければなりません (MUST)。内部アドレスで受信し、NATFW_EFIオブジェクトのactionが'deny'の場合は、error classを'Protocol error'（3）、response codeを'Requested rule action not applicable'（0x06）とするエラーRESPONSEを生成しなければなりません (MUST)。内部アドレスで受信した場合、IPアドレスと、該当する場合は1つ以上のポートを予約します。メッセージにNATFW_EXTERNAL_BINDINGオブジェクトが含まれている場合、edge-NAT以外の各NATは、割り当てた外部IPアドレスと、該当する場合は1つ以上のポート（外部バインディングアドレス）を同オブジェクトに含めなければなりません (MUST)。edge-NATであり、その先にedge-firewallがない場合、NSLPメッセージはそれ以上転送しません。EXTERNALメッセージによって予約されたバインディングの変換後アドレスと、該当する場合はポート情報を格納したNATFW_EXTERNAL_IPオブジェクトを含む成功RESPONSEメッセージを生成します。EXTERNALメッセージにNATFW_EXTERNAL_BINDINGオブジェクトが含まれている場合、edge-NATはそのオブジェクトをRESPONSEメッセージにコピーしなければなりません (MUST)。RESPONSEメッセージをNI+へ返送します。edge-NATでない場合は、変換後IPアドレスをLE-MRMのシグナリング送信元IPアドレスとして使い、変換後のポート番号をNATFW_DTINFOオブジェクトの'DR port number'フィールドに設定して、NSLPメッセージをさらに転送します。つまり、変換後のポート番号を反映するようNATFW_DTINFOオブジェクトを更新します。edge-NATを含むすべてのNATは、NATFW_DTINFOオブジェクトがないEXTERNALメッセージ、または同オブジェクト内のアドレス情報が無効かローカルポリシーに適合しないEXTERNALメッセージを、前述のresponse codeで拒否しなければなりません (MUST)。たとえば、範囲指定（wildcard）されたアドレスが示されているのに、edge-NATがDSのIPアドレスとポートの正確な情報を要求する場合が該当します。
* Firewall: Non edge-firewalls remember the requested policy rule, keep NATFW NSLP signaling session state, and forward the message. Edge-firewalls stop forwarding the EXTERNAL message. The policy rule is immediately loaded if the action in the NATFW_EFI object is set to 'deny' and the node is an edge-firewall. The policy rule is remembered, but not activated, if the action in the NATFW_EFI object is set to 'allow'. In both cases, a successful RESPONSE message is generated. If the action is 'allow', and the NATFW_DTINFO object is included, and the MRM is set to LE-MRM in the request, additionally a NATFW_EXTERNAL_IP object is included in the RESPONSE message, holding the translated address, and if applicable port, information. This information is obtained from the NATFW_DTINFO object's 'DR port number' and the source-address of the LE-MRM. The edge-firewall MUST copy the NATFW_EXTERNAL_BINDING object to response message, if the object is included in the EXTERNAL message.
* ファイアウォール：edge-firewall以外のファイアウォールは、要求されたポリシールールを記憶し、NATFW NSLPシグナリングセッションの状態を保持して、メッセージを転送します。edge-firewallはEXTERNALメッセージの転送を停止します。edge-firewall上でNATFW_EFIオブジェクトのactionが'deny'の場合は、ポリシールールを直ちに設定します。actionが'allow'の場合は、ルールを記憶しますが有効化しません。どちらの場合も成功RESPONSEメッセージを生成します。actionが'allow'で、NATFW_DTINFOオブジェクトが含まれ、要求内のMRMがLE-MRMの場合は、変換後アドレスと、該当する場合はポート情報を格納したNATFW_EXTERNAL_IPオブジェクトもRESPONSEメッセージに含めます。この情報はNATFW_DTINFOオブジェクトの'DR port number'とLE-MRMのsource-addressから取得します。EXTERNALメッセージにNATFW_EXTERNAL_BINDINGオブジェクトが含まれている場合、edge-firewallはそのオブジェクトをRESPONSEメッセージにコピーしなければなりません (MUST)。
* Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the NAT case.
* NATとファイアウォールの複合装置：両方の機能を持つミドルボックスでの処理は、NATの場合と同じです。
o NSLP receiver: This type of message should never be received by any NR+, and it MUST generate an error RESPONSE message of class 'Permanent failure' (5) with response code 'No edge-device here' (0x06).
o NSLPレスポンダー：この種類のメッセージをNR+が受信することは想定されていません。受信した場合、NR+はerror classを'Permanent failure'（5）、response codeを'No edge-device here'（0x06）とするエラーRESPONSEメッセージを生成しなければなりません (MUST)。
Processing of a RESPONSE message is different for every NSIS node type:
RESPONSEメッセージの処理は、NSISノードの種類ごとに異なります。
o NSLP initiator: Upon receiving a successful RESPONSE message, the NI+ can rely on the requested configuration for future inbound NATFW NSLP signaling sessions. If the response contains a NATFW_EXTERNAL_IP object, the NI can use IP address and port pairs carried for further application signaling. After receiving an error RESPONSE message, the NI+ MAY try to generate the EXTERNAL message again or give up and report the failure to the application, depending on the error condition.
o NSLPイニシエーター：NI+は成功RESPONSEを受信すると、今後の受信NATFW NSLPシグナリングセッションで要求した設定が使われると見込めます。応答にNATFW_EXTERNAL_IPオブジェクトが含まれている場合、NIはそこに格納されたIPアドレスとポートの組を、以降のアプリケーション層シグナリングで使えます。エラーRESPONSEを受信した場合、NI+はエラーの内容に応じて、EXTERNALメッセージを再生成するか、処理を断念して失敗をアプリケーションに通知してもかまいません (MAY)。
o NSLP forwarder: NFs simply forward this message as long as they keep state for the requested reservation, if the RESPONSE message contains NATFW_INFO object with class set to 'Success' (2). If the RESPONSE message contains NATFW_INFO object with class set not to 'Success' (2), the NATFW NSLP signaling session is marked as 'Dead'.
o NSLPフォワーダー：成功（クラスが'Success'（2））のNATFW_INFOオブジェクトを含むRESPONSEメッセージは、要求された予約の状態を維持している限り、NFがそのまま転送します。NATFW_INFOオブジェクトのクラスが'Success'（2）以外の場合、NATFW NSLPシグナリングセッションをDeadとマークします。
o NSIS responder: This type of message should never be received by any NR+. The NF should never receive response messages and MUST silently discard it.
o NSISレスポンダー：NR+がこの種類のメッセージを受信することは想定されていません。NFがRESPONSEメッセージを受信することも想定されていません。受信した場合は、応答せずに破棄しなければなりません (MUST)。
NFs and the NR can also tear down the EXTERNAL session at any time by generating a NOTIFY message with the appropriate response code set.
NFとNRは、適切なresponse codeを設定したNOTIFYメッセージを生成することで、いつでもEXTERNALセッションを終了させることもできます。
Reservations with action 'allow' made with EXTERNAL MUST be enabled by a subsequent CREATE message. A reservation made with EXTERNAL (independent of selected action) is kept alive as long as the NI+ refreshes the particular NATFW NSLP signaling session and it can be reused for multiple, different CREATE messages. An NI+ may decide to tear down a reservation immediately after receiving a CREATE message. This implies that a new NATFW NSLP signaling session must be created for each new CREATE message. The CREATE message does not re-use the NATFW NSLP signaling session created by EXTERNAL.
EXTERNALで行ったaction 'allow'の予約は、後続のCREATEメッセージで有効化しなければなりません (MUST)。actionにかかわらず、EXTERNALで行った予約は、NI+が該当するNATFW NSLPシグナリングセッションを更新している限り維持され、複数の異なるCREATEメッセージで再利用できます。NI+はCREATEメッセージの受信直後に予約を終了させることもできます。その場合、新しいCREATEメッセージごとに新しいNATFW NSLPシグナリングセッションを作成する必要があります。CREATEメッセージは、EXTERNALによって作成されたNATFW NSLPシグナリングセッションを再利用しません。
Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode (see Section 3.7.6) no data traffic will be forwarded to the DR beyond the edge-NAT or edge-firewall. The only function of EXTERNAL is to ensure that subsequent CREATE messages traveling towards the NR will be forwarded across the public-private boundary towards the DR. Correlation of incoming CREATE messages to EXTERNAL reservation states is described in Section 3.8.
プロキシモード（セクション3.7.6参照）のCREATEまたはEXTERNALを使わなければ、edge-NATまたはedge-firewallを越えてDRへデータトラフィックは転送されません（CREATEについてはセクション3.7.1参照）。EXTERNALの唯一の役割は、その後NRへ向かうCREATEメッセージがパブリック／プライベート境界を越えてDRまで転送されるようにすることです。着信CREATEメッセージとEXTERNALの予約状態との照合については、セクション3.8で説明します。
NATFW NSLP signaling sessions are maintained on a soft-state basis. After a specified timeout, sessions and corresponding policy rules are removed automatically by the middlebox, if they are not refreshed. Soft-state is created by CREATE and EXTERNAL and the maintenance of this state must be done by these messages. State created by CREATE must be maintained by CREATE, state created by EXTERNAL must be maintained by EXTERNAL. Refresh messages, are messages carrying the same session ID as the initial message and a NATFW_LT lifetime object with a lifetime greater than zero. Messages with the same SID but which carry a different MRI are treated as updates of the policy rules and are processed as defined in Section 3.10. Every refresh CREATE or EXTERNAL message MUST be acknowledged by an appropriate response message generated by the NR. Upon reception by each NSLP forwarder, the state for the given session ID is extended by the NATFW NSLP signaling session refresh period, a period of time calculated based on a proposed refresh message period. The new (extended) lifetime of a NATFW NSLP signaling session is calculated as current local time plus proposed lifetime value (NATFW NSLP signaling session refresh period). Section 3.4 defines the process of calculating lifetimes in detail.
NATFW NSLPシグナリングセッションはソフトステート方式で維持します。所定のタイムアウトまでに更新されなければ、ミドルボックスがセッションと対応するポリシールールを自動的に削除します。CREATEメッセージとEXTERNALメッセージがソフトステートを作成し、同じ種類のメッセージでその状態を維持します。CREATEで作成した状態はCREATEで、EXTERNALで作成した状態はEXTERNALで維持します。更新メッセージは、最初のメッセージと同じセッションIDを持ち、ゼロより大きい有効期間を含むNATFW_LTオブジェクトを持つメッセージです。同じSIDを持ちながらMRIが異なるメッセージは、ポリシールールの更新として扱い、セクション3.10の定義に従って処理します。更新用のCREATEメッセージまたはEXTERNALメッセージを受信した場合、NRは適切なRESPONSEメッセージを生成して応答しなければなりません (MUST)。各NSLPフォワーダーは、メッセージを受信すると、提案された更新間隔に基づいて計算した期間だけ、該当するセッションIDの状態を延長します。NATFW NSLPシグナリングセッションの新しい有効期間は、現在のローカル時刻に提案された有効期間（NATFW NSLPシグナリングセッションの更新間隔）を加えて計算します。有効期間の計算についてはセクション3.4で詳しく説明します。
NI Public Internet NAT Private address NR
NI Public Internet NAT Private address NR
| | space |
| CREATE[lifetime > 0] | |
|----------------------------->| |
| | |
| | |
| | CREATE[lifetime > 0] |
| |--------------------------->|
| | |
| | RESPONSE[Success/Error] |
| RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| |
| | |
| | |
Figure 16: Successful Refresh Message Flow, CREATE as Example
図16：更新メッセージが成功する場合の流れ（CREATEの例）
Processing of NATFW NSLP signaling session refresh CREATE and EXTERNAL messages is different for every NSIS node type:
NATFW NSLPシグナリングセッションを更新するCREATEメッセージおよびEXTERNALメッセージの処理は、NSISノードの種類ごとに異なります。
o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling session refresh CREATE/EXTERNAL messages before the NATFW NSLP signaling session times out. The rate at which the refresh CREATE/EXTERNAL messages are sent and their relation to the NATFW NSLP signaling session state lifetime is discussed further in Section 3.4.
o NSLPイニシエーター：NIまたはNI+は、NATFW NSLPシグナリングセッションがタイムアウトする前に、更新用のCREATEメッセージまたはEXTERNALメッセージを生成できます。これらのメッセージの送信頻度と、NATFW NSLPシグナリングセッションの状態の有効期間との関係については、セクション3.4で説明します。
o NSLP forwarder: Processing of this message is independent of the middlebox type and is as described in Section 3.4.
o NSLPフォワーダー：このメッセージの処理はミドルボックスの種類に依存せず、セクション3.4の説明に従います。
o NSLP responder: NRs accepting a NATFW NSLP signaling session refresh CREATE/EXTERNAL message generate a successful RESPONSE message, including the granted lifetime value of Section 3.4 in a NATFW_LT object.
o NSLPレスポンダー：NATFW NSLPシグナリングセッションを更新するCREATEメッセージまたはEXTERNALメッセージを受け入れるNRは、セクション3.4で定めた許可有効期間をNATFW_LTオブジェクトに含む成功RESPONSEメッセージを生成します。
NATFW NSLP signaling sessions can be deleted at any time. NSLP initiators can trigger this deletion by using a CREATE or EXTERNAL messages with a lifetime value set to 0, as shown in Figure 17. Whether a CREATE or EXTERNAL message type is use depends on how the NATFW NSLP signaling session was created.
NATFW NSLPシグナリングセッションはいつでも削除できます。図17に示すように、NSLPイニシエーターは有効期間を0に設定したCREATEメッセージまたはEXTERNALメッセージを使ってセッションの削除を開始できます。どちらのメッセージを使うかは、NATFW NSLPシグナリングセッションをどちらで作成したかによります。
NI Public Internet NAT Private address NR
NI Public Internet NAT Private address NR
| | space |
| CREATE[lifetime=0] | |
|----------------------------->| |
| | |
| | CREATE[lifetime=0] |
| |--------------------------->|
| | |
Figure 17: Delete message flow, CREATE as Example
図17：削除メッセージの流れ（CREATEの例）
NSLP nodes receiving this message delete the NATFW NSLP signaling session immediately. Policy rules associated with this particular NATFW NSLP signaling session MUST be also deleted immediately. This message is forwarded until it reaches the final NR. The CREATE/ EXTERNAL message with a lifetime value of 0, does not generate any response, either positive or negative, since there is no NSIS state left at the nodes along the path.
このメッセージを受信したNSLPノードは、NATFW NSLPシグナリングセッションを直ちに削除します。このNATFW NSLPシグナリングセッションに関連するポリシールールも直ちに削除しなければなりません (MUST)。メッセージは最終的なNRに届くまで転送されます。有効期間が0のCREATEメッセージまたはEXTERNALメッセージは、正・負いずれの応答も生成しません。これは、経路上のノードにNSIS状態が残っていないためです。
NSIS initiators can use CREATE/EXTERNAL message with lifetime set to zero in an aggregated way, such that a single CREATE or EXTERNAL message is terminating multiple NATFW NSLP signaling sessions. NIs can follow this procedure if they like to aggregate NATFW NSLP signaling session deletion requests: the NI uses the CREATE or EXTERNAL message with the session ID set to zero and the MRI's source-address set to its used IP address. All other fields of the respective NATFW NSLP signaling sessions to be terminated are set as well; otherwise, these fields are completely wildcarded. The NSLP message is transferred to the NTLP requesting 'explicit routing' as described in Sections 5.2.1 and 7.1.4. in [RFC5971].
NSISイニシエーターは、有効期間を0に設定したCREATEメッセージまたはEXTERNALメッセージを集約して、1つのメッセージで複数のNATFW NSLPシグナリングセッションを終了させることもできます。削除要求を集約する場合、NIはセッションIDを0に設定し、MRIのsource-addressをNI自身が使用するIPアドレスに設定したCREATEメッセージまたはEXTERNALメッセージを使います。終了対象の各NATFW NSLPシグナリングセッションで指定されている他のフィールドも設定します。設定しないフィールドはすべて完全なワイルドカードになります。メッセージは、[RFC5971]のセクション5.2.1および7.1.4で説明されている「explicit routing」を要求してNTLPに渡します。
The outbound NF receiving such an aggregated CREATE or EXTERNAL message MUST reject it with an error RESPONSE of class 'Permanent failure' (5) with response code 'Authentication failed' (0x01) if the authentication fails and with an error RESPONSE of class 'Permanent failure' (5) with response code 'Authorization failed' (0x02) if the authorization fails. Proof of ownership of NATFW NSLP signaling sessions, as it is defined in this memo (see Section 5.2.1), is not possible when using this aggregation for multiple session termination. However, the outbound NF can use the relationship between the information of the received CREATE or EXTERNAL message and the GIST messaging association where the request has been received. The outbound NF MUST only accept this aggregated CREATE or EXTERNAL message through already established GIST messaging associations with the NI. The outbound NF MUST NOT propagate this aggregated CREATE or EXTERNAL message but it MAY generate and forward per NATFW NSLP signaling session CREATE or EXTERNAL messages.
集約されたCREATEメッセージまたはEXTERNALメッセージを受信した送信側NFは、認証に失敗した場合はerror classを'Permanent failure'（5）、response codeを'Authentication failed'（0x01）とし、認可に失敗した場合は同じerror classでresponse codeを'Authorization failed'（0x02）とするエラーRESPONSEを生成して、メッセージを拒否しなければなりません (MUST)。このメモで定義するNATFW NSLPシグナリングセッションの所有証明（セクション5.2.1参照）は、複数セッションの終了にこの集約方式を使う場合にはできません。ただし、送信側NFは、受信したCREATEメッセージまたはEXTERNALメッセージの情報と、要求を受信したGISTメッセージング関連付けとの関係を利用できます。送信側NFは、NIとの確立済みGISTメッセージング関連付けを通じて受信した場合に限り、この集約CREATEメッセージまたはEXTERNALメッセージを受け入れなければなりません (MUST)。送信側NFは、この集約メッセージを伝播してはならず (MUST NOT)、代わりにNATFW NSLPシグナリングセッションごとのCREATEメッセージまたはEXTERNALメッセージを生成して転送してもかまいません (MAY)。
NATFW NSLP forwarders and NATFW NSLP responders must have the ability to report asynchronous events to other NATFW NSLP nodes, especially to allow reporting back to the NATFW NSLP initiator. Such asynchronous events may be premature NATFW NSLP signaling session termination, changes in local policies, route change or any other reason that indicates change of the NATFW NSLP signaling session state.
NATFW NSLPフォワーダーとNATFW NSLPレスポンダーは、他のNATFW NSLPノードに非同期イベントを報告できる必要があります。特に、NATFW NSLPイニシエーターへ報告できることが重要です。非同期イベントには、NATFW NSLPシグナリングセッションの予期しない早期終了、ローカルポリシーの変更、経路変更、その他シグナリングセッションの状態変化を示す事象があります。
NFs and NRs may generate NOTIFY messages upon asynchronous events, with a NATFW_INFO object indicating the reason for event. These reasons can be carried in the NATFW_INFO object (class MUST be set to 'Informational' (1)) within the NOTIFY message. This list shows the response codes and the associated actions to take at NFs and the NI:
NFとNRは非同期イベントが発生したとき、イベントの理由を示すNATFW_INFOオブジェクトを含むNOTIFYメッセージを生成できます。理由はNOTIFYメッセージ内のNATFW_INFOオブジェクトで伝えます。このオブジェクトのclassは'Informational'（1）に設定しなければなりません (MUST)。次の一覧にresponse codeと、NFおよびNIが取る対応を示します。
o 'Route change: Possible route change on the outbound path' (0x01): Follow instructions in Section 3.9. This MUST be sent inbound and outbound, if the signaling session is any state except 'Transitory'. The NOTIFY message for signaling sessions in state Transitory MUST be discarded, as the signaling session is anyhow Transitory. The outbound NOTIFY message MUST be sent with explicit routing by providing the SII-Handle to the NTLP.
o 'Route change: Possible route change on the outbound path' (0x01)：セクション3.9の指示に従います。シグナリングセッションがTransitory以外の状態にある場合、このメッセージを受信方向と送信方向の両方に送信しなければなりません (MUST)。状態がTransitoryのシグナリングセッションに対するNOTIFYメッセージは、セッションがすでにTransitoryであるため破棄しなければなりません (MUST)。送信方向のNOTIFYメッセージは、SII-HandleをNTLPに渡して明示的ルーティングを指定し、送信しなければなりません (MUST)。
o 'Re-authentication required' (0x02): The NI should re-send the authentication. This MUST be sent inbound.
o 'Re-authentication required' (0x02)：NIは認証情報を再送するべきです。メッセージは受信方向に送信しなければなりません (MUST)。
o 'NATFW node is going down soon' (0x03): The NI and other NFs should be prepared for a service interruption at any time. This message MAY be sent inbound and outbound.
o 'NATFW node is going down soon' (0x03)：NIと他のNFは、いつでもサービスが中断する可能性に備える必要があります。このメッセージは受信方向または送信方向に送信してもかまいません (MAY)。
o 'NATFW signaling session lifetime expired' (0x04): The NATFW signaling session has expired and the signaling session is invalid now. NFs MUST mark the signaling session as 'Dead'. This message MAY be sent inbound and outbound.
o 'NATFW signaling session lifetime expired' (0x04)：NATFWシグナリングセッションの有効期間が満了し、セッションは無効になりました。NFはシグナリングセッションをDeadとマークしなければなりません (MUST)。このメッセージは受信方向または送信方向に送信してもかまいません (MAY)。
o 'NATFW signaling session terminated' (0x05): The NATFW signaling session has been terminated for some reason and the signaling session is invalid now. NFs MUST mark the signaling session as 'Dead'. This message MAY be sent inbound and outbound.
o 'NATFW signaling session terminated' (0x05)：何らかの理由でNATFWシグナリングセッションが終了し、セッションは無効になりました。NFはシグナリングセッションをDeadとマークしなければなりません (MUST)。このメッセージは受信方向または送信方向に送信してもかまいません (MAY)。
NOTIFY messages are always sent hop-by-hop inbound towards NI until they reach NI or outbound towards the NR as indicated in the list above.
NOTIFYメッセージは、上記の一覧に示した方向に送られます。NIへ送る場合は受信方向にホップごとに転送し、NRへ送る場合は送信方向に転送します。
The initial processing when receiving a NOTIFY message is the same for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages through already established NTLP messaging associations. The further processing is different for each NATFW NSLP node type and depends on the events notified:
NOTIFYメッセージ受信時の初期処理は、すべてのNATFWノードで共通です。NATFWノードは、確立済みのNTLPメッセージング関連付けを通じて受信したNOTIFYメッセージだけを受け入れなければなりません (MUST)。以降の処理はNATFW NSLPノードの種類と、通知されたイベントに応じて異なります。
o NSLP initiator: NIs analyze the notified event and behave appropriately based on the event type. NIs MUST NOT generate NOTIFY messages.
o NSLPイニシエーター：NIは通知されたイベントを分析し、イベントの種類に応じて適切に対応します。NIはNOTIFYメッセージを生成してはなりません (MUST NOT)。
o NSLP forwarder: NFs analyze the notified event and behave based on the above description per response code. NFs SHOULD generate NOTIFY messages upon asynchronous events and forward them inbound towards the NI or outbound towards the NR, depending on the received direction, i.e., inbound messages MUST be forwarded further inbound and outbound messages MUST be forwarded further outbound. NFs MUST silently discard NOTIFY messages that have been received outbound but are only allowed to be sent inbound, e.g., 'Re-authentication required' (0x02).
o NSLPフォワーダー：NFは通知されたイベントを分析し、前述のresponse codeごとの説明に従って対応します。NFは非同期イベントが発生した場合にNOTIFYメッセージを生成し、受信した方向に応じてNIへ受信方向に、またはNRへ送信方向に転送することが推奨されます (SHOULD)。受信方向で受信したメッセージはさらに受信方向へ転送しなければならず (MUST)、送信方向で受信したメッセージもさらに送信方向へ転送しなければなりません (MUST)。NFは、送信方向で受信したものの受信方向にしか送信できないNOTIFYメッセージ（例：'Re-authentication required'（0x02））を、応答せずに破棄しなければなりません (MUST)。
o NSLP responder: NRs SHOULD generate NOTIFY messages upon asynchronous events including a response code based on the reported event. The NR MUST silently discard NOTIFY messages that have been received outbound but are only allowed to be sent inbound, e.g., 'Re-authentication required' (0x02).
o NSLPレスポンダー：NRは、非同期イベントが発生した場合、通知されたイベントに応じたresponse codeを含むNOTIFYメッセージを生成することが推奨されます (SHOULD)。NRは、送信方向で受信したものの受信方向にしか送信できないNOTIFYメッセージ（例：'Re-authentication required'（0x02））を、応答せずに破棄しなければなりません (MUST)。
NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions at the same time, can experience problems when shutting down service suddenly. This sudden shutdown can be as a result of local node failure, for instance, due to a hardware failure. This NF generates NOTIFY messages for each of the NATFW NSLP signaling sessions and tries to send them inbound. Due to the number of NOTIFY messages to be sent, the shutdown of the node may be unnecessarily prolonged, since not all messages can be sent at the same time. This case can be described as a NOTIFY storm, if a multitude of NATFW NSLP signaling sessions is involved.
複数のNATFW NSLPシグナリングセッションを同時に維持するNFは、サービスを突然停止すると問題が生じることがあります。たとえば、ハードウェア障害などでノードに障害が発生し、突然停止する場合があります。このときNFは各シグナリングセッションについてNOTIFYメッセージを生成し、受信方向へ送信しようとします。大量のNOTIFYメッセージを一度に送信できないため、ノードの停止が不必要に長引くおそれがあります。多数のNATFW NSLPシグナリングセッションが関係するこの状況を、NOTIFY stormと呼ぶことがあります。
To avoid the need for generating per NATFW NSLP signaling session NOTIFY messages in such a scenario described or similar cases, NFs SHOULD follow this procedure: the NF uses the NOTIFY message with the session ID in the NTLP set to zero, with the MRI completely wildcarded, using the 'explicit routing' as described in Sections 5.2.1 and 7.1.4 of [RFC5971]. The inbound NF receiving this type of NOTIFY immediately regards all NATFW NSLP signaling sessions from that peer matching the MRI as void. This message will typically result in multiple NOTIFY messages at the inbound NF, i.e., the NF can generate per terminated NATFW NSLP signaling session a NOTIFY message. However, an NF MAY also aggregate the NOTIFY messages as described here.
このような状況や同様の状況で、NATFW NSLPシグナリングセッションごとにNOTIFYメッセージを生成する必要を避けるため、NFは次の手順に従うことが推奨されます (SHOULD)。NFは、NTLP内のセッションIDを0に設定し、MRIを完全なワイルドカードにしたNOTIFYメッセージを使い、[RFC5971]のセクション5.2.1および7.1.4で説明される「explicit routing」を指定します。この種類のNOTIFYを受信した受信側NFは、その送信元ピアからの、MRIが一致するすべてのNATFW NSLPシグナリングセッションを直ちに無効とみなします。このメッセージを受信したNFは通常、終了させたシグナリングセッションごとにNOTIFYメッセージを生成します。ただし、NFはここで説明する方法でNOTIFYメッセージを集約してもかまいません (MAY)。
Some migration scenarios need specialized support to cope with cases where NSIS is only deployed in some areas of the Internet. End-to-end signaling is going to fail without NSIS support at or near both data sender and data receiver terminals. A proxy mode of operation is needed. This proxy mode of operation must terminate the NATFW NSLP signaling topologically-wise as close as possible to the terminal for which it is proxying and proxy all messages. This NATFW NSLP node doing the proxying of the signaling messages becomes either the NI or the NR for the particular NATFW NSLP signaling session, depending on whether it is the DS or DR that does not support NSIS. Typically, the edge-NAT or the edge-firewall would be used to proxy NATFW NSLP messages.
NSISがインターネットの一部の領域にしか導入されていない状況に対応するには、移行シナリオによっては特別なサポートが必要です。データ送信者とデータ受信者の両端またはその近くでNSISがサポートされていなければ、エンドツーエンドのシグナリングは失敗します。そのため、プロキシ動作モードが必要です。このモードでは、代理する端末にトポロジー上できるだけ近い位置でNATFW NSLPシグナリングを終端し、すべてのメッセージを代理しなければなりません。シグナリングメッセージを代理するNATFW NSLPノードは、NSIS非対応なのがDSかDRかに応じて、当該セッションのNIまたはNRになります。通常はedge-NATまたはedge-firewallがNATFW NSLPメッセージを代理します。
This proxy mode operation does not require any new CREATE or EXTERNAL message type, but relies on extended CREATE and EXTERNAL message types. They are called, respectively, CREATE-PROXY and EXTERNAL-PROXY and are distinguished by setting the P flag in the NSLP header to P=1. This flag instructs edge-NATs and edge-firewalls receiving them to operate in proxy mode for the NATFW NSLP signaling session in question. The semantics of the CREATE and EXTERNAL message types are not changed and the behavior of the various node types is as defined in Sections 3.7.1 and 3.7.2, except for the proxying node. The following paragraphs describe the proxy mode operation for data receivers behind middleboxes and data senders behind middleboxes.
このプロキシ動作モードでは、新しい種類のCREATEメッセージやEXTERNALメッセージを追加せず、拡張されたメッセージ形式を使います。これらをそれぞれCREATE-PROXY、EXTERNAL-PROXYと呼び、NSLPヘッダーのPフラグをP=1に設定して区別します。このフラグは、受信したedge-NATおよびedge-firewallに、該当するNATFW NSLPシグナリングセッションをプロキシモードで処理するよう指示します。CREATEおよびEXTERNALメッセージの意味は変わりません。プロキシノードを除く各ノードの動作は、セクション3.7.1および3.7.2で定義したとおりです。以下では、ミドルボックスの背後にいるデータ受信者とデータ送信者に対するプロキシ動作を説明します。
The NATFW NSLP gives the NR the ability to install state on the inbound path towards the data sender for outbound data packets, even when only the receiving side is running NSIS (as shown in Figure 18). The goal of the method described is to trigger the edge-NAT/ edge-firewall to generate a CREATE message on behalf of the data receiver. In this case, an NR can signal towards the network border as it is performed in the standard EXTERNAL message handling scenario as in Section 3.7.2. The message is forwarded until the edge-NAT/ edge-firewall is reached. A public IP address and port number is reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike the standard EXTERNAL message handling case, the edge-NAT/ edge-firewall is triggered to send a CREATE message on a new reverse path that traverse several firewalls or NATs. The new reverse path for CREATE is necessary to handle routing asymmetries between the edge-NAT/edge-firewall and the DR. It must be stressed that the semantics of the CREATE and EXTERNAL messages are not changed, i.e., each is processed as described earlier.
NATFW NSLPでは、受信側だけがNSISを実行している場合でも、NRがデータ送信者への受信経路上に状態を設定し、送信データパケットを通過させられます（図18参照）。この方法では、edge-NATまたはedge-firewallを起動し、データ受信者に代わってCREATEメッセージを生成させます。この場合、NRはセクション3.7.2で説明した標準的なEXTERNALメッセージ処理と同じように、ネットワーク境界に向けてシグナリングできます。メッセージはedge-NATまたはedge-firewallまで転送されます。edge-NATまたはedge-firewallでパブリックIPアドレスとポート番号が予約されます。図18に示す標準的なEXTERNAL処理とは異なり、edge-NATまたはedge-firewallは、複数のファイアウォールやNATを通る新たな逆方向経路でCREATEメッセージを送信するよう起動されます。このCREATE用の逆方向経路は、edge-NATまたはedge-firewallとDRの間にある経路の非対称性に対処するために必要です。CREATEおよびEXTERNALメッセージの意味は変わらず、それぞれ前述のとおりに処理される点に注意してください。
DS Public Internet NAT/FW Private address DR
No NI NF space NR
NR+ NI+
| | EXTERNAL-PROXY[(DTInfo)] |
| |<------------------------- |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | CREATE |
| | ------------------------> |
| | RESPONSE[Error/Success] |
| | <---------------------- |
| | |
Figure 18: EXTERNAL Triggering Sending of CREATE Message
図18：EXTERNALによるCREATEメッセージ送信の起動
A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is used to build the relationship between received CREATEs at the message initiator. An NI+ uses the presence of the NATFW_NONCE object to correlate it to the particular EXTERNAL-PROXY. The absence of a NONCE object indicates a CREATE initiated by the DS and not by the edge-NAT. The two signaling sessions, i.e., the session for EXTERNAL-PROXY and the session for CREATE, are not independent. The primary session is the EXTERNAL-PROXY session. The CREATE session is secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is valid as long as the EXTERNAL-PROXY session is the signaling states 'Established' or 'Transitory'. There is no CREATE session in any other signaling state of the EXTERNAL-PROXY, i.e., 'Pending' or 'Dead'. This ensures fate-sharing between the two signaling sessions.
EXTERNALメッセージとCREATEメッセージで伝送するNATFW_NONCEオブジェクトを使い、メッセージ開始側で受信したCREATEメッセージを、対応するセッションと関連付けます。NI+はNATFW_NONCEオブジェクトの有無によって、CREATEメッセージを特定のEXTERNAL-PROXYと関連付けます。NONCEオブジェクトがなければ、そのCREATEメッセージはedge-NATではなくDSが開始したものです。EXTERNAL-PROXYセッションとCREATEセッションという2つのシグナリングセッションは独立していません。EXTERNAL-PROXYセッションが主セッションであり、CREATEセッションはそれに従属します。EXTERNAL-PROXYセッションの状態がEstablishedまたはTransitoryである間に限り、CREATEセッションは有効です。EXTERNAL-PROXYセッションがPendingまたはDeadなど他の状態なら、CREATEセッションは存在しません。これにより、2つのシグナリングセッションの存続期間を連動させます。
These processing rules of EXTERNAL-PROXY messages are added to the regular EXTERNAL processing: o NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value of the EXTERNAL-PROXY session as the nonce value of the NATFW_NONCE object.
EXTERNAL-PROXYメッセージには、通常のEXTERNAL処理に次の規則が追加されます。o NSLPイニシエーター（NI+）：NI+は、EXTERNAL-PROXYセッションのセッションID（SID）の値を、NATFW_NONCEオブジェクトのnonce値として設定しなければなりません (MUST)。
o NSLP forwarder being either edge-NAT or edge-firewall: When the NF accepts an EXTERNAL-PROXY message, it generates a successful RESPONSE message as if it were the NR, and it generates a CREATE message as defined in Section 3.7.1 and includes a NATFW_NONCE object having the same value as of the received NATFW_NONCE object. The NF MUST NOT generate a CREATE-PROXY message. The NF MUST refresh the CREATE message signaling session only if an EXTERNAL-PROXY refresh message has been received first. This also includes tearing down signaling sessions, i.e., the NF must tear down the CREATE signaling session only if an EXTERNAL-PROXY message with lifetime set to 0 has been received first.
o NSLPフォワーダーがedge-NATまたはedge-firewallである場合：NFがEXTERNAL-PROXYメッセージを受け入れると、NRとして成功RESPONSEメッセージを生成します。また、セクション3.7.1で定義したCREATEメッセージを生成し、受信したNATFW_NONCEオブジェクトと同じ値のNATFW_NONCEオブジェクトを含めます。NFはCREATE-PROXYメッセージを生成してはなりません (MUST NOT)。先にEXTERNAL-PROXYの更新メッセージを受信した場合に限り、NFはCREATEシグナリングセッションを更新しなければなりません (MUST)。シグナリングセッションの終了も同様です。つまり、先に有効期間を0に設定したEXTERNAL-PROXYメッセージを受信した場合に限り、NFはCREATEシグナリングセッションを終了します。
The scenario described in this section challenges the data receiver because it must make a correct assumption about the data sender's ability to use NSIS NATFW NSLP signaling. It is possible for the DR to make the wrong assumption in two different ways:
この節のシナリオでは、データ送信者がNSIS NATFW NSLPシグナリングを利用できるかどうかをデータ受信者が正しく判断する必要があり、DRにとって課題となります。DRは次の2通りの誤った判断をする可能性があります。
a) the DS is NSIS unaware but the DR assumes the DS to be NSIS aware, and
a) DSはNSIS非対応だが、DRはDSがNSIS対応だと判断する。
b) the DS is NSIS aware but the DR assumes the DS to be NSIS unaware.
b) DSはNSIS対応だが、DRはDSがNSIS非対応だと判断する。
Case a) will result in middleboxes blocking the data traffic, since the DS will never send the expected CREATE message. Case b) will result in the DR successfully requesting proxy mode support by the edge-NAT or edge-firewall. The edge-NAT/edge-firewall will send CREATE messages and DS will send CREATE messages as well. Both CREATE messages are handled as separated NATFW NSLP signaling sessions and therefore the common rules per NATFW NSLP signaling session apply; the NATFW_NONCE object is used to differentiate CREATE messages generated by the edge-NAT/edge-firewall from the NI-initiated CREATE messages. It is the NR's responsibility to decide whether to tear down the EXTERNAL-PROXY signaling sessions in the case where the data sender's side is NSIS aware, but was incorrectly assumed not to be so by the DR. It is RECOMMENDED that a DR behind NATs use the proxy mode of operation by default, unless the DR knows that the DS is NSIS aware. The DR MAY cache information about data senders that it has found to be NSIS aware in past NATFW NSLP signaling sessions.
ケースa)では、DSが想定されたCREATEメッセージを送信しないため、ミドルボックスがデータトラフィックを遮断します。ケースb)では、DRがedge-NATまたはedge-firewallにプロキシモードのサポートを要求し、要求は成功します。edge-NATまたはedge-firewallとDSの両方がCREATEメッセージを送信します。2つのCREATEメッセージは別々のNATFW NSLPシグナリングセッションとして扱い、各セッションに共通の規則を適用します。NATFW_NONCEオブジェクトを使って、edge-NATまたはedge-firewallが生成したCREATEメッセージと、NIが開始したCREATEメッセージを区別します。データ送信者側がNSIS対応であるのにDRが誤って非対応と判断した場合、EXTERNAL-PROXYシグナリングセッションを終了するかどうかはNRが決定します。DRがDSのNSIS対応を把握していない限り、NATの背後にあるDRは既定でプロキシ動作モードを使うことが推奨されます (SHOULD)。DRは、過去のNATFW NSLPシグナリングセッションでNSIS対応と判明したデータ送信者の情報をキャッシュしてもかまいません (MAY)。
There is a possible race condition between the RESPONSE message to the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT. The CREATE message can arrive earlier than the RESPONSE message. An NI+ MUST accept CREATE messages generated by the edge-NAT even if the RESPONSE message to the EXTERNAL-PROXY was not received.
EXTERNAL-PROXYへのRESPONSEメッセージと、edge-NATが生成するCREATEメッセージとの間で競合状態が起きる可能性があります。CREATEメッセージがRESPONSEメッセージより先に届く場合があります。NI+は、EXTERNAL-PROXYへのRESPONSEメッセージをまだ受信していなくても、edge-NATが生成したCREATEメッセージを受け入れなければなりません (MUST)。
As with data receivers behind middleboxes, data senders behind middleboxes can require proxy mode support. The issue here is that there is no NSIS support at the data receiver's side and, by default, there will be no response to CREATE messages. This scenario requires the last NSIS NATFW NSLP-aware node to terminate the forwarding and to proxy the response to the CREATE message, meaning that this node is generating RESPONSE messages. This last node may be an edge-NAT/ edge-firewall, or any other NATFW NSLP peer, that detects that there is no NR available (probably as a result of GIST timeouts but there may be other triggers).
データ受信者がミドルボックスの背後にいる場合と同様に、データ送信者がミドルボックスの背後にいる場合にもプロキシモードが必要になることがあります。この場合、データ受信者側にNSISがなく、既定ではCREATEメッセージへの応答がありません。そのため、最後のNSIS対応NATFW NSLPノードが転送を終端し、CREATEメッセージへの応答を代理する必要があります。つまり、このノードがRESPONSEメッセージを生成します。この最後のノードはedge-NAT、edge-firewall、またはNRが存在しないことを検出した他のNATFW NSLPピアです。NRが存在しないことは、おそらくGISTのタイムアウトで検出しますが、他の契機もありえます。
DS Private Address NAT/FW Public Internet NR
NI Space NF no NR
| | |
| CREATE-PROXY | |
|------------------------------>| |
| | |
| RESPONSE[SUCCESS/ERROR] | |
|<------------------------------| |
| | |
Figure 19: Proxy Mode CREATE Message Flow
図19：プロキシモードのCREATEメッセージフロー
The processing of CREATE-PROXY messages and RESPONSE messages is similar to Section 3.7.1, except that forwarding is stopped at the edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to NI according to the situation (error/success) and will be the NR for future NATFW NSLP communication.
CREATE-PROXYメッセージとRESPONSEメッセージの処理は、edge-NATまたはedge-firewallで転送を止める点を除き、セクション3.7.1と同様です。edge-NATまたはedge-firewallは、状況（成功またはエラー）に応じたRESPONSEをNIへ返します。また、その後のNATFW NSLP通信ではNRの役割を担います。
The NI can choose the proxy mode of operation although the DR is NSIS aware. The CREATE-PROXY mode would not configure all NATs and firewalls along the data path, since it is terminated at the edge-device. Any device beyond this point will never receive any NATFW NSLP signaling for this flow.
DRがNSIS対応であっても、NIはプロキシ動作モードを選べます。CREATE-PROXYはedge装置で終端するため、データパス上のすべてのNATやファイアウォールを設定するわけではありません。この地点より先の装置は、このフローに関するNATFW NSLPシグナリングを受信しません。
The above sections described the proxy mode for cases where the NATFW NSLP is solely deployed at the network edges. However, the NATFW NSLP might be incrementally deployed first in some network edges, but later on also in other parts of the network. Using the proxy mode only would prevent the NI from determining whether the other parts of the network have also been upgraded to use the NATFW NSLP. One way of determining whether the path from the NI to the NR is NATFW-NSLP-capable is to use the regular CREATE message and to wait for a successful response or an error response. This will lead to extra messages being sent, as a CREATE message, in addition to the CREATE-PROXY message (which is required anyhow), is sent from the NI.
前の各節では、NATFW NSLPがネットワークのedgeだけに導入されている場合のプロキシモードを説明しました。NATFW NSLPは、まず一部のネットワークedgeに導入し、後からネットワークの他の部分にも段階的に導入することがあります。プロキシモードだけを使うと、ネットワークの他の部分もNATFW NSLPに対応済みかどうかをNIが判断できません。NIからNRまでの経路がNATFW NSLPに対応しているかを確認する方法の1つは、通常のCREATEメッセージを使い、成功またはエラーのRESPONSEを待つことです。この方法ではNIからCREATE-PROXYに加えて通常のCREATEも送るため、メッセージ数が増えます。CREATE-PROXYはどちらにしても必要です。
The NATFW NSLP allows the usage of the proxy-mode and a further probing of the path by the edge-NAT or edge-firewall. The NI can request proxy-mode handling as described, and can set the E flag (see Figure 20) to request the edge-NAT or edge-firewall to probe the further path for NATFW NSLP enabled NFs or an NR.
NATFW NSLPでは、プロキシモードを使いながらedge-NATまたはedge-firewallに経路の先を調査させることができます。NIは前述のとおりプロキシモードでの処理を要求し、Eフラグ（図20参照）を設定して、edge-NATまたはedge-firewallに経路の先にあるNATFW NSLP対応のNFまたはNRを調べるよう要求できます。
The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY or EXTERNAL-proxy towards the NR, if the received proxy-mode message has the E flag set, in addition to the regular proxy mode handling. The edge-NAT or edge-firewall relies on NTLP measures to determine whether or not there is another NATFW NSLP reachable towards the NR. A failed attempt to forward the request message to the NR will be silently discarded. A successful attempt of forwarding the request message to the NR will be acknowledged by the NR with a successful response message, which is subject to the regular behavior described in the proxy-mode sections.
通常のプロキシ処理に加えて、受信したプロキシモードメッセージのEフラグが設定されている場合、edge-NATまたはedge-firewallはCREATE-PROXYまたはEXTERNAL-proxyをNRへ送り続けなければなりません (MUST)。edge-NATまたはedge-firewallはNTLPの機能を使い、NRの方向に到達可能な別のNATFW NSLPノードがあるかどうかを判断します。要求メッセージをNRへ転送できなかった場合は、何も通知せず破棄します。転送に成功した場合は、NRが成功RESPONSEメッセージで応答します。その後の処理には、プロキシモードの各節で説明した通常の動作が適用されます。
The proxy mode assumes that the edge-NAT or edge-firewall are properly configured by network operator, i.e., the edge-device is really the final NAT or firewall of that particular network. There is currently no known way of letting the NATFW NSLP automatically detect which of the NAT or firewalls are the actual edge of a network. Therefore, it is important for the network operator to configure the edge-NAT or edge-firewall and also to re-configure these devices if they are not at the edge anymore. For instance, an edge-NAT is located within an ISP and the ISP chooses to place another NAT in front of this edge-NAT. In this case, the ISP needs to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to configure the newly installed NAT to be the edge-NAT.
プロキシモードでは、ネットワーク運用者がedge-NATまたはedge-firewallを適切に設定し、その装置が当該ネットワークの最終段にあるNATまたはファイアウォールであることを前提とします。NATFW NSLPが、どの装置がネットワークの実際のedgeかを自動的に検出する方法は、現在知られていません。そのため、ネットワーク運用者がedge-NATまたはedge-firewallを設定し、それらがedgeではなくなった場合には再設定することが重要です。たとえば、ISP内にあるedge-NATの前段にISPが別のNATを配置する場合があります。この場合、ISPは従来のedge-NATを通常のNATFW NSLP NATとして再設定し、新しく導入したNATをedge-NATとして設定する必要があります。
Section 3.7.2 describes how NSIS nodes behind NATs can obtain a publicly reachable IP address and port number at a NAT and how the resulting mapping rule can be activated by using CREATE messages (see Section 3.7.1). The information about the public IP address/port number can be transmitted via an application-level signaling protocol and/or third party to the communication partner that would like to send data toward the host behind the NAT. However, NSIS signaling flows are sent towards the address of the NAT at which this particular IP address and port number is allocated and not directly to the allocated IP address and port number. The NATFW NSLP forwarder at this NAT needs to know how the incoming NSLP CREATE messages are related to reserved addresses, meaning how to demultiplex incoming NSIS CREATE messages.
セクション3.7.2では、NATの背後にあるNSISノードがNATで外部から到達可能なIPアドレスとポート番号を取得する方法と、CREATEメッセージを使って対応するマッピングルールを有効化する方法（セクション3.7.1参照）を説明しました。パブリックIPアドレスとポート番号の情報は、NATの背後のホストへデータを送信する通信相手に、アプリケーション層のシグナリングプロトコルまたは第三者を通じて伝えられます。しかしNSISシグナリングフローは、割り当てられたIPアドレスとポート番号へ直接送られるのではなく、それらを割り当てたNATのアドレスへ送られます。このNAT上のNATFW NSLPフォワーダーは、着信したNSLP CREATEメッセージと予約済みアドレスとの対応関係、つまり着信するNSIS CREATEメッセージの多重分離方法を把握する必要があります。
The demultiplexing method uses information stored at the local NATFW NSLP node and in the policy rule. The policy rule uses the LE-MRM MRI source-address (see [RFC5971]) as the flow destination IP address and the network-layer-version (IP-ver) as IP version. The external IP address at the NAT is stored as the external flow destination IP address. All other parameters of the policy rule other than the flow destination IP address are wildcarded if no NATFW_DTINFO object is included in the EXTERNAL message. The LE-MRM MRI destination-address MUST NOT be used in the policy rule, since it is solely a signaling destination address.
多重分離には、ローカルのNATFW NSLPノードとポリシールールに保存された情報を使います。ポリシールールでは、LE-MRM MRIのsource-address（[RFC5971]参照）をフロー宛先IPアドレスとして、network-layer-version（IP-ver）をIPバージョンとして使います。NATの外部IPアドレスは、外部フロー宛先IPアドレスとして保存します。EXTERNALメッセージにNATFW_DTINFOオブジェクトが含まれていない場合、フロー宛先IPアドレス以外のポリシールールのパラメーターはすべてワイルドカードにします。LE-MRM MRIのdestination-addressはシグナリング宛先アドレスにすぎないため、ポリシールールで使ってはなりません (MUST NOT)。
If the NATFW_DTINFO object is included in the EXTERNAL message, the policy rule is filled with further information. The 'dst port number' field of the NATFW_DTINFO is stored as the flow destination port number. The 'protocol' field is stored as the flow protocol. The 'src port number' field is stored as the flow source port number. The 'data sender's IPv4 address' is stored as the flow source IP address. Note that some of these fields can contain wildcards.
EXTERNALメッセージにNATFW_DTINFOオブジェクトが含まれる場合、ポリシールールに次の情報も設定します。NATFW_DTINFOの'dst port number'フィールドはフロー宛先ポート番号として、'protocol'フィールドはフロープロトコルとして、'src port number'フィールドはフロー送信元ポート番号として保存します。また、'data sender's IPv4 address'はフロー送信元IPアドレスとして保存します。これらのフィールドの一部はワイルドカードの場合があります。
When receiving a CREATE message at the NATFW NSLP, the NATFW NSLP uses the flow information stored in the MRI to do the matching process. This table shows the parameters to be compared against each other. Note that not all parameters need be present in an MRI at the same time.
NATFW NSLPノードはCREATEメッセージを受信すると、MRIに格納されたフロー情報を使って照合します。次の表に相互に照合するパラメーターを示します。すべてのパラメーターが同時にMRIに存在するとは限りません。
+-------------------------------+--------------------------------+
| Flow parameter (Policy Rule) | MRI parameter (CREATE message) |
+-------------------------------+--------------------------------+
| IP version | network-layer-version |
| Protocol | IP-protocol |
| source IP address (w) | source-address (w) |
| external IP address | destination-address |
| destination IP address (n/u) | N/A |
| source port number (w) | L4-source-port (w) |
| external port number (w) | L4-destination-port (w) |
| destination port number (n/u) | N/A |
| IPsec-SPI | ipsec-SPI |
+-------------------------------+--------------------------------+
Table entries marked with (w) can be wildcarded and entries marked with (n/u) are not used for the matching.
(w)を付した表の項目はワイルドカードにできます。(n/u)を付した項目は照合に使いません。
Table 1
Table 1
It should be noted that the Protocol/IP-protocol entries in Table 1 refer to the 'Protocol' field in the IPv4 header or the 'next header' entry in the IPv6 header.
表1のProtocol／IP-protocol項目は、IPv4ヘッダーの'Protocol'フィールドまたはIPv6ヘッダーの'Next Header'項目を指す点に注意してください。
The NATFW NSLP needs to react to route changes in the data path. This assumes the capability to detect route changes, to perform NAT and firewall configuration on the new path and possibly to tear down NATFW NSLP signaling session state on the old path. The detection of route changes is described in Section 7 of [RFC5971], and the NATFW NSLP relies on notifications about route changes by the NTLP. This notification will be conveyed by the API between NTLP and NSLP, which is out of the scope of this memo.
NATFW NSLPは、データパス上の経路変更に対応する必要があります。そのため、経路変更を検出し、新しい経路上でNATおよびファイアウォールを設定し、必要に応じて古い経路上のNATFW NSLPシグナリングセッションの状態を削除する機能が前提となります。経路変更の検出については[RFC5971]のセクション7で説明されています。NATFW NSLPはNTLPから経路変更の通知を受け取ります。この通知はNTLPとNSLPの間のAPIを通じて伝達されますが、そのAPIは本メモの範囲外です。
A NATFW NSLP node other than the NI or NI+ detecting a route change, by means described in the NTLP specification or others, generates a NOTIFY message indicating this change and sends this inbound towards NI and outbound towards the NR (see also Section 3.7.5). Intermediate NFs on the way to the NI can use this information to decide later if their NATFW NSLP signaling session can be deleted locally, if they do not receive an update within a certain time period, as described in Section 3.2.8. It is important to consider the transport limitations of NOTIFY messages as mandated in Section 3.7.5.
NIまたはNI+以外のNATFW NSLPノードが、NTLP仕様などで定められた方法で経路変更を検出した場合、その変更を示すNOTIFYメッセージを生成し、NIへ受信方向に、NRへ送信方向に送ります（セクション3.7.5参照）。NIへ向かう経路上の中間NFはこの通知を使い、セクション3.2.8で説明したとおり、一定時間内に更新を受信しなければシグナリングセッションの状態をローカルで削除できるか、後で判断します。セクション3.7.5で定められたNOTIFYメッセージの転送制限を考慮することが重要です。
The NI receiving this NOTIFY message MAY generate a new CREATE or EXTERNAL message and send it towards the NATFW NSLP signaling session's NI as for the initial message using the same session ID.
このNOTIFYメッセージを受信したNIは、新しいCREATEメッセージまたはEXTERNALメッセージを生成し、最初のメッセージと同様に、同じセッションIDを使って該当するNATFW NSLPシグナリングセッションのNIへ送ってもかまいません (MAY)。
All the remaining processing and message forwarding, such as NSLP next-hop discovery, is subject to regular NSLP processing as described in the particular sections. Normal routing will guide the new CREATE or EXTERNAL message to the correct NFs along the changed route. NFs that were on the original path receiving these new CREATE or EXTERNAL messages (see also Section 3.10), can use the session ID to update the existing NATFW NSLP signaling session; whereas NFs that were not on the original path will create new state for this NATFW NSLP signaling session. The next section describes how policy rules are updated.
次ホップとなるNSLPノードの検出など、以降の処理とメッセージ転送は、各節で説明する通常のNSLP処理に従います。通常のルーティングにより、新しいCREATEメッセージまたはEXTERNALメッセージは、変更後の経路上にある正しいNFへ届きます。元の経路にあったNFがこれらのメッセージを受信した場合（セクション3.10参照）、セッションIDを使って既存のNATFW NSLPシグナリングセッションを更新できます。一方、元の経路になかったNFは、このセッションの新しい状態を作成します。ポリシールールの更新方法については次の節で説明します。
NSIS initiators can request an update of the installed/reserved policy rules at any time within a NATFW NSLP signaling session. Updates to policy rules can be required due to node mobility (NI is moving from one IP address to another), route changes (this can result in a different NAT mapping at a different NAT device), or the wish of the NI to simply change the rule. NIs can update policy rules in existing NATFW NSLP signaling sessions by sending an appropriate CREATE or EXTERNAL message (similar to Section 3.4) with modified message routing information (MRI) as compared with that installed previously, but using the existing session ID to identify the intended target of the update. With respect to authorization and authentication, this update CREATE or EXTERNAL message is treated in exactly the same way as any initial message. Therefore, any node along in the NATFW NSLP signaling session can reject the update with an error RESPONSE message, as defined in the previous sections.
NSISイニシエーターは、NATFW NSLPシグナリングセッション内であればいつでも、設定済みまたは予約済みのポリシールールの更新を要求できます。ノードの移動（NIがあるIPアドレスから別のIPアドレスへ移る）、経路変更（別のNAT装置で異なるNATマッピングが生じる場合があります）、またはNIがルールを変更したい場合などに、ポリシールールを更新することがあります。NIは、以前に設定したものと異なるメッセージルーティング情報（MRI）を持つCREATEメッセージまたはEXTERNALメッセージ（セクション3.4と同様）を送信し、既存のセッションIDで更新対象を識別することで、既存セッションのポリシールールを更新できます。認証と認可については、この更新メッセージも最初のメッセージとまったく同じように扱います。そのため、前述の節で定義したとおり、NATFW NSLPシグナリングセッション上の任意のノードがエラーRESPONSEメッセージで更新を拒否できます。
The message processing and forwarding is executed as defined in the particular sections. An NF or the NR receiving an update simply replaces the installed policy rules installed in the firewall/NAT. The local procedures on how to update the MRI in the firewall/NAT is out of the scope of this memo.
メッセージの処理と転送は各節で定義したとおりに行います。更新を受信したNFまたはNRは、ファイアウォールまたはNATに設定済みのポリシールールを更新後のルールに置き換えます。ファイアウォールまたはNAT内でMRIを更新する手順は、本メモの範囲外です。
A NATFW NSLP message consists of an NSLP header and one or more objects following the header. The NSLP header is carried in all NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded using big endian (network ordered) binary data representations. Header and objects are aligned to 32-bit boundaries and object lengths that are not multiples of 32 bits must be padded to the next higher 32-bit multiple.
NATFW NSLPメッセージは、NSLPヘッダーと、その後に続く1つ以上のオブジェクトから成ります。すべてのNATFW NSLPメッセージにNSLPヘッダーが含まれます。オブジェクトは、ビッグエンディアン（ネットワークバイト順）のバイナリ表現を使ったType-Length-Value（TLV）形式で符号化されます。ヘッダーとオブジェクトは32ビット境界に揃えます。オブジェクト長が32ビットの倍数でない場合は、次の大きい32ビットの倍数になるまでパディングしなければなりません。
The whole NSLP message is carried as payload of a NTLP message.
NSLPメッセージ全体は、NTLPメッセージのペイロードとして伝送されます。
Note that the notation 0x is used to indicate hexadecimal numbers.
0xという表記は、16進数を示します。
All GIST NSLP-Data objects for the NATFW NSLP MUST contain this common header as the first 32 bits of the object (this is not the same as the GIST Common Header). It contains two fields, the NSLP message type and the P Flag, plus two reserved fields. The total length is 32 bits. The layout of the NSLP header is defined by Figure 20.
NATFW NSLP用のすべてのGIST NSLP-Dataオブジェクトは、先頭の32ビットにこの共通ヘッダーを含まなければなりません (MUST)。これはGIST Common Headerとは別のものです。ヘッダーにはNSLPメッセージタイプとPフラグの2つのフィールド、および予約済みフィールドが2つあります。全長は32ビットです。NSLPヘッダーの配置を図20に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type |P|E| reserved | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Common NSLP Header
図20：共通NSLPヘッダー
The reserved field MUST be set to zero in the NATFW NSLP header before sending and MUST be ignored during processing of the header.
送信前にNATFW NSLPヘッダーの予約済みフィールドを0に設定しなければならず (MUST)、ヘッダーの処理時にはその値を無視しなければなりません (MUST)。
The defined messages types are:
定義されているメッセージタイプは次のとおりです。
o 0x1: CREATE
o 0x1: CREATE
o 0x2: EXTERNAL
o 0x2: EXTERNAL
o 0x3: RESPONSE
o 0x3: RESPONSE
o 0x4: NOTIFY
o 0x4: NOTIFY
If a message with another type is received, an error RESPONSE of class 'Protocol error' (3) with response code 'Illegal message type' (0x01) MUST be generated.
他の種類のメッセージを受信した場合は、error classを'Protocol error'（3）、response codeを'Illegal message type'（0x01）とするエラーRESPONSEを生成しなければなりません (MUST)。
The P flag indicates the usage of proxy mode. If the proxy mode is used, it MUST be set to 1. Proxy mode MUST only be used in combination with the message types CREATE and EXTERNAL. The P flag MUST be ignored when processing messages with type RESPONSE or NOTIFY.
Pフラグはプロキシモードの使用を示します。プロキシモードを使う場合、Pフラグを1に設定しなければなりません (MUST)。プロキシモードはCREATEまたはEXTERNALメッセージとの組み合わせでのみ使わなければなりません (MUST)。RESPONSEまたはNOTIFYメッセージを処理する際は、Pフラグを無視しなければなりません (MUST)。
The E flag indicates, in proxy mode, whether the edge-NAT or edge-firewall MUST continue sending the message to the NR, i.e., end-to-end. The E flag can only be set to 1 if the P flag is set; otherwise, it MUST be ignored. The E flag MUST only be used in combination with the message types CREATE and EXTERNAL. The E flag MUST be ignored when processing messages with type RESPONSE or NOTIFY.
プロキシモードでは、Eフラグは、edge-NATまたはedge-firewallがNRまで（エンドツーエンドで）メッセージを転送し続けなければならない (MUST)かを示します。Eフラグを1に設定できるのはPフラグが設定されている場合だけです。それ以外の場合はEフラグを無視しなければなりません (MUST)。EフラグはCREATEまたはEXTERNALメッセージとの組み合わせでのみ使わなければなりません (MUST)。RESPONSEまたはNOTIFYメッセージを処理する際は、Eフラグを無視しなければなりません (MUST)。
NATFW NSLP objects use a common header format defined by Figure 21. The object header contains these fields: two flags, two reserved bits, the NSLP object type, a reserved field of 4 bits, and the object length. Its total length is 32 bits.
NATFW NSLPオブジェクトは、図21で定義する共通ヘッダー形式を使います。オブジェクトヘッダーには、2つのフラグ、2つの予約ビット、NSLPオブジェクトタイプ、4ビットの予約フィールド、およびオブジェクト長の各フィールドがあります。全長は32ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Object Type |r|r|r|r| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Common NSLP Object Header
図21：共通NSLPオブジェクトヘッダー
The object length field contains the total length of the object without the object header. The unit is a word, consisting of 4 octets. The particular values of type and length for each NSLP object are listed in the subsequent sections that define the NSLP objects. An error RESPONSE of class 'Protocol error' (3) with response code 'Wrong object length' (0x07) MUST be generated if the length given in the object header is inconsistent with the type of object specified or the message is shorter than implied by the object length. The two leading bits of the NSLP object header are used to signal the desired treatment for objects whose treatment has not been defined in this memo (see [RFC5971], Appendix A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses a subset of the categories defined in GIST:
オブジェクト長フィールドには、オブジェクトヘッダーを除いたオブジェクト全体の長さが格納されます。単位は4オクテットから成るワードです。各NSLPオブジェクトのタイプと長さの値は、オブジェクトを定義する後続の節に示します。オブジェクトヘッダーの長さがオブジェクトタイプに適合しない場合、またはメッセージ長がオブジェクト長から示される長さより短い場合は、error classを'Protocol error'（3）、response codeを'Wrong object length'（0x07）とするエラーRESPONSEを生成しなければなりません (MUST)。NSLPオブジェクトヘッダーの先頭2ビットは、本メモで処理方法を定義していないオブジェクト（つまり未定義のオブジェクトタイプ）の扱いを指定します（[RFC5971]の付録A.2.1参照）。NATFW NSLPはGISTで定義されるカテゴリの一部を使用します。
o AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected with an error RESPONSE of class 'Protocol error' (3) with response code 'Unknown object present' (0x06).
o AB=00（'Mandatory'）：オブジェクトを解釈できない場合、そのオブジェクトを含むメッセージ全体を拒否し、error classを'Protocol error'（3）、response codeを'Unknown object present'（0x06）とするエラーRESPONSEを生成しなければなりません (MUST)。
o AB=01 ("Optional"): If the object is not understood, it should be deleted and then the rest of the message processed as usual.
o AB=01（'Optional'）：オブジェクトを解釈できない場合、そのオブジェクトを削除し、残りのメッセージを通常どおり処理します。
o AB=10 ("Forward"): If the object is not understood, it should be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
o AB=10（'Forward'）：オブジェクトを解釈できない場合、メッセージ処理の結果として転送するメッセージ内では変更せずに保持しますが、ローカルには保存しません。
The combination AB=11 MUST NOT be used and an error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated.
AB=11の組み合わせを使ってはならず (MUST NOT)、error classを'Protocol error'（3）、response codeを'Invalid Flag-Field combination'（0x09）とするエラーRESPONSEを生成しなければなりません (MUST)。
The following sections do not repeat the common NSLP object header, they just list the type and the length.
次の節では共通NSLPオブジェクトヘッダーを繰り返さず、タイプと長さだけを示します。
The signaling session lifetime object carries the requested or granted lifetime of a NATFW NSLP signaling session measured in seconds.
シグナリングセッション有効期間オブジェクトには、NATFW NSLPシグナリングセッションについて要求または許可された有効期間を秒単位で格納します。
Type: NATFW_LT (0x00C)
Type: NATFW_LT (0x00C)
Length: 1
Length: 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NATFW NSLP signaling session lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Signaling Session Lifetime Object
図22：シグナリングセッション有効期間オブジェクト
The external address object can be included in RESPONSE messages (Section 4.3.3) only. It carries the publicly reachable IP address, and if applicable port number, at an edge-NAT.
外部アドレスオブジェクトはRESPONSEメッセージ（セクション4.3.3）のみに含められます。edge-NATで外部から到達可能なIPアドレスと、該当する場合はポート番号を格納します。
Type: NATFW_EXTERNAL_IP (0x00D)
Type: NATFW_EXTERNAL_IP (0x00D)
Length: 2
Length: 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: External Address Object for IPv4 Addresses
図23：IPv4アドレス用の外部アドレスオブジェクト
Please note that the field 'port number' MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.
たとえば従来型NATによってIPアドレスだけが予約されている場合、'port number'フィールドを0に設定しなければなりません (MUST)。このオブジェクトの処理時には、port numberが0なら無視しなければなりません (MUST)。
IP-Ver (4 bits): The IP version number. This field MUST be set to 4.
IP-Ver（4ビット）：IPバージョン番号です。このフィールドは4に設定しなければなりません (MUST)。
The external binding address object can be included in RESPONSE messages (Section 4.3.3) and EXTERNAL (Section 3.7.2) messages. It carries one or multiple external binding addresses, and if applicable port number, for multi-level NAT deployments (for an example, see Section 2.5). The utilization of the information carried in this object is described in Appendix B.
外部バインディングアドレスオブジェクトは、RESPONSEメッセージ（セクション4.3.3参照）とEXTERNALメッセージ（セクション3.7.2参照）に含められます。このオブジェクトには、多段NAT構成で使う1つ以上の外部バインディングアドレスと、該当する場合はポート番号が格納されます（例はセクション2.5参照）。このオブジェクトの情報の利用方法は付録Bで説明します。
Type: NATFW_EXTERNAL_BINDING (0x00E)
Type: NATFW_EXTERNAL_BINDING (0x00E)
Length: 1 + number of IPv4 addresses
Length: 1 + number of IPv4 addresses
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: External Binding Address Object
図24：外部バインディングアドレスオブジェクト
Please note that the field 'port number' MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.
たとえば従来型NATによってIPアドレスだけが予約されている場合、'port number'フィールドを0に設定しなければなりません (MUST)。このオブジェクトの処理時には、port numberが0なら無視しなければなりません (MUST)。
IP-Ver (4 bits): The IP version number. This field MUST be set to 4.
IP-Ver（4ビット）：IPバージョン番号です。このフィールドは4に設定しなければなりません (MUST)。
In general, flow information is kept in the message routing information (MRI) of the NTLP. Nevertheless, some additional information may be required for NSLP operations. The 'extended flow information' object carries this additional information about the action of the policy rule for firewalls/NATs and a potential contiguous port.
一般に、フロー情報はNTLPのメッセージルーティング情報（MRI）に格納されます。ただし、NSLPの処理では追加情報が必要になることがあります。拡張フロー情報オブジェクトには、ファイアウォールやNATに対するポリシールールの動作と、連続するポート範囲の指定に関する追加情報が格納されます。
Type: NATFW_EFI (0x00F)
Type: NATFW_EFI (0x00F)
Length: 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule action | sub_ports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Extended Flow Information
図25：拡張フロー情報
This object has two fields, 'rule action' and 'sub_ports'. The 'rule action' field has these meanings:
このオブジェクトには'rule action'と'sub_ports'という2つのフィールドがあります。'rule action'フィールドの値の意味は次のとおりです。
o 0x0001: Allow: A policy rule with this action allows data traffic to traverse the middlebox and the NATFW NSLP MUST allow NSLP signaling to be forwarded.
o 0x0001: Allow: この動作のポリシールールは、データトラフィックがミドルボックスを通過することを許可します。また、NATFW NSLPはNSLPシグナリングの転送を許可しなければなりません (MUST)。
o 0x0002: Deny: A policy rule with this action blocks data traffic from traversing the middlebox and the NATFW NSLP MUST NOT allow NSLP signaling to be forwarded.
o 0x0002: Deny: この動作のポリシールールは、データトラフィックがミドルボックスを通過することを遮断します。また、NATFW NSLPはNSLPシグナリングの転送を許可してはなりません (MUST NOT)。
If the 'rule action' field contains neither 0x0001 nor 0x0002, an error RESPONSE of class 'Signaling session failure' (7) with response code 'Unknown policy rule action' (0x05) MUST be generated.
'rule action'フィールドが0x0001でも0x0002でもない場合、error classを'Signaling session failure'（7）、response codeを'Unknown policy rule action'（0x05）とするエラーRESPONSEを生成しなければなりません (MUST)。
The 'sub_ports' field contains the number of contiguous transport layer ports to which this rule applies. The default value of this field is 0, i.e., only the port specified in the NTLP's MRM or NATFW_DTINFO object is used for the policy rule. A value of 1 indicates that additionally to the port specified in the NTLP's MRM (port1), a second port (port2) is used. This value of port 2 is calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT be used in this field and an error RESPONSE of class 'Signaling session failure' (7) with response code 'Requested value in sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. These two contiguous numbered ports can be used by legacy voice over IP equipment. This legacy equipment assumes two adjacent port numbers for its RTP/RTCP flows, respectively.
'sub_ports'フィールドには、このルールが適用される連続したトランスポート層ポートの数を格納します。既定値は0であり、この場合、ポリシールールではNTLPのMRMまたはNATFW_DTINFOオブジェクトに指定されたポートだけを使います。値1は、NTLPのMRMで指定したポート（port1）に加え、2番目のポート（port2）も使うことを示します。port2の値は port2 = port1 + 1 として計算します。このフィールドに0または1以外の値を使ってはならず (MUST NOT)、error classを'Signaling session failure'（7）、response codeを'Requested value in sub_ports field in NATFW_EFI not permitted'（0x08）とするエラーRESPONSEを生成しなければなりません (MUST)。この連続する2つのポートは、従来型のVoice over IP機器で使用できます。この機器は、RTPとRTCPのフローにそれぞれ隣接するポート番号を使うことを前提としています。
This object carries the response code in RESPONSE messages, which indicates either a successful or failed CREATE or EXTERNAL message depending on the value of the 'response code' field. This object is also carried in a NOTIFY message to specify the reason for the notification.
このオブジェクトはRESPONSEメッセージでresponse codeを伝えます。'response code'フィールドの値に応じて、CREATEまたはEXTERNALメッセージが成功したか失敗したかを示します。また、通知の理由を示すためにNOTIFYメッセージにも含まれます。
Type: NATFW_INFO (0x010)
Type: NATFW_INFO (0x010)
Length: 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv. | Class | Response Code |r|r|r|r| Object Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Information Code Object
図26：情報コードオブジェクト
The field 'resv.' is reserved for future extensions and MUST be set to zero when generating such an object and MUST be ignored when receiving. The 'Object Type' field contains the type of the object causing the error. The value of 'Object Type' is set to 0, if no object is concerned. The leading fours bits marked with 'r' are always set to zero and ignored. The 4-bit class field contains the error class. The following classes are defined:
'resv.'フィールドは将来の拡張用に予約されています。このオブジェクトを生成する際は0に設定しなければならず (MUST)、受信時は無視しなければなりません (MUST)。'Object Type'フィールドには、エラーの原因となったオブジェクトのタイプを格納します。該当するオブジェクトがない場合、'Object Type'の値は0です。'r'で示す先頭の4ビットは常に0に設定し、受信時に無視します。4ビットの'Class'フィールドにはエラークラスを格納します。次のクラスが定義されています。
o 0: Reserved
o 0: Reserved
o 1: Informational (NOTIFY only)
o 1: Informational (NOTIFY only)
o 2: Success
o 2: Success
o 3: Protocol error
o 3: Protocol error
o 4: Transient failure
o 4: Transient failure
o 5: Permanent failure
o 5: Permanent failure
o 7: Signaling session failure
o 7: Signaling session failure
Within each error class a number of responses codes are defined as follows.
各エラークラスには、次のresponse codeが定義されています。
o Informational:
o Informational:
* 0x01: Route change: possible route change on the outbound path.
* 0x01: Route change: possible route change on the outbound path（送信経路で経路変更が起きた可能性があります）。
* 0x02: Re-authentication required.
* 0x02: Re-authentication required（再認証が必要です）。
* 0x03: NATFW node is going down soon.
* 0x03: NATFW node is going down soon（NATFWノードがまもなく停止します）。
* 0x04: NATFW signaling session lifetime expired.
* 0x04: NATFW signaling session lifetime expired（NATFWシグナリングセッションの有効期間が満了しました）。
* 0x05: NATFW signaling session terminated.
* 0x05: NATFW signaling session terminated（NATFWシグナリングセッションが終了しました）。
o Success:
o Success:
* 0x01: All successfully processed.
* 0x01: All successfully processed（すべて正常に処理されました）。
o Protocol error:
o Protocol error:
* 0x01: Illegal message type: the type given in the Message Type field of the NSLP header is unknown.
* 0x01: Illegal message type: NSLPヘッダーのMessage Typeフィールドに指定されたタイプが不明です。
* 0x02: Wrong message length: the length given for the message in the NSLP header does not match the length of the message data.
* 0x02: Wrong message length: NSLPヘッダーに示されたメッセージ長がメッセージデータの長さと一致しません。
* 0x03: Bad flags value: an undefined flag or combination of flags was set in the NSLP header.
* 0x03: Bad flags value: NSLPヘッダーに未定義のフラグまたはフラグの組み合わせが設定されています。
* 0x04: Mandatory object missing: an object required in a message of this type was missing.
* 0x04: Mandatory object missing: この種類のメッセージに必要なオブジェクトがありません。
* 0x05: Illegal object present: an object was present that must not be used in a message of this type.
* 0x05: Illegal object present: この種類のメッセージで使用が禁止されているオブジェクトが含まれています。
* 0x06: Unknown object present: an object of an unknown type was present in the message.
* 0x06: Unknown object present: メッセージに未知のタイプのオブジェクトが含まれています。
* 0x07: Wrong object length: the length given for the object in the object header did not match the length of the object data present.
* 0x07: Wrong object length: オブジェクトヘッダーに示されたオブジェクト長が、実際に含まれるオブジェクトデータの長さと一致しません。
* 0x08: Unknown object field value: a field in an object had an unknown value.
* 0x08: Unknown object field value（オブジェクトのフィールドに未知の値が含まれています）。
* 0x09: Invalid Flag-Field combination: An object contains an invalid combination of flags and/or fields.
* 0x09: Invalid Flag-Field combination（オブジェクトに無効なフラグまたはフィールドの組み合わせが含まれています）。
* 0x0A: Duplicate object present.
* 0x0A: Duplicate object present（オブジェクトが重複しています）。
* 0x0B: Received EXTERNAL request message on external side.
* 0x0B: Received EXTERNAL request message on external side（外部側でEXTERNAL要求メッセージを受信しました）。
o Transient failure:
o Transient failure:
* 0x01: Requested resources temporarily not available.
* 0x01: Requested resources temporarily not available（要求されたリソースを一時的に利用できません）。
o Permanent failure:
o Permanent failure:
* 0x01: Authentication failed.
* 0x01: Authentication failed（認証に失敗しました）。
* 0x02: Authorization failed.
* 0x02: Authorization failed（認可に失敗しました）。
* 0x04: Internal or system error.
* 0x04: Internal or system error（内部エラーまたはシステムエラーです）。
* 0x06: No edge-device here.
* 0x06: No edge-device here（ここにedge装置はありません）。
* 0x07: Did not reach the NR.
* 0x07: Did not reach the NR（NRに到達しませんでした）。
o Signaling session failure:
o Signaling session failure:
* 0x01: Session terminated asynchronously.
* 0x01: Session terminated asynchronously（セッションが非同期に終了しました）。
* 0x02: Requested lifetime is too big.
* 0x02: Requested lifetime is too big（要求された有効期間が長すぎます）。
* 0x03: No reservation found matching the MRI of the CREATE request.
* 0x03: No reservation found matching the MRI of the CREATE request（CREATE要求のMRIに一致する予約が見つかりませんでした）。
* 0x04: Requested policy rule denied due to policy conflict.
* 0x04: Requested policy rule denied due to policy conflict（ポリシー競合により要求されたポリシールールが拒否されました）。
* 0x05: Unknown policy rule action.
* 0x05: Unknown policy rule action（ポリシールールの動作が不明です）。
* 0x06: Requested rule action not applicable.
* 0x06: Requested rule action not applicable（要求されたルールの動作は適用できません）。
* 0x07: NATFW_DTINFO object is required.
* 0x07: NATFW_DTINFO object is required（NATFW_DTINFOオブジェクトが必要です）。
* 0x08: Requested value in sub_ports field in NATFW_EFI not permitted.
* 0x08: Requested value in sub_ports field in NATFW_EFI not permitted（NATFW_EFIのsub_portsフィールドで要求された値は許可されません）。
* 0x09: Requested IP protocol not supported.
* 0x09: Requested IP protocol not supported（要求されたIPプロトコルはサポートされていません）。
* 0x0A: Plain IP policy rules not permitted -- need transport layer information.
* 0x0A: Plain IP policy rules not permitted -- need transport layer information（通常のIPポリシールールは許可されません。トランスポート層の情報が必要です）。
* 0x0B: ICMP type value not permitted.
* 0x0B: ICMP type value not permitted（ICMP typeの値は許可されません）。
* 0x0C: Source IP address range is too large.
* 0x0C: Source IP address range is too large（送信元IPアドレスの範囲が広すぎます）。
* 0x0D: Destination IP address range is too large.
* 0x0D: Destination IP address range is too large（宛先IPアドレス範囲が広すぎます）。
* 0x0E: Source L4-port range is too large.
* 0x0E: Source L4-port range is too large（送信元L4ポート範囲が広すぎます）。
* 0x0F: Destination L4-port range is too large.
* 0x0F: Destination L4-port range is too large（宛先L4ポート範囲が広すぎます）。
* 0x10: Requested lifetime is too small.
* 0x10: Requested lifetime is too small（要求された有効期間が短すぎます）。
* 0x11: Modified lifetime is too big.
* 0x11: Modified lifetime is too big（変更後の有効期間が長すぎます）。
* 0x12: Modified lifetime is too small.
* 0x12: Modified lifetime is too small（変更後の有効期間が短すぎます）。
This object carries the nonce value as described in Section 3.7.6.
このオブジェクトには、セクション3.7.6で説明したnonce値を格納します。
Type: NATFW_NONCE (0x011)
Type: NATFW_NONCE (0x011)
Length: 1
Length: 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Nonce Object
図27：Nonceオブジェクト
This object carries the MSN value as described in Section 3.5.
このオブジェクトには、セクション3.5で説明したMSN値を格納します。
Type: NATFW_MSN (0x012)
Type: NATFW_MSN (0x012)
Length: 1
Length: 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Message Sequence Number Object
図28：メッセージシーケンス番号オブジェクト
The 'data terminal information' object carries additional information that MUST be included the EXTERNAL message. EXTERNAL messages are transported by the NTLP using the Loose-End message routing method (LE-MRM). The LE-MRM contains only the DR's IP address and a signaling destination address (destination IP address). This destination IP address is used for message routing only and is not necessarily reflecting the address of the data sender. This object contains information about (if applicable) DR's port number (the destination port number), the DS's port number (the source port number), the used transport protocol, the prefix length of the IP address, and DS's IP address.
data terminal informationオブジェクトには、EXTERNALメッセージに含めなければならない (MUST)追加情報を格納します。NTLPはLoose-Endメッセージルーティング方式（LE-MRM）を使ってEXTERNALメッセージを転送します。LE-MRMに含まれるのはDRのIPアドレスとシグナリング宛先アドレス（宛先IPアドレス）だけです。この宛先IPアドレスはメッセージルーティングにのみ使われ、必ずしもデータ送信者のアドレスを示しません。このオブジェクトには、該当する場合のDRポート（宛先ポート番号）、DSポート（送信元ポート番号）、使用するトランスポートプロトコル、IPアドレスのプレフィックス長、およびDSのIPアドレスに関する情報が含まれます。
Type: NATFW_DTINFO (0x013) Length: variable. Maximum 3.
Type: NATFW_DTINFO (0x013) Length: variable. Maximum 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|P|S| reserved | sender prefix | protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DR port number | DS port number :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPsec-SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data sender's IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Data Terminal IPv4 Address Object
図29：IPv4アドレス用のデータ端末情報オブジェクト
The flags are:
フラグの意味は次のとおりです。
o I: I=1 means that 'protocol' should be interpreted.
o I: I=1の場合、'protocol'を解釈します。
o P: P=1 means that 'dst port number' and 'src port number' are present and should be interpreted.
o P: P=1の場合、'dst port number'と'src port number'が含まれており、これらを解釈します。
o S: S=1 means that SPI is present and should be interpreted.
o S: S=1の場合、SPIが含まれており、これを解釈します。
The SPI field is only present if S is set. The port numbers are only present if P is set. The flags P and S MUST NOT be set at the same time. An error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated if they are both set. If either P or S is set, I MUST be set as well and the protocol field MUST carry the particular protocol. An error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated if S or P is set but I is not set.
SPIフィールドが含まれるのはSが設定されている場合だけです。ポート番号が含まれるのはPが設定されている場合だけです。PとSのフラグを同時に設定してはなりません (MUST NOT)。両方が設定された場合、error classを'Protocol error'（3）、response codeを'Invalid Flag-Field combination'（0x09）とするエラーRESPONSEを生成しなければなりません (MUST)。PまたはSが設定されている場合、Iも設定しなければならず (MUST)、'protocol'フィールドに該当するプロトコルを格納しなければなりません (MUST)。PまたはSが設定されているのにIが設定されていない場合も、同じerror classとresponse codeのエラーRESPONSEを生成しなければなりません (MUST)。
The fields MUST be interpreted according to these rules:
各フィールドは、次の規則に従って解釈しなければなりません (MUST)。
o (data) sender prefix: This parameter indicates the prefix length of the 'data sender's IP address' in bits. For instance, a full IPv4 address requires 'sender prefix' to be set to 32. A value of 0 indicates an IP address wildcard.
o data sender prefix：このパラメーターは、'data sender's IP address'のプレフィックス長をビット単位で示します。たとえば、IPv4アドレス全体を指定する場合、'sender prefix'を32に設定します。値0はIPアドレスがワイルドカードであることを示します。
o protocol: The IP protocol field. This field MUST be interpreted if I=1; otherwise, it MUST be set to 0 and MUST be ignored.
o protocol：IPプロトコルフィールドです。I=1の場合、このフィールドを解釈しなければなりません (MUST)。それ以外の場合、このフィールドを0に設定しなければならず (MUST)、無視しなければなりません (MUST)。
o DR port number: The port number at the data receiver (DR), i.e., the destination port. A value of 0 indicates a port wildcard, i.e., the destination port number is not known. Any other value indicates the destination port number.
o DR port number：データ受信者（DR）側のポート番号、つまり宛先ポートです。値0は宛先ポート番号が不明であることを示すワイルドカードです。その他の値は宛先ポート番号を示します。
o DS port number: The port number at the data sender (DS), i.e., the source port. A value of 0 indicates a port wildcard, i.e., the source port number is not known. Any other value indicates the source port number.
o DS port number：データ送信者（DS）側のポート番号、つまり送信元ポートです。値0は送信元ポート番号が不明であることを示すワイルドカードです。その他の値は送信元ポート番号を示します。
o data sender's IPv4 address: The source IP address of the data sender. This field MUST be set to zero if no IP address is provided, i.e., a complete wildcard is desired (see the dest prefix field above).
o data sender's IPv4 address：データ送信者の送信元IPアドレスです。IPアドレスを指定せず完全なワイルドカードを使う場合、このフィールドを0に設定しなければなりません (MUST)（上記のdest prefixフィールド参照）。
The 'ICMP types' object contains additional information needed to configure a NAT of firewall with rules to control ICMP traffic. The object contains a number of values of the ICMP Type field for which a filter action should be set up:
ICMP typesオブジェクトには、ICMPトラフィックを制御するルールでNATまたはファイアウォールを設定するための追加情報を格納します。このオブジェクトには、フィルター動作を設定するICMP Typeフィールドの値を複数格納できます。
Type: NATFW_ICMP_TYPES (0x014)
Type: NATFW_ICMP_TYPES (0x014)
Length: Variable = ((Number of Types carried + 1) + 3) DIV 4
Where DIV is an integer division.
DIVは整数除算を表します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Type | Type | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | Type | (Padding) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: ICMP Types Object
図30：ICMP typesオブジェクト
The fields MUST be interpreted according to these rules:
各フィールドは、次の規則に従って解釈しなければなりません (MUST)。
count: 8-bit integer specifying the number of 'Type' entries in the object.
o count：オブジェクト内の'Type'項目数を示す8ビット整数です。
type: 8-bit field specifying an ICMP Type value to which this rule applies.
o type：このルールが適用されるICMP Type値を示す8ビットフィールドです。
padding: Sufficient 0 bits to pad out the last word so that the total size of the object is an even multiple of words. Ignored on reception.
o padding：オブジェクト全体のサイズがワードの整数倍になるよう、最後のワードを埋めるために必要な数の0ビットです。受信時には無視します。
This section defines the content of each NATFW NSLP message type. The message types are defined in Section 4.1.
この節では、各NATFW NSLPメッセージタイプの内容を定義します。メッセージタイプについてはセクション4.1で定義します。
Basically, each message is constructed of an NSLP header and one or more NSLP objects. The order of objects is not defined, meaning that objects may occur in any sequence. Objects are marked either with mandatory (M) or optional (O). Where (M) implies that this particular object MUST be included within the message and where (O) implies that this particular object is OPTIONAL within the message. Objects defined in this memo always carry the flag combination AB=00 in the NSLP object header. An error RESPONSE message of class 'Protocol error' (3) with response code 'Mandatory object missing' (0x04) MUST be generated if a mandatory declared object is missing. An error RESPONSE message of class 'Protocol error' (3) with response code 'Illegal object present' (0x05) MUST be generated if an object was present that must not be used in a message of this type. An error RESPONSE message of class 'Protocol error' (3) with response code 'Duplicate object present' (0x0A) MUST be generated if an object appears more than once in a message.
各メッセージは、基本的にNSLPヘッダーと1つ以上のNSLPオブジェクトから成ります。オブジェクトの順序は定められておらず、任意の順序で現れることがあります。各オブジェクトにはmandatory（M）またはoptional（O）の指定があります。(M)は、そのオブジェクトをメッセージに含めなければならないことを示します (MUST)。(O)は、そのオブジェクトをメッセージに含めてもよいことを示します (MAY)。本メモで定義するオブジェクトのNSLPオブジェクトヘッダーでは、常にフラグの組み合わせAB=00を使います。mandatoryと宣言されたオブジェクトがない場合、error classを'Protocol error'（3）、response codeを'Mandatory object missing'（0x04）とするエラーRESPONSEを生成しなければなりません (MUST)。この種類のメッセージで使ってはならないオブジェクトが含まれる場合、error classを'Protocol error'（3）、response codeを'Illegal object present'（0x05）とするエラーRESPONSEを生成しなければなりません (MUST)。同じオブジェクトがメッセージ内に複数回現れる場合、error classを'Protocol error'（3）、response codeを'Duplicate object present'（0x0A）とするエラーRESPONSEを生成しなければなりません (MUST)。
Each section elaborates the required settings and parameters to be set by the NSLP for the NTLP, for instance, how the message routing information is set.
各節では、たとえばメッセージルーティング情報の設定方法など、NTLP向けにNSLPが設定する項目やパラメーターを詳しく説明します。
The CREATE message is used to create NATFW NSLP signaling sessions and to create policy rules. Furthermore, CREATE messages are used to refresh NATFW NSLP signaling sessions and to delete them.
CREATEメッセージは、NATFW NSLPシグナリングセッションとポリシールールの作成に使います。また、シグナリングセッションの更新と削除にも使います。
The CREATE message carries these objects:
CREATEメッセージには次のオブジェクトが含まれます。
o Signaling Session Lifetime object (M)
o シグナリングセッション有効期間オブジェクト (M)
o Extended flow information object (M)
o 拡張フロー情報オブジェクト (M)
o Message sequence number object (M)
o メッセージシーケンス番号オブジェクト (M)
o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)
o NSLPヘッダーのPフラグが1の場合はNonceオブジェクト (M)、それ以外の場合は (O)
o ICMP Types Object (O) The message routing information in the NTLP MUST be set to DS as source IP address and DR as destination IP address. All other parameters MUST be set according to the required policy rule. CREATE messages MUST be transported by using the path-coupled MRM with the direction set to 'downstream' (outbound).
o ICMP Types Object (O)。NTLPのメッセージルーティング情報では、source-addressをDS、destination-addressをDRに設定しなければなりません (MUST)。他のすべてのパラメーターは、要求されたポリシールールに従って設定しなければなりません (MUST)。CREATEメッセージは、directionを'downstream'（送信方向）に設定したパス結合型MRMを使って伝送しなければなりません (MUST)。
The EXTERNAL message is used to a) reserve an external IP address/ port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to block incoming data traffic at inbound firewalls.
EXTERNALメッセージは、a) NATで外部IPアドレスまたはポートを予約する、b) NSIS対応DRについてファイアウォールに通知する、またはc) 受信側ファイアウォールで着信データトラフィックを遮断するために使います。
The EXTERNAL message carries these objects:
EXTERNALメッセージには次のオブジェクトが含まれます。
o Signaling Session Lifetime object (M)
o シグナリングセッション有効期間オブジェクト (M)
o Message sequence number object (M)
o メッセージシーケンス番号オブジェクト (M)
o Extended flow information object (M)
o 拡張フロー情報オブジェクト (M)
o Data terminal information object (M)
o データ端末情報オブジェクト (M)
o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)
o NSLPヘッダーのPフラグが1の場合はNonceオブジェクト (M)、それ以外の場合は (O)
o ICMP Types Object (O)
o ICMP Types Object (O)
o External binding address object (O)
o 外部バインディングアドレスオブジェクト (O)
The selected message routing method of the EXTERNAL message depends on a number of considerations. Section 3.7.2 describes exhaustively how to select the correct method. EXTERNAL messages can be transported via the path-coupled message routing method (PC-MRM) or via the loose-end message routing method (LE-MRM). In the case of PC-MRM, the source-address is set to the DS's address and the destination-address is set to the DR's address, the direction is set to inbound. In the case of LE-MRM, the destination-address is set to the DR's address or to the signaling destination IP address. The source-address is set to the DS's address.
EXTERNALメッセージに使うメッセージルーティング方式は、複数の要件を考慮して選びます。適切な方式の選び方はセクション3.7.2で詳しく説明します。EXTERNALメッセージは、パス結合型メッセージルーティング方式（PC-MRM）またはルーズエンド型メッセージルーティング方式（LE-MRM）で伝送できます。PC-MRMの場合、source-addressをDSのアドレス、destination-addressをDRのアドレスに設定し、directionを受信方向に設定します。LE-MRMの場合、destination-addressをDRのアドレスまたはシグナリング宛先IPアドレスに設定し、source-addressをDSのアドレスに設定します。
RESPONSE messages are responses to CREATE and EXTERNAL messages. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE.
RESPONSEメッセージはCREATEメッセージおよびEXTERNALメッセージへの応答です。NOTIFYやRESPONSEなど、その他のメッセージに対してRESPONSEメッセージを生成してはなりません (MUST NOT)。
The RESPONSE message for the class 'Success' (2) carries these objects: o Signaling Session Lifetime object (M)
error classが'Success'（2）のRESPONSEメッセージには、次のオブジェクトが含まれます。o シグナリングセッション有効期間オブジェクト (M)
o Message sequence number object (M)
o メッセージシーケンス番号オブジェクト (M)
o Information code object (M)
o 情報コードオブジェクト (M)
o External address object (O)
o 外部アドレスオブジェクト (O)
o External binding address object (O)
o 外部バインディングアドレスオブジェクト (O)
The RESPONSE message for other classes than 'Success' (2) carries these objects:
error classが'Success'（2）以外のRESPONSEメッセージには、次のオブジェクトが含まれます。
o Message sequence number object (M)
o メッセージシーケンス番号オブジェクト (M)
o Information code object (M)
o 情報コードオブジェクト (M)
o Signaling Session Lifetime object (O)
o シグナリングセッション有効期間オブジェクト (O)
This message is routed towards the NI hop-by-hop, using existing NTLP messaging associations. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.
このメッセージは、既存のNTLPメッセージング関連付けを使い、NIへホップごとにルーティングします。このメッセージで使うMRMは、対応するCREATEメッセージまたはEXTERNALメッセージで使われたMRMと同じでなければなりません (MUST)。
The NOTIFY messages is used to report asynchronous events happening along the signaled path to other NATFW NSLP nodes.
NOTIFYメッセージは、シグナリング経路上で発生した非同期イベントを他のNATFW NSLPノードに報告するために使います。
The NOTIFY message carries this object:
NOTIFYメッセージには次のオブジェクトが含まれます。
o Information code object (M)
o 情報コードオブジェクト (M)
The NOTIFY message is routed towards the next NF, NI, or NR hop-by-hop using the existing inbound or outbound node messaging association entry within the node's Message Routing State table. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.
NOTIFYメッセージは、ノードのMessage Routing Stateテーブルにある既存の受信方向または送信方向のノード間メッセージング関連付けエントリーを使い、次のNF、NI、またはNRへホップごとにルーティングします。このメッセージで使うMRMは、対応するCREATEメッセージまたはEXTERNALメッセージで使われたMRMと同じでなければなりません (MUST)。
Security is of major concern particularly in the case of firewall traversal. This section provides security considerations for the NAT/firewall traversal and is organized as follows.
特にファイアウォールを通過する場合、セキュリティは重大な懸念事項です。この節ではNAT／ファイアウォールの通過に関するセキュリティ上の考慮事項を説明し、以下のように構成します。
In Section 5.1, we describe how the participating entities relate to each other from a security point of view. That subsection also motivates a particular authorization model.
セクション5.1では、セキュリティの観点から参加エンティティ同士の関係を説明し、特定の認可モデルを採用する理由も示します。
Security threats that focus on NSIS in general are described in [RFC4081] and they are applicable to this document as well.
NSIS全般に関するセキュリティ脅威は[RFC4081]で説明されており、本書にも当てはまります。
Finally, we illustrate how the security requirements that were created based on the security threats can be fulfilled by specific security mechanisms. These aspects will be elaborated in Section 5.2.
最後に、セキュリティ脅威に基づく要件を、具体的なセキュリティ機構でどのように満たせるかを説明します。これらについてはセクション5.2で詳しく述べます。
The NATFW NSLP is a protocol that may involve a number of NSIS nodes and is, as such, not a two-party protocol. Figures 1 and 2 of [RFC4081] already depict the possible set of communication patterns. In this section, we will re-evaluate these communication patterns with respect to the NATFW NSLP protocol interaction.
NATFW NSLPは複数のNSISノードが関与しうるプロトコルであり、2者間だけで完結するプロトコルではありません。[RFC4081]の図1と図2には、考えられる通信パターンがすでに示されています。この節では、NATFW NSLPのプロトコル上のやり取りに照らして、これらの通信パターンを改めて検討します。
The security solutions for providing authorization have a direct impact on the treatment of different NSLPs. As it can be seen from the QoS NSLP [RFC5974] and the corresponding Diameter QoS work [RFC5866], accounting and charging seems to play an important role for QoS reservations, whereas monetary aspects might only indirectly effect authorization decisions for NAT and firewall signaling. Hence, there are differences in the semantics of authorization handling between QoS and NATFW signaling. A NATFW-aware node will most likely want to authorize the entity (e.g., user or machine) requesting the establishment of pinholes or NAT bindings. The outcome of the authorization decision is either allowed or disallowed, whereas a QoS authorization decision might indicate that a different set of QoS parameters is authorized (see [RFC5866] as an example).
認可を実現するセキュリティ方式は、NSLPごとの処理に直接影響します。QoS NSLP [RFC5974]と関連するDiameter QoSの取り組み [RFC5866]に見られるように、QoS予約ではアカウンティングや課金が重要な役割を持つようです。一方、金銭面がNATやファイアウォールのシグナリングに対する認可判断に影響するのは、間接的な場合に限られることがあります。そのため、QoSとNATFWのシグナリングでは認可処理の意味が異なります。NATFW対応ノードは、ピンホールやNATバインディングの確立を要求するエンティティ（ユーザーや装置など）を認可しようとします。認可判断の結果は許可または不許可のいずれかです。一方、QoSの認可判断では、別のQoSパラメーター群が認可されることもあります（例は[RFC5866]参照）。
Starting with the simplest scenario, it is assumed that neighboring nodes are able to authenticate each other and to establish keying material to protect the signaling message communication. The nodes will have to authorize each other, additionally to the authentication. We use the term 'Security Context' as a placeholder for referring to the entire security procedure, the necessary infrastructure that needs to be in place in order for this to work (e.g., key management) and the established security-related state. The required long-term keys (symmetric or asymmetric keys) used for authentication either are made available using an out-of-band mechanism between the two NSIS NATFW nodes or are dynamically established using mechanisms not further specified in this document. Note that the deployment environment will most likely have an impact on the choice of credentials being used. The choice of these credentials used is also outside the scope of this document.
最も単純なシナリオでは、隣接ノード同士が互いを認証し、シグナリングメッセージの通信を保護するための鍵素材を確立できると想定します。ノードは認証だけでなく、互いを認可する必要もあります。ここでは'Security Context'を、セキュリティ手順全体、それを機能させるために必要な基盤（鍵管理など）、および確立されたセキュリティ関連状態を総称する仮の用語として使います。認証に使う長期鍵（共通鍵または公開鍵）は、2つのNSIS NATFWノード間の帯域外の仕組みで事前に提供するか、本書では詳述しない仕組みで動的に確立します。導入環境は、使用する認証情報の選択に影響すると考えられます。認証情報の選択も本書の範囲外です。
+------------------------+ +-------------------------+
|Network A | | Network B|
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | Security | box 2 | | |
| | +---------+ Context +---------+ | |
| | Security | | Security | |
| | Context | | Context | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+------------------------+ +-------------------------+
Figure 31: Peer-to-Peer Relationship
図31：ピア間の関係
Figure 31 shows a possible relationship between participating NSIS-aware nodes. Host A might be, for example, a host in an enterprise network that has keying material established (e.g., a shared secret) with the company's firewall (Middlebox 1). The network administrator of Network A (company network) has created access control lists for Host A (or whatever identifiers a particular company wants to use). Exactly the same procedure might also be used between Host B and Middlebox 2 in Network B. For the communication between Middlebox 1 and Middlebox 2 a security context is also assumed in order to allow authentication, authorization, and signaling message protection to be successful.
図31は、NSIS対応ノード間にありうる関係を示します。たとえば、ホストAは企業ネットワーク内のホストであり、企業のファイアウォール（Middlebox 1）との間で鍵素材（共有シークレットなど）を確立しています。ネットワークA（企業ネットワーク）の管理者は、ホストA（または企業が使う任意の識別子）に対するアクセス制御リストを作成しています。ネットワークB内のホストBとMiddlebox 2の間でも、同じ手順を使う場合があります。Middlebox 1とMiddlebox 2の間にもSecurity Contextがあると想定します。これにより認証、認可、およびシグナリングメッセージの保護を実現できます。
In larger corporations, for example, a middlebox is used to protect individual departments. In many cases, the entire enterprise is controlled by a single (or a small number of) security department(s), which give instructions to the department administrators. In such a scenario, the previously discussed peer-to-peer relationship might be prevalent. Sometimes it might be necessary to preserve authentication and authorization information within the network. As a possible solution, a centralized approach could be used, whereby an interaction between the individual middleboxes and a central entity (for example, a policy decision point - PDP) takes place. As an alternative, individual middleboxes exchange the authorization decision with another middlebox within the same trust domain. Individual middleboxes within an administrative domain may exploit their relationship instead of requesting authentication and authorization of the signaling initiator again and again. Figure 32 illustrates a network structure that uses a centralized entity.
大企業では、たとえば部門ごとにミドルボックスを設置して保護することがあります。多くの場合、企業全体は1つ（または少数）のセキュリティ部門が管理し、各部門の管理者に指示を出します。このような環境では、前述のピア間の関係が一般的な場合があります。ネットワーク内で認証情報と認可情報を共有する必要がある場合もあります。解決策の1つとして、各ミドルボックスと中央エンティティ（たとえばpolicy decision point（PDP））が連携する集中型の仕組みを使えます。別の方法として、各ミドルボックスが同じ信頼ドメイン内の別のミドルボックスと認可判断を交換します。管理ドメイン内のミドルボックスは、シグナリング開始者を毎回認証・認可する代わりに、相互の既存の関係を利用することもできます。図32に、中央エンティティを使うネットワーク構成を示します。
+-----------------------------------------------------------+
| Network A |
| +---------+ +---------+
| +----///--------+ Middle- +------///------++ Middle- +---
| | Security | box 2 | Security | box 2 |
| | Context +----+----+ Context +----+----+
| +----+----+ | | |
| | Middle- +--------+ +---------+ | |
| | box 1 | | | | |
| +----+----+ | | | |
| | Security | +----+-----+ | |
| | Context | | Policy | | |
| +--+---+ +-----------+ Decision +----------+ |
| | Host | | Point | |
| | A | +----------+ |
| +------+ |
+-----------------------------------------------------------+
Figure 32: Intra-Domain Relationship
図32：ドメイン内の関係
The interaction between individual middleboxes and a policy decision point (or AAA server) is outside the scope of this document.
各ミドルボックスとポリシー決定ポイント（またはAAAサーバー）との連携は、本書の範囲外です。
The peer-to-peer relationship between neighboring NSIS NATFW NSLP nodes might not always be sufficient. Network B might require additional authorization of the signaling message initiator (in addition to the authorization of the neighboring node). If authentication and authorization information is not attached to the initial signaling message then the signaling message arriving at Middlebox 2 would result in an error message being created, which indicates the additional authorization requirement. In many cases, the signaling message initiator might already be aware of the additionally required authorization before the signaling message exchange is executed.
隣接するNSIS NATFW NSLPノード間のピア関係だけでは、常に十分とは限りません。ネットワークBでは、隣接ノードの認可に加えて、シグナリングメッセージの開始者も認可する必要がある場合があります。最初のシグナリングメッセージに認証情報と認可情報が含まれていなければ、Middlebox 2に到着した時点で追加の認可要件を示すエラーメッセージが生成されます。多くの場合、シグナリングメッセージの開始者は、メッセージ交換を始める前に追加の認可が必要だと把握しています。
Figure 33 shows this scenario.
このシナリオを図33に示します。
+--------------------+ +---------------------+
| Network A | |Network B |
| | Security | |
| +---------+ Context +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | +-------+ box 2 | | |
| | +---------+ | +---------+ | |
| |Security | | | Security | |
| |Context | | | Context |
| | | | | | |
| +--+---+ | | | +--+---+ |
| | Host +----///----+------+ | | Host | |
| | A | | Security | | B | |
| +------+ | Context | +------+ |
+--------------------+ +---------------------+
Figure 33: End-to-Middle Relationship
図33：エンド・ミドル間の関係
The following list of security requirements has been created to ensure proper secure operation of the NATFW NSLP.
NATFW NSLPを安全に運用するため、次のセキュリティ要件を定めています。
Based on the analyzed threats, it is RECOMMENDED to provide, between neighboring NATFW NSLP nodes, the following mechanisms:
分析した脅威を踏まえ、隣接するNATFW NSLPノード間で次の機構を提供することが推奨されます (SHOULD)。
o data origin authentication,
o データ送信元認証
o replay protection,
o リプレイ保護
o integrity protection, and,
o 完全性保護、および
o optionally, confidentiality protection
o 任意の機密性保護
It is RECOMMENDED to use the authentication and key exchange security mechanisms provided in [RFC5971] between neighboring nodes when sending NATFW signaling messages. The proposed security mechanisms of GIST provide support for authentication and key exchange in addition to denial-of-service protection. Depending on the chosen security protocol, support for multiple authentication protocols might be provided. If security between neighboring nodes is desired, then the usage of C-MODE with a secure transport protocol for the delivery of most NSIS messages with the usage of D-MODE only to discover the next NATFW NSLP-aware node along the path is highly RECOMMENDED. See [RFC5971] for the definitions of C-MODE and D-MODE. Almost all security threats at the NATFW NSLP-layer can be prevented by using a mutually authenticated Transport Layer secured connection and by relying on authorization by the neighboring NATFW NSLP entities.
NATFWシグナリングメッセージの送信時には、隣接ノード間で[RFC5971]が提供する認証および鍵交換のセキュリティ機構を使うことが推奨されます (SHOULD)。提案されているGISTのセキュリティ機構は、サービス拒否攻撃への保護に加え、認証と鍵交換をサポートします。選択したセキュリティプロトコルによっては、複数の認証プロトコルをサポートできます。隣接ノード間のセキュリティを確保する場合、大半のNSISメッセージを安全なトランスポートプロトコルで配送するC-MODEを使い、経路上の次のNATFW NSLP対応ノードの検出に限ってD-MODEを使うことが強く推奨されます (SHOULD)。C-MODEとD-MODEの定義は[RFC5971]を参照してください。相互認証されたトランスポート層セキュア接続を使い、隣接するNATFW NSLPエンティティによる認可を適用することで、NATFW NSLP層におけるほぼすべてのセキュリティ脅威を防止できます。
The NATFW NSLP relies on an established security association between neighboring peers to prevent unauthorized nodes from modifying or deleting installed state. Between non-neighboring nodes the session ID (SID) carried in the NTLP is used to show ownership of a NATFW NSLP signaling session. The session ID MUST be generated in a random way and thereby prevents an off-path adversary from mounting targeted attacks. Hence, an adversary would have to learn the randomly generated session ID to perform an attack. In a mobility environment a former on-path node that is now off-path can perform an attack. Messages for a particular NATFW NSLP signaling session are handled by the NTLP to the NATFW NSLP for further processing. Messages carrying a different session ID not associated with any NATFW NSLP are subject to the regular processing for new NATFW NSLP signaling sessions.
NATFW NSLPは、隣接ピア間で確立されたセキュリティアソシエーションに依存し、権限のないノードによる設定済み状態の変更や削除を防ぎます。非隣接ノード間では、NTLPで伝送されるセッションID（SID）を使って、NATFW NSLPシグナリングセッションの所有権を示します。セッションIDはランダムに生成しなければなりません (MUST)。これにより、経路外の攻撃者が特定のセッションを狙う攻撃を防ぎます。したがって、攻撃者が攻撃するにはランダム生成されたセッションIDを知る必要があります。モビリティ環境では、以前は経路上にいたものの、現在は経路外にいるノードが攻撃を仕掛ける可能性があります。特定のNATFW NSLPシグナリングセッションに関するメッセージは、NTLPからNATFW NSLPに渡され、さらに処理されます。NATFW NSLPセッションに関連付けられていないセッションIDを持つメッセージは、新しいNATFW NSLPシグナリングセッションに対する通常の処理を受けます。
Based on the security threats and the listed requirements, it was noted that some threats also demand authentication and authorization of a NATFW signaling entity (including the initiator) towards a non-neighboring node. This mechanism mainly demands entity authentication. The most important information exchanged at the NATFW NSLP is information related to the establishment for firewall pinholes and NAT bindings. This information can, however, not be protected over multiple NSIS NATFW NSLP hops since this information might change depending on the capability of each individual NATFW NSLP node.
セキュリティ脅威と前述の要件から、一部の脅威に対処するには、開始者を含むNATFWシグナリングエンティティを非隣接ノードに対して認証・認可する必要もあると分かります。この機構では主にエンティティ認証を行います。NATFW NSLPで交換される最も重要な情報は、ファイアウォールのピンホールとNATバインディングの確立に関するものです。ただし、この情報は各NATFW NSLPノードの機能によって変わる可能性があるため、複数のNSIS NATFW NSLPホップをまたいで保護することはできません。
Some scenarios might also benefit from the usage of authorization tokens. Their purpose is to associate two different signaling protocols (e.g., SIP and NSIS) and their authorization decision. These tokens are obtained by non-NSIS protocols, such as SIP or as part of network access authentication. When a NAT or firewall along the path receives the token it might be verified locally or passed to the AAA infrastructure. Examples of authorization tokens can be found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 34 shows an example of this protocol interaction.
An authorization token is provided by the SIP proxy, which acts as the assertion generating entity and gets delivered to the end host with proper authentication and authorization. When the NATFW signaling message is transmitted towards the network, the authorization token is attached to the signaling messages to refer to the previous authorization decision. The assertion-verifying entity needs to process the token or it might be necessary to interact with the assertion-granting entity using HTTP (or other protocols). As a result of a successfully authorization by a NATFW NSLP node, the requested action is executed and later a RESPONSE message is generated.
SIPプロキシは、アサーション生成エンティティとして認可トークンを発行し、適切な認証と認可を経てエンドホストへ届けます。NATFWシグナリングメッセージをネットワークへ送る際、以前の認可判断を参照できるよう、認可トークンをメッセージに添付します。アサーション検証エンティティはトークンを処理しますが、HTTPなどのプロトコルを使ってアサーション付与エンティティと通信する必要がある場合もあります。NATFW NSLPノードによる認可に成功すると、要求された処理を実行し、その後RESPONSEメッセージを生成します。
+----------------+ Trust Relationship +----------------+
| +------------+ |<.......................>| +------------+ |
| | Protocol | | | | Assertion | |
| | requesting | | HTTP, SIP Request | | Granting | |
| | authz | |------------------------>| | Entity | |
| | assertions | |<------------------------| +------------+ |
| +------------+ | Artifact/Assertion | Entity Cecil |
| ^ | +----------------+
| | | ^ ^|
| | | . || HTTP,
| | | Trust . || other
| API Access | Relationship. || protocols
| | | . ||
| | | . ||
| | | v |v
| v | +----------------+
| +------------+ | | +------------+ |
| | Protocol | | NSIS NATFW CREATE + | | Assertion | |
| | using authz| | Assertion/Artifact | | Verifying | |
| | assertion | | ----------------------- | | Entity | |
| +------------+ | | +------------+ |
| Entity Alice | <---------------------- | Entity Bob |
+----------------+ RESPONSE +----------------+
Figure 34: Authorization Token Usage
図34：認可トークンの使用
Threats against the usage of authorization tokens have been mentioned in [RFC4081]. Hence, it is required to provide confidentiality protection to avoid allowing an eavesdropper to learn the token and to use it in another NATFW NSLP signaling session (replay attack). The token itself also needs to be protected against tempering.
認可トークンの利用に対する脅威は[RFC4081]で説明されています。盗聴者によるトークンの取得と、別のNATFW NSLPシグナリングセッションでの再利用（リプレイ攻撃）を防ぐため、機密性を保護する必要があります。トークン自体の改ざんも防ぐ必要があります。
The prior sections describe how to secure the NATFW NSLP in the presence of established trust between the various players and the particular relationships (e.g., intra-domain, end-to-middle, or peer-to-peer). However, in typical Internet deployments there is no established trust, other than granting access to a network, but not between various sites in the Internet. Furthermore, the NATFW NSLP may be incrementally deployed with a widely varying ability to be able to use authentication and authorization services.
前の各節では、参加者間に信頼関係が確立されている場合に、特定の関係（ドメイン内、エンド・ミドル間、ピア間など）に応じてNATFW NSLPを保護する方法を説明しました。しかし通常のインターネット環境では、ネットワークへのアクセスを認める関係はあっても、インターネット上の各サイト間に信頼関係が確立されているとは限りません。また、NATFW NSLPは段階的に導入される可能性があり、認証・認可サービスを利用できる能力は環境によって大きく異なります。
The NATFW NSLP offers a way to keep the authentication and authorization at the "edge" of the network. The local edge network can deploy and use any type of Authentication and Authorization (AA) scheme without the need to have AA technology match with other edges in the Internet (assuming that firewalls and NATs are deployed at the edges of the network and not somewhere in the cores).
NATFW NSLPは、認証と認可をネットワークの「edge」で行う方法を提供します。ファイアウォールとNATがネットワークのedgeに配置され、その中核部分には配置されないことを前提に、各ローカルedgeネットワークは、インターネット上の他のedgeとAA技術を統一せずに、任意の認証・認可（AA）方式を導入して利用できます。
Each network edge that has the NATFW NSLP deployed can use the EXTERNAL request message to allow a secure access to the network. Using the EXTERNAL request message does allow the DR to open the firewall/NAT on the receiver's side. However, the edge-devices should not allow the firewall/NAT to be opened up completely (i.e., should not apply an allow-all policy), but should let DRs reserve very specific policies. For instance, a DR can request reservation of an 'allow' policy rule for an incoming TCP connection for a Jabber file transfer. This reserved policy (see Figure 15) rule must be activated by matching the CREATE request message (see Figure 15). This mechanism allows for the authentication and authorization issues to be managed locally at the particular edge-network. In the reverse direction, the CREATE request message can be handled independently on the DS side with respect to authentication and authorization.
NATFW NSLPを導入した各ネットワークedgeは、EXTERNAL要求メッセージを使ってネットワークへの安全なアクセスを許可できます。EXTERNAL要求メッセージによって、DRは受信側のファイアウォールまたはNATを開けられます。ただし、edge装置はファイアウォールまたはNATを全面的に開放する（つまりallow-allポリシーを適用する）べきではありません。DRが非常に限定的なポリシーを予約できるようにするべきです。たとえばDRは、Jabberのファイル転送用に、着信TCP接続を許可するポリシールールを予約できます。この予約済みルール（図15参照）は、一致するCREATE要求メッセージ（図15参照）によって有効化する必要があります。この仕組みにより、特定のedgeネットワークで認証・認可をローカルに管理できます。逆方向では、CREATE要求メッセージに対する認証・認可をDS側で独立して処理できます。
The usage described in the above paragraph is further simplified for an incremental deployment: there is no requirement to activate a reserved policy rule with a CREATE request message. This is completely handled by the EXTERNAL-PROXY request message and the associated CREATE request message. Both of them are handled by the local authentication and authorization scheme.
前段落の利用方法は、段階的な導入ではさらに簡素化されます。予約済みポリシールールをCREATE要求メッセージで有効化する必要はありません。EXTERNAL-PROXY要求メッセージと、それに対応するCREATE要求メッセージだけで処理します。どちらのメッセージもローカルの認証・認可方式で処理します。
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempts to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as STUN [RFC5389] are considered as a general class of workarounds for NAT traversal and as solutions for scenarios with no middlebox communication.
This memo specifies a path-coupled middlebox communication protocol, i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are not intended as a short-term workaround, but more as a long-term solution for middlebox communication. In NSIS, endpoints are involved in allocating, maintaining, and deleting addresses and ports at the middlebox. However, the full control of addresses and ports at the middlebox is at the NATFW NSLP daemon located at the respective NAT.
本メモでは、パス結合型のミドルボックス通信プロトコル、すなわちNSIS NATFW NSLPを規定します。NSIS全般およびNATFW NSLPは短期的な回避策ではなく、ミドルボックス通信の長期的な解決策として意図されています。NSISでは、エンドポイントがミドルボックスでのアドレスとポートの割り当て、維持、削除に関与します。ただし、ミドルボックス上のアドレスとポートを完全に制御するのは、それぞれのNATに置かれたNATFW NSLPデーモンです。
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.
したがって本書は、長期的な代替策を提案することで、[RFC3424]のUNSAFに関する考慮事項に対処します。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the NATFW NSLP, in accordance with BCP 26, RFC 5226 [RFC5226].
この節では、BCP 26およびRFC 5226 [RFC5226]に従い、NATFW NSLPに関する値を登録するための指針をInternet Assigned Numbers Authority（IANA）に示します。
The NATFW NSLP requires IANA to create a number of new registries:
NATFW NSLPでは、IANAが次の新しいレジストリを作成する必要があります。
o NATFW NSLP Message Types
o NATFW NSLPメッセージタイプ
o NATFW NSLP Header Flags
o NATFW NSLPヘッダーフラグ
o NSLP Response Codes
o NSLP応答コード
It also requires registration of new values in a number of registries:
また、次の既存レジストリに新しい値を登録する必要があります。
o NSLP Message Objects
o NSLPメッセージオブジェクト
o NSLP Identifiers (under GIST Parameters)
o NSLP識別子（GISTパラメーター内）
o Router Alert Option Values (IPv4 and IPv6)
o Router Alertオプション値（IPv4およびIPv6）
The NATFW NSLP Message Type is an 8-bit value. The allocation of values for new message types requires IETF Review. Updates and deletion of values from the registry are not possible. This specification defines four NATFW NSLP message types, which form the initial contents of this registry. IANA has added these four NATFW NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE (0x3), and NOTIFY (0x4). 0x0 is Reserved. Each registry entry consists of value, description, and reference.
NATFW NSLPメッセージタイプは8ビット値です。新しいメッセージタイプへの値の割り当てにはIETF Reviewが必要です。レジストリ値の更新や削除はできません。本仕様では、レジストリの初期登録項目となる4つのNATFW NSLPメッセージタイプを定義します。IANAはCREATE（0x1）、EXTERNAL（0x2）、RESPONSE（0x3）、NOTIFY（0x4）の4つを登録しました。0x0はReservedです。各登録項目には、値、説明、および参照情報を記載します。
NATFW NSLP messages have a message-specific 8-bit flags/reserved field in their header. The registration of flags is subject to IANA registration. The allocation of values for flag types requires IETF Review. Updates and deletion of values from the registry are not possible. This specification defines only two flags in Section 4.1, the P flag (bit 8) and the E flag (bit 9). Each registry entry consists of value, bit position, description (containing the section number), and reference.
NATFW NSLPメッセージのヘッダーには、メッセージごとに用いる8ビットのフラグ／予約フィールドがあります。フラグの登録はIANAが管理します。フラグ種別への値の割り当てにはIETF Reviewが必要です。レジストリ値の更新や削除はできません。本仕様ではセクション4.1の2つのフラグ、Pフラグ（ビット8）とEフラグ（ビット9）だけを定義します。各登録項目には、値、ビット位置、説明（節番号を含む）、および参照情報を記載します。
In Section 4.2 this document defines 9 objects for the NATFW NSLP: NATFW_LT, NATFW_EXTERNAL_IP, NATFW_EXTERNAL_BINDING, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, NATFW_ICMP_TYPES. IANA has assigned values for them from the NSLP Message Objects registry.
本書のセクション4.2では、NATFW NSLP用に次の9つのオブジェクトを定義します。NATFW_LT、NATFW_EXTERNAL_IP、NATFW_EXTERNAL_BINDING、NATFW_EFI、NATFW_INFO、NATFW_NONCE、NATFW_MSN、NATFW_DTINFO、NATFW_ICMP_TYPES。IANAはNSLP Message Objectsレジストリから、それぞれに値を割り当てました。
In addition, this document defines a number of Response Codes for the NATFW NSLP. These can be found in Section 4.2.5 and have been assigned values from the NSLP Response Code registry. The allocation of new values for Response Codes requires IETF Review. IANA has assigned values for them as given in Section 4.2.5 for the error class and also for the number of responses values per error class. Each registry entry consists of response code, value, description, and reference.
本書ではNATFW NSLP用に複数の応答コードも定義しています。これらはセクション4.2.5に示されており、NSLP Response Codeレジストリから値が割り当てられています。新しい応答コード値の割り当てにはIETF Reviewが必要です。IANAはセクション4.2.5に示すとおり、エラークラスの値と各エラークラス内の応答コード値を割り当てました。各登録項目には、応答コード、値、説明、および参照情報を記載します。
GIST NSLPID
GIST NSLPID
This specification defines an NSLP for use with GIST and thus requires an assigned NSLP identifier. IANA has added one new value (33) to the NSLP Identifiers (NSLPID) registry defined in [RFC5971] for the NATFW NSLP.
本仕様はGISTで使うNSLPを定義するため、NSLP識別子の割り当てが必要です。IANAはNATFW NSLP用に、[RFC5971]で定義されたNSLP Identifiers（NSLPID）レジストリへ新しい値33を追加しました。
IPv4 and IPv6 Router Alert Option (RAO) value
IPv4およびIPv6のRouter Alert Option（RAO）値
The GIST specification also requires that each NSLP-ID be associated with specific Router Alert Option (RAO) value. For the purposes of the NATFW NSLP, a single IPv4 RAO value (65) and a single IPv6 RAO value (68) have been allocated.
GIST仕様では、各NSLP-IDを特定のRouter Alert Option（RAO）値に関連付ける必要があります。NATFW NSLP用には、IPv4 RAO値65とIPv6 RAO値68がそれぞれ1つ割り当てられています。
We would like to thank the following individuals for their contributions to this document at different stages:
本書の作成にあたり、各段階で貢献いただいた次の方々に感謝します。
o Marcus Brunner and Henning Schulzrinne for their work on IETF documents that led us to start with this document;
o Marcus Brunner and Henning Schulzrinne：本書の作成開始につながったIETF文書での取り組み。
o Miquel Martin for his large contribution on the initial version of this document and one of the first prototype implementations;
o Miquel Martin：本書の初版と初期のプロトタイプ実装の1つへの多大な貢献。
o Srinath Thiruvengadam and Ali Fessi work for their work on the NAT/firewall threats document;
o Srinath Thiruvengadam and Ali Fessi：NAT／ファイアウォールの脅威に関する文書での取り組み。
o Henning Peters for his comments and suggestions;
o Henning Peters：コメントと提案。
o Ben Campbell as Gen-ART reviewer;
o Ben Campbell：Gen-ARTレビュアー。
o and the NSIS working group.
o NSISワーキンググループ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[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., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[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., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
[rsvp-firewall] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as firewall Signalling Protocol", Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pp. 57 to 62, IEEE Computer Society Press, July 2001.
[rsvp-firewall] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as firewall Signalling Protocol", Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pp. 57 to 62, IEEE Computer Society Press, July 2001.
As with all other message types, EXTERNAL messages need a reachable IP address of the data sender on the GIST level. For the path-coupled MRM, the source-address of GIST is the reachable IP address (i.e., the real IP address of the data sender, or a wildcard). While this is straightforward, it is not necessarily so for the loose-end MRM. Many applications do not provide the IP address of the communication counterpart, i.e., either the data sender or both a data sender and receiver. For the EXTERNAL messages, the case of data sender is of interest only. The rest of this section gives informational guidance about determining a good destination-address of the LE-MRM in GIST for EXTERNAL messages.
他のメッセージタイプと同様に、EXTERNALメッセージではGISTレベルでデータ送信者の到達可能なIPアドレスが必要です。パス結合型MRMでは、GISTのsource-addressが到達可能なIPアドレス（データ送信者の実IPアドレスまたはワイルドカード）です。これは明確ですが、LE-MRMではそうとは限りません。多くのアプリケーションは通信相手、つまりデータ送信者、またはデータ送信者と受信者の双方のIPアドレスを提供しません。EXTERNALメッセージではデータ送信者のIPアドレスだけが問題になります。この付録の残りでは、EXTERNALメッセージ用のGIST LE-MRMで適切なdestination-addressを選ぶための参考情報を示します。
This signaling destination address (SDA, the destination-address in GIST) can be the data sender, but for applications that do not provide an address upfront, the destination IP address has to be chosen independently, as it is unknown at the time when the NATFW NSLP signaling has to start. Choosing the 'correct' destination IP address may be difficult and it is possible that there is no 'right answer' for all applications relying on the NATFW NSLP.
シグナリング宛先アドレス（SDA、GISTのdestination-address）にはデータ送信者のアドレスを使えます。ただし、アドレスを事前に提供しないアプリケーションでは、NATFW NSLPシグナリングを開始する時点でデータ送信者のIPアドレスが分からないため、宛先IPアドレスを別途選ぶ必要があります。「正しい」宛先IPアドレスを選ぶのは難しい場合があり、NATFW NSLPを利用するすべてのアプリケーションに共通する正解がないこともあります。
Whenever possible, it is RECOMMENDED to chose the data sender's IP address as the SDA. It is necessary to differentiate between the received IP addresses on the data sender. Some application-level signaling protocols (e.g., SIP) have the ability to transfer multiple contact IP addresses of the data sender. For instance, private IP addresses, public IP addresses at a NAT, and public IP addresses at a relay. It is RECOMMENDED to use all non-private IP addresses as SDAs.
可能な場合は、データ送信者のIPアドレスをSDAに選ぶことが推奨されます (SHOULD)。データ送信者が提示するIPアドレスは区別する必要があります。一部のアプリケーション層シグナリングプロトコル（SIPなど）は、データ送信者の複数の連絡先IPアドレスを伝えられます。たとえば、プライベートIPアドレス、NAT上のパブリックIPアドレス、リレー上のパブリックIPアドレスです。プライベート以外のIPアドレスをすべてSDAとして使うことが推奨されます (SHOULD)。
A different SDA must be chosen, if the IP address of the data sender is unknown. This can have multiple reasons: the application-level signaling protocol cannot determine any data sender IP address at this point in time or the data receiver is server behind a NAT, i.e., accepting inbound packets from any host. In this case, the NATFW NSLP can be instructed to use the public IP address of an application server or any other node. Choosing the SDA in this case is out of the scope of the NATFW NSLP and depends on the application's choice. The local network can provide a network-SDA, i.e., an SDA that is only meaningful to the local network. This will ensure that GIST packets with destination-address set to this network-SDA are going to be routed to an edge-NAT or edge-firewall.
データ送信者のIPアドレスが分からない場合は、別のSDAを選ぶ必要があります。アプリケーション層のシグナリングプロトコルがその時点でデータ送信者のIPアドレスを特定できない場合や、データ受信者がNATの背後にあるサーバーで、任意のホストからの着信パケットを受け付ける場合など、理由はいくつかあります。この場合、NATFW NSLPにアプリケーションサーバーや別のノードのパブリックIPアドレスを使うよう指示できます。この場合のSDAの選択はNATFW NSLPの範囲外であり、アプリケーション側が決めます。ローカルネットワークは、そのネットワーク内でのみ意味を持つnetwork-SDAを提供できます。これにより、destination-addressにnetwork-SDAを設定したGISTパケットがedge-NATまたはedge-firewallへルーティングされます。
The NATFW_EXTERNAL_BINDING object carries information, which has a different utility to the information carried within the NATFW_EXTERNAL_IP object. The NATFW_EXTERNAL_IP object has the public IP address and potentially port numbers that can be used by the application at the NI to be reachable via the public Internet. However, there are cases in which various NIs are located behind the same public NAT, but are subject to a multi-level NAT deployment, as shown in Figure 35. They can use their public IP address port assigned to them to communicate between each other (e.g., NI with NR1 and NR2) but they are forced to send their traffic through the edge-NAT, even though there is a shorter way possible.
NATFW_EXTERNAL_BINDINGオブジェクトとNATFW_EXTERNAL_IPオブジェクトには、用途の異なる情報が格納されます。NATFW_EXTERNAL_IPオブジェクトには、パブリックインターネット経由で到達可能にするためにNI上のアプリケーションが使うパブリックIPアドレスと、該当する場合はポート番号が格納されます。一方、図35のように、複数のNIが同じパブリックNATの背後にあり、さらに多段NATが配置されている場合があります。それぞれに割り当てられたパブリックIPアドレスとポートを使って相互に通信できます（たとえば、NIとNR1またはNR2の通信）。しかし、より短い経路があっても、トラフィックをedge-NAT経由で送らざるを得ません。
NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP) | NR1--192.168.0/24-- NAT3-- | NR2 10.1.2.3
NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP) | NR1--192.168.0/24-- NAT3-- | NR2 10.1.2.3
Figure 35: Multi-Level NAT Scenario
図35：多段NATのシナリオ
Figure 35 shows an example that is explored here:
図35に、以下で検討する例を示します。
1. NI -> NR1: Both NI and NR1 send EXTERNAL messages towards NAT2 and get an external address+port binding. Then, they exchange that external binding and all traffic gets pinned to NAT2 instead of taking the shortest path by NAT1 to NAT3 directly. However, to do that, NR1 and NI both need to be aware that they also have the address on the external side of NAT1 and NAT3, respectively. If ICE is deployed and there is actually a STUN server in the 10/8 network configured, it is possible to get the shorter path to work. The NATFW NSLP provides all external addresses in the NATFW_EXTERNAL_BINDING towards the public network it could allow for optimizations.
1. NI -> NR1：NIとNR1はどちらもNAT2に向けてEXTERNALメッセージを送り、外部アドレスとポートのバインディングを取得します。その後、両者がその外部バインディングを交換すると、トラフィックはNAT1からNAT3へ直接向かう最短経路を通らず、NAT2を経由するよう固定されます。この経路を短縮するには、NIとNR1がそれぞれNAT1とNAT3の外部側アドレスも持つことを認識する必要があります。ICEを導入し、10/8ネットワークにSTUNサーバーを実際に設定していれば、短い経路を利用できる可能性があります。NATFW NSLPは、外部アドレスをすべてNATFW_EXTERNAL_BINDINGでパブリックネットワーク側に伝え、経路の最適化を可能にできます。
2. For the case NI -> NR2 is even more obvious. Pinning this to NAT2 is an important fallback, but allowing for trying for a direct path between NAT1 and NAT3 might be worth it.
2. NI -> NR2の場合は、さらに分かりやすい例です。NAT2経由に固定する方法は重要な代替手段ですが、NAT1からNAT3への直接経路も試せるようにするとよい場合があります。
Please note that if there are overlapping address domains between NR and the public Internet, the regular routing will not necessary allow sending the packet to the right domain.
NRとパブリックインターネットの間でアドレス領域が重複している場合、通常のルーティングでは必ずしもパケットを正しい領域に送れるとは限りません。
Section 3.7.2 describes how data receivers behind middleboxes can instruct inbound firewalls/NATs to forward NATFW NSLP signaling towards them. Finding an inbound edge-NAT in an address environment with NAT'ed addresses is quite easy. It is only required to find some edge-NAT, as the data traffic will be route-pinned to the NAT. Locating the appropriate edge-firewall with the PC-MRM sent inbound is difficult. For cases with a single, symmetric route from the Internet to the data receiver, it is quite easy; simply follow the default route in the inbound direction.
セクション3.7.2では、ミドルボックスの背後にいるデータ受信者が、受信側ファイアウォールまたはNATにNATFW NSLPシグナリングを自分に向けて転送するよう指示する方法を説明しました。NAT変換されたアドレスを使う環境では、受信側のedge-NATを見つけるのは比較的簡単です。データトラフィックはNATまで経路固定されるため、edge-NATを1つ見つければ十分です。一方、受信方向に送るPC-MRMを使って適切なedge-firewallを見つけるのは困難です。インターネットからデータ受信者までの経路が1つで対称な場合は簡単で、受信方向のデフォルトルートに従えばよいです。
+------+ Data Flow
+-------| EFW1 +----------+ <===========
| +------+ ,--+--.
+--+--+ / \
NI+-----| FW1 | (Internet )----NR+/NI/DS
NR +--+--+ \ /
| +------+ `--+--'
+-------| EFW2 +----------+
+------+
~~~~~~~~~~~~~~~~~~~~~>
Signaling Flow
Figure 36: Data Receiver behind Multiple Firewalls Located in Parallel
図36：並列に配置された複数のファイアウォールの背後にいるデータ受信者
When a data receiver, and thus NR, is located in a network site that is multihomed with several independently firewalled connections to the public Internet (as shown in Figure 36), the specific firewall through which the data traffic will be routed has to be ascertained. NATFW NSLP signaling messages sent from the NI+/NR during the EXTERNAL message exchange towards the NR+ must be routed by the NTLP to the edge-firewall that will be passed by the data traffic as well. The NTLP would need to be aware about the routing within the Internet to determine the path between the DS and DR. Out of this, the NTLP could determine which of the edge-firewalls, either EFW1 or EFW2, must be selected to forward the NATFW NSLP signaling. Signaling to the wrong edge-firewall, as shown in Figure 36, would install the NATFW NSLP policy rules at the wrong device. This causes either a blocked data flow (when the policy rule is 'allow') or an ongoing attack (when the policy rule is 'deny'). Requiring the NTLP to know all about the routing within the Internet is definitely a tough challenge and usually not possible. In a case as described, the NTLP must basically give up and return an error to the NSLP level, indicating that the next hop discovery is not possible.
データ受信者、したがってNRが、パブリックインターネットへの接続ごとに独立したファイアウォールを持つマルチホーム環境にある場合（図36参照）、データトラフィックが通るファイアウォールを特定する必要があります。EXTERNALメッセージの交換中にNI+／NRからNR+へ送られるNATFW NSLPシグナリングメッセージは、データトラフィックも通るedge-firewallへNTLPがルーティングする必要があります。DSとDRの間の経路を決めるには、NTLPがインターネット内のルーティング情報を把握しなければなりません。それができれば、NATFW NSLPシグナリングの転送先としてEFW1とEFW2のどちらを選ぶべきか判断できます。図36のように誤ったedge-firewallへシグナリングすると、誤った装置にNATFW NSLPのポリシールールを設定します。その結果、actionが'allow'ならデータフローが遮断され、actionが'deny'なら攻撃が継続するおそれがあります。NTLPにインターネット内のあらゆるルーティング情報を要求するのは非常に困難で、通常は実現できません。このような場合、NTLPは処理を断念し、次ホップを検出できないことを示すエラーをNSLP層に返す必要があります。
This section gives some examples on how NATFW NSLP policy rules could be mapped to real firewall or NAT resources. The firewall rules and NAT bindings are described in a natural way, i.e., in a way that one will find in common implementations.
この節では、NATFW NSLPのポリシールールを実際のファイアウォールルールやNATリソースに対応付ける例を示します。ファイアウォールルールとNATバインディングは、一般的な実装で見られる形式で説明します。
The policy rule/MRI to be installed can be wildcarded to some degree. Wildcarding applies to IP address, transport layer port numbers, and the IP payload (or next header in IPv6). Processing of wildcarding splits into the NTLP and the NATFW NSLP layer. The processing at the NTLP layer is independent of the NSLP layer processing and per-layer constraints apply. For wildcarding in the NTLP, see Section 5.8 of [RFC5971].
設定するポリシールールまたはMRIでは、一部の値をワイルドカードにできます。ワイルドカード指定の対象は、IPアドレス、トランスポート層のポート番号、およびIPペイロード（IPv6ではNext Header）です。ワイルドカード処理はNTLP層とNATFW NSLP層に分かれます。NTLP層での処理はNSLP層の処理と独立しており、各層に固有の制約が適用されます。NTLPのワイルドカード指定については[RFC5971]のセクション5.8を参照してください。
Wildcarding at the NATFW NSLP level is always a node local policy decision. A signaling message carrying a wildcarded MRI (and thus policy rule) arriving at an NSLP node can be rejected if the local policy does not allow the request. For instance, take an MRI with IP addresses set (not wildcarded), transport protocol TCP, and TCP port numbers completely wildcarded. If the local policy allows only requests for TCP with all ports set and not wildcarded, the request is going to be rejected.
NATFW NSLP層でのワイルドカード指定は、常にノードごとのローカルポリシー判断です。MRI（したがってポリシールール）にワイルドカードを含むシグナリングメッセージがNSLPノードに到着した場合、ローカルポリシーが要求を許可しなければ拒否できます。たとえば、IPアドレスは指定し、トランスポートプロトコルをTCPとし、TCPポート番号をすべてワイルドカードにしたMRIを考えます。すべてのポートが明示され、ワイルドカードでないTCP要求だけをローカルポリシーが許可する場合、この要求は拒否されます。
This section describes how a NSLP policy rule signaled with a CREATE message is mapped to a firewall rule. The MRI is set as follows:
この節では、CREATEメッセージで通知されたNSLPポリシールールをファイアウォールルールに対応付ける方法を説明します。MRIを次のように設定します。
o network-layer-version=IPv4
o network-layer-version=IPv4
o source-address=192.0.2.100, prefix-length=32
o source-address=192.0.2.100, prefix-length=32
o destination-address=192.0.50.5, prefix-length=32
o destination-address=192.0.50.5, prefix-length=32
o IP-protocol=UDP
o IP-protocol=UDP
o L4-source-port=34543, L4-destination-port=23198
o L4-source-port=34543, L4-destination-port=23198
The NATFW_EFI object is set to action=allow and sub_ports=0.
NATFW_EFI object is set to action=allow and sub_ports=0.
The resulting policy rule (firewall rule) to be installed might look like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198.
設定するポリシールール（ファイアウォールルール）は、たとえば次のようになります。allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198。
This section describes how a NSLP policy rule signaled with an EXTERNAL message is mapped to a NAT binding. It is assumed that the EXTERNAL message is sent by a NI+ located behind a NAT and does contain a NATFW_DTINFO object. The MRI is set following using the signaling destination address, since the IP address of the real data sender is not known:
この節では、EXTERNALメッセージで通知されたNSLPポリシールールをNATバインディングに対応付ける方法を説明します。ここでは、NATFW_DTINFOオブジェクトを含むEXTERNALメッセージが、NATの背後にいるNI+から送られるものとします。実際のデータ送信者のIPアドレスが不明なため、MRIではシグナリング宛先アドレスを使って次の項目を設定します。
o network-layer-version=IPv4
o ネットワークレイヤーバージョン= IPv4
o source-address= 192.168.5.100
o source-address= 192.168.5.100
o destination-address=SDA
o destination-address=SDA
o IP-protocol=UDP
o IP-protocol=UDP
The NATFW_EFI object is set to action=allow and sub_ports=0. The NATFW_DTINFO object contains these parameters:
NATFW_EFI object is set to action=allow and sub_ports=0. NATFW_DTINFOオブジェクトには、次のパラメーターが含まれます。
o P=1
o P=1
o dest prefix=0
o dest prefix=0
o protocol=UDP
o protocol=UDP
o dst port number = 20230, src port number=0
o dst port number = 20230, src port number=0
o src IP=0.0.0.0
o src IP=0.0.0.0
The edge-NAT allocates the external IP 192.0.2.79 and port 45000.
edge-NATは、外部IPアドレス192.0.2.79とポート45000を割り当てます。
The resulting policy rule (NAT binding) to be installed could look like: translate udp from any to 192.0.2.79 port=45000 to 192.168.5.100 port=20230.
設定するポリシールール（NATバインディング）は、たとえば次のようになります。translate udp from any to 192.0.2.79 port=45000 to 192.168.5.100 port=20230。
The dynamic configuration of twice-NATs requires application-level support, as stated in Section 2.5. The NATFW NSLP cannot be used for configuring twice-NATs if application-level support is needed. Assuming application-level support performing the configuration of the twice-NAT and the NATFW NSLP being installed at this devices, the NATFW NSLP must be able to traverse it. The NSLP is probably able to traverse the twice-NAT, as is any other data traffic, but the flow information stored in the NTLP's MRI will be invalidated through the translation of source and destination IP addresses. The NATFW NSLP implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP signaling messages as any other NATFW NSLP node does. For the given signaling flow, the NATFW NSLP node MUST look up the corresponding IP address translation and modify the NTLP/NSLP signaling accordingly. The modification results in an updated MRI with respect to the source and destination IP addresses.
セクション2.5で述べたとおり、Twice-NATの動的な設定にはアプリケーション層のサポートが必要です。アプリケーション層のサポートが必要なTwice-NATの設定には、NATFW NSLPを使えません。アプリケーション層がTwice-NATを設定し、装置にNATFW NSLPが導入されている場合、NATFW NSLPはその装置を通過できる必要があります。NSLPは他のデータトラフィックと同様にTwice-NATを通過できると考えられますが、送信元および宛先IPアドレスが変換されるため、NTLPのMRIに格納されたフロー情報は無効になります。Twice-NAT上のNATFW NSLP実装は、他のNATFW NSLPノードと同様に、NATFW NSLPおよびNTLPのシグナリングメッセージを捕捉しなければなりません (MUST)。該当するシグナリングフローについて、NATFW NSLPノードは対応するIPアドレス変換を検索し、それに応じてNTLP／NSLPのシグナリングを変更しなければなりません (MUST)。変更後のMRIには、変換後の送信元および宛先IPアドレスを反映します。
This section gives an example on how to use the NATFW NLSP for a receiver behind a NAT, where only the receiving side is NATFW NSLP enabled. We assume FTP as the application to show a working example. An FTP server is located behind a NAT, as shown in Figure 5, and uses the NATFW NSLP to allocate NAT bindings for the control and data channel of the FTP protocol. The information about where to reach the server is communicated by a separate protocol (e.g., email, chat) to the DS side.
この節では、受信側だけがNATFW NSLPに対応している場合に、NATの背後にいる受信者にNATFW NLSPを使う例を示します。実際に動作する例としてFTPを使います。図5のようにFTPサーバーはNATの背後にあり、FTPプロトコルの制御チャネルとデータチャネル用のNATバインディングを割り当てるため、NATFW NSLPを使います。サーバーへの接続情報は、別のプロトコル（メールやチャットなど）でDS側に伝えます。
Public Internet Private Address
Space
FTP Client FTP Server
DS NAT NI+
| | |
| | EXTERNAL |
| |<---------------------------|(1)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(2)
| |CREATE |
| |--------------------------->|(3)
| |RESPONSE[Success] |
| |<---------------------------|(4)
| | |
| | <Use port=XYZ, IP=a.b.c.d> |
|<=======================================================|(5)
|FTP control port=XYZ | FTP control port=21 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6)
| | |
| FTP control/get X | FTP control/get X |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7)
| | EXTERNAL |
| |<---------------------------|(8)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(9)
| |CREATE |
| |--------------------------->|(10)
| |RESPONSE[Success] |
| |<---------------------------|(11)
| | |
| Use port=FOO, IP=a.b.c.d | Use port=FOO, IP=a.b.c.d |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12)
| | |
|FTP data to port=FOO | FTP data to port=20 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13)
Figure 37: Flow Chart
図37：フローチャート
1. EXTERNAL request message sent to NAT, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (carrying nonce for CREATE), and the data terminal information object (I/P-flags set, sender prefix=0, protocol=TCP, DR port number = 21, DS's IP address=0); using the LE-MRM. This is used to allocate the external binding for the FTP control channel (TCP, port 21).
1. 次のオブジェクトを含むEXTERNAL要求メッセージをLE-MRMでNATへ送ります。シグナリングセッション有効期間、拡張フロー情報オブジェクト（rule action=allow、sub_ports=0）、メッセージシーケンス番号オブジェクト、CREATE用のnonceを格納するNonceオブジェクト、およびdata terminal informationオブジェクト（I/P-flags set、sender prefix=0、protocol=TCP、DR port number = 21、DS's IP address=0）。これによりFTP制御チャネル（TCP、ポート21）用の外部バインディングを割り当てます。
2. Successful RESPONSE sent to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), external address object (port=XYZ, IPv4 addr=a.b.c.d).
2. 次のオブジェクトを含む成功RESPONSEをNI+へ送ります。シグナリングセッション有効期間、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（'Success':2）、外部アドレスオブジェクト（port=XYZ、IPv4 addr=a.b.c.d）。
3. The NAT sends a CREATE towards NI+, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (with copied value from (1)); using the PC-MRM (src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21, downstream).
3. NATは、次のオブジェクトを含むCREATEをNI+へ送ります。シグナリングセッション有効期間、拡張フロー情報オブジェクト（rule action=allow、sub_ports=0）、メッセージシーケンス番号オブジェクト、(1)から値をコピーしたNonceオブジェクト。PC-MRMのパラメーターは(src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21, downstream)です。
4. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
4. 次のオブジェクトを含む成功RESPONSEをNATへ送ります。シグナリングセッション有効期間、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（'Success':2）。
5. The application at NI+ sends external NAT binding information to the other end, i.e., the FTP client at the DS.
5. NI+上のアプリケーションは、外部NATバインディング情報を相手側、つまりDS上のFTPクライアントへ送ります。
6. The FTP client connects the FTP control channel to port=XYZ, IP=a.b.c.d.
6. FTPクライアントはport=XYZ、IP=a.b.c.dへFTP制御チャネルを接続します。
7. The FTP client sends a get command for file X.
7. FTPクライアントはファイルXに対するgetコマンドを送ります。
8. EXTERNAL request message sent to NAT, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (carrying nonce for CREATE), and the data terminal information object (I/P-flags set, sender prefix=32, protocol=TCP, DR port number = 20, DS's IP address=DS-IP); using the LE-MRM. This is used to allocate the external binding for the FTP data channel (TCP, port 22).
8. 次のオブジェクトを含むEXTERNAL要求メッセージをLE-MRMでNATへ送ります。シグナリングセッション有効期間、拡張フロー情報オブジェクト（rule action=allow、sub_ports=0）、メッセージシーケンス番号オブジェクト、CREATE用のnonceを格納するNonceオブジェクト、およびdata terminal informationオブジェクト（I/P-flags set、sender prefix=32、protocol=TCP、DR port number = 20、DS's IP address=DS-IP）。これによりFTPデータチャネル（TCP、ポート22）用の外部バインディングを割り当てます。
9. Successful RESPONSE sent to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), external address object (port=FOO, IPv4 addr=a.b.c.d).
9. 次のオブジェクトを含む成功RESPONSEをNI+へ送ります。シグナリングセッション有効期間、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（'Success':2）、外部アドレスオブジェクト（port=FOO、IPv4 addr=a.b.c.d）。
10. The NAT sends a CREATE towards NI+, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (with copied value from (1)); using the PC-MRM (src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20, downstream).
10. NATは、次のオブジェクトを含むCREATEをNI+へ送ります。シグナリングセッション有効期間、拡張フロー情報オブジェクト（rule action=allow、sub_ports=0）、メッセージシーケンス番号オブジェクト、(1)から値をコピーしたNonceオブジェクト。PC-MRMのパラメーターは(src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20, downstream)です。
11. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
11. 次のオブジェクトを含む成功RESPONSEをNATへ送ります。シグナリングセッション有効期間、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（'Success':2）。
12. The FTP server responses with port=FOO and IP=a.b.c.d.
12. FTPサーバーはport=FOOとIP=a.b.c.dを返します。
13. The FTP clients connects the data channel to port=FOO and IP=a.b.c.d.
13. FTPクライアントはport=FOO、IP=a.b.c.dへデータチャネルを接続します。
Authors' Addresses
著者の連絡先
Martin Stiemerling NEC Europe Ltd. and University of Goettingen Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Martin Stiemerling NEC Europe Ltd. and University of Goettingen Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Phone: +49 (0) 6221 4342 113
EMail: Martin.Stiemerling@neclab.eu
URI: http://www.stiemerling.org
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Cedric Aoun Consultant Paris, France
Cedric Aoun Consultant Paris, France
EMail: cedaoun@yahoo.fr
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly Consulting Soham UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com