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