idnits 2.17.1 draft-ietf-nsis-nslp-natfw-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2803. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2819), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 841 has weird spacing: '...creates polic...' == Line 842 has weird spacing: '...rvation mode ...' == Line 850 has weird spacing: '...nvolved will ...' == Line 1090 has weird spacing: '... o The data ...' == Line 1123 has weird spacing: '... device respo...' == (5 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Processing of REA messages is specific to the NSIS node type: o NSLP initiator: NI+ only generate REA messages and should never receive them. o NSLP forwarder: NSLP forwarders receiving REA messages MUST first check authentication and authorization before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired policy rule given by NTLP's message routing information (MRI). Further processing depends on the middlebox type: * 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 a NF MAY generate a RESPONSE message with an error of type 'REA received from outside'. If received at the internal address, an IP address/port is reserved. In the case it is an edge-NAT, the NSLP message is not forwarded any further and a RESPONSE message with the external address and port information is generated. If it is not an edge-NAT, the NSLP message is forwarded further with the translated IP address/port (if required by the NI+). * Firewall: Firewalls MUST not change their configuration upon a REA message. They simply MUST forward the message and MUST keep NTLP state. Firewalls that are configured as edge-Firewalls MAY return an error of type 'no NAT here'. * Combined NAT and Firewall: Processing at combined Firewall and NAT middleboxes is the same as in the NAT case. o NSLP receiver: This type of message should never be received by any NR+ and it SHOULD be discarded silently. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2004) is 7122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Error' on line 1191 -- Looks like a reference, but probably isn't: 'CREATE' on line 1502 -- Looks like a reference, but probably isn't: 'DSinfo' on line 1465 -- Looks like a reference, but probably isn't: 'SUCCESS' on line 1473 -- Looks like a reference, but probably isn't: 'NoNR' on line 1502 -- Looks like a reference, but probably isn't: 'M' on line 2106 -- Looks like a reference, but probably isn't: 'O' on line 2096 -- Looks like a reference, but probably isn't: 'RFC 2113' on line 2667 == Unused Reference: '5' is defined on line 2379, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2393, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2396, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2405, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2413, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 2417, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 2454, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 2462, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 2471, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 2476, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 2479, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 2483, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 2487, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 2492, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. '1') ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '2') == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '3') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '4') ** Obsolete normative reference: RFC 3330 (ref. '5') (Obsoleted by RFC 5735) == Outdated reference: A later version (-06) exists of draft-ietf-nsis-threats-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-threats (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '7') -- Duplicate reference: RFC2663, mentioned in '9', was also mentioned in '8'. -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '11') (Obsoleted by RFC 4966) == Outdated reference: A later version (-02) exists of draft-aoun-nsis-nslp-natfw-migration-01 == Outdated reference: A later version (-01) exists of draft-aoun-nsis-nslp-natfw-intrarealm-00 == Outdated reference: A later version (-01) exists of draft-martin-nsis-nslp-natfw-sip-00 -- No information found for draft-martin-nsis-nslp-natfw-security - is the name correct? == Outdated reference: A later version (-02) exists of draft-fessi-nsis-natfw-threats-01 -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '24') (Obsoleted by RFC 3852) == Outdated reference: A later version (-04) exists of draft-manner-lrsvp-00 == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-vpn-problem-statement-req-02 == Outdated reference: A later version (-03) exists of draft-ford-midcom-p2p-02 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '35') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-05 Summary: 15 errors (**), 0 flaws (~~), 35 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group M. Stiemerling 2 Internet-Draft NEC 3 Expires: April 25, 2005 H. Tschofenig 4 Siemens 5 M. Martin 6 NEC 7 C. Aoun 8 Nortel Networks 9 October 25, 2004 11 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 12 draft-ietf-nsis-nslp-natfw-04 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 25, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 46 Network Address Translators and Firewalls. This NSLP allows hosts to 47 signal along a data path for Network Address Translators and 48 Firewalls to be configured according to the data flow needs. The 49 network scenarios, problems and solutions for path-coupled Network 50 Address Translator and Firewall signaling are described. The overall 51 architecture is given by the framework and requirements defined by 52 the Next Steps in Signaling (NSIS) working group. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 7 58 1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8 59 1.3 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 60 1.4 General Scenario for NATFW Traversal . . . . . . . . . . . 9 62 2. Network Deployment Scenarios using NATFW NSLP . . . . . . . . 11 63 2.1 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 11 64 2.2 NAT with two private Networks . . . . . . . . . . . . . . 12 65 2.3 NAT with Private Network on Sender Side . . . . . . . . . 12 66 2.4 NAT with Private Network on Receiver Side Scenario . . . . 13 67 2.5 Both End Hosts behind twice-NATs . . . . . . . . . . . . . 14 68 2.6 Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 15 69 2.7 IPv4/v6 NAT with two Private Networks . . . . . . . . . . 15 70 2.8 Multihomed Network with NAT . . . . . . . . . . . . . . . 16 72 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 18 73 3.1 Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 18 74 3.2 Basic protocol overview . . . . . . . . . . . . . . . . . 18 75 3.3 Protocol Operations . . . . . . . . . . . . . . . . . . . 20 76 3.3.1 Creating Sessions . . . . . . . . . . . . . . . . . . 21 77 3.3.2 Reserving External Addresses . . . . . . . . . . . . . 23 78 3.3.3 NATFW Session refresh . . . . . . . . . . . . . . . . 27 79 3.3.4 Deleting Sessions . . . . . . . . . . . . . . . . . . 28 80 3.3.5 Reporting Asynchronous Events . . . . . . . . . . . . 29 81 3.3.6 QUERY capabilities within the NATFW NSLP protocol . . 30 82 3.3.7 QUERY Message semantics . . . . . . . . . . . . . . . 31 83 3.3.8 Reserving External Addresses and triggering Create 84 messages . . . . . . . . . . . . . . . . . . . . . . . 32 85 3.3.9 Using CREATE messages to Trigger Reverse Path 86 CREATE Messages . . . . . . . . . . . . . . . . . . . 34 87 3.4 Calculation of Session Lifetime . . . . . . . . . . . . . 36 88 3.5 Firewall and NAT Resources . . . . . . . . . . . . . . . . 38 89 3.6 De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 38 90 3.7 Selecting Opportunistic Addresses for REA . . . . . . . . 38 92 4. NATFW NSLP NTLP Requirements . . . . . . . . . . . . . . . . . 40 94 5. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 41 95 5.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 41 96 5.2 NSLP message types . . . . . . . . . . . . . . . . . . . . 41 97 5.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 42 98 5.3.1 Session Lifetime Object . . . . . . . . . . . . . . . 42 99 5.3.2 External Address Object . . . . . . . . . . . . . . . 43 100 5.3.3 Extended Flow Information Object . . . . . . . . . . . 44 101 5.3.4 Response Code Object . . . . . . . . . . . . . . . . . 45 102 5.3.5 Response Type Object . . . . . . . . . . . . . . . . . 45 103 5.3.6 Message Sequence Number Object . . . . . . . . . . . . 46 104 5.3.7 Scoping Object . . . . . . . . . . . . . . . . . . . . 46 105 5.3.8 Bound Session ID Object . . . . . . . . . . . . . . . 47 106 5.3.9 Notify Target Object . . . . . . . . . . . . . . . . . 47 107 5.4 Message Formats . . . . . . . . . . . . . . . . . . . . . 48 108 5.4.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 48 109 5.4.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 49 110 5.4.3 TRIGGER . . . . . . . . . . . . . . . . . . . . . . . 49 111 5.4.4 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 49 112 5.4.5 QUERY . . . . . . . . . . . . . . . . . . . . . . . . 50 113 5.4.6 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 50 115 6. NSIS NAT and Firewall Transition Issues . . . . . . . . . . . 51 117 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 118 7.1 Trust Relationship and Authorization . . . . . . . . . . . 52 119 7.1.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 53 120 7.1.2 Intra-Domain Trust Relationship . . . . . . . . . . . 54 121 7.1.3 End-to-Middle Trust Relationship . . . . . . . . . . . 55 123 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 57 125 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 58 127 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 128 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 59 129 10.2 Informative References . . . . . . . . . . . . . . . . . . . 59 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 62 133 A. Problems and Challenges . . . . . . . . . . . . . . . . . . . 63 134 A.1 Missing Network-to-Network Trust Relationship . . . . . . 63 135 A.2 Relationship with routing . . . . . . . . . . . . . . . . 64 136 A.3 Affected Parts of the Network . . . . . . . . . . . . . . 64 137 A.4 NSIS backward compatibility with NSIS unaware NAT and 138 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 64 139 A.5 Authentication and Authorization . . . . . . . . . . . . . 65 140 A.6 Directional Properties . . . . . . . . . . . . . . . . . . 65 141 A.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 66 142 A.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 66 143 A.9 Combining Middlebox and QoS signaling . . . . . . . . . . 66 144 A.10 Inability to know the scenario . . . . . . . . . . . . . . 67 146 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 148 Intellectual Property and Copyright Statements . . . . . . . . 69 150 1. Introduction 152 Firewalls and Network Address Translators (NAT) have both been used 153 throughout the Internet for many years, and they will remain present 154 for the foreseeable future. Firewalls are used to protect networks 155 against certain types of attacks from the outside, and in times of 156 IPv4 address depletion, NATs virtually extend the IP address space. 157 Both types of devices may be obstacles to many applications, since 158 they only allow traffic created by a limited set of applications to 159 traverse them (e.g., most HTTP traffic, and client/server 160 applications), due to the relatively static properties of the 161 protocols used. Other applications, such as IP telephony and most 162 other peer-to-peer applications, which have more dynamic properties, 163 create traffic which is unable to traverse NATs and Firewalls 164 unassisted. In practice, the traffic from many applications cannot 165 traverse autonomous Firewalls or NATs, even when they have added 166 functionality which attempts to restore the transparency of the 167 network. 169 Several solutions to enable applications to traverse such entities 170 have been proposed and are currently in use. Typically, application 171 level gateways (ALG) have been integrated with the Firewall or NAT to 172 configure the Firewall or NAT dynamically. Another approach is 173 middlebox communication (MIDCOM, currently under standardization at 174 the IETF). In this approach, ALGs external to the Firewall or NAT 175 configure the corresponding entity via the MIDCOM protocol [7]. 176 Several other work-around solutions are available, including STUN 177 [35] and TURN [37]. However, all of these approaches introduce other 178 problems that are generally hard to solve, such as dependencies on 179 the type of NAT implementation (full-cone, symmetric, ...), or 180 dependencies on a certain network topology. 182 NAT and Firewall (NATFW) signaling shares a property with Quality of 183 Service (QoS) signaling. The signaling of both must reach any device 184 on the data path that is involved in QoS or NATFW treatment of data 185 packets. This means, that for both, NATFW and QoS, it is convenient 186 if signaling travels path-coupled, meaning that the signaling 187 messages follow exactly the same path that the data packets take. 188 RSVP [14] is an example of a current QoS signaling protocol that is 189 path-coupled. 191 This memo defines a path-coupled signaling protocol for NAT and 192 Firewall configuration within the framework of NSIS, called the NATFW 193 NSIS Signaling Layer Protocol (NSLP). The general requirements for 194 NSIS are defined in [2]. The general framework of NSIS is outlined 195 in [1]. It introduces the split between an NSIS transport layer and 196 an NSIS signaling layer. The transport of NSLP messages is handled 197 by an NSIS Network Transport Layer Protocol (NTLP, with GIMPS [3] 198 being the implementation of the abstract NTLP). The signaling logic 199 for QoS and NATFW signaling is implemented in the different NSLPs. 200 The QoS NSLP is defined in [4], while the NATFW NSLP is defined in 201 this document. 203 The NATFW NSLP is designed to request the dynamic configuration of 204 NATs and/or Firewalls along the data path to enable data flows to 205 traverse these devices without being obstructed. Here is a 206 simplified example: A source host sends a NATFW NSLP signaling 207 message towards its data destination. This message follows the data 208 path. Every NATFW NSLP NAT/Firewall along the data path intercepts 209 these messages, processes them, and configures itself accordingly. 210 Afterwards, the actual data flow can traverse every configured 211 Firewall/NAT. 213 NATFW NSLP runs in two different modes, one is the CREATE mode in 214 which state at firewalls and NATs is created. In the above example, 215 this takes place in the direction from the data sender to the data 216 receiver. The other mode is the RESERVE mode. In this mode, NATs 217 are discovered by the NSLP/NTLP signaling messages, and a publicly 218 reachable IP address and a port number are reserved at each NAT. 219 This mode enables hosts located in a private addressing realm 220 delimited by a NAT to subsequently receive data originated in the 221 public network. Both modes create NATFW NSLP and NTLP state in 222 network entities. NTLP state allows signaling messages to travel in 223 the forward (downstream ) and the reverse (upstream) direction along 224 the path between an NAT/Firewall NSLP sender and a corresponding 225 receiver. NAT bindings and firewall rules are NAT/Firewall specific 226 state. This state is managed using a soft-state mechanism, i.e., it 227 expires unless it is refreshed every now and then by a CREATE 228 message. If state is to be deleted explicitly before it 229 automatically expires, another message can be used for that. To find 230 out what state is currently installed in NSIS NAT/Firewall nodes, a 231 QUERY message can be used at any time. 233 Section 2 describes the network environment for NATFW NSLP signaling, 234 highlighting the trust relationships and authorization required. 235 Section 3 defines the NATFW signaling protocol. Section 5 defines 236 the messages and and message components. In the remaining parts of 237 the main body of the document, Section 6 covers transition issues, 238 while Section 7 addresses security considerations, with more 239 extensive discussions of security issues currently being contained in 240 [20]. Currently unsolved problems and challenges are listed and 241 discussed in Appendix A. Please note that readers familiar with 242 Firewalls and NATs and their possible location within networks can 243 safely skip Section 2. 245 1.1 Terminology and Abbreviations 247 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 248 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 249 document are to be interpreted as described in RFC 2119. 251 This document uses a number of terms defined in [2]. The following 252 additional terms are used: 253 o NSIS NAT Forwarding State: This term refers to a state used to 254 forward the NSIS signaling message towards the targeted 255 destination address. 256 o Policy rule: A policy rule is "a basic building block of a 257 policy-based system. It is the binding of a set of actions to a 258 set of conditions - where the conditions are evaluated to 259 determine whether the actions are performed" [38]. In the context 260 of NSIS NATFW NSLP, the condition is a specification of a set of 261 packets to which rules are applied. The set of actions always 262 contains just a single element per rule, and is limited to either 263 action "reserved", "deny" or action "allow". 264 o Firewall: A packet filtering device that matches packets against a 265 set of policy rules and applies the actions. In the context of 266 NSIS NATFW NSLP we refer to this device as a Firewall. 267 o Network Address Translator: Network Address Translation is a 268 method by which IP addresses are mapped from one realm to another, 269 in an attempt to provide transparent routing between hosts (see 270 [8]). Network Address Translators are devices that perform this 271 work. 272 o Middlebox: "A middlebox is defined as any intermediate device 273 performing functions other than the normal, standard functions of 274 an IP router on the datagram path between a source host and a 275 destination host" [12]. In the context of this document, the term 276 middlebox refers to Firewalls and NATs only. Other types of 277 middlebox are currently outside the scope of this document. 278 o Security Gateway: IPsec based gateways. 279 o (Data) Receiver (DR or R): The node in the network that is 280 receiving the data packets of a flow. 281 o (Data) Sender (DS or S): The node in the network that is sending 282 the data packets of a flow. 283 o NATFW NSLP session: An application layer flow of information for 284 which some network control state information is to be manipulated 285 or monitored (as defined in [1]). The control state for NATFW 286 NSLP consists of NSLP state and associated policy rules at a 287 middlebox. 288 o NSIS peer or peer: An NSIS node with which an NSIS adjacency has 289 been created as defined in [3]. 290 o Edge NAT: An edge NAT is a NAT device that is reachable from the 291 public Internet and that has a globally routable IP address. 293 o Edge Firewall: An edge Firewall is a Firewall device that is 294 located on the demarcation line of an administrative domain. 295 o Public Network: "A Global or Public Network is an address realm 296 with unique network addresses assigned by Internet Assigned 297 Numbers Authority (IANA) or an equivalent address registry. This 298 network is also referred as External network during NAT 299 discussions" [8]. 300 o Private/Local Network: "A private network is an address realm 301 independent of external network addresses. Private network may 302 also be referred alternately as Local Network. Transparent 303 routing between hosts in private realm and external realm is 304 facilitated by a NAT router" [8]. IP address space allocation for 305 private networks is recommended in [36] 306 o Public/Global IP address: An IP address located in the public 307 network according to Section 2.7 of [8]. 308 o Private/Local IP address: An IP address located in the private 309 network according to Section 2.8 of [8]. 310 o Initial CREATE: A CREATE message creating a new session. 312 1.2 Middleboxes 314 The term middlebox covers a range of devices which intercept the flow 315 of packets between end hosts and perform actions other than standard 316 forwarding expected in an IP router. As such, middleboxes fall into 317 a number of categories with a wide range of functionality, not all of 318 which is pertinent to the NATFW NSLP. Middlebox categories in the 319 scope of this memo are Firewalls that filter data packets against a 320 set of filter rules, and NATs that translate packet addresses from 321 one address realm to another address realm. Other categories of 322 middleboxes, such as QoS traffic shapers and security gateways, are 323 out of scope. 325 The term NAT used in this document is a placeholder for a range of 326 different NAT flavors. We consider the following types of NATs: 327 o traditional NAT (basic NAT and NAPT) 328 o Bi-directional NAT 329 o Twice-NAT 330 o Multihomed NAT 331 For definitions and a detailed discussion about the characteristics 332 of each NAT type please see [8]. 334 Both types of middleboxes under consideration here use policy rules 335 to make a decision on data packet treatment. Policy rules consist of 336 a flow identifier which selects the packets to which the policy 337 applies and an associated action; data packets matching the flow 338 identifier are subjected to the policy rule action. A typical flow 339 identifier is the 5-tuple selector which matches the following fields 340 of a packet to configured values: 342 o Source and destination IP addresses 343 o Transport protocol number 344 o Transport source and destination port numbers 346 For further examples of flow identifiers see Section 5.1 of [3]. 348 Actions for Firewalls are usually one or more of: 349 o Allow: forward data packet 350 o Deny: block data packet and discard it 351 o Other actions such as logging, diverting, duplicating, etc 353 Actions for NATs include (amongst many others): 354 o Change source IP address and transport port number to a globally 355 routeable IP address and associated port number. 356 o Change destination IP address and transport port number to a 357 private IP address and associated port number. 359 1.3 Non-Goals 361 Traversal of non-NSIS and non-NATFW NSLP aware NATs and Firewalls 362 is outside the scope of this document. 363 Only Firewalls and NATs are considered in this document, any other 364 types of devices, for instance IPSec security gateway, are out of 365 scope. 366 The exact implementation of policy rules and their mapping to 367 firewall rule sets and NAT bindings or sessions at the middlebox 368 is an implementation issue and thus out of scope of this document. 369 Some devices categorized as firewalls only accept traffic after 370 cryptographic verification (i.e., IPsec protected data traffic). 371 Particularly for network access scenarios, either link layer or 372 network layer data protection is common. We do not address these 373 types of devices (referred to as security gateways) since per-flow 374 signaling is typically not used in this environment. 375 Another application, for which NSIS signaling has been proposed 376 but which is out of scope for this document, is discovering 377 security gateways, for the purpose of executing IKE to create an 378 IPsec SA. 379 In mobility scenarios, a common problem is the traversal of a 380 security gateway at the edge of a corporate network. Network 381 administrators allow only authenticated data to enter the network. 382 A problem statement for the traversal of these security gateways 383 in the context of Mobile IP can be found in [28]). This topic is 384 not within the scope of the present document. 386 1.4 General Scenario for NATFW Traversal 388 The purpose of NSIS NATFW signaling is to enable communication 389 between endpoints across networks even in the presence of NAT and 390 Firewall middleboxes. It is assumed that these middleboxes will be 391 statically configured in such a way that NSIS NATFW signaling 392 messages themselves are allowed to traverse them. NSIS NATFW NSLP 393 signaling is used to dynamically install additional policy rules in 394 all NATFW middleboxes along the data path. Firewalls are configured 395 to forward data packets matching the policy rule provided by the NSLP 396 signaling. NATs are configured to translate data packets matching 397 the policy rule provided by the NSLP signaling. 399 The basic high-level picture of NSIS usage is that end hosts are 400 located behind middleboxes, meaning that there is a middlebox on the 401 data path from the end host in a private network and the external 402 network (NAT/FW in Figure 1). Applications located at these end 403 hosts try to establish communication with corresponding applications 404 on other such end hosts. They trigger the NSIS entity at the local 405 host to provide for middlebox traversal along the prospective data 406 path (e.g., via an API call). The NSIS entity in turn uses NSIS 407 NATFW NSLP signaling to establish policy rules along the data path, 408 allowing the data to travel from the sender to the receiver 409 unobstructed. 411 Application Application Server (0, 1, or more) Application 413 +----+ +----+ +----+ 414 | +------------------------+ +------------------------+ | 415 +-+--+ +----+ +-+--+ 416 | | 417 | NSIS Entities NSIS Entities | 418 +-+--+ +----+ +-----+ +-+--+ 419 | +--------+ +----------------------------+ +-----+ | 420 +-+--+ +-+--+ +--+--+ +-+--+ 421 | | ------ | | 422 | | //// \\\\\ | | 423 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 424 | | | | | Internet | | | | | 425 | +--------+ +-----+ +----+ +-----+ | 426 +----+ +----+ |\ | +----+ +----+ 427 \\\\ ///// 428 sender NAT/FW (1+) ------ NATFW (1+) receiver 430 Figure 1: Generic View on NSIS in a NAT / Firewall case 432 For end-to-end NATFW signaling, it is necessary that each firewall 433 and each NAT along the path between the data sender and the data 434 receiver implement the NSIS NATFW NSLP. There might be several NATs 435 and FWs in various possible combinations on a path between two hosts. 436 Section 2 presents a number of likely scenarios with different 437 combinations of NATs and firewalls. 439 2. Network Deployment Scenarios using NATFW NSLP 441 This section introduces several scenarios for middlebox placement 442 within IP networks. Middleboxes are typically found at various 443 different locations, including at Enterprise network borders, within 444 enterprise networks, as mobile phone network gateways, etc. Usually, 445 middleboxes are placed more towards the edge of networks than in 446 network cores. Firewalls and NATs may be found at these locations 447 either alone, or they may be combined; other categories of 448 middleboxes may also be found at such locations, possibly combined 449 with the NATs and/or Firewalls. To reduce the number of network 450 elements needed, combined Firewall and NATs have been made available. 452 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 453 regular data path to the NSIS responder (NR). On the data path, 454 NATFW NSLP signaling messages reach different NSIS peers that 455 implement the NATFW NSLP. Each NATFW NSLP node processes the 456 signaling messages according to Section 3 and, if necessary, installs 457 policy rules for subsequent data packets. 459 Each of the following sub-sections introduces a different scenario 460 for a different set of middleboxes and their ordering within the 461 topology. It is assumed that each middlebox implements the NSIS 462 NATFW NSLP signaling protocol. 464 2.1 Firewall Traversal 466 This section describes a scenario with Firewalls only; NATs are not 467 involved. Each end host is behind a Firewall. The Firewalls are 468 connected via the public Internet. Figure 2 shows the topology. The 469 part labeled "public" is the Internet connecting both Firewalls. 471 +----+ //----\\ +----+ 472 NI -----| FW |---| |------| FW |--- NR 473 +----+ \\----// +----+ 475 private public private 477 FW: Firewall 478 NI: NSIS Initiator 479 NR: NSIS Responder 481 Figure 2: Firewall Traversal Scenario 483 Each Firewall on the data path must provide traversal service for 484 NATFW NSLP in order to permit the NSIS message to reach the other end 485 host. All Firewalls process NSIS signaling and establish appropriate 486 policy rules, so that the required data packet flow can traverse 487 them. 489 2.2 NAT with two private Networks 491 Figure 3 shows a scenario with NATs at both ends of the network. 492 Therefore, each application instance, NSIS initiator and NSIS 493 responder, are behind NATs. The outermost NAT at each side is 494 connected to the public Internet. The NATs are generically labeled 495 as MB (for middlebox), since those devices certainly implement NAT 496 functionality, but can implement firewall functionality as well. 498 Only two middleboxes MB are shown in Figure 3 at each side, but in 499 general, any number of MBs on each side must be considered. 501 +----+ +----+ //----\\ +----+ +----+ 502 NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR 503 +----+ +----+ \\----// +----+ +----+ 505 private public private 507 MB: Middlebox 508 NI: NSIS Initiator 509 NR: NSIS Responder 511 Figure 3: NAT with two Private Networks Scenario 513 Signaling traffic from NI to NR has to traverse all the middleboxes 514 on the path, and all the middleboxes must be configured properly to 515 allow NSIS signaling to traverse them. The NATFW signaling must 516 configure all middleboxes and consider any address translation that 517 will result from this configuration in further signaling. The sender 518 (NI) has to know the IP address of the receiver (NR) in advance, 519 otherwise it will not be possible to send any NSIS signaling messages 520 towards the responder. Note that this IP address is not the private 521 IP address of the responder. Instead a NAT binding (including a 522 public IP address) has to be previously installed on the NAT that 523 subsequently allows packets reaching the NAT to be forwarded to the 524 receiver within the private address realm. This generally requires 525 further support from an application layer protocol for the purpose of 526 discovering and exchanging information. The receiver might have a 527 number of ways to learn its public IP address and port number and 528 might need to signal this information to the sender using the 529 application level signaling protocol. 531 2.3 NAT with Private Network on Sender Side 533 This scenario shows an application instance at the sending node that 534 is behind one or more NATs (shown as generic MB, see discussion in 535 Section 2.2). The receiver is located in the public Internet. 537 +----+ +----+ //----\\ 538 NI --| MB |-----| MB |---| |--- NR 539 +----+ +----+ \\----// 541 private public 543 MB: Middlebox 544 NI: NSIS Initiator 545 NR: NSIS Responder 547 Figure 4: NAT with Private Network on Sender Side Scenario 549 The traffic from NI to NR has to traverse middleboxes only on the 550 sender's side. The receiver has a public IP address. The NI sends 551 its signaling message directly to the address of the NSIS responder. 552 Middleboxes along the path intercept the signaling messages and 553 configure the policy rules accordingly. 555 Note that the data sender does not necessarily know whether the 556 receiver is behind a NAT or not, hence, it is the receiving side that 557 has to detect whether itself is behind a NAT or not. As described in 558 Section 3.3.2 NSIS can also provide help for this procedure. 560 2.4 NAT with Private Network on Receiver Side Scenario 562 The application instance receiving data is behind one or more NATs 563 shown as MB (see discussion in Section 2.2). 565 //----\\ +----+ +----+ 566 NI ---| |---| MB |-----| MB |--- NR 567 \\----// +----+ +----+ 569 public private 571 MB: Middlebox 572 NI: NSIS Initiator 573 NR: NSIS Responder 575 Figure 5: NAT with Private Network on Receiver Scenario 577 Initially, the NSIS responder must determine its publicly reachable 578 IP address at the external middlebox and notify the NSIS initiator 579 about this address. One possibility is that an application level 580 protocol is used, meaning that the public IP address is signaled via 581 this protocol to the NI. Afterwards the NI can start its signaling 582 towards the NR and so establish the path via the middleboxes in the 583 receiver side private network. 585 This scenario describes the use case for the RESERVE mode of the 586 NATFW NSLP. 588 2.5 Both End Hosts behind twice-NATs 590 This is a special case, where the main problem arises from the need 591 to detect that both end hosts are logically within the same address 592 space, but are also in two partitions of the address realm on either 593 side of a twice-NAT (see [8] for a discussion of twice-NAT 594 functionality). 596 Sender and receiver are both within a single private address realm 597 but the two partitions potentially have overlapping IP address 598 ranges. Figure 6 shows the arrangement of NATs. This is a common 599 configuration in networks, particularly after the merging of 600 companies that have used the same private address space, resulting in 601 overlapping address ranges. 603 public 604 +----+ +----+ //----\\ 605 NI --| MB |--+--| MB |---| | 606 +----+ | +----+ \\----// 607 | 608 | +----+ 609 +--| MB |------------ NR 610 +----+ 612 private 614 MB: Middlebox 615 NI: NSIS Initiator 616 NR: NSIS Responder 618 Figure 6: NAT to Public, Sender and Receiver on either side of a 619 twice-NAT Scenario 621 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 622 addresses and port numbers on both sides, at private and public 623 interfaces. 625 This scenario requires the assistance of application level entities, 626 such as a DNS server. The application level gateways must handle 627 requests that are based on symbolic names, and configure the 628 middleboxes so that data packets are correctly forwarded from NI to 629 NR. The configuration of those middleboxes may require other 630 middlebox communication protocols, such as MIDCOM [7]. NSIS 631 signaling is not required in the twice-NAT only case, since 632 middleboxes of the twice-NAT type are normally configured by other 633 means. Nevertheless, NSIS signaling might by useful when there are 634 also Firewalls on path. In this case NSIS will not configure any 635 policy rule at twice-NATs, but will configure policy rules at the 636 Firewalls on the path. The NSIS signaling protocol must be at least 637 robust enough to survive this scenario. 639 2.6 Both End Hosts Behind Same NAT 641 When NSIS initiator and NSIS responder are behind the same NAT (thus 642 being in the same address realm, see Figure 7), they are most likely 643 not aware of this fact. As in Section 2.4 the NSIS responder must 644 determine its public IP address in advance and transfer it to the 645 NSIS initiator. Afterwards, the NSIS initiator can start sending the 646 signaling messages to the responder's public IP address. During this 647 process, a public IP address will be allocated for the NSIS initiator 648 at the same middlebox as for the responder. Now, the NSIS signaling 649 and the subsequent data packets will traverse the NAT twice: from 650 initiator to public IP address of responder (first time) and from 651 public IP address of responder to responder (second time). This is 652 the worst case in which both sender and receiver obtain a public IP 653 address at the NAT, and the communication path is certainly not 654 optimal in this case. 656 NI public 657 \ +----+ //----\\ 658 +-| MB |----| | 659 / +----+ \\----// 660 NR 661 private 663 MB: Middlebox 664 NI: NSIS Initiator 665 NR: NSIS Responder 667 Figure 7: NAT to Public, Both Hosts Behind Same NAT 669 The NSIS NATFW signaling protocol should support mechanisms to detect 670 such a scenario. The signaling should be exchanged directly between 671 NI and NR without involving the middlebox. 673 2.7 IPv4/v6 NAT with two Private Networks 675 This scenario combines the use case described in Section 2.2 with the 676 IPv4 to IPv6 transition scenario involving address and protocol 677 translation, i.e., using Network Address and Protocol Translators 678 (NAT-PT, [11]). 680 The difference from the other scenarios is the use of IPv6 to IPv4 681 (and vice versa) address and protocol translation. Additionally, the 682 base NTLP must support transport of messages in mixed IPv4 and IPv6 683 networks where some NSIS peers provide translation. 685 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 686 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 687 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 689 private public public private 690 IPv4 IPv6 692 MB: Middlebox 693 NI: NSIS Initiator 694 NR: NSIS Responder 696 Figure 8: IPv4/v6 NAT with two Private Networks 698 This scenario needs the same type of application level support as 699 described in Section 2.5, and so the issues relating to twice-NATs 700 apply here as well. 702 2.8 Multihomed Network with NAT 704 The previous sub-sections sketched network topologies where several 705 NATs and/or Firewalls are ordered sequentially on the path. This 706 section describes a multihomed scenario with two NATs placed on 707 alternative paths to the public network. 709 +----+ 710 NI -------| MB |\ 711 \ +----+ \ //---\\ 712 \ -| |-- NR 713 \ \\---// 714 \ +----+ | 715 --| MB |-------+ 716 +----+ 717 private 718 private public 720 MB: Middlebox 721 NI: NSIS Initiator 722 NR: NSIS Responder 724 Figure 9: Multihomed Network with Two NATs 726 Depending on the destination or load balancing requirements, either 727 one or the other middlebox is used for the data flow. Which 728 middlebox is used depends on local policy or routing decisions. 729 NATFW NSLP must be able to handle this situation properly, see 730 Section 3.3.2 for an expanded discussion of this topic with respect 731 to NATs. 733 3. Protocol Description 735 This section defines messages, objects, and protocol semantics for 736 the NATFW NSLP. Section 3.1 introduces the base element of a NSLP 737 session , the policy rule. Section 3.2 introduces the protocol and 738 the protocol behavior is defined in Section 3.3. Section 5 defines 739 the syntax of the messages and objects. 741 3.1 Policy Rules 743 Policy rules, bound to a session, are the building block of middlebox 744 devices considered in the NATFW NSLP. For Firewalls the policy rule 745 usually consists of a 5-tuple, source/destination addresses, 746 transport protocol, and source/destination port numbers, plus an 747 action such as allow or deny. For NATs the policy rule consists of 748 action 'translate this address' and further mapping information, that 749 might be, in the simplest case, internal IP address and external IP 750 address. 752 Policy rules are usually carried in one piece in signaling 753 applications. In NSIS the policy rule is divided into the flow 754 identifier, an allow or deny action, and additional information. The 755 filter specification is carried within NTLP's message routing 756 information (MRI) and additional information, including the 757 specification of the action, is carried in NSLP's objects. 758 Additional information is, for example, the lifetime of a policy rule 759 or session. 761 3.2 Basic protocol overview 763 The NSIS NATFW NSLP is carried over the NSIS Transport Layer Protocol 764 (NTLP) defined in [3]. NATFW NSLP messages are initiated by the NSIS 765 initiator (NI), handled by NSIS forwarders (NF) and finally processed 766 by the NSIS responder (NR). It is required that at least NI and NR 767 implement this NSLP, intermediate NFs only implement this NSLP when 768 they provide relevant middlebox functions. NSIS forwarders that do 769 not have any NATFW NSLP functions just forward these packets when 770 they have no interest. 772 A Data Sender (DS), intending to send data to a Data Receiver (DR) 773 must first initiate NATFW NSLP signaling. This causes the NI 774 associated with the data sender (DS) to launch NSLP signaling towards 775 the address of data receiver DR (see Figure 10). Although it is 776 expected that the DS and the NATFW NSLP NI will normally reside on 777 the same host, this specification does not rule out scenarios where 778 the DS and NI reside on different hosts. 780 +-------+ +-------+ +-------+ +-------+ 781 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 782 | |--->| NF1 |--->| NF2 |--->| | 783 +-------+ +-------+ +-------+ +-------+ 785 ========================================> 786 Data Traffic Direction 788 ---> : NATFW NSLP request signaling 789 ~~~> : NATFW NSLP response signaling 790 DS/NI : Data sender and NSIS initiator 791 DR/NR : Data receiver and NSIS responder 792 MB1 : Middlebox 1 and NSIS forwarder 1 793 MB2 : Middlebox 2 and NSIS forwarder 2 795 Figure 10: General NSIS signaling 797 The sequence of NSLP events is as follows: 798 o NSLP request messages are processed each time a NF with NATFW NSLP 799 support is traversed. These nodes process the message, check 800 local policies for authorization and authentication, possibly 801 create policy rules, and forward the signaling message to the next 802 NSIS node. The request message is forwarded until it reaches the 803 NSIS responder. 804 o NSIS responders will check received messages and process them if 805 applicable. NSIS responders generate response messages and send 806 them hop-by-hop back to the NI via the same chain of NFs 807 (traversal of the same NF chain is guaranteed through the 808 established reverse message routing state in the NTLP). 809 o The response message is processed at each NF implementing the 810 NATFW NSLP. 811 o Once the NI has received a successful response, the Data Sender 812 can start sending its data flow to the Data Receiver. 814 Because NATFW NSLP signaling follows the data path from DS to DR, 815 this immediately enables communication between both hosts for 816 scenarios with only Firewalls on the data path or NATs on sender 817 side. For scenarios with NATs on the receiver side certain problems 818 arise, as described in Section 2. 820 When the NR and the NI are located in different address realms and 821 the NR is behind a NAT, the NI cannot signal to the NR directly. The 822 DR and NR are not reachable from the NIs using the private address of 823 the NR and thus NATFW signaling messages cannot be sent to the NR/ 824 DR's address. Therefore, the NR must first obtain a NAT binding that 825 provides an address that is reachable for the NI. Once the NR has 826 acquired a public IP address, it forwards this information to the DS 827 via a separate protocol (such as SDP within SIP). This application 828 layer signaling, which is out of scope of the NATFW NSLP, may involve 829 third parties that assist in exchanging these messages. 831 NATFW NSLP signaling supports this scenario by using the RESERVE mode 832 of operation 833 1. The NR acquires a public address by signaling on the reverse path 834 (NR towards NI) and thus making itself available to other hosts. 835 This process of acquiring a public addresses is called 836 reservation. During this process the DR reserves publicly 837 reachable addresses and ports suitable for NATFW NSLP signaling, 838 but data traffic will not be allowed to use this address/port 839 initially. 840 2. The NI signals directly to the NR as the NI would do if there is 841 no NAT in between, and creates policy rules at middleboxes. 842 Note, that the reservation mode will only allow the forwarding 843 of signaling messages but not data flow packets. Data flow 844 packets will be 'activated' by the signaling from NI towards NR. 845 The RESERVE mode of operation is detailed in Section 3.3.2 847 The protocol works on a soft-state basis, meaning that whatever state 848 is installed or reserved on a middlebox will expire, and thus be 849 de-installed/ forgotten after a certain period of time. To prevent 850 this, the NATFW nodes involved will have to specifically request a 851 session extension. An explicit NATFW NSLP state deletion capability 852 is also provided by the protocol. 854 Middleboxes should return an error in case of a failure, such that 855 appropriate actions can be taken; this ability would allow debugging 856 and error recovery. Error messages could be sent upstream (for 857 errors related to received messages as well as asynchronous error 858 notification messages) towards the NI as well as downstream towards 859 the NR (in the case of asynchronous error notification messages). 861 The next sections define the NATFW NSLP message types and formats, 862 protocol operations, and policy rule operations. 864 3.3 Protocol Operations 866 This section defines the protocol operations, how to create sessions, 867 maintain them, and how to reserve addresses. All the NATFW NSLP 868 protocol messages require C-mode handling by the NTLP and cannot be 869 piggybacked into D-mode NTLP messages used during the NTLP path 870 discovery/refresh phase. The usage of the NTLP by protocol messages 871 is described in more details in Section 5. 873 The protocol uses six messages: 875 o CREATE: a request message used for creating, changing, refreshing 876 and deleting NATFW NSLP sessions. 877 o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for 878 reserving an external address 879 o RESPONSE: used as a response to CREATE, REA and QUERY messages 880 with Success or Error information 881 o QUERY: a request message used by authorized NATFW NEs for querying 882 installed NATFW states 883 o NOTIFY: an asynchronous message used by NATFW NEs to alert 884 upstream and/or downstream NATFW NEs about specific events 885 (especially failures). 886 o TRIGGER: a message sent upstream to trigger the sending of CREATE 887 messages 888 The following sections will present the semantics of these messages 889 by exhibiting their impact on the protocol state machine. 891 3.3.1 Creating Sessions 893 Allowing two hosts to exchange data even in the presence of 894 middleboxes is realized in the NATFW NSLP by the CREATE request 895 message. The data sender generates a CREATE message as defined in 896 Section 5.4.1 and hands it to the NTLP. The NTLP forwards the whole 897 message on the basis of the message routing information towards the 898 NR. Each NSIS forwarder along the path that implements NATFW NSLP, 899 processes the NSLP message. Forwarding is thus managed NSLP 900 hop-by-hop but may pass transparently through NSIS forwarders which 901 do not contain NATFW NSLP functionality and non-NSIS aware routers 902 between NSLP hop waypoints. When the message reaches the NR, the NR 903 can accept the request or reject it. The NR generates a response to 904 the request and this response is transported hop-by-hop towards the 905 NI. NATFW NSLP forwarders may reject requests at any time. Figure 906 11 sketches the message flow between NI (DS), a NF (NAT), and NR 907 (DR). 909 NI Private Network NF Public Internet NR 910 | | | 911 | CREATE | | 912 |----------------------------->| | 913 | | | 914 | RESPONSE[Error](if necessary)| | 915 |<-----------------------------| CREATE | 916 | |--------------------------->| 917 | | | 918 | | RESPONSE[Success/Error] | 919 | RESPONSE[Success/Error] |<---------------------------| 920 |<-----------------------------| | 921 | | | 922 | | | 924 Figure 11: Creation message flow 926 Since the CREATE message is used for several purposes within the 927 lifetime of a session, there are several processing rules for NATFW 928 NEs when generating and receiving CREATE messages. The different 929 processing methods depend not only on the function which the CREATE 930 is performing (to create, modify, refresh or delete a session) but 931 also on the node at which the processing happens. For an initial 932 CREATE message the processing of CREATE messages is different for 933 every NSIS node type: 934 o NSLP initiator: NI only generates initial CREATE messages and 935 hands them over to the NTLP. After receiving a successful 936 response, the data path is configured and the DS can start 937 sending its data to the DR. After receiving an 'error' response 938 message the NI MAY try to generate the CREATE message again or 939 give up and report the failure to the application, depending on 940 the error condition. 941 o NATFW NSLP forwarder: NFs receiving an initial CREATE message 942 MUST first check authentication and authorization before any 943 further processing is executed. The NF SHOULD check with its 944 local policies if it can accept the desired policy rule given the 945 combination of the NTLP's 'Message-Routing-Information' (MRI) [3] 946 (the flow description information) and the CREATE payload 947 (behavior to be enforced on the packet stream). An initial CREATE 948 is distinguished from subsequent CREATE messages by the presence 949 of existing NSLP session state related to the same session ID or 950 the same MRI. The NSLP message processing depends on the 951 middlebox type: 952 * NAT: When the initial CREATE message is received at the public 953 side of the NAT, it looks for a reservation made in advance, by 954 using a REA message Section 3.3.2, that matches the destination 955 address/port of the MRI provided by the NTLP. If no 956 reservation had been made in advance the NSLP SHOULD return an 957 error response message of type 'no reservation found' and 958 discard the request. If there is a reservation, NSLP stores 959 the data sender's address as part of the policy rule to be 960 loaded and forwards the message with the address set to the 961 internal (private in most cases) address of the next NSIS node. 962 When the initial CREATE message, for a new session, is received 963 at the private side the NAT binding is reserved, but not 964 activated. The NSLP message is forwarded to the next NSIS hop 965 with source address set to the NAT's external address from the 966 newly reserved binding. 967 * Firewall: When the initial CREATE message is received the NSLP 968 just remembers the requested policy rule, but does not install 969 any policy rule. Afterwards, the message is forwarded to the 970 next NSLP hop. There is a difference between requests from 971 trusted (authorized NIs) and un-trusted (un-authorized NIs); 972 requests from trusted NIs will be pre-authorized, whereas 973 requests from un-trusted NIs will not be pre-authorized. This 974 difference is required to speed-up the protocol operations as 975 well as for proxy mode usage (please refer to Section 3.3.8 and 976 [17]). 977 * Combined NAT and Firewall: Processing at combined Firewall and 978 NAT middleboxes is the same as in the NAT case. No policy 979 rules are installed. Implementations MUST take into account 980 the order of packet processing in the Firewall and NAT 981 functions within the device. This will be referred to as 982 'order of functions' and is generally different depending on 983 whether the packet arrives at the external or internal side of 984 the middlebox. 985 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 986 with a 'success' (response object has success information) 987 RESPONSE message if they accept the CREATE request message. 988 Otherwise they SHOULD generate a RESPONSE message with an error 989 code. RESPONSE messages are sent back NSLP hop-by-hop towards the 990 NI, independently of the response codes, either success or error. 992 Policy rules at middleboxes MUST be only installed upon receiving a 993 successful response. This is a countermeasure to several problems, 994 for example wastage of resources due to loading policy rules at 995 intermediate NF when the CREATE message does not reach the final NR 996 for some reason. 998 3.3.2 Reserving External Addresses 1000 NSIS signaling is intended to travel end-to-end, even in the presence 1001 of NATs and Firewalls on-path. This works well in cases where the 1002 data sender is itself behind a NAT as described in Section 3.3.1. 1003 For scenarios where the data receiver is located behind a NAT and 1004 needs to receive data flows from outside its own network (see Figure 1005 5) the problem is more troublesome. NSIS signaling, as well as 1006 subsequent data flows, are directed to a particular destination IP 1007 address that must be known in advance and reachable. 1009 +-------------+ AS-Data Receiver Communication 1010 +-------->| Application |<-----------------------------+ 1011 | | Server | | 1012 | +-------------+ | 1013 | IP(R-NAT_B) | 1014 | NSIS Signaling Message +-------+--+ 1015 | +------------------------------------------>| NAT/NAPT | 1016 | | | B | 1017 | | +-------+--+ 1018 | | | 1019 AS-Data| | | 1020 Receiver| | +----------+ | 1021 Comm.| | | NAT/NAPT | | 1022 | | | A | | 1023 | | +----------+ | 1024 | | | 1025 | | | 1026 | | | 1027 | | | 1028 v | IP(R) v 1029 +--------+ +---------+ 1030 | Data | | Data | 1031 | Sender | | Receiver| 1032 +--------+ +---------+ 1034 Figure 12: The Data Receiver behind NAT problem 1036 Figure 12 describes a typical message communication in a peer-to-peer 1037 networking environment whereby the two end points learn of each 1038 others existence with the help of a third party (referred to as an 1039 Application Server). Communication between the application server 1040 and each of the two end points (data sender and data receiver) 1041 enables the two end hosts to learn each other's IP addresses. The 1042 approach described in this memo supports this peer-to-peer approach, 1043 but is not limited to it. 1045 Some sort of communication between the data sender/data receiver and 1046 a third party is typically necessary (independently of whether NSIS 1047 is in use). NSIS signaling messages cannot be used to communicate 1048 the relevant application level end point identifiers (in the generic 1049 case at least) as a replacement for communication with the 1050 application server. 1052 If the data receiver is behind a NAT then an NSIS signaling message 1053 will be addressed to the IP address allocated at the NAT (assuming 1054 one had already been allocated). If no corresponding NSIS NAT 1055 Forwarding State at NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) 1056 then the signaling message will terminate at the NAT device (most 1057 likely without generating a proper response message). The signaling 1058 message transmitted by the data sender cannot install the NAT binding 1059 or NSIS NAT Forwarding State "on-the-fly" since this would assume 1060 that the data sender knows the topology at the data receiver side 1061 (i.e., the number and the arrangement of the NAT and the private IP 1062 address(es) of the data receiver). The primary goal of path-coupled 1063 middlebox communication was not to avoid end hosts learning and 1064 preserving this type of topology knowledge. 1066 Public Internet Private Address 1067 Space 1068 Edge 1069 NI(DS) NAT NAT NR(DR) 1070 NR+ NI+ 1071 | | | | 1072 | | | | 1073 | | | | 1074 | | REA | REA | 1075 | |<----------------------|<----------------------| 1076 | | | | 1077 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1078 | |---------------------->|---------------------->| 1079 | | | | 1080 | | | | 1082 ============================================================> 1083 Data Traffic Direction 1085 Figure 13: Reservation message flow 1087 Figure 13 shows the message flow for reserving an external address/ 1088 port at a NAT. In this case the roles of the different NSIS entities 1089 are: 1090 o The data receiver (DR) for the anticipated data traffic is the 1091 NSIS initiator (NI+) for the RESERVE-EXTERNAL-ADDRESS (REA) 1092 message, but becomes the NSIS responder (NR) for following CREATE 1093 messages. 1094 o The actual data sender (DS) will be the NSIS initiator (NI) for 1095 later CREATE messages and may be the NSIS target of the signaling 1096 (NR+). 1097 o The actual target of the REA message, the Opportunistic Address 1098 (OA) an arbitrary address, that would force the message to get 1099 intercepted by the far outmost NAT in the network. 1101 The NI+ agent (could be on the data receiver DR or on any other host 1102 within the private network) sends a the REA message targeted to the 1103 Opportunistic Address (OA). The OA selection for this message is 1104 discussed in Section 3.7. The message routing for the REA message is 1105 in the reverse direction to the normal message routing used for 1106 path-coupled signaling where the signaling is sent downstream (as 1107 opposed to upstream in this case). When establishing NAT bindings 1108 (and NSIS NAT Forwarding State) the direction does not matter since 1109 the data path is modified through route pinning due to the external 1110 NAT address. Subsequent NSIS messages (and also data traffic) will 1111 travel through the same NAT boxes. 1113 The REA signaling message creates NSIS NAT Forwarding State at any 1114 intermediate NSIS NAT node(s) encountered. Furthermore it has to be 1115 ensured that the edge NAT device is discovered as part of this 1116 process. The end host cannot be assumed to know this device - 1117 instead the NAT box itself is assumed to know that it is located at 1118 the outer perimeter of the private network addressing realm. 1119 Forwarding of the REA message beyond this entity is not necessary, 1120 and should be prohibited as it provides information on the 1121 capabilities of internal hosts. 1123 The edge NAT device responds to the REA message with a RESPONSE 1124 message containing a success object carrying the public reachable IP 1125 address/port number. 1127 Processing of REA messages is specific to the NSIS node type: 1128 o NSLP initiator: NI+ only generate REA messages and should never 1129 receive them. 1130 o NSLP forwarder: NSLP forwarders receiving REA messages MUST first 1131 check authentication and authorization before any further 1132 processing is executed. The NF SHOULD check with its local 1133 policies if it can accept the desired policy rule given by NTLP's 1134 message routing information (MRI). Further processing depends on 1135 the middlebox type: 1136 * NAT: NATs check whether the message is received at the 1137 external (public in most cases) address or at the internal 1138 (private) address. If received at the external address a NF 1139 MAY generate a RESPONSE message with an error of type 'REA 1140 received from outside'. If received at the internal address, 1141 an IP address/port is reserved. In the case it is an edge-NAT, 1142 the NSLP message is not forwarded any further and a RESPONSE 1143 message with the external address and port information is 1144 generated. If it is not an edge-NAT, the NSLP message is 1145 forwarded further with the translated IP address/port (if 1146 required by the NI+). 1147 * Firewall: Firewalls MUST not change their configuration upon a 1148 REA message. They simply MUST forward the message and MUST 1149 keep NTLP state. Firewalls that are configured as 1150 edge-Firewalls MAY return an error of type 'no NAT here'. 1151 * Combined NAT and Firewall: Processing at combined Firewall and 1152 NAT middleboxes is the same as in the NAT case. 1153 o NSLP receiver: This type of message should never be received by 1154 any NR+ and it SHOULD be discarded silently. 1156 Processing of a RESPONSE message with an external address object is 1157 different for every NSIS node type: 1158 o NSLP initiator: Upon receiving a RESPONSE message with an 1159 external address object, the NI+ can use the IP address and port 1160 pairs carried for further application signaling. 1161 o NSLP forwarder: NFs simply forward this message as long as they 1162 keep state for the requested reservation. 1163 o NSIS responder: This type of message should never be received by 1164 an NR and it SHOULD be discarded silently. 1165 o Edge-NATs: This type of message should never be received by any 1166 Edge-NAT and it SHOULD be discarded silently. 1168 3.3.3 NATFW Session refresh 1170 NATFW NSLP sessions are maintained on a soft-state basis. After a 1171 specified timeout, sessions and corresponding policy rules are 1172 removed automatically by the middlebox, if they are not refreshed. 1173 The protocol uses a CREATE message to refresh sessions. Even if used 1174 for refresh purposes the CREATE message requires that a response 1175 message is generated by the NR. This response message is routed back 1176 towards the NI, to allow the intermediate NFs to propose a refresh 1177 period that would align with their local policies. The NI sends 1178 CREATE messages destined for the NR. Upon reception by each NSIS 1179 forwarder, the state for the given session ID is extended by the 1180 session refresh period, a period of time calculated based on a 1181 proposed refresh message period. The lifetime extension of a session 1182 is calculated as current local time plus proposed lifetime value 1183 (session refresh period). Section 3.4 defines the process of 1184 calculating lifetimes in detail. 1186 NI Public Internet NAT Private address NR 1187 | | space | 1188 | CREATE[lifetime > 0] | | 1189 |----------------------------->| | 1190 | | | 1191 | RESPONSE[Error] (if needed) | | 1192 |<-----------------------------| CREATE[lifetime > 0] | 1193 | |--------------------------->| 1194 | | | 1195 | | RESPONSE[Success/Error] | 1196 | RESPONSE[Success/Error] |<---------------------------| 1197 |<-----------------------------| | 1198 | | | 1199 | | | 1201 Figure 14: State Refresh Message Flow 1203 Processing of session refresh CREATE messages is different for every 1204 NSIS node type: 1205 o NSLP initiator: The NI can generate session refresh CREATE 1206 messages before the session times out. The rate at which the 1207 refresh CREATE messages are sent and their relation to the session 1208 state lifetime are further discussed in Section 3.4. The message 1209 routing information and the extended flow information object MUST 1210 be set equal to the values of the initial CREATE request message. 1211 o NSLP forwarder: NSLP forwarders receiving session refresh messages 1212 MUST first check authentication and authorization before any 1213 further processing is executed. The NF SHOULD check with its 1214 local policies if it can accept the desired lifetime extension for 1215 the session referred by the session ID. Processing of this 1216 message is independent of the middlebox type. 1217 o NSLP responder: NRs accepting a session refresh CREATE message 1218 generate a RESPONSE message with response object set to success. 1220 3.3.4 Deleting Sessions 1222 NATFW NSLP sessions may be deleted at any time. NSLP initiators can 1223 trigger this deletion by using a CREATE messages with a lifetime 1224 value set to 0, as shown in Figure 15. 1226 NI Public Internet NAT Private address NR 1227 | | space | 1228 | CREATE[lifetime=0] | | 1229 |----------------------------->| | 1230 | | | 1231 | | CREATE[lifetime=0] | 1232 | |--------------------------->| 1233 | | | 1235 Figure 15: Delete message flow 1237 NSLP nodes receiving this message MUST delete the session 1238 immediately. Policy rules associated with this particular session 1239 MUST be deleted immediately. This message is forwarded until it 1240 reaches the final NR. The CREATE request message with a lifetime 1241 value of 0, does not generate any response, neither positive nor 1242 negative, since there is no NSIS state left at the nodes along the 1243 path. 1245 3.3.5 Reporting Asynchronous Events 1247 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 1248 to report asynchronous events to other NATFW NSLP nodes, especially 1249 to allow reporting back to the NATFW NSLP initiator. Such 1250 asynchronous events may be premature session termination, changes in 1251 local policies, routing change or any other reason that indicates 1252 change of the NATFW NSLP session state. Currently, asynchronous 1253 session termination, re-authorization required and route change 1254 detected are the only events that are defined, but other events may 1255 be defined in later versions of this memo. One or several events 1256 could be reported within the NOTIFY message. 1258 NFs and NRs may generate NOTIFY messages upon asynchronous events, 1259 with a response object indicating the reason of the event. There are 1260 two suggested mode of operations: 1261 1. NOTIFY messages are sent hop-by-hop upstream towards NI. Those 1262 NOTIFY messages may be sent downstream towards NR, if generated 1263 by a NF, if needed. Indication to send NOTIFY messages 1264 downstream to NR is indicated within the CREATE message. 1265 2. During session creation, via CREATE or REA, NIs may insert a 1266 special 'notify address' object into the NSLP message, indicating 1267 a node's address that should be notified about this event. When 1268 this address is used, NOTIFY messages are not sent to the NR. 1269 Note: Should this mode include the first one?, in that case NR 1270 could be reached by providing its address as the 'notify address' 1271 this would use 32 or 128 bits instead of a flag bit as done in 1272 the first mode. 1274 Processing is different for every NATFW NSLP node type and depends on 1275 the notified events : 1276 o NSLP initiator: NIs receiving NOTIFY messages MUST first check for 1277 authentication and authorization. After successfully doing so, 1278 NIs analyze the notified event(s) and behave appropriately based 1279 on the event type. Section 5.3.4 discusses the required behavior 1280 for each notified event. NIs MUST NOT generate NOTIFY messages. 1281 o NSLP forwarder: NFs receiving NOTIFY messages MUST first check for 1282 authentication and authorization. After successfully doing so, 1283 NFs analyze the notified event(s) and behave based on the notified 1284 events defined in Section 5.3.4. NFs occurring an asynchronous 1285 event generate NOTIFY messages and set the response object(s) code 1286 based on the reported event(s). NOTIFY messages are sent 1287 hop-by-hop upstream towards NI (This depends on the design choice 1288 mentioned above). 1289 o NSLP responder: NRs may generate NOTIFY messages. NRs receiving 1290 NOTIFY messages MUST first check for authentication and 1291 authorization. After successfully doing so, NRs analyze the 1292 notified event(s) and behave appropriately based on the event 1293 type. Section 5.3.4 discusses the required behavior for each 1294 notified event. NRs occurring an asynchronous event generate 1295 NOTIFY messages and set the response object(s) code based on the 1296 reported event(s). NOTIFY messages are sent hop-by-hop upstream 1297 towards NI (This depends on the design choice mentioned above). 1299 3.3.6 QUERY capabilities within the NATFW NSLP protocol 1301 The NATFW NSLP provides query capabilities that could be used by a 1302 session owner to track the session state. This would be used for 1303 diagnostic purposes when no data packets were received and the policy 1304 rule was supposed to have been created on the NATFW NFs. 1306 The QUERY message could be used to query the following session 1307 information: session id, flow source, destination and status of the 1308 state listed in best status to worst status: up, high traffic (used 1309 to detect DOS attack or unexpected traffic rate), pending, down. The 1310 status of the policy rule will probably provide sufficient diagnostic 1311 information; in case more diagnostic information is required it could 1312 be provided by the NATFW NF logs. Session status is only provided by 1313 an NF if no session status was provided in the QUERY message or the 1314 NF's session status is worse than the one provided by the queried 1315 upstream NEs. The Session information could be retrieved by sending 1316 a QUERY against a specific session id, a flow source and destination 1317 or user identifier with session id or flow source and destination. 1319 QUERY message processing is different for every NATFW NSLP node type: 1320 o NSLP initiator: NIs only generate QUERY messages, but never with 1321 session status information, so that received QUERY messages MUST 1322 be discarded. 1323 o NSLP forwarder: NFs receiving QUERY messages MUST first check for 1324 authentication and authorization. After successfully doing so, 1325 NFs will behave differently depending on the QUERY. If the QUERY 1326 is about a specific session: if it contains a session status the 1327 NF compares it to the current local session status; if no session 1328 status is provided in the QUERY message the NF will insert its own 1329 session status in the QUERY message. If the current local session 1330 status is worse, it will incorporate its own session status field 1331 in the QUERY message. Every NF will provide the flow description 1332 in case it was not inside the QUERY. Once the message processing 1333 is done, if the message was not scoped then NF will forward the 1334 QUERY message to the next downstream node. 1335 o NSLP responder: NRs (any node being the destination of the 1336 message) receiving QUERY messages MUST first check for 1337 authentication and authorization. After successfully doing so, 1338 NRs must process the message as the NFs and respond with a 1339 RESPONSE message to the NI. The RESPONSE message will travel 1340 along the established reverse path given by the message routing 1341 state. 1343 Responses to QUERY messages are processed differently for every NATFW 1344 NSLP node type: 1345 o NSLP initiator: NIs receiving RESPONSEs to QUERY messages MUST 1346 first check for authentication and authorization. After 1347 successfully doing so, the objects within the RESPONSE messages 1348 are provided up to the application layers and the session state 1349 remains as it was unless the application triggers NATFW NSLP state 1350 changes. 1351 o NSLP forwarder: NFs receiving RESPONSEs to QUERY messages MUST 1352 first check for authentication and authorization. After 1353 successfully doing so, NFs forward the message upstream without 1354 any interpretation. 1355 o NSLP responder: if an NR receives a RESPONSE to QUERY message it 1356 MUST discard it. 1358 3.3.7 QUERY Message semantics 1360 From a semantics perspective, the QUERY messages may require the 1361 following information incorporated within the messages: 1362 o Session ID 1363 o Flow source (address and port) and destination (address and port), 1364 in case the flow doesn't use a transport protocol a protocol 1365 number would be used with another identifier (SPI for IPsec) 1366 QUERY responses should provide the following information: 1367 o List of active sessions 1368 o Editor's note: next version will discuss in which form the list 1369 publishes the active sessions (by session id or session ID and 1370 flow description or other formats) 1371 o Information related to a session (when the query is specific to 1372 one session): session ID, flow description and policy rule state 1373 information 1375 3.3.8 Reserving External Addresses and triggering Create messages 1377 Some migration scenarios need specialized support to cope with cases 1378 where only the receiving side is running NSIS. End-to-end signaling 1379 is going to fail without NSIS support at both data sender and data 1380 receiver, unless the NATFW NSLP also gives the NR the ability to 1381 install sessions. The goal of the described method is to trigger the 1382 network to generate a CREATE message at the edge NAT. In this case, 1383 a NR can signal towards the Opportunistic Address as is done in the 1384 standard REA message handling scenario Section 3.3.2. The message is 1385 forwarded until it reaches the edge-NAT and retrieves a public IP 1386 address and port number. As shown in Figure 16, unlike the standard 1387 REA message handling case, the edge-NAT is triggered to send a CREATE 1388 message on a new reverse path to handle asymmetric routes, which 1389 could go through internal firewalls or NATs. This behavior requires 1390 within the REA message an indication to the edge NAT if either the 1391 standard behavior is required or a CREATE message is required to be 1392 sent by the edge-NAT. In addition when a CREATE message need to be 1393 sent by the edge-NAT, the REA message includes the data sender 1394 address if available to the NR. 1396 DS Public Internet NAT Private address NR 1397 No NI | space 1398 | | REA[CREATE] | 1399 | |<------------------------- | 1400 | | RESPONSE[Error/Success] | 1401 | | ---------------------- > | 1402 | | CREATE | 1403 | | ------------------------> | 1404 | | RESPONSE[Error/Success] | 1405 | | <---------------------- | 1406 | | | 1407 | | | 1409 Figure 16: REA Triggering Sending of CREATE Message on Separate 1410 Reverse Path 1412 If a CREATE message is received from the far end NI and relates to an 1413 installed session (correlation being made with the message routing 1414 information, MRI), that CREATE message would have precedence over the 1415 previous CREATE. The CREATE sent by the NI could specify a more 1416 granular policy rule as only the data sender (the triggered CREATE 1417 may not have that information) could send data whereas in the REA 1418 triggered CREATE message any data source can send packets to the data 1419 receiver. The edge NAT is not aware of the applications context for 1420 which the CREATE messages were required. Hence it is up to the NR to 1421 inform the Edge NAT if there was a possibility to reduce the number 1422 of accepted data sources to the real data sender, as well as to 1423 inform the Edge NAT to refresh the established session. 1425 For that purpose the NR will send TRIGGER messages, to the edge NAT 1426 that responded to the REA message. These messages are sent upon 1427 reception, from the user application, of further information on the 1428 Data Sender (either explicit information or implied information such 1429 as far end-host data sender address is equivalent to data reception 1430 address and same for the transport port). The TRIGGER messages would 1431 be sent periodically to the Edge NAT that responded to the REA. The 1432 TRIGGER messages would be sent until either a CREATE message is 1433 received from the far-end or when the user application no longer 1434 needs the NSIS session. Figure 17 shows how TRIGGER messages would 1435 be used after the message sequences of Figure 16. Triggered CREATE 1436 message follow the path pinned down by the earlier CREATE messages 1437 triggered by the REA message in Figure 16. If a CREATE message is 1438 received from the far end NI and relates to an installed session, 1439 that CREATE message would have precedence over the triggered CREATE 1440 messages. TRIGGER messages do not require to be responded back with 1441 a RESPONSE message on the existing established reverse path. In case 1442 normal CREATE messages (i.e. not sent by the NI) where not received 1443 by the NR and the session is no longer needed, the NR could use the 1444 TRIGGER message indicating that the session should be removed (CREATE 1445 message will be sent by edge NAT with lifetime=0). The benefits of 1446 using REA triggering a CREATE and then using the TRIGGER messages are 1447 that an end-host does not need to know if the far-end host support 1448 the NSIS protocol. 1450 Foo.com Public Internet Bar.com 1451 DS NAT Firewall NR 1452 No NI | | TRIGGER[DSinfo] 1453 TRIGGER[DSinfo]<-------------| 1454 <-------------| | 1455 |CREATE | 1456 |----------->|CREATE | 1457 | |-------------->| 1458 | | RESPONSE[SUCCESS] 1459 | | <-------------| 1460 RESPONSE[SUCCESS] | 1461 |<-----------| | 1462 Refresh period expiry | 1463 or updates to Data Sender information 1464 | | 1465 | | TRIGGER[DSinfo] 1466 TRIGGER[DSinfo]<-------------| 1467 <-------------| | 1468 |CREATE | 1469 |----------->|CREATE | 1470 | |-------------->| 1471 | | RESPONSE[SUCCESS] 1472 | | <-------------| 1473 RESPONSE[SUCCESS] | 1474 |<-----------| | 1476 Figure 17: TRIGGER message usage 1478 3.3.9 Using CREATE messages to Trigger Reverse Path CREATE Messages 1480 In certain network deployments, where the NATFW NSLP might not be 1481 available on the end-host (Figure 18) or the NSIS messages are scoped 1482 (Figure 19) implicitly or explicitly with a scoping object, a CREATE 1483 message could be used to trigger another CREATE message sent by the 1484 last NF terminating the CREATE message. To handle routing asymmetry 1485 issues, the triggered CREATE messages will be sent on a newly pinned 1486 down reverse path. 1488 In Figure 18, the first CREATE indicates that if the message can not 1489 reach its destination (NoNR indication), a CREATE message should be 1490 sent back to the NI by the last reached NATFW NE. As in Section 1491 3.3.8 this mode of operation requires that the CREATE message 1492 indicate the type of required response behavior which in this case is 1493 a triggered CREATE message. However this response behavior is 1494 subject to a condition: it should be sent only if the NR can not 1495 respond. This conditional behavior requires a specific flag to 1496 indicate it (NoNR indication in Figure 18). 1498 Foo.com Public Internet Bar.com 1499 2-RESPONSE1 1500 /-------------|--------------------- 1501 / --> FW1-NF --------------------- \ 1502 V / 1-CREATE1[CREATE,NoNR] | \ \ 1503 Host Foo/ | | NF3-NF Host Bar 1504 NI/NR ^ | | |^ 1505 \ \ | 3-CREATE2 | || 1506 \ \--- FW2-NF --------------------------| 1507 \----/ \-------------------------- 1508 | 4-RESPONSE2 | 1510 Figure 18: CREATE Triggering Sending of CREATE Message at last NSLP 1511 and Using Separate Reverse path 1513 To minimize the asymmetric route problem, the node responding with a 1514 CREATE message would request the NTLP to rediscover the reverse path. 1515 A RESPONSE message would be sent on the existing pinned down reverse 1516 path (Step 2 in Figure 18), and a CREATE would be sent on a newly 1517 discovered reverse path (Step 3 in Figure 18). Upon reception of the 1518 latter message, the initiating NI will respond with a RESPONSE 1519 message (Step 4 in Figure 18) as is done for the normal CREATE 1520 message operations (Section 3.3.1). The CREATE message would need to 1521 indicate to the last NATFW NF that a CREATE must be sent on a 1522 separately discovered path and that a RESPONSE message needs to be 1523 sent on the established pinned down reverse path. The new CREATE 1524 message need to indicate to the NI that this session is bound to the 1525 previous session. In addition the first message should indicate that 1526 the last available NATFW NF will need to terminate the message and 1527 start the above procedures. 1529 Foo.com Public Internet Bar.com 1530 2-RESPONSE1 1531 /-------------|--------------------- 1532 / --> FW1-NF --------------------- \ 1533 V / 1-CREATE1[CREATE,scope] | \ \ 1534 Host Foo/ | | NF3-NF Host Bar 1535 NI/NR ^ | | |^ 1536 \ \ | 3-CREATE2 | || 1537 \ \--- FW2-NF --------------------------| 1538 \----/ \-------------------------- 1539 | 4-RESPONSE2 | 1541 Figure 19: CREATE Triggering Sending of CREATE Message with Scoping 1542 and Using Separate Reverse path 1544 In Figure 19, the first CREATE indicates that once the end of the 1545 scope is reached, the last NATFW NSLP will send a CREATE message (if 1546 the first CREATE request was successful). As in Section 3.3.8, this 1547 mode of operation requires that the CREATE message indicate the 1548 required type of response behavior which in this case is a CREATE 1549 message. As the CREATE needs to terminate at a scope end, the scope 1550 need to be provided within the CREATE message. 1552 3.4 Calculation of Session Lifetime 1554 NATFW NSLP sessions, and the corresponding policy rules which may 1555 have been installed, are maintained via soft-state mechanism. Each 1556 session is assigned a lifetime and the session is kept alive as long 1557 as the lifetime is valid. After the expiration of the lifetime, 1558 sessions and policy rules MUST be removed automatically and resources 1559 bound to them should be freed as well. Session lifetime is kept at 1560 every NATFW NSLP node. The NSLP forwarders and NSLP responder 1561 (except when TRIGGER is used) are not responsible for triggering 1562 lifetime extension refresh messages (see Section 3.3.3): this is the 1563 task of the NSIS initiator. 1565 NSIS initiator MUST choose a session lifetime (expressed in seconds) 1566 value before sending any message (except 'delete session' messages) 1567 to other NSLP nodes. The session lifetime value is calculated based 1568 on: 1569 o The number of lost refresh messages that NFs should cope with 1570 o The end to end delay between the NI and NR 1571 o Network vulnerability due to session hijacking ([21]). Session 1572 hijacking is made easier when the NI does not explicitly remove 1573 the session. 1574 o The user application's data exchange duration, in terms of 1575 seconds, minutes or hours and networking needs. This duration is 1576 modeled as M x R, with R the message refresh period (in seconds) 1577 and M a multiple of R. 1579 As opposed to the NTLP Message Routing state [3] lifetime, the NSLP 1580 session lifetime is not required to have a small value since the NSLP 1581 state refresh is not handling routing changes but security related 1582 concerns. [14] provides a good algorithm to calculate the session 1583 lifetime as well as how to avoid refresh message synchronization 1584 within the network. [14] recommends: 1585 1. The refresh message timer to be randomly set to a value in the 1586 range [0.5R, 1.5R]. 1587 2. To avoid premature loss of state, L (with L being the session 1588 lifetime) must satisfy L >= (K + 0.5)*1.5*R, where K is a small 1589 integer. Then in the worst case, K-1 successive messages may be 1590 lost without state being deleted. Currently K = 3 is suggested 1591 as the default. However, it may be necessary to set a larger K 1592 value for hops with high loss rate. Other algorithms could be 1593 used to define the relation between the session lifetime and the 1594 refresh message period, the algorithm provided is only given as 1595 an example. 1597 This requested lifetime value is placed in the 'lifetime' object of 1598 the NSLP message and messages are forwarded to the next NATFW NSLP 1599 node. 1601 NATFW NFs processing the request message along the path MAY change 1602 the requested lifetime to fit their needs and/or local policy. If an 1603 NF changes the lifetime value it must also indicate the corresponding 1604 refresh message period. NFs MUST NOT increase the lifetime value 1605 unless the lifetime value was below their acceptable range; they MAY 1606 reject the requested lifetime immediately and MUST generate an error 1607 response message of type 'lifetime too big' upon rejection. The NSLP 1608 request message is forwarded until it reaches the NSLP responder. 1609 NSLP responder MAY reject the requested lifetime value and MUST 1610 generate an error response message of type 'lifetime too big' upon 1611 rejection. The NSLP responder MAY also lower the requested lifetime 1612 to an acceptable value (based on its local policies). NSLP 1613 responders generate their appropriate response message for the 1614 received request message, sets the lifetime value to the above 1615 granted lifetime and sends the message back hop-by-hop towards NSLP 1616 initiator. 1618 Each NSLP forwarder processes the response message, reads and stores 1619 the granted lifetime value. The forwarders SHOULD accept the granted 1620 lifetime, as long as the value is within the tolerable lifetime range 1621 defined in their local policies. They MAY reject the lifetime and 1622 generate a 'lifetime not acceptable' error response message. Figure 1623 20 shows the procedure with an example, where an initiator requests 1624 60 seconds lifetime in the CREATE message and the lifetime is 1625 shortened along the path by the forwarder to 20 seconds and by the 1626 responder to 15 seconds. 1628 +-------+ CREATE(lt=60s) +-----------+ CREATE(lt=20s) +--------+ 1629 | |---------------->| NSLP |---------------->| | 1630 | NI | | | | NR | 1631 | |<----------------| forwarder |<----------------| | 1632 +-------+ RESPONSE(lt=15s +-----------+ RESPONSE(lt=15s +--------+ 1633 MRR=3s) MRR=3s) 1635 lt = lifetime 1636 MRR = Message Refresh Rate 1638 Figure 20: Lifetime Calculation Example 1640 3.5 Firewall and NAT Resources 1642 TBD: This section needs to be done and will describe how to map flow 1643 routing information to middlebox policy rules. Further, this section 1644 should clarify wildcarding. 1646 3.6 De-Multiplexing at NATs 1648 Section 3.3.2 describes how NSIS nodes behind NATs can obtain a 1649 publicly reachable IP address and port number at a NAT. The 1650 information IP address/port number can then be transmitted via a 1651 signaling protocol and/or third party to the communication partner 1652 that would like to send data towards hosts behind the NAT. However, 1653 NSIS signaling flows are sent towards the address of the NAT at which 1654 this particular IP address and port number is allocated. The NATFW 1655 NSLP forwarder at this NAT needs to know how the incoming NSLP 1656 requests are related to reserved addresses, meaning how to 1657 de-multiplex incoming requests. 1659 The de-multiplexing method uses information stored at NATs (such as 1660 mapping of public IP address to private, transport protocol, port 1661 numbers) and information given by NTLP's message routing information. 1663 3.7 Selecting Opportunistic Addresses for REA 1665 REA do need, as with all other message types, a final destination IP 1666 address to reach. But as many applications do not provide a 1667 destination IP address in the first place, there is a need to choose 1668 a destination address for REA messages. This destination address can 1669 be the final target, but for applications which do not provide an 1670 upfront address, the destination address has to be chosen 1671 independently. Choosing the 'correct' destination IP address may be 1672 difficult and it is possible there is no 'right answer'. [19] shows 1673 choices for SIP and this section provides some hints about choosing a 1674 good destination IP address. 1676 1. Public IP address of the data sender: 1677 * Assumption: 1678 + The data receiver already learned the IP address of the 1679 data sender (e.g., via a third party). 1680 * Problems: 1681 + The data sender might also be behind a NAT. In this case 1682 the public IP address of the data receiver is the IP 1683 address allocated at this NAT. 1684 + Due to routing asymmetry it might be possible that the 1685 routes taken by a) the data sender and the application 1686 server b) the data sender and NAT B might be different, 1687 this could happen in a network deployment such as in Figure 1688 12. As a consequence it might be necessary to advertise a 1689 new (and different) external IP address within the 1690 application (which may or may not allow that) after using 1691 NSIS to establish a NAT binding. 1692 2. Public IP address of the data receiver (allocated at NAT B): 1693 * Assumption: 1694 + The data receiver already learned his externally visible IP 1695 address (e.g., based on the third party communication). 1696 * Problems: 1697 + Communication with a third party is required. 1698 3. IP address of the Application Server: 1699 * Assumption: 1700 + An application server (or a different third party) is 1701 available. 1702 * Problems: 1703 + If the NSIS signaling message is not terminated at the NAT 1704 of the local network then an NSIS unaware application 1705 server might discard the message. 1706 + Routing might not be optimal since the route between a) the 1707 data receiver and the application server b) the data 1708 receiver and the data sender might be different. 1710 4. NATFW NSLP NTLP Requirements 1712 The NATFW NSLP requires the following capabilities from the NTLP: 1713 o Ability to detect that the NSIS Responder does not support NATFW 1714 NSLP. This capability is key to launching the proxy mode behavior 1715 as described in Section 3.3.8 and [17]. 1716 o Detection of NATs and their support of the NSIS NATFW NSLP. If 1717 the NTLP discovers that the NSIS host is behind an NSIS aware NAT, 1718 the NR will send REA messages to the opportunistic address. If 1719 the NTLP discovers that the NSIS host is behind a NAT that does 1720 not support NSIS then the NSIS host will need to use a separate 1721 NAT traversal mechanism. 1722 o Message origin authentication and message integrity protection 1723 o Detection of routing changes 1724 o Protection against malicious announcement of fake path changes, 1725 this is needed to mitigate a threat discussed in section 7 of [21] 1727 5. NATFW NSLP Message Components 1729 A NATFW NSLP message consists of a NSLP header and one or more 1730 objects following the header. The NSLP header is common for all 1731 NSLPs and objects are Type-Length-Value (TLV) encoded using big 1732 endian (network ordered) binary data representations. Header and 1733 objects are aligned to 32 bit boundaries and object lengths that are 1734 not multiples of 32 bits must be padded to the next higher 32 bit 1735 multiple. 1737 The whole NSLP message is carried as payload of a NTLP message. 1739 Note that the notation 0x is used to indicate hexadecimal numbers. 1741 5.1 NSLP Header 1743 The NSLP header is common to all NSLPs and is the first part of all 1744 NSLP messages. It contains two fields, the NSLP message type and a 1745 reserved field. The total length is 32 bits. The layout of the NSLP 1746 header is defined by Figure 21. 1748 0 16 31 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | NSLP message type | reserved | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 Figure 21: Common NSLP header 1755 The reserved field MUST be set to zero in the NATFW NSLP header 1756 before sending and MUST be ignored during processing of the header. 1757 Note that other NSLPs use this field as a flag field. 1759 5.2 NSLP message types 1761 The message types identify requests and responses. Defined messages 1762 types for requests are: 1763 o 0x0101 : CREATE 1764 o 0x0102 : RESERVE-EXTERNAL-ADDRESS(REA) 1765 o 0x0103 : QUERY 1766 o 0x0104 : NOTIFY 1767 o 0x0105 : RESPONSE 1768 o 0x0106 : TRIGGER 1769 Defined message types for responses are (TBD): 1771 o TBD 1773 5.3 NSLP Objects 1775 NATFW NSLP objects use a common header format defined by Figure 22. 1776 Objects are Type-Length-Value (TLV) encoded using big endian (network 1777 ordered) binary data representations. The object header contains two 1778 fields, the NSLP object type and the object length. Its total length 1779 is 32 bits. 1781 Note that all objects MUST be padded to a length which is a multiple 1782 of 32 bits. 1784 0 16 31 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | NSLP object type | NSLP object length | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 Figure 22: Common NSLP object header 1791 The length is the total length of the object without the object 1792 header. The unit is a word, consisting of 4 octets. The particular 1793 values of type and length for each NSLP object are listed in the 1794 subsequent sections that define the NSLP objects. 1796 TBD: Processing of unknown options is currently subject to 1797 discussions within the working group. It is proposed to extend the 1798 NSLP object header with some bits that indicate treatment of unknown 1799 options. The compatibility bits (CP) are coded into two 2 bits and 1800 determine the action to take upon receiving an unknown option. The 1801 applied behavior based on the CP bits is: 1802 00 - Abort processing and report error 1803 01 - Ignore object and do not forward 1804 10 - Ignore object and do forward 1805 All other combinations MUST NOT be set and objects carrying these 1806 other CP bit combinations MUST discarded. 1808 5.3.1 Session Lifetime Object 1810 The session lifetime object carries the requested or granted lifetime 1811 of a NATFW NSLP session measured in seconds. The object consists 1812 only of the 4 bytes lifetime field. 1814 0 16 31 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | OID_NATFW_LT | 0x0001 | 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 | NATFW NSLP session lifetime | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 Figure 23: Lifetime object 1823 5.3.2 External Address Object 1825 The external address objects can be included in RESPONSE messages 1826 (Section 5.4.4) only. It contains the external IP address and port 1827 number allocated at the edge-NAT. Two fields are defined, the 1828 external IP address, and the external port number. For IPv4 the 1829 object with value OID_NATFW_IPv4 is defined. It has a length of 8 1830 bytes and is shown in Figure 24. 1832 0 16 31 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | OID_NATFW_IPv4 | 0x0002 | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | port number | reserved | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | IPv4 address | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 Figure 24: External Address Object for IPv4 addresses 1843 For IPv6 the object with value OID_NATFW_IPv6 is defined. It has a 1844 length of 20 bytes and is shown in Figure 25. 1846 0 16 31 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | OID_NATFW_IPv6 | 0x0005 | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | port number | reserved | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | | 1853 + + 1854 | | 1855 + IPv6 address + 1856 | | 1857 + + 1858 | | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 Figure 25: External Address Object for IPv6 addresses 1863 5.3.3 Extended Flow Information Object 1865 In general, flow information is kept at the NTLP level during 1866 signaling. The message routing information of the NTLP carries all 1867 necessary information. Nevertheless, some additional information may 1868 be required for NSLP operations. The 'extended flow information' 1869 object carries this additional information about action to be taken 1870 on the installed policy rules and subsequent numbers of policy rules. 1872 These fields are defined for the policy rule object: 1873 o Rule action: This field indicates the action for the policy rule 1874 to be activated. Allow values are 'allow' (0x01) and 'deny' 1875 (0x02) 1876 o Number of ports: This field gives the number of ports that should 1877 be allocated beginning at the port given in NTLP's message routing 1878 information. 1880 0 16 31 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | OID_NATFW_FLOW | 0x0001 | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | rule action | number of ports | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 Figure 26: Extended Flow Information 1889 5.3.4 Response Code Object 1891 This object carries the response code, which may be indications for 1892 either a successful request or failed request depending on the value 1893 of the 'response code' field. 1895 0 16 31 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | OID_NATFW_RESPONSE | 0x0001 | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | response code | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 Figure 27: Response Code Object 1904 TBD: Define response classes, success codes and error codes. 1905 Possible error classes are: 1906 o Policy rule errors 1907 o Authentication and Authorization errors 1908 o NAT 1909 Currently errors defined in this memo are: 1910 o lifetime too big 1911 o lifetime not acceptable 1912 o no NAT here 1913 o no reservation found 1914 o requested external address from outside 1915 o re-authorization needed 1916 o routing change detected 1918 5.3.5 Response Type Object 1920 The response type object indicates that a specific response is needed 1921 to the NSLP responder. 1923 0 16 31 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | OID_NATFW_RESP_TYPE | 0x0001 | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 |C|S|L| reserved | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | Source IP address | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 Figure 28: Response Type Object 1934 If the C bit is set to 1 the required response is a CREATE request 1935 message, otherwise a RESPONSE message. If the S bit is set to 1 the 1936 scoping object MUST be used. If the L bit is set to 1 the CREATE 1937 request message is ONLY sent if the message does not reach its 1938 target, even though the if the C bit is set. 1940 The source IP address is optional and may be set to a zero IP address 1941 or to a real IP address. If set to a real address, NATFW NSLP uses 1942 this address as assumed data sender's address. 1944 5.3.6 Message Sequence Number Object 1946 TBD. 1948 0 16 31 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | OID_NATFW_MSN | 0x0001 | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | message sequence number | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 Figure 29: Message Sequence Number Object 1957 5.3.7 Scoping Object 1959 The scoping object determines the allowed scope for the particular 1960 message. 1962 0 16 31 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | OID_NATFW_SCOPE | 0x0001 | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | message scope | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 Figure 30: Scoping Object 1971 These possible message scope values are: region, single hop. 1973 5.3.8 Bound Session ID Object 1975 This object carries a session ID and is used for QUERY messages only. 1977 0 16 31 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | OID_NATFW_BID | 0x0001 | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | bound session ID | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 Figure 31: Bound Session ID Object 1986 5.3.9 Notify Target Object 1988 This object carries the IP address of the notify target node. TBD: 1989 Details on this, like IPv6 version etc. 1991 0 16 31 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | OID_NATFW_NOTIFY_TGT | 0x0001 | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | notify nodes' IPv4 address | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 Figure 32: Notify Target Object 2000 5.4 Message Formats 2002 This section defines the content of each NATFW NSLP message type. 2003 The message types are defined in Section 5.2. First, the request 2004 messages are defined with their respective objects to be included in 2005 the message. Second, the response messages are defined with their 2006 respective objects to be included. 2008 Basically, each message is constructed of NSLP header and one or more 2009 NSLP objects. The order of objects is not defined, meaning that 2010 objects may occur in any sequence. Objects are marked either with 2011 mandatory [M] or optional [O]. Where [M] implies that this 2012 particular object MUST be included within the message and where [O] 2013 implies that this particular object is OPTIONAL within the message. 2015 Each section elaborates the required settings and parameters to be 2016 set by the NSLP for the NTLP, for instance, how the message routing 2017 information is set. 2019 5.4.1 CREATE 2021 The CREATE request message is used to create NSLP sessions and to 2022 create policy rules. Furthermore, CREATE messages are used to 2023 refresh sessions and to delete them. 2025 The CREATE message carries these objects: 2026 o Lifetime object [M] 2027 o Extended flow information object [M] 2028 o Message sequence number object [M] 2029 o Respose type object [O] 2030 o Scoping object[O] 2031 o Notify target [O] 2033 The message routing information in the NTLP MUST be set to DS as 2034 source address and DR as destination address. All other parameters 2035 MUST be set according the required policy rule. When the CREATE 2036 messages is received by a node operating in proxy mode Section 3.3.8 2037 the NI address is the NR address from the message that triggered the 2038 CREATE to be sent, if that address is not valid (wildcarded) the 2039 proxy node address is used instead. The NR address would be the NI's 2040 address provided by the message routing information of the message 2041 that triggered the CREATE. 2043 5.4.2 RESERVE-EXTERNAL-ADDRESS (REA) 2045 The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to target 2046 a NAT and to allocated an external IP address and possibly port 2047 number, so that the initiator of the REA request has a public 2048 reachable IP address/port number. 2050 The REA request message carries these objects: 2051 o Lifetime object [M] 2052 o Message sequence number object [M] 2053 o Response type object [M] 2054 o Scoping object [M] 2055 o Extended flow information [O] 2057 The REA message needs special NTLP treatment. First of all, REA 2058 messages travel the wrong way, from the DR towards DS. Second, the 2059 DS' address used during the signaling may be not the actual DS (see 2060 Section 3.7). Therefore, the NTLP flow routing information is set to 2061 DR as initiator and DS as responders, a special field is given in the 2062 NTLP: The signaling destination. 2064 5.4.3 TRIGGER 2066 The TRIGGER request message is used in proxy mode operation. 2068 The TRIGGER request message carries these objects: 2069 o Lifetime object [M] 2070 o Message sequence number object [M] 2071 o Response type object [M] 2072 o Scoping object [M] 2073 o Extended flow information [O] 2075 NTLP settings to be defined. 2077 5.4.4 RESPONSE 2079 RESPONSE messages are responses to CREATE, REA, and QUERY messages. 2081 The RESPONSE message carries these objects: 2082 o Lifetime object [M] 2083 o Response object [M] 2084 o External address object ([M] for success responses to REA) 2086 This message is routed upstream. 2088 5.4.5 QUERY 2090 QUERY messages are used for diagnosis purposes. 2092 The QUERY message carries these objects: 2093 o Response object [M] 2094 o Message sequence number object [M] 2095 o Scoping object [M] 2096 o Bound session ID [O] 2098 This message is routed downstream. 2100 5.4.6 NOTIFY 2102 The NOTIFY messages is used to report asynchronous events happening 2103 along the signaled path to other NATFW NSLP nodes. 2105 The NOTIFY message carries this object: 2106 o Response code object with NOTIFY code [M]. 2108 The message routing information in the NTLP MUST be set to DS as 2109 source address and DR as destination address, forwarding direction is 2110 upstream (Note that Section 5.4.6 discusses some design options 2111 regarding the message transport). The session id object must be set 2112 to the corresponding session that is effected by this asynchronous 2113 event. 2115 6. NSIS NAT and Firewall Transition Issues 2117 NSIS NAT and Firewall transition issues are premature and will be 2118 addressed in a separate draft (see [17]). An update of this section 2119 will be based on consensus. 2121 7. Security Considerations 2123 Security is of major concern particularly in case of Firewall 2124 traversal. Security threats for NSIS signaling in general have been 2125 described in [6] and they are applicable to this document. [21] 2126 extends this threat investigtion by considering NATFW NSLP specific 2127 threats. Based on the identified threats a list of security 2128 requirements have been defined. As an important requirement for 2129 security protection it is necessary to provide 2130 o data origin authentication 2131 o replay protection 2132 o integrity protection and 2133 o optionally confidentiality protection 2134 between neighboring NATFW NSLP nodes. 2136 To consider the aspect of authentication and key exchange we aim to 2137 reuse the mechanisms provided in [3] between neighboring nodes. 2139 Some scenarios also demand security between non-neighboring nodes but 2140 this aspect is still in discussions. A possible commonality with the 2141 QoS NSLP has been identified and CMS [24] has been investigated as a 2142 possible candidate for security protection between non-neighboring 2143 entities. Note that this aspect also includes some more 2144 sophisticated user authentication mechanisms, as described in [23]. 2145 With regard to end-to-end security the need for a binding between an 2146 NSIS signaling session and application layer session has been 2147 described in Section 3.3 of [6]. 2149 In order to solicit feedback from the IETF community on some hard 2150 security problems for path-coupled NATFW signaling a more detailed 2151 description in [22] is available. 2153 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 2154 and is, as such, not a two-party protocol. This fact requires more 2155 thoughts about scenarios, trust relationships and authorization 2156 mechanisms. This section lists a few scenarios relevant for security 2157 and illustrates possible trust reationships which have an impact to 2158 authorization. More problematic scenarios are described in Appendix 2159 A. 2161 7.1 Trust Relationship and Authorization 2163 Trust relationships and authorization are very important for the 2164 protocol machinery. Trust and authorization are closely related to 2165 each other in the sense that a certain degree of trust is required to 2166 authorize a particular action. For any action (e.g. "create/delete 2167 /prolong policy rules), authorization is very important due to the 2168 nature of middleboxes. 2170 Different types of trust relationships may affect different 2171 categories of middleboxes. As explained in [26], establishment of a 2172 financial relationship is typically very important for QoS signaling, 2173 whereas financial relationships are less directly of interest for 2174 NATFW middlebox signaling. It is therefore not particularly 2175 surprising that there are differences in the nature and level of 2176 authorization likely to be required in a QoS signaling environment 2177 and in NATFW middlebox signaling. For NATFW middlebox signaling, a 2178 stronger or weaker degree of authorization might be needed. 2179 Typically NATFW signaling requires authorization to configure and 2180 traverse particular nodes or networks which may derive indirectly 2181 from a financial relationship. This is a more 'absolute' situation 2182 either the usage is allowed or not, and the effect on both network 2183 owner and network user is 'binary'. 2185 Different trust relationships that appear in middlebox signaling 2186 environments are described in the subsequent sub-sections. QoS 2187 signaling today uses peer-to-peer trust relationships. They are 2188 simplest kind of trust relationships. However, there are reasons to 2189 believe that this is not the only type of trust relationship found in 2190 today's networks. 2192 7.1.1 Peer-to-Peer Trust Relationship 2194 Starting with the simplest scenario, it is assumed that neighboring 2195 nodes trust each other. The required security association to 2196 authenticate and to protect a signaling message is either available 2197 (after manual configuration), or has been dynamically established 2198 with the help of an authentication and key exchange protocol. If 2199 nodes are located closely together, it is assumed that security 2200 association establishment is easier than establishing it between 2201 distant nodes. It is, however, difficult to describe this 2202 relationship generally due to the different usage scenarios and 2203 environments. Authorization heavily depends on the participating 2204 entities, but for this scenario, it is assumed that neighboring 2205 entities trust each other (at least for the purpose of policy rule 2206 creation, maintenance, and deletion). Note that Figure 33 does not 2207 illustrate the trust relationship between the end host and the access 2208 network. 2210 +------------------------+ +-------------------------+ 2211 | | | | 2212 | Network A | | Network B | 2213 | | | | 2214 | +---------+ +---------+ | 2215 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 2216 | | | box 1 | Trust | box 2 | | | 2217 | | +---------+ Relationship +---------+ | | 2218 | | | | | | 2219 | | | | | | 2220 | | | | | | 2221 | | Trust | | Trust | | 2222 | | Relationship | | Relationship | | 2223 | | | | | | 2224 | | | | | | 2225 | | | | | | 2226 | +--+---+ | | +--+---+ | 2227 | | Host | | | | Host | | 2228 | | A | | | | B | | 2229 | +------+ | | +------+ | 2230 +------------------------+ +-------------------------+ 2232 Figure 33: Peer-to-Peer Trust Relationship 2234 7.1.2 Intra-Domain Trust Relationship 2236 In larger corporations, often more than one middlebox is used to 2237 protect or serve different departments. In many cases, the entire 2238 enterprise is controlled by a security department, which gives 2239 instructions to the department administrators. In such a scenario, a 2240 peer-to-peer trust-relationship might be prevalent. Sometimes it 2241 might be necessary to preserve authentication and authorization 2242 information within the network. As a possible solution, a 2243 centralized approach could be used, whereby an interaction between 2244 the individual middleboxes and a central entity (for example a policy 2245 decision point - PDP) takes place. As an alternative, individual 2246 middleboxes could exchange the authorization decision with another 2247 middlebox within the same trust domain. Individual middleboxes 2248 within an administrative domain should exploit their trust 2249 relationship instead of requesting authentication and authorization 2250 of the signaling initiator again and again. Thereby complex protocol 2251 interactions are avoided. This provides both a performance 2252 improvement without a security disadvantage since a single 2253 administrative domain can be seen as a single entity. Figure 34 2254 illustrates a network structure which uses a centralized entity. 2256 +-----------------------------------------------------------+ 2257 | | 2258 | Network A | 2259 | | 2260 | | 2261 | +---------+ +---------+ 2262 | +----///--------+ Middle- +------///------++ Middle- +--- 2263 | | | box 2 | | box 2 | 2264 | | +----+----+ +----+----+ 2265 | | | | | 2266 | +----+----+ | | | 2267 | | Middle- +--------+ +---------+ | | 2268 | | box 1 | | | | | 2269 | +----+----+ | | | | 2270 | | | | | | 2271 | - | | | | 2272 | - | +----+-----+ | | 2273 | | | | Policy | | | 2274 | +--+---+ +-----------+ Decision +----------+ | 2275 | | Host | | Point | | 2276 | | A | +----------+ | 2277 | +------+ | 2278 +-----------------------------------------------------------+ 2280 Figure 34: Intra-domain Trust Relationship 2282 7.1.3 End-to-Middle Trust Relationship 2284 In some scenarios, a simple peer-to-peer trust relationship between 2285 participating nodes is not sufficient. Network B might require 2286 additional authorization of the signaling message initiator. If 2287 authentication and authorization information is not attached to the 2288 initial signaling message then the signaling message arriving at 2289 Middlebox 2 would result in an error message being created, which 2290 indicates the additional authorization requirement. In many cases 2291 the signaling message initiator is already aware of the additionally 2292 required authorization before the signaling message exchange is 2293 executed. Replay protection is a requirement for authentication to 2294 the non-neighboring middlebox, which might be difficult to accomplish 2295 without adding additional roundtrips to the signaling protocol (e.g., 2296 by adding a challenge/response type of message exchange). 2298 Figure 35 shows the slightly more complex trust relationships in this 2299 scenario. 2301 +----------------------+ +--------------------------+ 2302 | | | | 2303 | Network A | | Network B | 2304 | | | | 2305 | | Trust | | 2306 | | Relationship | | 2307 | +---------+ +---------+ | 2308 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 2309 | | | box 1 | +-------+ box 2 | | | 2310 | | +---------+ | +---------+ | | 2311 | | | | | | | 2312 | |Trust | | | | | 2313 | |Relationship | | | | | 2314 | | | | | Trust | | 2315 | | | | | Relationship| | 2316 | | | | | | | 2317 | | | | | | | 2318 | | | | | | | 2319 | | | | | | | 2320 | +--+---+ | | | +--+---+ | 2321 | | Host +----///----+------+ | | Host | | 2322 | | A | |Trust | | B | | 2323 | +------+ |Relationship | +------+ | 2324 +----------------------+ +--------------------------+ 2326 Figure 35: End-to-Middle Trust Relationship 2328 Finally it should be noted that installing packet filters provides 2329 some security, but also has some weaknesses, which heavily depend on 2330 the type of packet filter installed. A packet filter cannot prevent 2331 an adversary to inject traffic (due to the IP spoofing capabilities). 2332 This type of attack might not be particular helpful if the packet 2333 filter is a standard 5 tuple which is very restrictive. If packet 2334 filter installation, however, allows specifying a rule, which 2335 restricts only the source IP address, then IP spoofing allows 2336 transmitting traffic to an arbitrary address. NSIS aims to provide 2337 path-coupled signaling and therefore an adversary is somewhat 2338 restricted in the location from which attacks can be performed. Some 2339 trust is therefore assumed from nodes and networks along the path. 2341 8. Open Issues 2343 The NATFW NSLP has a series of related documents discussing several 2344 other aspects of path-coupled NATFW signaling, including security 2345 [22], migration (i.e., traversal of nsis unaware NATs) [17], 2346 intra-realm signaling [18], and inter-working with SIP [19]. 2347 Summaries of the outcomes from these documents may be added, 2348 depending on WG feedback, to a later version of this draft. 2350 A more detailed list of open issue can be found at: 2351 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-natfw-issues/index 2353 9. Contributors 2355 A number of individuals have contributed to this draft. Since it was 2356 not possible to list them all in the authors section, it was decided 2357 to split it and move Marcus Brunner and Henning Schulzrinne into the 2358 contributors section. Separating into two groups was done without 2359 treating any one of them better (or worse) than others. 2361 10. References 2363 10.1 Normative References 2365 [1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT 2366 draft-ietf-nsis-fw-05.txt, October 2003. 2368 [2] Brunner et al., M., "Requirements for Signaling Protocols", 2369 DRAFT draft-ietf-nsis-req-09.txt, October 2003. 2371 [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 2372 Messaging Protocol for Signaling", DRAFT 2373 draft-ietf-nsis-ntlp-02.txt, October 2003. 2375 [4] Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 2376 Quality-of-Service signaling", DRAFT 2377 draft-ietf-nsis-qos-nslp-03.txt, May 2004. 2379 [5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 2381 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 2382 DRAFT draft-ietf-nsis-threats-01.txt, January 2003. 2384 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 2385 Rayhan, "Middlebox communication architecture and framework", 2386 RFC 3303, August 2002. 2388 10.2 Informative References 2390 [8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 2391 (NAT) Terminology and Considerations, RFC 2663", August 1999. 2393 [9] Srisuresh, P. and M. Holdrege, "Network Address Translator 2394 (NAT)Terminology and Considerations, RFC 2663". 2396 [10] Srisuresh, P. and E. Egevang, "Traditional IP Network Address 2397 Translator (Traditional NAT), RFC 3022", January 2001. 2399 [11] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 2400 Protocol Translation (NAT-PT), RFC 2766", February 2000. 2402 [12] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 2403 RFC 3234, February 2002. 2405 [13] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, 2406 "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2407 2694, September 1999. 2409 [14] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 2410 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 2411 Specification", September 1997. 2413 [15] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 2414 Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 2415 3182, October 2001. 2417 [16] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and 2418 X. Fu, "Security Implications of the Session Identifier", June 2419 2003. 2421 [17] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 2422 Tschofenig, "NAT/Firewall NSLP Migration Considerations", DRAFT 2423 draft-aoun-nsis-nslp-natfw-migration-01.txt, Februar 2004. 2425 [18] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 2426 Tschofenig, "NATFirewall NSLP Intra-realm considerations", 2427 DRAFT draft-aoun-nsis-nslp-natfw-intrarealm-00.txt, Februar 2428 2004. 2430 [19] Martin, M., Brunner, M. and M. Stiemerling, "SIP NSIS 2431 Interactions for NAT/Firewall Traversal", DRAFT 2432 draft-martin-nsis-nslp-natfw-sip-00.txt, Februar 2004. 2434 [20] Martin, M., Brunner, M., Stiemerling, M., Girao, J. and C. 2435 Aoun, "A NSIS NAT/Firewall NSLP Security Infrastructure", DRAFT 2436 draft-martin-nsis-nslp-natfw-security-01.txt, February 2004. 2438 [21] Fessi, A., Brunner, M., Stiemerling, M., Thiruvengadam, S., 2439 Tschofenig, H. and C. Aoun, "Security Threats for the NAT/ 2440 Firewall NSLP", DRAFT draft-fessi-nsis-natfw-threats-01.txt, 2441 July 2004. 2443 [22] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security 2444 Problems", draft-tschofenig-nsis-natfw-security-problems-00.txt 2445 (work in progress), July 2004. 2447 [23] Tschofenig, H. and J. Kross, "Extended QoS Authorization for 2448 the QoS NSLP", draft-tschofenig-nsis-qos-ext-authz-00.txt (work 2449 in progress), July 2004. 2451 [24] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 2452 August 2002. 2454 [25] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K. 2455 Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt, 2456 November 2002. 2458 [26] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. 2459 Schulzrinne, "NSIS Authentication, Authorization and Accounting 2460 Issues", March 2003. 2462 [27] Amini, L. and H. Schulzrinne, "Observations from router-level 2463 internet traces", DIMACS Workshop on Internet and WWW 2464 Measurement, Mapping and Modelin Jersey) , Februar 2002. 2466 [28] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 2467 Traversal of VPN Gateways", 2468 draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in 2469 progress), April 2003. 2471 [29] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin, 2472 "Problem Space and Usage Scenarios for PANA", 2473 draft-ietf-pana-usage-scenarios-06 (work in progress), April 2474 2003. 2476 [30] Shore, M., "The TIST (Topology-Insensitive Service Traversal) 2477 Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002. 2479 [31] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT 2480 Traversal Client for CASP", DRAFT 2481 draft-tschofenig-nsis-casp-midcom-01.txt, March 2003. 2483 [32] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2484 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2485 Session Initiation Protocol", RFC 3261, June 2002. 2487 [33] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H. 2488 Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and 2489 Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June 2490 2003. 2492 [34] Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P) 2493 communication Network Address Translators(NAT)", DRAFT 2494 draft-ford-midcom-p2p-02.txt, March 2004. 2496 [35] Rosenberg et al, J., "STUN - Simple Traversal of User Datagram 2497 Protocol (UDP) Through Network Address Translators (NATs)", RFC 2498 3489, March 2003. 2500 [36] Rekhter et al, Y., "Address Allocation for Private Internets", 2501 RFC 1918, February 1996. 2503 [37] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 2504 draft-rosenberg-midcom-turn-05 (work in progress), July 2004. 2506 [38] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 2507 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 2508 Waldbusser, "Terminology for Policy-Based Management", RFC 2509 3198, November 2001. 2511 Authors' Addresses 2513 Martin Stiemerling 2514 Network Laboratories, NEC Europe Ltd. 2515 Kurfuersten-Anlage 36 2516 Heidelberg 69115 2517 Germany 2519 Phone: +49 (0) 6221 905 11 13 2520 EMail: stiemerling@netlab.nec.de 2521 URI: http://www.stiemerling.org 2523 Hannes Tschofenig 2524 Siemens AG 2525 Otto-Hahn-Ring 6 2526 Munich 81739 2527 Germany 2529 Phone: 2530 EMail: Hannes.Tschofenig@siemens.com 2531 URI: 2533 Miquel Martin 2534 Network Laboratories, NEC Europe Ltd. 2535 Kurfuersten-Anlage 36 2536 Heidelberg 69115 2537 Germany 2539 Phone: +49 (0) 6221 905 11 16 2540 EMail: miquel.martin@netlab.nec.de 2541 URI: 2543 Cedric Aoun 2544 Nortel Networks/ENST Paris 2546 France 2548 EMail: cedric.aoun@nortelnetworks.com 2550 Appendix A. Problems and Challenges 2552 This section describes a number of problems that have to be addressed 2553 for NSIS NAT/Firewall. Issues presented here are subject to further 2554 discussions. These issues might be also of relevance to other NSLP 2555 protocols. 2557 A.1 Missing Network-to-Network Trust Relationship 2559 Peer-to-peer trust relationship, as shown in Figure 33, is a very 2560 convenient assumption that allows simplified signaling message 2561 processing. However, it might not always be applicable, especially 2562 between two arbitrary access networks (over a core network where 2563 signaling messages are not interpreted). Possibly peer-to-peer trust 2564 relationship does not exist because of the large number of networks 2565 and the unwillingness of administrators to have other network 2566 operators to create holes in their Firewalls without proper 2567 authorization. 2569 +----------------------+ +--------------------------+ 2570 | | | | 2571 | Network A | | Network B | 2572 | | | | 2573 | +---------+ Missing +---------+ | 2574 | +-///-+ Middle- | Trust | Middle- +-///-+ | 2575 | | | box 1 | Relation- | box 2 | | | 2576 | | +---------+ ship +---------+ | | 2577 | | | or | | | 2578 | | | Authorization| | | 2579 | | | | | | 2580 | | Trust | | Trust | | 2581 | | Relationship | | Relationship | | 2582 | | | | | | 2583 | | | | | | 2584 | | | | | | 2585 | +--+---+ | | +--+---+ | 2586 | | Host | | | | Host | | 2587 | | A | | | | B | | 2588 | +------+ | | +------+ | 2589 +----------------------+ +--------------------------+ 2591 Figure 36: Missing Network-to-Network Trust Relationship 2593 Figure 36 illustrates a problem whereby an external node is not 2594 allowed to manipulate (create, delete, query, etc.) packet filters at 2595 a Firewall. Opening pinholes is only allowed for internal nodes or 2596 with a certain authorization permission. Hence the solution 2597 alternatives in Section 3.3.2 focus on establishing the necessary 2598 trust with cooperation of internal nodes. 2600 A.2 Relationship with routing 2602 The data path is following the "normal" routes. The NAT/FW devices 2603 along the data path are those providing the service. In this case 2604 the service is something like "open a pinhole" or even more general 2605 "allow for connectivity between two communication partners". The 2606 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 2607 does not need to determine what middleboxes or in what order the data 2608 flow will go through. 2610 Creating NAT bindings modifies the path of data packets between two 2611 end points. Without NATs involved, packets flow from endhost to 2612 endhost following the path given by the routing. With NATs involved, 2613 this end-to-end flow is not directly possible, because of separated 2614 address realms. Thus, data packets flow towards the external IP 2615 address at a NAT (external IP address may be a public IP address). 2616 Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with 2617 routing - instead they only follow the path of the data packets. 2619 A.3 Affected Parts of the Network 2621 NATs and Firewalls are usually located at the edge of the network, 2622 whereby other signaling applications affect all nodes along the path. 2623 One typical example is QoS signaling where all networks along the 2624 path must provide QoS in order to achieve true end-to-end QoS. In 2625 the NAT/Firewall case, only some of the domains/nodes are affected 2626 (typically access networks), whereas most parts of the networks and 2627 nodes are unaffected (e.g., the core network). 2629 This fact raises some questions. Should an NSIS NTLP node intercept 2630 every signaling message independently of the upper layer signaling 2631 application or should it be possible to make the discovery procedure 2632 more intelligent to skip nodes. These questions are also related to 2633 the question whether NSIS NAT/FW should be combined with other NSIS 2634 signaling applications. 2636 A.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls 2638 Backward compatibility is a key for NSIS deployments, as such the 2639 NSIS protocol suite should be sufficiently robust to allow traversal 2640 of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ). 2642 NSIS NATFW NSLP's backward compatibility issues are different than 2643 the NSIS QoS NSLP backward compatibility issues, where an NSIS 2644 unaware QoS gate will simply forward the QoS NSLP message. An NSIS 2645 unaware Firewall rejects NSIS messages, since Firewalls typically 2646 implement the policy "default to deny". 2648 The NSIS backward compatibility support on none NSIS aware Firewall 2649 would typically consist of configuring a static policy rule that 2650 allows the forwarding of the NSIS protocol messages (either protocol 2651 type if raw transport mode is used or transport port number in case a 2652 transport protocol is used). 2654 For NATs backward compatibility is more problematic since signaling 2655 messages are forwarded (at least in one direction), but with a 2656 changed IP address and changed port numbers. The content of the NSIS 2657 signaling message is, however, unchanged. This can lead to 2658 unexpected results, both due to embedded unchanged local scoped 2659 addresses and none NSIS aware Firewalls configured with specific 2660 policy rules allowing forwarding of the NSIS protocol (case of 2661 transport protocols are used for the NTLP). NSIS unaware NATs must 2662 be detected to maintain a well-known deterministic mode of operation 2663 for all the involved NSIS entities. Such a "legacy" NAT detection 2664 procedure can be done during the NSIS discover procedure itself. 2666 Based on experience it was discovered that routers unaware of the 2667 Router Alert IP option [RFC 2113] discarded packets, this is 2668 certainly a problem for NSIS signaling. 2670 A.5 Authentication and Authorization 2672 For both types of middleboxes, Firewall and NAT security is a strong 2673 requirement. Authentication and authorization means must be 2674 provided. 2676 For NATFW signaling applications it is partially not possible to do 2677 authentication and authorization based on IP addresses. Since NATs 2678 change IP addresses, such an address based authentication and 2679 authorization scheme would fail. 2681 A.6 Directional Properties 2683 There two directional properties that need to be addressed by the 2684 NATFW NSLP: 2685 o Directionality of the data 2686 o Directionality of NSLP signaling 2688 Both properties are relevant to NATFW NSLP aware NATs and Firewalls. 2690 With regards to NSLP signaling directionality: As stated in the 2691 previous sections, the authentication and authorization of NSLP 2692 signaling messages received from hosts within the same trust domain 2693 (typically from hosts located within the security perimeter delimited 2694 by Firewalls) is normally simpler than received messages sent by 2695 hosts located in different trust domains. 2697 The way NSIS signaling messages enters the NSIS entity of a Firewall 2698 (see Figure 2) might be important, because different policies might 2699 apply for authentication and admission control. 2701 Hosts deployed within the secured network perimeter delimited by a 2702 Firewall, are protected from hosts deployed outside the secured 2703 network perimeter, hence by nature the Firewall has more restrictions 2704 on flows triggered from hosts deployed outside the security 2705 perimeter. 2707 A.7 Addressing 2709 A more general problem of NATs is the addressing of the end-point. 2710 NSIS signaling message have to be addressed to the other end host to 2711 follow data packets subsequently sent. Therefore, a public IP 2712 address of the receiver has to be known prior to sending an NSIS 2713 message. When NSIS signaling messages contain IP addresses of the 2714 sender and the receiver in the signaling message payloads, then an 2715 NSIS entity must modify them. This is one of the cases, where a NSIS 2716 aware NATs is also helpful for other types of signaling applications 2717 e.g., QoS signaling. 2719 A.8 NTLP/NSLP NAT Support 2721 It must be possible for NSIS NATs along the path to change NTLP and/ 2722 or NSLP message payloads, which carry IP address and port 2723 information. This functionality includes the support of providing 2724 mid-session and mid-path modification of these payloads. As a 2725 consequence these payloads must not be reordered, integrity protected 2726 and/or encrypted in a non peer-to-peer fashion (e.g., end-to-middle, 2727 end-to-end protection). Ideally these mutable payloads must be 2728 marked (e.g., a protected flag) to assist NATs in their effort of 2729 adjusting these payloads. 2731 A.9 Combining Middlebox and QoS signaling 2733 In many cases, middlebox and QoS signaling has to be combined at 2734 least logically. Hence, it was suggested to combine them into a 2735 single signaling message or to tie them together with the help of 2736 some sort of data connection identifier, later on referred as Session 2737 ID. This, however, has some disadvantages such as: 2739 - NAT/FW NSLP signaling affects a much small number of NSIS nodes 2740 along the path (for example compared to the QoS signaling). 2742 - NAT/FW signaling might show different signaling patterns (e.g., 2743 required end-to-middle communication). 2745 - The refresh interval is likely to be different. 2747 - The number of error cases increase as different signaling 2748 applications are combined into a single message. The combination of 2749 error cases has to be considered. 2751 A.10 Inability to know the scenario 2753 In Section 2 a number of different scenarios are presented. Data 2754 receiver and sender may be located behind zero, one, or more 2755 Firewalls and NATs. Depending on the scenario, different signaling 2756 approaches have to be taken. For instance, data receiver with no 2757 NAT and Firewall can receive any sort of data and signaling without 2758 any further action. Data receivers behind a NAT must first obtain a 2759 public IP address before any signaling can happen. The scenario 2760 might even change over time with moving networks, ad-hoc networks or 2761 with mobility. 2763 NSIS signaling must assume the worst case and cannot put 2764 responsibility to the user to know which scenario is currently 2765 applicable. As a result, it might be necessary to perform a 2766 "discovery" periodically such that the NSIS entity at the end host 2767 has enough information to decide which scenario is currently 2768 applicable. This additional messaging, which might not be necessary 2769 in all cases, requires additional performance, bandwidth and adds 2770 complexity. Additional, information by the user can provide 2771 information to assist this "discovery" process, but cannot replace 2772 it. 2774 Appendix B. Acknowledgments 2776 We would like to acknowledge: Vishal Sankhla and Joao Girao for their 2777 input to this draft; and Reinaldo Penno for his comments on the 2778 initial version of the document. Furthermore, we would like thank 2779 Elwyn Davis for his valuable help and input. 2781 Intellectual Property Statement 2783 The IETF takes no position regarding the validity or scope of any 2784 Intellectual Property Rights or other rights that might be claimed to 2785 pertain to the implementation or use of the technology described in 2786 this document or the extent to which any license under such rights 2787 might or might not be available; nor does it represent that it has 2788 made any independent effort to identify any such rights. Information 2789 on the procedures with respect to rights in RFC documents can be 2790 found in BCP 78 and BCP 79. 2792 Copies of IPR disclosures made to the IETF Secretariat and any 2793 assurances of licenses to be made available, or the result of an 2794 attempt made to obtain a general license or permission for the use of 2795 such proprietary rights by implementers or users of this 2796 specification can be obtained from the IETF on-line IPR repository at 2797 http://www.ietf.org/ipr. 2799 The IETF invites any interested party to bring to its attention any 2800 copyrights, patents or patent applications, or other proprietary 2801 rights that may cover technology that may be required to implement 2802 this standard. Please address the information to the IETF at 2803 ietf-ipr@ietf.org. 2805 Disclaimer of Validity 2807 This document and the information contained herein are provided on an 2808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2810 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2811 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2812 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2815 Copyright Statement 2817 Copyright (C) The Internet Society (2004). This document is subject 2818 to the rights, licenses and restrictions contained in BCP 78, and 2819 except as set forth therein, the authors retain all their rights. 2821 Acknowledgment 2823 Funding for the RFC Editor function is currently provided by the 2824 Internet Society.