idnits 2.17.1 draft-ietf-nsis-nslp-natfw-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3733. ** 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 7 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 962 has weird spacing: '...creates polic...' == Line 963 has weird spacing: '...rvation mode ...' == Line 992 has weird spacing: '...nvolved will ...' == Line 1235 has weird spacing: '... o The data ...' == Line 1275 has weird spacing: '... device respo...' == (6 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: When the data sender's IP address is not known, NI+s MUST NOT include a DSInfo object. o NSLP forwarder: NSLP forwarders receiving REA messages MUST first check authentication and authorization before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired policy rule given by NTLP's message routing information (MRI). Further processing depends on the middlebox type: * NAT: NATs check whether the message is received at the external (public in most cases) address or at the internal (private) address. If received at the external address a NF MAY generate a RESPONSE message with an error of type 'REA received from outside'. If received at the internal address, an IP address/port is reserved. In the case it is an edge-NAT, the NSLP message is not forwarded any further and a RESPONSE message with the external address and port information is generated. If it is not an edge-NAT, the NSLP message is forwarded further with the translated IP address/port. The edge-NAT MAY reject REA messages not carrying a DSInfo object or if the address information within this object is invalid or too much wildcarded. * Firewall: Firewalls MUST not change their configuration upon a REA message. They simply MUST forward the message and MUST keep NTLP state. Firewalls that are configured as edge-Firewalls MAY return an error of type 'no NAT here'. * Combined NAT and Firewall: Processing at combined Firewall and NAT middleboxes is the same as in the NAT case. o NSLP receiver: This type of message should never be received by any NR+ and it SHOULD be discarded silently. == 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: The processing of REA[PROXY] messages is different for every NSIS entity: o NSLP initiator (NI+): When the data sender's address information is known in advance the NI+ MAY include a DSInfo object in the REA[PROXY] request message. When the data sender's address is not known, NI+'s MUST NOT include a DSInfo object. NI+ only generate REA[PROXY] messages and should never receive them. o NSLP forwarder: NSLP forwarders receiving REA[PROXY] messages MUST first check authentication and authorization before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired policy rule given by NTLP's message routing information (MRI). Further processing depends on the middlebox type: * NAT: NATs check whether the message is received at the external (public in most cases) address or at the internal (private) address. If received at the external address a NF MAY generate a RESPONSE message with an error of type 'REA received from outside' and stop forwarding. If received at the internal address, an IP address/port is reserved. If it is not an edge-NAT, the NSLP message is forwarded further with the translated IP address/port. In the case it is an edge-NAT, the NSLP message is not forwarded any further. The edge-NAT checks whether it is willing to send CREATE messages on behalf on NI+ and if so it checks the DSInfo object. The edge-NAT MAY reject the REA[PROXY] request if there is no DSInfo object or if the address information within DSInfo is not valid or too much wildcarded. If accepted a RESPONSE message with the external address and port information is generated. When the edge-NAT accepts it generates a CREATE message as defined in Section 3.3.1. The edge-NAT MUST refresh the CREATE message session only if a REA[PROXY] refresh message has been received first. * Firewall: Firewalls MUST not change their configuration upon a REA message. They simply MUST forward the message and MUST keep NTLP state. Edge-Firewalls SHOULD reply with an error RESPONSE indicating 'no egde-NAT here'. * Combined NAT and Firewall: Processing at combined Firewall and NAT middleboxes is the same as in the NAT case. o NSLP receiver: This type of message should never be received by any NR+ and it SHOULD be discarded silently. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2005) is 6998 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 1363 -- Looks like a reference, but probably isn't: 'PROXY' on line 1682 -- Looks like a reference, but probably isn't: 'M' on line 2292 -- Looks like a reference, but probably isn't: 'O' on line 2282 -- Looks like a reference, but probably isn't: 'RFC 2113' on line 3593 == Unused Reference: '10' is defined on line 3357, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 3365, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3381, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 3388, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 3392, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 3429, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-05 -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '8') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '17') (Obsoleted by RFC 3852) == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-vpn-problem-statement-req-02 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '24') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-06 == Outdated reference: A later version (-05) exists of draft-tschofenig-sip-saml-02 Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group M. Stiemerling 2 Internet-Draft NEC 3 Expires: August 24, 2005 H. Tschofenig 4 Siemens 5 C. Aoun 6 Nortel 7 February 20, 2005 9 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 10 draft-ietf-nsis-nslp-natfw-05 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 24, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 46 Network Address Translators and Firewalls. This NSLP allows hosts to 47 signal along a data path for Network Address Translators and 48 Firewalls to be configured according to the data flow needs. The 49 network scenarios, problems and solutions for path-coupled Network 50 Address Translator and Firewall signaling are described. The overall 51 architecture is given by the framework and requirements defined by 52 the Next Steps in Signaling (NSIS) working group. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 7 58 1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8 59 1.3 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 60 1.4 General Scenario for NATFW Traversal . . . . . . . . . . . 10 62 2. Network Deployment Scenarios using NATFW NSLP . . . . . . . . 12 63 2.1 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 12 64 2.2 NAT with two private Networks . . . . . . . . . . . . . . 13 65 2.3 NAT with Private Network on Sender Side . . . . . . . . . 14 66 2.4 NAT with Private Network on Receiver Side Scenario . . . . 14 67 2.5 Both End Hosts behind twice-NATs . . . . . . . . . . . . . 15 68 2.6 Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 16 69 2.7 IPv4/v6 NAT with two Private Networks . . . . . . . . . . 17 70 2.8 Multihomed Network with NAT . . . . . . . . . . . . . . . 18 71 2.9 Multihomed Network with Firewall . . . . . . . . . . . . . 19 73 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 20 74 3.1 Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 20 75 3.2 Basic protocol overview . . . . . . . . . . . . . . . . . 20 76 3.3 Protocol Operations . . . . . . . . . . . . . . . . . . . 23 77 3.3.1 Creating Sessions . . . . . . . . . . . . . . . . . . 24 78 3.3.2 Reserving External Addresses . . . . . . . . . . . . . 26 79 3.3.3 NATFW Session refresh . . . . . . . . . . . . . . . . 31 80 3.3.4 Deleting Sessions . . . . . . . . . . . . . . . . . . 32 81 3.3.5 Reporting Asynchronous Events . . . . . . . . . . . . 33 82 3.3.6 QUERY capabilities within the NATFW NSLP protocol . . 33 83 3.3.7 Proxy Mode for Data Receiver behind NAT . . . . . . . 35 84 3.3.8 Proxy Mode for Data Sender behind Middleboxes . . . . 37 85 3.3.9 Proxy Mode for Data Receiver behind Firewall . . . . . 38 86 3.4 Calculation of Session Lifetime . . . . . . . . . . . . . 40 87 3.5 Firewall and NAT Resources . . . . . . . . . . . . . . . . 42 88 3.6 De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 43 89 3.7 Selecting Opportunistic Addresses for REA . . . . . . . . 43 91 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 45 92 4.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 45 93 4.2 NSLP message types . . . . . . . . . . . . . . . . . . . . 45 94 4.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 46 95 4.3.1 Session Lifetime Object . . . . . . . . . . . . . . . 46 96 4.3.2 External Address Object . . . . . . . . . . . . . . . 47 97 4.3.3 Extended Flow Information Object . . . . . . . . . . . 48 98 4.3.4 Response Code Object . . . . . . . . . . . . . . . . . 49 99 4.3.5 Proxy Support Type Object . . . . . . . . . . . . . . 49 100 4.3.6 Message Sequence Number Object . . . . . . . . . . . . 49 101 4.3.7 Bound Session ID Object . . . . . . . . . . . . . . . 50 102 4.3.8 Data Sender Information Object . . . . . . . . . . . . 50 103 4.4 Message Formats . . . . . . . . . . . . . . . . . . . . . 51 104 4.4.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 51 105 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 52 106 4.4.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 52 107 4.4.4 QUERY . . . . . . . . . . . . . . . . . . . . . . . . 52 108 4.4.5 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 53 109 4.4.6 UCREATE . . . . . . . . . . . . . . . . . . . . . . . 53 111 5. NATFW NSLP NTLP Requirements . . . . . . . . . . . . . . . . . 54 113 6. NSIS NAT and Firewall Transition Issues . . . . . . . . . . . 55 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 116 7.1 Trust Relationship and Authorization . . . . . . . . . . . 56 117 7.1.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 57 118 7.1.2 Intra-Domain Trust Relationship . . . . . . . . . . . 57 119 7.1.3 End-to-Middle Trust Relationship . . . . . . . . . . . 58 120 7.2 Security Threats and Requirements . . . . . . . . . . . . 59 121 7.2.1 Attacks related to authentication and authorization . 59 122 7.2.1.1 Data Sender (DS) behind a firewall . . . . . . . . 61 123 7.2.1.2 Data Sender (DS) behind a NAT . . . . . . . . . . 62 124 7.2.1.3 Data Receiver (DR) behind a firewall . . . . . . . 62 125 7.2.1.4 Data Receiver (DR) behind a NAT . . . . . . . . . 64 126 7.2.1.5 NSLP Message Injection . . . . . . . . . . . . . . 65 127 7.2.2 Denial-of-Service Attacks . . . . . . . . . . . . . . 65 128 7.2.2.1 Flooding with CREATE messages from outside . . . . 66 129 7.2.2.2 Flooding with REA messages from inside . . . . . . 67 130 7.2.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 67 131 7.2.4 Message Modification by non-NSIS on-path node . . . . 68 132 7.2.5 Message Modification by malicous NSIS node . . . . . . 68 133 7.2.6 Session Modification/Deletion . . . . . . . . . . . . 69 134 7.2.6.1 Misuse of mobility in NAT handling . . . . . . . . 70 135 7.2.7 Misuse of unreleased sessions . . . . . . . . . . . . 72 136 7.2.8 Data traffic injection . . . . . . . . . . . . . . . . 73 137 7.2.9 Eavesdropping and traffic analysis . . . . . . . . . . 75 138 7.3 Security Framework for the NAT/Firewall NSLP . . . . . . . 76 139 7.3.1 Security Protection between neighboring NATFW NSLP 140 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 76 141 7.3.2 Security Protection between non-neighboring NATFW 142 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 76 143 7.3.3 End-to-End Security . . . . . . . . . . . . . . . . . 78 145 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 79 147 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 81 149 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 150 10.1 Normative References . . . . . . . . . . . . . . . . . . . 82 151 10.2 Informative References . . . . . . . . . . . . . . . . . . 82 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 84 155 A. Problems and Challenges . . . . . . . . . . . . . . . . . . . 86 156 A.1 Missing Network-to-Network Trust Relationship . . . . . . 86 157 A.2 Relationship with routing . . . . . . . . . . . . . . . . 87 158 A.3 Affected Parts of the Network . . . . . . . . . . . . . . 87 159 A.4 NSIS backward compatibility with NSIS unaware NAT and 160 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 87 161 A.5 Authentication and Authorization . . . . . . . . . . . . . 88 162 A.6 Directional Properties . . . . . . . . . . . . . . . . . . 88 163 A.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 89 164 A.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 89 165 A.9 Combining Middlebox and QoS signaling . . . . . . . . . . 89 166 A.10 Inability to know the scenario . . . . . . . . . . . . . . 90 168 B. Object ID allocation for testing . . . . . . . . . . . . . . . 91 170 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 172 Intellectual Property and Copyright Statements . . . . . . . . 93 174 1. Introduction 176 Firewalls and Network Address Translators (NAT) have both been used 177 throughout the Internet for many years, and they will remain present 178 for the foreseeable future. Firewalls are used to protect networks 179 against certain types of attacks from the outside, and in times of 180 IPv4 address depletion, NATs virtually extend the IP address space. 181 Both types of devices may be obstacles to some applications, since 182 they only allow traffic created by a limited set of applications to 183 traverse them (e.g., most HTTP traffic, and client/server 184 applications), due to the relatively static properties of the 185 protocols used. Other applications, such as IP telephony and most 186 other peer-to-peer applications, which have more dynamic properties, 187 create traffic which is unable to traverse NATs and Firewalls 188 unassisted. In practice, the traffic from many applications cannot 189 traverse autonomous Firewalls or NATs, even when they have added 190 functionality which attempts to restore the transparency of the 191 network. 193 Several solutions to enable applications to traverse such entities 194 have been proposed and are currently in use. Typically, application 195 level gateways (ALG) have been integrated with the Firewall or NAT to 196 configure the Firewall or NAT dynamically. Another approach is 197 middlebox communication (MIDCOM, currently under standardization at 198 the IETF). In this approach, ALGs external to the Firewall or NAT 199 configure the corresponding entity via the MIDCOM protocol [5]. 200 Several other work-around solutions are available, including STUN 201 [24] and TURN [27]. However, all of these approaches introduce other 202 problems that are generally hard to solve, such as dependencies on 203 the type of NAT implementation (full-cone, symmetric, ...), or 204 dependencies on certain network topologies. 206 NAT and Firewall (NATFW) signaling shares a property with Quality of 207 Service (QoS) signaling. The signaling of both must reach any device 208 on the data path that is involved in QoS or NATFW treatment of data 209 packets. This means, that for both, NATFW and QoS, it is convenient 210 if signaling travels path-coupled, meaning that the signaling 211 messages follow exactly the same path that the data packets take. 212 RSVP [11] is an example of a current QoS signaling protocol that is 213 path-coupled. 215 This memo defines a path-coupled signaling protocol for NAT and 216 Firewall configuration within the framework of NSIS, called the NATFW 217 NSIS Signaling Layer Protocol (NSLP). The general requirements for 218 NSIS are defined in [3]. The general framework of NSIS is outlined 219 in [2]. It introduces the split between an NSIS transport layer and 220 an NSIS signaling layer. The transport of NSLP messages is handled 221 by an NSIS Network Transport Layer Protocol (NTLP, with GIMPS [1] 222 being the implementation of the abstract NTLP). The signaling logic 223 for QoS and NATFW signaling is implemented in the different NSLPs. 224 The QoS NSLP is defined in [4], while the NATFW NSLP is defined in 225 this memo. 227 The NATFW NSLP is designed to request the dynamic configuration of 228 NATs and/or Firewalls along the data path. Dynamic configuration 229 includes enabling data flows to traverse these devices without being 230 obstructed as well as blocking of particular data flows at upstream 231 firewalls. Enabling data flows requires the loading of firewall pin 232 holes (loading of firewall rules with action allow) and creating NAT 233 bindings. Blocking of data flows requires the loading of firewalls 234 rules with action deny/drop. A simplified example for enabling data 235 flows: A source host sends a NATFW NSLP signaling message towards 236 its data destination. This message follows the data path. Every 237 NATFW NSLP NAT/Firewall along the data path intercepts these 238 messages, processes them, and configures itself accordingly. 239 Afterwards, the actual data flow can traverse every configured 240 Firewall/NAT. 242 It is necessary to distinguish between two different basic scenarios 243 when operating the NATFW NSLP, independent of the type of middlebox 244 to be configured. 245 1. Both data sender and data receiver of the network are NSIS NATFW 246 NSLP aware. This includes the cases where the data sender is 247 logically decomposed from the NSIS initiator or the data receiver 248 logically decomposed from the NSIS receiver, but both sides 249 support NSIS. This scenario assumes deployment of NSIS all over 250 the Internet, or at least at all NATs and firewalls. 251 2. Only one end host is NSIS NATFW NSLP aware, either data receiver 252 or data sender. 254 NATFW NSLP provides three modes to cope with various possible 255 scenarios likely to be encountered before and after widespread 256 deployment of NSIS. Once there is full deployment of NSIS (in the 257 sense that both end hosts support NATFW NSLP signaling), the 258 requisite NAT and firewall state can be created using either just 259 CREATE mode if the data receiver resides in a public addressing 260 realm, or a combination of RESERVE-EXTERNAL-ADDRESS and CREATE modes 261 if the data receiver resides in a private addressing realm and needs 262 to preconfigure the boundary NAT to provide a publically reachable 263 address for use by the data sender. During the introduction of NSIS, 264 it is likely that one or other of the data sender and receiver will 265 not be NSIS capable. In these cases the NATFW NSLP can utilise NSIS 266 aware middleboxes on the path between the sender and receiver to 267 provide proxy NATFW NSLP services. Typically these boxes will be at 268 the boundaries of the realms in which the end hosts are located. If 269 the data receiver is NSIS unaware, the normal modes can be employed 270 but the NSIS signaling terminates at the NSIS aware node 271 topologically closest to the receiver which then acts as a proxy for 272 the receiver. If the data sender is unaware a variant of the 273 RESERVE-EXTERNAL-ADDRESS mode can be used by a data receiver behind a 274 NAT and the specialised UCREATE mode can be used by a data receiver 275 behind a firewall. 277 All modes of operation create NATFW NSLP and NTLP state in NSIS 278 entities. NTLP state allows signaling messages to travel in the 279 forward (downstream) and the reverse (upstream) direction along the 280 path between a NAT/Firewall NSLP sender and a corresponding receiver. 281 NAT bindings and firewall rules are NAT/Firewall specific state. 282 This state is managed using a soft-state mechanism, i.e., it expires 283 unless it is refreshed from time to time. 285 Section 2 describes the network environment for NATFW NSLP signaling, 286 highlighting the trust relationships and authorization required. 287 Section 3 defines the NATFW signaling protocol. Section 4 defines 288 the messages and and message components. In the remaining parts of 289 the main body of the document, Section 6 covers transition issues and 290 Section 7 addresses security considerations. Currently unsolved 291 problems and challenges are listed and discussed in Appendix A. 292 Please note that readers familiar with Firewalls and NATs and their 293 possible location within networks can safely skip Section 2. 295 1.1 Terminology and Abbreviations 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 299 document are to be interpreted as described in RFC 2119. 301 This document uses a number of terms defined in [3]. The following 302 additional terms are used: 303 o Policy rule: A policy rule is "a basic building block of a 304 policy-based system. It is the binding of a set of actions to a 305 set of conditions - where the conditions are evaluated to 306 determine whether the actions are performed" [26]. In the context 307 of NSIS NATFW NSLP, the condition is a specification of a set of 308 packets to which rules are applied. The set of actions always 309 contains just a single element per rule, and is limited to either 310 action "reserved", "deny" or action "allow". 311 o Firewall: A packet filtering device that matches packets against a 312 set of policy rules and applies the actions. In the context of 313 NSIS NATFW NSLP we refer to this device as a Firewall. 314 o Network Address Translator: Network Address Translation is a 315 method by which IP addresses are mapped from one IP address realm 316 to another, in an attempt to provide transparent routing between 317 hosts (see [7]). Network Address Translators are devices that 318 perform this work. 319 o Middlebox: "A middlebox is defined as any intermediate device 320 performing functions other than the normal, standard functions of 321 an IP router on the datagram path between a source host and a 322 destination host" [9]. In the context of this document, the term 323 middlebox refers to Firewalls and NATs only. Other types of 324 middlebox are currently outside of the scope of this document. 325 o Security Gateway: IPsec based gateways. 326 o (Data) Receiver (DR or R): The node in the network that is 327 receiving the data packets of a flow. 328 o (Data) Sender (DS or S): The node in the network that is sending 329 the data packets of a flow. 330 o NATFW NSLP session: An application layer flow of information for 331 which some network control state information is to be manipulated 332 or monitored (as defined in [2]). The control state for NATFW 333 NSLP consists of NSLP state and associated policy rules at a 334 middlebox. 335 o NSIS peer or peer: An NSIS node with which an NSIS adjacency has 336 been created as defined in [1]. 337 o Edge-NAT: An edge-NAT is a NAT device that is reachable from the 338 public Internet and that has a globally routable IP address. 339 o Edge-Firewall: An edge-Firewall is a Firewall device that is 340 located on the demarcation line of an administrative domain. 341 o Public Network: "A Global or Public Network is an address realm 342 with unique network addresses assigned by Internet Assigned 343 Numbers Authority (IANA) or an equivalent address registry. This 344 network is also referred as external network during NAT 345 discussions" [7]. 346 o Private/Local Network: "A private network is an address realm 347 independent of external network addresses. Private network may 348 also be referred alternately as Local Network. Transparent 349 routing between hosts in private realm and external realm is 350 facilitated by a NAT router" [7]. IP address space allocation for 351 private networks is recommended in [25] 352 o Public/Global IP address: An IP address located in the public 353 network according to Section 2.7 of [7]. 354 o Private/Local IP address: An IP address located in the private 355 network according to Section 2.8 of [7]. 356 o Initial CREATE: A CREATE message creating a new session. 358 1.2 Middleboxes 360 The term middlebox covers a range of devices which intercept the flow 361 of packets between end hosts and perform actions other than standard 362 forwarding expected in an IP router. As such, middleboxes fall into 363 a number of categories with a wide range of functionality, not all of 364 which is pertinent to the NATFW NSLP. Middlebox categories in the 365 scope of this memo are Firewalls that filter data packets against a 366 set of filter rules, and NATs that translate packet addresses from 367 one address realm to another address realm. Other categories of 368 middleboxes, such as QoS traffic shapers and security gateways, are 369 out of scope. 371 The term NAT used in this document is a placeholder for a range of 372 different NAT flavors. We consider the following types of NATs: 373 o traditional NAT (basic NAT and NAPT) 374 o Bi-directional NAT 375 o Twice-NAT 376 o Multihomed NAT 377 For definitions and a detailed discussion about the characteristics 378 of each NAT type please see [7]. 380 Both types of middleboxes under consideration here use policy rules 381 to make a decision on data packet treatment. Policy rules consist of 382 a flow identifier which selects the packets to which the policy 383 applies and an associated action; data packets matching the flow 384 identifier are subjected to the policy rule action. A typical flow 385 identifier is the 5-tuple selector which matches the following fields 386 of a packet to configured values: 387 o Source and destination IP addresses 388 o Transport protocol number 389 o Transport source and destination port numbers 391 For further examples of flow identifiers see Section 5.2.2 of [1]. 393 Actions for Firewalls are usually one or more of: 394 o Allow: forward data packet 395 o Deny: block data packet and discard it 396 o Other actions such as logging, diverting, duplicating, etc 398 Actions for NATs include (amongst many others): 399 o Change source IP address and transport port number to a globally 400 routeable IP address and associated port number. 401 o Change destination IP address and transport port number to a 402 private IP address and associated port number. 404 1.3 Non-Goals 406 Traversal of non-NSIS and non-NATFW NSLP aware NATs and Firewalls 407 is outside the scope of this document. 408 Only Firewalls and NATs are considered in this document, any other 409 types of devices, for instance IPSec security gateway, are out of 410 scope. 411 The exact implementation of policy rules and their mapping to 412 firewall rule sets and NAT bindings or sessions at the middlebox 413 is an implementation issue and thus out of scope of this document. 415 Some devices categorized as firewalls only accept traffic after 416 cryptographic verification (i.e., IPsec protected data traffic). 417 Particularly for network access scenarios, either link layer or 418 network layer data protection is common. We do not address these 419 types of devices (referred to as security gateways) since per-flow 420 signaling is typically not used in this environment. 421 Another application, for which NSIS signaling has been proposed 422 but which is out of scope for this document, is discovering 423 security gateways, for the purpose of executing IKE to create an 424 IPsec SA. 425 In mobility scenarios, a common problem is the traversal of a 426 security gateway at the edge of a corporate network. Network 427 administrators allow only authenticated data to enter the network. 428 A problem statement for the traversal of these security gateways 429 in the context of Mobile IP can be found in [22]). This topic is 430 not within the scope of the present document. 432 1.4 General Scenario for NATFW Traversal 434 The purpose of NSIS NATFW signaling is to enable communication 435 between endpoints across networks even in the presence of NAT and 436 Firewall middleboxes. It is assumed that these middleboxes will be 437 statically configured in such a way that NSIS NATFW signaling 438 messages themselves are allowed to traverse them. NSIS NATFW NSLP 439 signaling is used to dynamically install additional policy rules in 440 all NATFW middleboxes along the data path. Firewalls are configured 441 to forward data packets matching the policy rule provided by the NSLP 442 signaling. NATs are configured to translate data packets matching 443 the policy rule provided by the NSLP signaling. However, there is an 444 exception to the primary goal of NSIS NATFW signaling, NSIS NATFW 445 nodes can request blocking of particular data flows instead of 446 enabling these flows at upstream firewalls. 448 The basic high-level picture of NSIS usage is that end hosts are 449 located behind middleboxes, meaning that there is a middlebox on the 450 data path from the end host in a private network and the external 451 network (NAT/FW in Figure 1). Applications located at these end 452 hosts try to establish communication with corresponding applications 453 on other such end hosts. They trigger the NSIS entity at the local 454 host to provide for middlebox traversal along the prospective data 455 path (e.g., via an API call). The NSIS entity in turn uses NSIS 456 NATFW NSLP signaling to establish policy rules along the data path, 457 allowing the data to travel from the sender to the receiver 458 unobstructed. 460 Application Application Server (0, 1, or more) Application 462 +----+ +----+ +----+ 463 | +------------------------+ +------------------------+ | 464 +-+--+ +----+ +-+--+ 465 | | 466 | NSIS Entities NSIS Entities | 467 +-+--+ +----+ +-----+ +-+--+ 468 | +--------+ +----------------------------+ +-----+ | 469 +-+--+ +-+--+ +--+--+ +-+--+ 470 | | ------ | | 471 | | //// \\\\\ | | 472 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 473 | | | | | Internet | | | | | 474 | +--------+ +-----+ +----+ +-----+ | 475 +----+ +----+ |\ | +----+ +----+ 476 \\\\ ///// 477 sender NAT/FW (1+) ------ NATFW (1+) receiver 479 Figure 1: Generic View on NSIS in a NAT / Firewall case 481 For end-to-end NATFW signaling, it is necessary that each firewall 482 and each NAT along the path between the data sender and the data 483 receiver implements the NSIS NATFW NSLP. There might be several NATs 484 and FWs in various possible combinations on a path between two hosts. 485 Section 2 presents a number of likely scenarios with different 486 combinations of NATs and firewalls. 488 2. Network Deployment Scenarios using NATFW NSLP 490 This section introduces several scenarios for middlebox placement 491 within IP networks. Middleboxes are typically found at various 492 different locations, including at Enterprise network borders, within 493 enterprise networks, as mobile phone network gateways, etc. Usually, 494 middleboxes are placed more towards the edge of networks than in 495 network cores. Firewalls and NATs may be found at these locations 496 either alone, or they may be combined; other categories of 497 middleboxes may also be found at such locations, possibly combined 498 with the NATs and/or Firewalls. To reduce the number of network 499 elements needed, combined Firewall and NATs have been made available. 501 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 502 regular data path to the NSIS responder (NR). On the data path, 503 NATFW NSLP signaling messages reach different NSIS nodes that 504 implement the NATFW NSLP. Each NATFW NSLP node processes the 505 signaling messages according to Section 3 and, if necessary, installs 506 policy rules for subsequent data packets. 508 Each of the following sub-sections introduces a different scenario 509 for a different set of middleboxes and their ordering within the 510 topology. It is assumed that each middlebox implements the NSIS 511 NATFW NSLP signaling protocol. 513 2.1 Firewall Traversal 515 This section describes a scenario with Firewalls only; NATs are not 516 involved. Each end host is behind a Firewall. The Firewalls are 517 connected via the public Internet. Figure 2 shows the topology. The 518 part labeled "public" is the Internet connecting both Firewalls. 520 +----+ //----\\ +----+ 521 NI -----| FW |---| |------| FW |--- NR 522 +----+ \\----// +----+ 524 private public private 526 FW: Firewall 527 NI: NSIS Initiator 528 NR: NSIS Responder 530 Figure 2: Firewall Traversal Scenario 532 Each Firewall on the data path must provide traversal service for 533 NATFW NSLP in order to permit the NSIS message to reach the other end 534 host. All Firewalls process NSIS signaling and establish appropriate 535 policy rules, so that the required data packet flow can traverse 536 them. 538 Placing firewalls in a network topology can be done in several very 539 different ways. To distinguish firewalls located at network borders, 540 such as administrative domains, from others located internally, the 541 term edge-Firewall is used. A similar distinction can be made for 542 NATs, with an edge-NAT fulfilling the equivalent role. 544 2.2 NAT with two private Networks 546 Figure 3 shows a scenario with NATs at both ends of the network. 547 Therefore, each application instance, NSIS initiator and NSIS 548 responder, are behind NATs. The outermost NAT, called edge-NAT, at 549 each side is connected to the public Internet. The NATs are 550 generically labeled as MB (for middlebox), since those devices 551 certainly implement NAT functionality, but can implement firewall 552 functionality as well. 554 Only two middleboxes MB are shown in Figure 3 at each side, but in 555 general, any number of MBs on each side must be considered. 557 +----+ +----+ //----\\ +----+ +----+ 558 NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR 559 +----+ +----+ \\----// +----+ +----+ 561 private public private 563 MB: Middlebox 564 NI: NSIS Initiator 565 NR: NSIS Responder 567 Figure 3: NAT with two Private Networks Scenario 569 Signaling traffic from NI to NR has to traverse all the middleboxes 570 on the path, and all the middleboxes must be configured properly to 571 allow NSIS signaling to traverse them. The NATFW signaling must 572 configure all middleboxes and consider any address translation that 573 will result from this configuration in further signaling. The sender 574 (NI) has to know the IP address of the receiver (NR) in advance, 575 otherwise it will not be possible to send any NSIS signaling messages 576 towards the responder. Note that this IP address is not the private 577 IP address of the responder. Instead a NAT binding (including a 578 public IP address) has to be previously installed on the NAT that 579 subsequently allows packets reaching the NAT to be forwarded to the 580 receiver within the private address realm. This generally requires 581 further support from an application layer protocol for the purpose of 582 discovering and exchanging information. The receiver might have a 583 number of ways to learn its public IP address and port number and 584 might need to signal this information to the sender using the 585 application level signaling protocol. 587 2.3 NAT with Private Network on Sender Side 589 This scenario shows an application instance at the sending node that 590 is behind one or more NATs (shown as generic MB, see discussion in 591 Section 2.2). The receiver is located in the public Internet. 593 +----+ +----+ //----\\ 594 NI --| MB |-----| MB |---| |--- NR 595 +----+ +----+ \\----// 597 private public 599 MB: Middlebox 600 NI: NSIS Initiator 601 NR: NSIS Responder 603 Figure 4: NAT with Private Network on Sender Side Scenario 605 The traffic from NI to NR has to traverse middleboxes only on the 606 sender's side. The receiver has a public IP address. The NI sends 607 its signaling message directly to the address of the NSIS responder. 608 Middleboxes along the path intercept the signaling messages and 609 configure the policy rules accordingly. 611 Note that the data sender does not necessarily know whether the 612 receiver is behind a NAT or not, hence, it is the receiving side that 613 has to detect whether itself is behind a NAT or not. As described in 614 Section 3.3.2 NSIS can also provide help for this procedure. 616 2.4 NAT with Private Network on Receiver Side Scenario 618 The application instance receiving data is behind one or more NATs 619 shown as MB (see discussion in Section 2.2). 621 //----\\ +----+ +----+ 622 NI ---| |---| MB |-----| MB |--- NR 623 \\----// +----+ +----+ 625 public private 627 MB: Middlebox 628 NI: NSIS Initiator 629 NR: NSIS Responder 631 Figure 5: NAT with Private Network on Receiver Scenario 633 Initially, the NSIS responder must determine its publicly reachable 634 IP address at the external middlebox and notify the NSIS initiator 635 about this address. One possibility is that an application level 636 protocol is used, meaning that the public IP address is signaled via 637 this protocol to the NI. Afterwards the NI can start its signaling 638 towards the NR and so establish the path via the middleboxes in the 639 receiver side private network. 641 This scenario describes the use case for the RESERVE-EXTERNAL-ADDRESS 642 mode of the NATFW NSLP. 644 2.5 Both End Hosts behind twice-NATs 646 This is a special case, where the main problem arises from the need 647 to detect that both end hosts are logically within the same address 648 space, but are also in two partitions of the address realm on either 649 side of a twice-NAT (see [7] for a discussion of twice-NAT 650 functionality). 652 Sender and receiver are both within a single private address realm 653 but the two partitions potentially have overlapping IP address 654 ranges. Figure 6 shows the arrangement of NATs. This is a common 655 configuration in networks, particularly after the merging of 656 companies that have used the same private address space, resulting in 657 overlapping address ranges. 659 public 660 +----+ +----+ //----\\ 661 NI --| MB |--+--| MB |---| | 662 +----+ | +----+ \\----// 663 | 664 | +----+ 665 +--| MB |------------ NR 666 +----+ 668 private 670 MB: Middlebox 671 NI: NSIS Initiator 672 NR: NSIS Responder 674 Figure 6: NAT to Public, Sender and Receiver on either side of a 675 twice-NAT Scenario 677 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 678 addresses and port numbers on both sides, meaning the mapping of 679 source and destination address at the private and public interfaces. 681 This scenario requires the assistance of application level entities, 682 such as a DNS server. The application level gateways must handle 683 requests that are based on symbolic names, and configure the 684 middleboxes so that data packets are correctly forwarded from NI to 685 NR. The configuration of those middleboxes may require other 686 middlebox communication protocols, such as MIDCOM [5]. NSIS 687 signaling is not required in the twice-NAT only case, since 688 middleboxes of the twice-NAT type are normally configured by other 689 means. Nevertheless, NSIS signaling might by useful when there are 690 also Firewalls on path. In this case NSIS will not configure any 691 policy rule at twice-NATs, but will configure policy rules at the 692 Firewalls on the path. The NSIS signaling protocol must be at least 693 robust enough to survive this scenario. This requires that 694 twice-NATs must implement the NATFW NSLP also and participate in 695 NATFW sessions but they do not change the configuration of the NAT, 696 i.e., they only read the address mapping information out of the NAT 697 and translate the Message Routing Information (MRI, [1])within the 698 NSLP and NTLP accordingly. 700 2.6 Both End Hosts Behind Same NAT 702 When NSIS initiator and NSIS responder are behind the same NAT (thus 703 being in the same address realm, see Figure 7), they are most likely 704 not aware of this fact. As in Section 2.4 the NSIS responder must 705 determine its public IP address in advance and transfer it to the 706 NSIS initiator. Afterwards, the NSIS initiator can start sending the 707 signaling messages to the responder's public IP address. During this 708 process, a public IP address will be allocated for the NSIS initiator 709 at the same middlebox as for the responder. Now, the NSIS signaling 710 and the subsequent data packets will traverse the NAT twice: from 711 initiator to public IP address of responder (first time) and from 712 public IP address of responder to responder (second time). This is 713 the worst case in which both sender and receiver obtain a public IP 714 address at the NAT, and the communication path is certainly not 715 optimal in this case. 717 NI public 718 \ +----+ //----\\ 719 +-| MB |----| | 720 / +----+ \\----// 721 NR 722 private 724 MB: Middlebox 725 NI: NSIS Initiator 726 NR: NSIS Responder 728 Figure 7: NAT to Public, Both Hosts Behind Same NAT 730 The NSIS NATFW signaling protocol should support mechanisms to detect 731 such a scenario. 733 2.7 IPv4/v6 NAT with two Private Networks 735 This scenario combines the use case described in Section 2.2 with the 736 IPv4 to IPv6 transition scenario involving address and protocol 737 translation, i.e., using Network Address and Protocol Translators 738 (NAT-PT, [8]). 740 The difference from the other scenarios is the use of IPv6 to IPv4 741 (and vice versa) address and protocol translation. Additionally, the 742 base NTLP must support transport of messages in mixed IPv4 and IPv6 743 networks where some NSIS peers provide translation. 745 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 746 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 747 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 749 private public public private 750 IPv4 IPv6 752 MB: Middlebox 753 NI: NSIS Initiator 754 NR: NSIS Responder 756 Figure 8: IPv4/v6 NAT with two Private Networks 758 This scenario needs the same type of application level support as 759 described in Section 2.5, and so the issues relating to twice-NATs 760 apply here as well. 762 2.8 Multihomed Network with NAT 764 The previous sub-sections sketched network topologies where several 765 NATs and/or Firewalls are ordered sequentially on the path. This 766 section describes a multihomed scenario with two NATs placed on 767 alternative paths to the public network. 769 +----+ 770 NI -------| MB |\ 771 \ +----+ \ //---\\ 772 \ -| |-- NR 773 \ \\---// 774 \ +----+ | 775 --| MB |-------+ 776 +----+ 777 private 778 private public 780 MB: Middlebox 781 NI: NSIS Initiator 782 NR: NSIS Responder 784 Figure 9: Multihomed Network with Two NATs 786 Depending on the destination or load balancing requirements, either 787 one or the other middlebox is used for the data flow. Which 788 middlebox is used depends on local policy or routing decisions. 789 NATFW NSLP must be able to handle this situation properly, see 790 Section 3.3.2 for an expanded discussion of this topic with respect 791 to NATs. 793 2.9 Multihomed Network with Firewall 795 This section describes a multihomed scenario with two firewalls 796 placed on alternative paths to the public network (Figure 10). The 797 routing in the private and public network decided which firewall is 798 being taken for data flows. Depending on the data flow's direction, 799 either outbound or inbound, a different firewall could be traversed. 800 This is a challenge for a certain mode of the NATFW NSLP where the 801 NSIS responder is located behind these firewalls within the private 802 network: the UCREATE mode. The UCREATE mode is used to block a 803 particular data flow on an upstream firewall. NSIS must route the 804 UCREATE mode message upstream from NR to NI without probably knowing 805 the data traffic's subsequent path will take from NI to NR. 807 +----+ 808 NR -------| MB |\ 809 \ +----+ \ //---\\ 810 \ -| |-- NI 811 \ \\---// 812 \ +----+ | 813 --| MB |-------+ 814 +----+ 815 private 816 private public 818 MB: Middlebox 819 NI: NSIS Initiator 820 NR: NSIS Responder 822 Figure 10: Multihomed Network with Two Firewalls 824 3. Protocol Description 826 This section defines messages, objects, and protocol semantics for 827 the NATFW NSLP. Section 3.1 introduces the base element of a NSLP 828 session , the policy rule. Section 3.2 introduces the protocol and 829 the protocol behavior is defined in Section 3.3. Section 4 defines 830 the syntax of the messages and objects. 832 3.1 Policy Rules 834 Policy rules, bound to a session, are the building block of middlebox 835 devices considered in the NATFW NSLP. For Firewalls the policy rule 836 usually consists of a 5-tuple, source/destination addresses, 837 transport protocol, and source/destination port numbers, plus an 838 action, such as allow or deny. For NATs the policy rule consists of 839 action 'translate this address' and further mapping information, that 840 might be, in the simplest case, internal IP address and external IP 841 address. 843 Policy rules are usually carried in one piece in signaling 844 applications. In NSIS the policy rule is divided into the flow 845 identifier, an allow or deny action, and additional information. The 846 filter specification is carried within NTLP's message routing 847 information (MRI) and additional information, including the 848 specification of the action, is carried in NSLP's objects. 849 Additional information is, for example, the lifetime of a policy rule 850 or session. 852 3.2 Basic protocol overview 854 The NSIS NATFW NSLP is carried over the NSIS Transport Layer Protocol 855 (NTLP) defined in [1]. The interworking with the NTLP and other 856 components is shown in Figure 51. NATFW NSLP messages are initiated 857 by the NSIS initiator (NI), handled by NSIS forwarders (NF) and 858 finally processed by the NSIS responder (NR). It is required that at 859 least NI and NR implement this NSLP, intermediate NFs only implement 860 this NSLP when they provide relevant middlebox functions. NSIS 861 forwarders that do not have any NATFW NSLP functions just forward 862 these packets when they have no interest. 864 A Data Sender (DS), intending to send data to a Data Receiver (DR) 865 must first initiate NATFW NSLP signaling. This causes the NI 866 associated with the data sender (DS) to launch NSLP signaling towards 867 the address of data receiver DR (see Figure 11). Although it is 868 expected that the DS and the NATFW NSLP NI will usually reside on the 869 same host, this specification does not rule out scenarios where the 870 DS and NI reside on different hosts, the so-called proxy mode (see 871 Section 1.) 872 +-------+ +-------+ +-------+ +-------+ 873 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 874 | |--->| NF1 |--->| NF2 |--->| | 875 +-------+ +-------+ +-------+ +-------+ 877 ========================================> 878 Data Traffic Direction 880 ---> : NATFW NSLP request signaling 881 ~~~> : NATFW NSLP response signaling 882 DS/NI : Data sender and NSIS initiator 883 DR/NR : Data receiver and NSIS responder 884 MB1 : Middlebox 1 and NSIS forwarder 1 885 MB2 : Middlebox 2 and NSIS forwarder 2 887 Figure 11: General NSIS signaling 889 +-------+ +-------+ +-------+ +-------+ 890 | DS/NI |<~~~| MB1/ |<~~~| NR | | DR | 891 | |--->| NF1 |--->| | | | 892 +-------+ +-------+ +-------+ +-------+ 894 ========================================> 895 Data Traffic Direction 897 ---> : NATFW NSLP request signaling 898 ~~~> : NATFW NSLP response signaling 899 DS/NI : Data sender and NSIS initiator 900 DR/NR : Data receiver and NSIS responder 901 MB1 : Middlebox 1 and NSIS forwarder 1 902 MB2 : Middlebox 2 and NSIS forwarder 2 904 Figure 12: A NSIS proxy mode signaling 906 The sequence of NSLP events is as follows: 907 o NSIS initiators generate NATFW NSLP request messages and send 908 those towards the NSIS responder. Note, that the NSIS initiator 909 may not necessarily be the data sender but may be the data 910 receiver, for instance, when using the RESERVE-EXTERNAL-ADDRESS 911 message. 913 o NSLP request messages are processed each time a NF with NATFW NSLP 914 support is traversed. These nodes process the message, check 915 local policies for authorization and authentication, possibly 916 create policy rules, and forward the signaling message to the next 917 NSIS node. The request message is forwarded until it reaches the 918 NSIS responder. 919 o NSIS responders will check received messages and process them if 920 applicable. NSIS responders generate response messages and send 921 them hop-by-hop back to the NI via the same chain of NFs 922 (traversal of the same NF chain is guaranteed through the 923 established reverse message routing state in the NTLP). Note, 924 that NSIS responder may not necessarily be the data receiver but 925 may be any intermediate NSIS node that terminates the forwarding, 926 for example, in a proxy mode case where an edge-NAT is replying to 927 requests 928 o The response message is processed at each NF implementing the 929 NATFW NSLP. 930 o Once the NI has received a successful response, the data sender 931 can start sending its data flow to the data receiver. 933 Because NATFW NSLP signaling follows the data path from DS to DR, 934 this immediately enables communication between both hosts for 935 scenarios with only Firewalls on the data path or NATs on sender 936 side. For scenarios with NATs on the receiver side certain problems 937 arise, as described in Section 2. 939 When the NR and the NI are located in different address realms and 940 the NR is located behind a NAT, the NI cannot signal to the NR 941 directly. The DR and NR are not reachable from the NIs using the 942 private address of the NR and thus NATFW signaling messages cannot be 943 sent to the NR/DR's address. Therefore, the NR must first obtain a 944 NAT binding that provides an address that is reachable for the NI. 945 Once the NR has acquired a public IP address, it forwards this 946 information to the DS via a separate protocol (such as SDP within 947 SIP). This application layer signaling, which is out of scope of the 948 NATFW NSLP, may involve third parties that assist in exchanging these 949 messages. 951 NATFW NSLP signaling supports this scenario by using the 952 RESERVE-EXTERNAL-ADDRESS mode of operation 953 1. The NR acquires a public address by signaling on the reverse path 954 (NR towards NI) and thus making itself available to other hosts. 955 This process of acquiring a public addresses is called 956 reservation. During this process the DR reserves publicly 957 reachable addresses and ports suitable for NATFW NSLP signaling, 958 but data traffic will not be allowed to use this address/port 959 initially. 961 2. The NI signals directly to the NR as the NI would do if there is 962 no NAT in between, and creates policy rules at middleboxes. 963 Note, that the reservation mode will only allow the forwarding 964 of signaling messages but not data flow packets. Data flow 965 packets will be 'activated' by the signaling from NI towards NR. 966 The RESERVE-EXTERNAL-ADDRESS mode of operation is detailed in 967 Section 3.3.2 969 The above usage assumes that both ends of a communication support 970 NSIS but fail when NSIS is only deployed at one end of the network. 971 In this case only the receiving or sending side are NSIS aware and 972 not both at the same time (see also Section 1). NATFW NSLP supports 973 this scenario by using a proxy mode, as described in Section 3.3.7 974 and Section 3.3.8. 976 The basic functionality of the NATFW NSLP provides for opening 977 firewall pin holes and creating NAT bindings to enable data flows to 978 traverse these devices. Firewalls are expected to work on a deny-all 979 policy, meaning that traffic that does not explicitly match any 980 firewall filter rule will be blocked. In contrast, the normal 981 behavior of NATs is to block all traffic that does not match any 982 already configured/installed binding or session. However, in some 983 scenarios it is required to support firewalls having allow-all 984 policies, allowing data traffic to traverse unless it is blocked 985 explicitly. Data receivers can utilize NATFW NSLP's UCREATE message 986 to install policy rules at upstream firewalls to block unwanted 987 traffic. 989 The protocol works on a soft-state basis, meaning that whatever state 990 is installed or reserved on a middlebox will expire, and thus be 991 de-installed/ forgotten after a certain period of time. To prevent 992 this, the NATFW nodes involved will have to specifically request a 993 session extension. An explicit NATFW NSLP state deletion capability 994 is also provided by the protocol. 996 Middleboxes should return an error in case of a failure, such that 997 appropriate actions can be taken; this ability would allow debugging 998 and error recovery. Error messages could be sent upstream (for 999 errors related to received messages as well as asynchronous error 1000 notification messages) towards the NI as well as downstream towards 1001 the NR (in the case of asynchronous error notification messages). 1003 The next sections define the NATFW NSLP message types and formats, 1004 protocol operations, and policy rule operations. 1006 3.3 Protocol Operations 1008 This section defines the protocol operations including, how to create 1009 sessions, maintain them, and how to reserve addresses. All the NATFW 1010 NSLP protocol messages require C-mode handling by the NTLP and cannot 1011 be piggybacked into D-mode NTLP messages used during the NTLP path 1012 discovery/refresh phase. The usage of the NTLP by protocol messages 1013 is described in detail in Section 4. 1015 The protocol uses six messages: 1016 o CREATE: a request message used for creating, changing, refreshing 1017 and deleting NATFW NSLP sessions. 1018 o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for 1019 reserving an external address and probably port number, depending 1020 on the type of NAT. 1021 o QUERY: a request message used by authorized NATFW NEs for querying 1022 installed NATFW states 1023 o NOTIFY: an asynchronous message used by NATFW NEs to alert 1024 upstream and/or downstream NATFW NEs about specific events 1025 (especially failures). 1026 o UCREATE: a request message used by data receivers to instruct 1027 upstream firewalls to block data traffic. 1028 o RESPONSE: used as a response to CREATE, REA, UCREATE and QUERY 1029 messages with Success or Error information 1031 3.3.1 Creating Sessions 1033 Allowing two hosts to exchange data even in the presence of 1034 middleboxes is realized in the NATFW NSLP by the CREATE request 1035 message. The data sender generates a CREATE message as defined in 1036 Section 4.4.1 and hands it to the NTLP. The NTLP forwards the whole 1037 message on the basis of the message routing information towards the 1038 NR. Each NSIS forwarder along the path that implements NATFW NSLP, 1039 processes the NSLP message. Forwarding is thus managed NSLP 1040 hop-by-hop but may pass transparently through NSIS forwarders which 1041 do not contain NATFW NSLP functionality and non-NSIS aware routers 1042 between NSLP hop waypoints. When the message reaches the NR, the NR 1043 can accept the request or reject it. The NR generates a response to 1044 the request and this response is transported hop-by-hop towards the 1045 NI. NATFW NSLP forwarders may reject requests at any time. 1046 Figure 13 sketches the message flow between NI (DS), a NF (NAT), and 1047 NR (DR). 1049 NI Private Network NF Public Internet NR 1050 | | | 1051 | CREATE | | 1052 |----------------------------->| | 1053 | | | 1054 | RESPONSE[Error](if necessary)| | 1055 |<-----------------------------| CREATE | 1056 | |--------------------------->| 1057 | | | 1058 | | RESPONSE[Success/Error] | 1059 | RESPONSE[Success/Error] |<---------------------------| 1060 |<-----------------------------| | 1061 | | | 1062 | | | 1064 Figure 13: Creation message flow 1066 Since the CREATE message is used for several purposes within the 1067 lifetime of a session, there are several processing rules for NATFW 1068 NEs when generating and receiving CREATE messages. The different 1069 processing methods depend not only on the function which the CREATE 1070 is performing (to create, modify, refresh or delete a session) but 1071 also on the node at which the processing happens. For an initial 1072 CREATE message, the CREATE message creating a new NSIS session, the 1073 processing of CREATE messages is different for every NSIS node type: 1074 o NSLP initiator: NI only generates initial CREATE messages and 1075 hands them over to the NTLP. After receiving a successful 1076 response, the data path is configured and the DS can start 1077 sending its data to the DR. After receiving an 'error' response 1078 message the NI MAY try to generate the CREATE message again or 1079 give up and report the failure to the application, depending on 1080 the error condition. 1081 o NATFW NSLP forwarder: NFs receiving an initial CREATE message 1082 MUST first check authentication and authorization before any 1083 further processing is executed. The NF SHOULD check with its 1084 local policies if it can accept the desired policy rule given the 1085 combination of the NTLP's 'Message-Routing-Information' (MRI) [1] 1086 (the flow description information) and the CREATE payload 1087 (behavior to be enforced on the packet stream). An initial CREATE 1088 is distinguished from subsequent CREATE messages by the absence of 1089 existing NSLP session state related to the same session ID or the 1090 same MRI. The NSLP message processing depends on the middlebox 1091 type: 1092 * NAT: When the initial CREATE message is received at the public 1093 side of the NAT, it looks for a reservation made in advance, by 1094 using a REA message Section 3.3.2, that matches the destination 1095 address/port of the MRI provided by the NTLP. If no 1096 reservation had been made in advance the NSLP MAY return an 1097 error response message of type 'no reservation found' and 1098 discard the request. If there is a reservation, NSLP stores 1099 the data sender's address as part of the policy rule to be 1100 loaded and forwards the message with the address set to the 1101 internal (private in most cases) address of the next NSIS node. 1102 When the initial CREATE message, for a new session, is received 1103 at the private side the NAT binding is reserved, but not 1104 activated. The NSLP message is forwarded to the next NSIS hop 1105 with source address set to the NAT's external address from the 1106 newly reserved binding. 1107 * Firewall: When the initial CREATE message is received the NSLP 1108 just remembers the requested policy rule, but does not install 1109 any policy rule. Afterwards, the message is forwarded to the 1110 next NSLP hop. There is a difference between requests from 1111 trusted (authorized NIs) and un-trusted (un-authorized NIs); 1112 requests from trusted NIs will be pre-authorized, whereas 1113 requests from un-trusted NIs will not be pre-authorized. This 1114 difference is required to speed-up the protocol operations as 1115 well as for proxy mode usage (please refer to Section 3.3.7 and 1116 [13]). 1117 * Combined NAT and Firewall: Processing at combined Firewall and 1118 NAT middleboxes is the same as in the NAT case. No policy 1119 rules are installed. Implementations MUST take into account 1120 the order of packet processing in the Firewall and NAT 1121 functions within the device. This will be referred to as 1122 'order of functions' and is generally different depending on 1123 whether the packet arrives at the external or internal side of 1124 the middlebox. 1125 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1126 with a 'success' (response object has success information) 1127 RESPONSE message if they accept the CREATE request message and the 1128 authorization and authentication checks have been successful. 1129 Otherwise they SHOULD generate a RESPONSE message with an error 1130 code. RESPONSE messages are sent back NSLP hop-by-hop towards the 1131 NI, independently of the response codes, either success or error. 1133 Policy rules at middleboxes MUST be only installed upon receiving a 1134 successful response. This is a countermeasure to several problems, 1135 for example wastage of resources due to loading policy rules at 1136 intermediate NF when the CREATE message does not reach the final NR 1137 for some reason. 1139 3.3.2 Reserving External Addresses 1141 NSIS signaling is intended to travel end-to-end, even in the presence 1142 of NATs and Firewalls on-path. This works well in cases where the 1143 data sender is itself behind a NAT as described in Section 3.3.1. 1145 For scenarios where the data receiver is located behind a NAT and 1146 needs to receive data flows from outside its own network (see 1147 Figure 5) the problem is more troublesome. NSIS signaling, as well 1148 as subsequent data flows, are directed to a particular destination IP 1149 address that must be known in advance and reachable. 1151 +-------------+ AS-Data Receiver Communication 1152 +-------->| Application |<-----------------------------+ 1153 | | Server | | 1154 | +-------------+ | 1155 | IP(R-NAT_B) | 1156 | NSIS Signaling Message +-------+--+ 1157 | +------------------------------------------>| NAT/NAPT | 1158 | | | B | 1159 | | +-------+--+ 1160 | | | 1161 AS-Data| | | 1162 Receiver| | +----------+ | 1163 Comm.| | | NAT/NAPT | | 1164 | | | A | | 1165 | | +----------+ | 1166 | | | 1167 | | | 1168 | | | 1169 | | | 1170 v | IP(R) v 1171 +--------+ +---------+ 1172 | Data | | Data | 1173 | Sender | | Receiver| 1174 +--------+ +---------+ 1176 Figure 14: The Data Receiver behind NAT problem 1178 Figure 14 describes a typical message communication in a peer-to-peer 1179 networking environment whereby the two end points learn of each 1180 others existence with the help of a third party (referred to as an 1181 Application Server). Communication between the application server 1182 and each of the two end points (data sender and data receiver) 1183 enables the two end hosts to learn each other's IP addresses. The 1184 approach described in this memo supports this peer-to-peer approach, 1185 but is not limited to it. 1187 Some sort of communication between the data sender/data receiver and 1188 a third party is typically necessary (independently of whether NSIS 1189 is used). NSIS signaling messages cannot be used to communicate the 1190 relevant application level end point identifiers (in the generic case 1191 at least) as a replacement for communication with the application 1192 server. 1194 If the data receiver is behind a NAT then an NSIS signaling message 1195 will be addressed to the IP address allocated at the NAT (assuming 1196 one had already been allocated). If no corresponding NSIS NAT 1197 Forwarding State at NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) 1198 then the signaling message will terminate at the NAT device (most 1199 likely without generating a proper response message). The signaling 1200 message transmitted by the data sender cannot install the NAT binding 1201 or NSIS NAT Forwarding State "on-the-fly" since this would assume 1202 that the data sender knows the topology at the data receiver side 1203 (i.e., the number and the arrangement of the NAT and the private IP 1204 address(es) of the data receiver). The primary goal of path-coupled 1205 middlebox communication was not to avoid end hosts learning and 1206 preserving this type of topology knowledge. Data receivers behind a 1207 NAT must first reserve an external IP address (probably port number 1208 too). 1210 Public Internet Private Address 1211 Space 1212 Edge 1213 NI(DS) NAT NAT NR(DR) 1214 NR+ NI+ 1215 | | | | 1216 | | | | 1217 | | | | 1218 | | REA | REA | 1219 | |<----------------------|<----------------------| 1220 | | | | 1221 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1222 | |---------------------->|---------------------->| 1223 | | | | 1224 | | | | 1226 ============================================================> 1227 Data Traffic Direction 1229 Figure 15: Reservation message flow 1231 Figure 15 shows the message flow for reserving an external 1232 address/port at a NAT. In this case the roles of the different NSIS 1233 entities are: 1235 o The data receiver (DR) for the anticipated data traffic is the 1236 NSIS initiator (NI+) for the RESERVE-EXTERNAL-ADDRESS (REA) 1237 message, but becomes the NSIS responder (NR) for following CREATE 1238 messages. 1239 o The actual data sender (DS) will be the NSIS initiator (NI) for 1240 later CREATE messages and may be the NSIS target of the signaling 1241 (NR+). 1242 o The actual target of the REA message, the Opportunistic Address 1243 (OA) is an arbitrary address, that would force the message to get 1244 intercepted by the far outmost NAT in the network. The 1245 Opportunistic Address is shown as NR+. 1247 The NI+ (could be on the data receiver DR or on any other host within 1248 the private network) sends a the REA message targeted to the 1249 Opportunistic Address (OA defined earlier). The OA selection for 1250 this message is discussed in Section 3.7. The message routing for 1251 the REA message is in the reverse direction to the normal message 1252 routing used for path-coupled signaling where the signaling is sent 1253 downstream (as opposed to upstream in this case). When establishing 1254 NAT bindings (and NSIS session state) the direction does not matter 1255 since the data path is modified through route pinning due to the 1256 external NAT address. Subsequent NSIS messages (and also data 1257 traffic) will travel through the same NAT boxes. 1259 NI+ may include a data sender's address information object (DSInfo) 1260 if they are aware about the data sender. The DSInfo object is used 1261 by the edge-NAT to limit the possible NI addresses to one address. A 1262 NI+ can specify a specific IP address and port from where the 1263 subsequent NSIS signaling must be originated. 1265 The REA signaling message creates NSIS NAT session state at any 1266 intermediate NSIS NAT peer(s) encountered. Furthermore it has to be 1267 ensured that the edge-NAT device is discovered as part of this 1268 process. The end host cannot be assumed to know this device - 1269 instead the NAT box itself is assumed to know that it is located at 1270 the outer perimeter of the private network addressing realm. 1271 Forwarding of the REA message beyond this entity is not necessary, 1272 and should be prohibited as it provides information on the 1273 capabilities of internal hosts. 1275 The edge-NAT device responds to the REA message with a RESPONSE 1276 message containing a success object carrying the public reachable IP 1277 address/port number. 1279 Processing of REA messages is specific to the NSIS node type: 1280 o NSLP initiator: NI+ only generate REA messages and should never 1281 receive them. When the data sender's address information is known 1282 in advance the NI+ MAY include a DSInfo object in the REA message. 1284 When the data sender's IP address is not known, NI+s MUST NOT 1285 include a DSInfo object. 1286 o NSLP forwarder: NSLP forwarders receiving REA messages MUST first 1287 check authentication and authorization before any further 1288 processing is executed. The NF SHOULD check with its local 1289 policies if it can accept the desired policy rule given by NTLP's 1290 message routing information (MRI). Further processing depends on 1291 the middlebox type: 1292 * NAT: NATs check whether the message is received at the 1293 external (public in most cases) address or at the internal 1294 (private) address. If received at the external address a NF 1295 MAY generate a RESPONSE message with an error of type 'REA 1296 received from outside'. If received at the internal address, 1297 an IP address/port is reserved. In the case it is an edge-NAT, 1298 the NSLP message is not forwarded any further and a RESPONSE 1299 message with the external address and port information is 1300 generated. If it is not an edge-NAT, the NSLP message is 1301 forwarded further with the translated IP address/port. The 1302 edge-NAT MAY reject REA messages not carrying a DSInfo object 1303 or if the address information within this object is invalid or 1304 too much wildcarded. 1305 * Firewall: Firewalls MUST not change their configuration upon a 1306 REA message. They simply MUST forward the message and MUST 1307 keep NTLP state. Firewalls that are configured as 1308 edge-Firewalls MAY return an error of type 'no NAT here'. 1309 * Combined NAT and Firewall: Processing at combined Firewall and 1310 NAT middleboxes is the same as in the NAT case. 1311 o NSLP receiver: This type of message should never be received by 1312 any NR+ and it SHOULD be discarded silently. 1314 Processing of a RESPONSE message with an external address object is 1315 different for every NSIS node type: 1316 o NSLP initiator: Upon receiving a RESPONSE message with an 1317 external address object, the NI+ can use the IP address and port 1318 pairs carried for further application signaling. 1319 o NSLP forwarder: NFs simply forward this message as long as they 1320 keep state for the requested reservation. 1321 o NSIS responder: This type of message should never be received by 1322 an NR and it SHOULD be discarded silently. 1323 o Edge-NATs: This type of message should never be received by any 1324 Edge-NAT and it SHOULD be discarded silently. 1326 Reservations made with REA MUST be enabled by a subsequent CREATE 1327 message. Without using CREATE (Section 3.3.1 or REA in proxy mode 1328 Section 3.3.7 no data traffic will be forwarded to DR beyond the 1329 edge-NAT. REA is just taking care about enabling the forwarding of 1330 subsequent CREATE messages traveling towards the NR. Correlation of 1331 incoming CREATE messages to REA reservation states is described in 1332 Section 3.6 1334 3.3.3 NATFW Session refresh 1336 NATFW NSLP sessions are maintained on a soft-state basis. After a 1337 specified timeout, sessions and corresponding policy rules are 1338 removed automatically by the middlebox, if they are not refreshed. 1339 Soft-state is created by CREATE, REA, and UCREATE and the maintenance 1340 of this state must be done by these messages. State created by 1341 CREATE must be maintained by CREATE, state created by REA must be 1342 maintained by REA, and state created by UCREATE must be maintained by 1343 UCREATE. Refresh messages, either CREATE/REA/UCREATE, are messages 1344 carrying the exact MRI and session ID as the initial message and a 1345 lifetime object with a lifetime greater than zero. Every refresh 1346 request message MUST be acknowledged by an appropriate response 1347 message generated by the NR. This response message is routed back 1348 towards the NI, to allow the intermediate NFs to propose a refresh 1349 period that would align with their local policies. The NI sends 1350 refresh messages destined for the NR. Upon reception by each NSIS 1351 forwarder, the state for the given session ID is extended by the 1352 session refresh period, a period of time calculated based on a 1353 proposed refresh message period. The lifetime extension of a session 1354 is calculated as current local time plus proposed lifetime value 1355 (session refresh period). Section 3.4 defines the process of 1356 calculating lifetimes in detail. 1358 NI Public Internet NAT Private address NR 1359 | | space | 1360 | CREATE[lifetime > 0] | | 1361 |----------------------------->| | 1362 | | | 1363 | RESPONSE[Error] (if needed) | | 1364 |<-----------------------------| CREATE[lifetime > 0] | 1365 | |--------------------------->| 1366 | | | 1367 | | RESPONSE[Success/Error] | 1368 | RESPONSE[Success/Error] |<---------------------------| 1369 |<-----------------------------| | 1370 | | | 1371 | | | 1373 Figure 16: State Refresh Message Flow, CREATE as example 1375 Processing of session refresh CREATE/REA/UCREATE messages is 1376 different for every NSIS node type: 1377 o NSLP initiator: The NI can generate session refresh 1378 CREATE/REA/UCREATE messages before the session times out. The 1379 rate at which the refresh CREATE/REA/UCREATE messages are sent and 1380 their relation to the session state lifetime are further discussed 1381 in Section 3.4. The message routing information and the extended 1382 flow information object MUST be set equal to the values of the 1383 initial request message. 1384 o NSLP forwarder: NSLP forwarders receiving session refresh messages 1385 MUST first check authentication and authorization before any 1386 further processing is executed. The NF SHOULD check with its 1387 local policies if it can accept the desired lifetime extension for 1388 the session referred by the session ID. Processing of this 1389 message is independent of the middlebox type. 1390 o NSLP responder: NRs accepting a session refresh CREATE/REA/UCREATE 1391 message generate a RESPONSE message with response object set to 1392 success. NRs MUST check for authorization and authentication. 1394 3.3.4 Deleting Sessions 1396 NATFW NSLP sessions may be deleted at any time. NSLP initiators can 1397 trigger this deletion by using a CREATE, REA, or UCREATE messages 1398 with a lifetime value set to 0, as shown in Figure 17. 1400 NI Public Internet NAT Private address NR 1401 | | space | 1402 | CREATE[lifetime=0] | | 1403 |----------------------------->| | 1404 | | | 1405 | | CREATE[lifetime=0] | 1406 | |--------------------------->| 1407 | | | 1409 Figure 17: Delete message flow, CREATE as example 1411 NSLP nodes receiving this message MUST first check for authorization 1412 and authentication and afterwards MUST delete the session 1413 immediately. Policy rules associated with this particular session 1414 MUST be deleted immediately. This message is forwarded until it 1415 reaches the final NR. The CREATE/REA/UCREATE request message with a 1416 lifetime value of 0, does not generate any response, neither positive 1417 nor negative, since there is no NSIS state left at the nodes along 1418 the path. 1420 3.3.5 Reporting Asynchronous Events 1422 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 1423 to report asynchronous events to other NATFW NSLP nodes, especially 1424 to allow reporting back to the NATFW NSLP initiator. Such 1425 asynchronous events may be premature session termination, changes in 1426 local policies, routing change or any other reason that indicates 1427 change of the NATFW NSLP session state. Currently, asynchronous 1428 session termination, re-authorization required and route change 1429 detected are the only events that are defined, but other events may 1430 be defined in later versions of this memo. One or several events 1431 could be reported within the NOTIFY message. 1433 NFs and NRs may generate NOTIFY messages upon asynchronous events, 1434 with a response object indicating the reason of the event and a 1435 corresponding session ID. NOTIFY messages are sent hop-by-hop 1436 upstream towards NI until they reach NI. 1438 Processing is different for every NATFW NSLP node type and depends on 1439 the notified events: 1440 o NSLP initiator: NIs receiving NOTIFY messages MUST first check for 1441 authentication and authorization. After successfully doing so, 1442 NIs analyze the notified event(s) and behave appropriately based 1443 on the event type. Section 4.3.4 discusses the required behavior 1444 for each notified event. NIs MUST NOT generate NOTIFY messages. 1445 o NSLP forwarder: NFs receiving NOTIFY messages MUST first check for 1446 authentication and authorization and MUST only accept NOTIFY 1447 messages from downstream peers. After successfully doing so, NFs 1448 analyze the notified event(s) and behave based on the notified 1449 events defined in Section 4.3.4. NFs occurring an asynchronous 1450 event generate NOTIFY messages and set the response object(s) code 1451 based on the reported event(s). NOTIFY messages are sent further 1452 hop-by-hop upstream towards the NI. NFs SHOULD generate NOTIFY 1453 messages upon asynchronous events and forward them upstream 1454 towards the NI. 1455 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 1456 asynchronous events. NRs receiving NOTIFY messages MUST ignore 1457 this message and discard it. NOTIFY messages are sent hop-by-hop 1458 upstream towards NI 1460 3.3.6 QUERY capabilities within the NATFW NSLP protocol 1462 The NATFW NSLP provides query capabilities that could be used by a 1463 session owner to track the session state. This would be used for 1464 diagnostic purposes when no data packets were received and the policy 1465 rule was supposed to have been created on the NATFW NFs. 1467 The QUERY message can be used to query the following session 1468 information: session id, flow source, destination and status of the 1469 state options for status ordered from best to worst are: up, high 1470 traffic (used to detect DOS attack or unexpected traffic rate), 1471 pending, down. The status of the policy rule will probably provide 1472 sufficient diagnostic information; in case more diagnostic 1473 information is required it could be provided by the NATFW NF logs. 1474 Session status is only provided by an NF if no session status was 1475 provided in the QUERY message or the NF's session status is worse 1476 than the one provided by the queried upstream NEs. The Session 1477 information could be retrieved by sending a QUERY against a specific 1478 session id, a flow source and destination or user identifier with 1479 session id or flow source and destination. 1481 QUERY message processing is different for every NATFW NSLP node type: 1482 o NSLP initiator: NIs only generate QUERY messages, but never with 1483 session status information, so that received QUERY messages MUST 1484 be discarded. 1485 o NSLP forwarder: NFs receiving QUERY messages MUST first check for 1486 authentication and authorization. After successfully doing so, 1487 NFs will behave differently depending on the QUERY. If the QUERY 1488 is about a specific session: if it contains a session status the 1489 NF compares it to the current local session status; if no session 1490 status is provided in the QUERY message the NF will insert its own 1491 session status in the QUERY message. If the current local session 1492 status is worse, it will incorporate its own session status field 1493 in the QUERY message. Every NF will provide the flow description 1494 in case it was not inside the QUERY. Once the message processing 1495 is done, if the message was not scoped then NF will forward the 1496 QUERY message to the next downstream node. 1497 o NSLP responder: NRs (any node being the destination of the 1498 message) receiving QUERY messages MUST first check for 1499 authentication and authorization. After successfully doing so, 1500 NRs must process the message as the NFs and respond with a 1501 RESPONSE message to the NI. The RESPONSE message will travel 1502 along the established reverse path given by the message routing 1503 state. 1505 Responses to QUERY messages are processed differently for every NATFW 1506 NSLP node type: 1507 o NSLP initiator: NIs receiving RESPONSEs to QUERY messages MUST 1508 first check for authentication and authorization. After 1509 successfully doing so, the objects within the RESPONSE messages 1510 are provided up to the application layers and the session state 1511 remains as it was unless the application triggers NATFW NSLP state 1512 changes. 1513 o NSLP forwarder: NFs receiving RESPONSEs to QUERY messages MUST 1514 first check for authentication and authorization. After 1515 successfully doing so, NFs forward the message upstream without 1516 any interpretation. 1517 o NSLP responder: if an NR receives a RESPONSE to QUERY message it 1518 MUST discard it. 1520 From a semantics perspective, the QUERY messages may require the 1521 following information incorporated within the messages: 1522 o Session ID 1523 o Flow source (address and port) and destination (address and port), 1524 in case the flow doesn't use a transport protocol a protocol 1525 number would be used with another identifier (SPI for IPsec) 1526 QUERY responses should provide the following information: 1527 o List of active sessions 1528 o Editor's note: next version will discuss in which form the list 1529 publishes the active sessions (by session id or session ID and 1530 flow description or other formats) 1531 o Information related to a session (when the query is specific to 1532 one session): session ID, flow description and policy rule state 1533 information 1535 3.3.7 Proxy Mode for Data Receiver behind NAT 1537 Some migration scenarios need specialized support to cope with cases 1538 where only the receiving side is running NSIS. End-to-end signaling 1539 is going to fail without NSIS support at both data sender and data 1540 receiver, unless the NATFW NSLP also gives the NR the ability to 1541 install state for downstream messages at NFs on the upstream path to 1542 the data sender. The goal of the described method is to trigger the 1543 network to generate a CREATE message at the edge-NAT on behalf of the 1544 data receiver. In this case, a NR can signal towards the 1545 Opportunistic Address as is performed in the standard REA message 1546 handling scenario for NATs Section 3.3.2. The message is forwarded 1547 until it reaches the edge-NAT. A public IP address and port number 1548 is reserved at an edge-NAT. As shown in Figure 18, unlike the 1549 standard REA message handling case, the edge-NAT is triggered to send 1550 a CREATE message on a new reverse path which could go through 1551 internal firewalls or NATs. The new reverse path for CREATE is 1552 necessary to handle routing asymmetries between the edge-NAT and DR. 1553 This behavior requires an indication to the edge-NAT within the REA 1554 message if either the standard behavior (as defined in Section 3.3.2) 1555 is required or a CREATE message is required to be sent by the 1556 edge-NAT. In addition when a CREATE message needs to be sent by the 1557 edge-NAT, the REA message may include the data sender's address 1558 (DSInfo) if available to the data receiver. Figure 18 shows this 1559 proxy mode REA as REA[PROXY]. 1561 DS Public Internet NAT Private address NR 1562 No NI NF space NI+ 1563 NR+ 1564 | | REA[PROXY,(DSInfo)] | 1565 | |<------------------------- | 1566 | | RESPONSE[Error/Success] | 1567 | | ---------------------- > | 1568 | | CREATE | 1569 | | ------------------------> | 1570 | | RESPONSE[Error/Success] | 1571 | | <---------------------- | 1572 | | | 1573 | | | 1575 Figure 18: REA Triggering Sending of CREATE Message on Separate 1576 Reverse Path 1578 The processing of REA[PROXY] messages is different for every NSIS 1579 entity: 1580 o NSLP initiator (NI+): When the data sender's address information 1581 is known in advance the NI+ MAY include a DSInfo object in the 1582 REA[PROXY] request message. When the data sender's address is not 1583 known, NI+'s MUST NOT include a DSInfo object. NI+ only generate 1584 REA[PROXY] messages and should never receive them. 1585 o NSLP forwarder: NSLP forwarders receiving REA[PROXY] messages MUST 1586 first check authentication and authorization before any further 1587 processing is executed. The NF SHOULD check with its local 1588 policies if it can accept the desired policy rule given by NTLP's 1589 message routing information (MRI). Further processing depends on 1590 the middlebox type: 1591 * NAT: NATs check whether the message is received at the 1592 external (public in most cases) address or at the internal 1593 (private) address. If received at the external address a NF 1594 MAY generate a RESPONSE message with an error of type 'REA 1595 received from outside' and stop forwarding. If received at the 1596 internal address, an IP address/port is reserved. If it is not 1597 an edge-NAT, the NSLP message is forwarded further with the 1598 translated IP address/port. In the case it is an edge-NAT, the 1599 NSLP message is not forwarded any further. The edge-NAT checks 1600 whether it is willing to send CREATE messages on behalf on NI+ 1601 and if so it checks the DSInfo object. The edge-NAT MAY reject 1602 the REA[PROXY] request if there is no DSInfo object or if the 1603 address information within DSInfo is not valid or too much 1604 wildcarded. If accepted a RESPONSE message with the external 1605 address and port information is generated. When the edge-NAT 1606 accepts it generates a CREATE message as defined in 1607 Section 3.3.1. The edge-NAT MUST refresh the CREATE message 1608 session only if a REA[PROXY] refresh message has been received 1609 first. 1610 * Firewall: Firewalls MUST not change their configuration upon a 1611 REA message. They simply MUST forward the message and MUST 1612 keep NTLP state. Edge-Firewalls SHOULD reply with an error 1613 RESPONSE indicating 'no egde-NAT here'. 1614 * Combined NAT and Firewall: Processing at combined Firewall and 1615 NAT middleboxes is the same as in the NAT case. 1616 o NSLP receiver: This type of message should never be received by 1617 any NR+ and it SHOULD be discarded silently. 1619 Processing of a RESPONSE message with an external address object is 1620 different for every NSIS node type: 1621 o NSLP initiator: Upon receiving a RESPONSE message with an 1622 external address object, the NI+ can use the IP address and port 1623 pairs carried for further application signaling. 1624 o NSLP forwarder: NFs simply forward this message as long as they 1625 keep state for the requested reservation. 1626 o NSIS responder: This type of message should never be received by 1627 an NR and it SHOULD be discarded silently. 1628 o Edge-NATs/edge-Firewall: This type of message should never be 1629 received by any Edge-NAT/edge-Firewall and it SHOULD be discarded 1630 silently. 1632 The scenario described in this chapter challenges the data receiver 1633 in a way that it must make a correct assumption about the data 1634 sender's ability to use NSIS NATFW NSLP signaling. There are two 1635 cases a) DS is NSIS unaware and DR assumes DS to NSIS aware and b) DS 1636 is NSIS aware but DR assumes DS to NSIS unaware. Case a) will result 1637 in middleboxes blocking the data traffic, since DS will never send 1638 the expected CREATE message. Case b) will result in the DR 1639 successfully requesting proxy mode support by the edge-NAT. The 1640 edge-NAT will send CREATE messages and DS will send CREATE messages 1641 too. The current specification defines that the CREATE by the DS 1642 will be discarded at the edge-NAT since there is already another 1643 CREATE state for this NSIS session and responding with an error 1644 RESPONSE back to DS/NIindicating 'CREATE already received by proxy 1645 mode'. 1647 3.3.8 Proxy Mode for Data Sender behind Middleboxes 1649 As with the data senders behind middleboxes in Section 3.3.7 also 1650 require proxy mode support as well. The problem here is that there 1651 is no NSIS support at the data receiver's side and, by default, there 1652 will be no response to CREATE request messages. This scenario 1653 requires the last NSIS NATFW NSLP aware node to terminate the 1654 forwarding and to proxy the response to the CREATE message, meaning 1655 that this node is generating RESPONSE messages. This last node may 1656 be an edge-NAT/edge-Firewall, or any other NATFW NSLP peer, that 1657 detects that there is no NR available (probably through GIMPS 1658 timeouts). This proxy mode handles data senders behind a middlebox 1659 only; for receivers behind a NAT see Section 3.3.7. 1661 NIs being aware about a NSIS unaware DR, send a CREATE message 1662 towards DR with a proxy support object. Intermediate NFs can use 1663 this additional information to decide whether to terminate the 1664 message forwarding or not. This proxy support object is an implicit 1665 scoping of the CREATE message. Termination of CREATE request 1666 messages with proxy support object included MUST only be done by 1667 egde-NATs/edge-Firewalls; future revisions of this document may 1668 change this behavior. 1670 DS Private Address FW Public Internet NR 1671 NI Space NF no NR 1672 | | | 1673 | CREATE[PROXY] | | 1674 |------------------------------>| | 1675 | | | 1676 | RESPONSE[SUCCESS/ERROR] | | 1677 |<------------------------------| | 1678 | | | 1680 Figure 19: Proxy Mode Create Message Flow 1682 The processing of CREATE[PROXY] messages and RESPONSE messages is 1683 similar to Section 3.3.1, except that forwarding is stopped at the 1684 edge-NAT/edge-Firewall. The edge-NAT/edge-Firewall responds back to 1685 NI according the situation (error/success) and will be the NR for 1686 future NATFW NSLP communication. 1688 3.3.9 Proxy Mode for Data Receiver behind Firewall 1690 Data receivers behind firewalls would like to provide a similar sort 1691 of proxy mode operation to those behind NATs. While finding the 1692 upstream edge-NAT is quite easy, it is only required to find an 1693 edge-NAT but not a very specific one and then the data traffic is 1694 route pinned to the NAT, the location of the appropriate 1695 edge-Firewall is more difficult. Data receivers that are located 1696 behind several firewalls that are placed topology-wise in parallel 1697 (multi-homed network), must find out the one firewall the data 1698 traffic will traverse. This feature of locating the right firewall 1699 can be used for proxy mode support and for blocking certain incoming 1700 data traffic. Proxy mode support is similar to Section 3.3.7 where 1701 the DR is behind one or more NATs and installs "allow" policy rules. 1702 Blocking incoming data traffic requires that the NATFW NSLP locates 1703 the appropriate firewall in order to install a deny policy rule. 1705 The upstream CREATE (UCREATE) message is used to locate upstream 1706 firewalls and to request installation of deny policy rules. The goal 1707 of the method described is to trigger the network to generate a 1708 CREATE message at the edge-Firewall on behalf of the data receiver. 1709 In this case, a NR can signal towards the data sender's address as in 1710 the standard REA message handling scenario for NATs Section 3.3.2. 1711 The message is forwarded until it reaches the edge-Firewall. As 1712 shown in Figure 20, the edge-Firewall is triggered to send a CREATE 1713 message on a new reverse path which could go through internal 1714 firewalls or NATs. The new reverse path for CREATE is necessary to 1715 handle routing asymmetries between the edge-Firewall and DR. UCREATE 1716 does not install any policy rule but the subsequent CREATE message 1717 initiated by the edge-Firewall does. 1719 DS Public Internet NAT Private address NR 1720 No NI NF space NI+ 1721 NR+ 1722 | | UCREATE | 1723 | |<------------------------- | 1724 | | RESPONSE[Error/Success] | 1725 | | ---------------------- > | 1726 | | CREATE | 1727 | | ------------------------> | 1728 | | RESPONSE[Error/Success] | 1729 | | <---------------------- | 1730 | | | 1731 | | | 1733 Figure 20: UCREATE Triggering Sending of CREATE Message on Separate 1734 Reverse Path 1736 The processing of UCREATE messages is different for every NSIS 1737 entity: 1738 o NSLP initiator (NI+): NI+ MUST always direct UCREATE message to 1739 the address of DS. NI+ only generate UCREATE messages and should 1740 never receive them. 1741 o NSLP forwarder: NSLP forwarders receiving UCREATE messages MUST 1742 first check authentication and authorization before any further 1743 processing is executed. The NF SHOULD check with its local 1744 policies if it can accept the desired policy rule given by NTLP's 1745 message routing information (MRI). Further processing depends on 1746 the middlebox type: 1747 * NAT: NATs check whether the message is received at the 1748 external (public in most cases) address or at the internal 1749 (private) address. If received at the internal interface, NATs 1750 allocated a public IP address and port and forward the message 1751 further. Edge-NATs receiving UCREATE SHOULD response with 1752 error RESPONSE indicating 'no edge-Firewall' 1753 * Firewall: Non edge-Firewalls simply forward the message. 1754 Edge-Firewalls stop forwarding the check for authentication and 1755 authorization. If the message is accepted, load the specified 1756 policy rule and generate CREATE messages back towards the DR as 1757 defined in Section 3.3.1. 1758 * Combined NAT and Firewall: Processing at combined Firewall and 1759 NAT middleboxes is the same as in the Firewall case. 1760 o NSLP receiver: This type of message should never be received by 1761 any NR+ and it SHOULD be discarded silently. 1763 Processing of a RESPONSE message with an external address object is 1764 different for every NSIS node type: 1765 o NSLP initiator (NI+): Upon receiving a RESPONSE message NI+ 1766 should await incoming corresponding CREATE messages. 1767 o NSLP forwarder: NFs simply forward this message as long as they 1768 keep state for the requested reservation. 1769 o NSIS responder: This type of message should never be received by 1770 an NR and it SHOULD be discarded silently. 1771 o Edge-NATs/edge-Firewall: This type of message should never be 1772 received by any Edge-NAT/edge-Firewall and it SHOULD be discarded 1773 silently. 1775 EDITOR's NOTE: The protocol behavior described within this section 1776 must be discussed at next IETF meeting. 1778 3.4 Calculation of Session Lifetime 1780 NATFW NSLP sessions, and the corresponding policy rules which may 1781 have been installed, are maintained via soft-state mechanism. Each 1782 session is assigned a lifetime and the session is kept alive as long 1783 as the lifetime is valid. After the expiration of the lifetime, 1784 sessions and policy rules MUST be removed automatically and resources 1785 bound to them should be freed as well. Session lifetime is kept at 1786 every NATFW NSLP node. The NSLP forwarders and NSLP responder are 1787 not responsible for triggering lifetime extension refresh messages 1788 (see Section 3.3.3): this is the task of the NSIS initiator. 1790 The NSIS initiator MUST choose a session lifetime (expressed in 1791 seconds) value before sending any message (lifetime is set to zero 1792 for deleting sessions) to other NSLP nodes. The session lifetime 1793 value is calculated based on: 1794 o The number of lost refresh messages that NFs should cope with 1795 o The end to end delay between the NI and NR 1796 o Network vulnerability due to session hijacking ([6]). Session 1797 hijacking is made easier when the NI does not explicitly remove 1798 the session. 1799 o The user application's data exchange duration, in terms of 1800 seconds, minutes or hours and networking needs. This duration is 1801 modeled as M x R, with R the message refresh period (in seconds) 1802 and M a multiplier for R. 1804 As opposed to the NTLP Message Routing state [1] lifetime, the NSLP 1805 session lifetime is not required to have a small value since the NSLP 1806 state refresh is not handling routing changes but security related 1807 concerns. [11] provides a good algorithm to calculate the session 1808 lifetime as well as how to avoid refresh message synchronization 1809 within the network. [11] recommends: 1810 1. The refresh message timer to be randomly set to a value in the 1811 range [0.5R, 1.5R]. 1812 2. To avoid premature loss of state, L (with L being the session 1813 lifetime) must satisfy L >= (K + 0.5)*1.5*R, where K is a small 1814 integer. Then in the worst case, K-1 successive messages may be 1815 lost without state being deleted. Currently K = 3 is suggested 1816 as the default. However, it may be necessary to set a larger K 1817 value for hops with high loss rate. Other algorithms could be 1818 used to define the relation between the session lifetime and the 1819 refresh message period, the algorithm provided is only given as 1820 an example. 1822 This requested lifetime value is placed in the 'lifetime' object of 1823 the NSLP message and messages are forwarded to the next NATFW NSLP 1824 node. 1826 NATFW NFs processing the request message along the path MAY change 1827 the requested lifetime to fit their needs and/or local policy. If an 1828 NF changes the lifetime value it must also indicate the corresponding 1829 refresh message period. NFs MUST NOT increase the lifetime value; 1830 they MAY reject the requested lifetime immediately and MUST generate 1831 an error response message of type 'lifetime too big' upon rejection. 1832 The NSLP request message is forwarded until it reaches the NSLP 1833 responder. NSLP responder MAY reject the requested lifetime value 1834 and MUST generate an error response message of type 'lifetime too 1835 big' upon rejection. The NSLP responder MAY also lower the requested 1836 lifetime to an acceptable value (based on its local policies). NSLP 1837 responders generate their appropriate response message for the 1838 received request message, sets the lifetime value to the above 1839 granted lifetime and sends the message back hop-by-hop towards NSLP 1840 initiator. 1842 Each NSLP forwarder processes the response message, reads and stores 1843 the granted lifetime value. The forwarders SHOULD accept the granted 1844 lifetime, as long as the value is within the tolerable lifetime range 1845 defined in their local policies. They MAY reject the lifetime and 1846 generate a 'lifetime not acceptable' error response message. 1847 Figure 21 shows the procedure with an example, where an initiator 1848 requests 60 seconds lifetime in the CREATE message and the lifetime 1849 is shortened along the path by the forwarder to 20 seconds and by the 1850 responder to 15 seconds. 1852 +-------+ CREATE(lt=60s) +-----------+ CREATE(lt=20s) +--------+ 1853 | |---------------->| NSLP |---------------->| | 1854 | NI | | | | NR | 1855 | |<----------------| forwarder |<----------------| | 1856 +-------+ RESPONSE(lt=15s +-----------+ RESPONSE(lt=15s +--------+ 1857 MRR=3s) MRR=3s) 1859 lt = lifetime 1860 MRR = Message Refresh Rate 1862 Figure 21: Lifetime Calculation Example 1864 3.5 Firewall and NAT Resources 1866 The NATFW NSLP carries (in conjunction with the NTLP's MRI) the 1867 policy rule to be installed at NATFW peers. This policy rule is an 1868 abstraction with respect to the real policy rule to be installed at 1869 the respective firewall or NAT. For firewalls policy rules must be 1870 mapped to filter rules, for NATs they must be mapped to NAT bindings, 1871 and at combined devices the order of firewall rules and NAT bindings 1872 must be observed. The exact mapping depends on the implementation of 1873 the firewall or NAT and is very different per vendor. 1875 EDITOR's NOTE: This section needs to describe how to map flow routing 1876 information to middlebox policy rules. Further, this section must 1877 clarify wildcarding. 1879 EDITOR's NOTE: Should this section describe how NATFW NSLP messages 1880 are handled in twice-NATs? 1882 3.6 De-Multiplexing at NATs 1884 Section 3.3.2 describes how NSIS nodes behind NATs can obtain a 1885 public reachable IP address and port number at a NAT and how it can 1886 be activated by using CREATE messages (see Section 3.3.1)". The 1887 information about the public IP address/port number can be 1888 transmitted via an application level signaling protocol and/or third 1889 party to the communication partner that would like to send data 1890 toward the host behind the NAT. However, NSIS signaling flows are 1891 sent towards the address of the NAT at which this particular IP 1892 address and port number is allocated and not directly to the 1893 allocated IP address and port number. The NATFW NSLP forwarder at 1894 this NAT needs to know how the incoming NSLP requests are related to 1895 reserved addresses, meaning how to de-multiplex incoming NSIS 1896 requests. 1898 The de-multiplexing method uses information stored at NATs (such as 1899 mapping of public IP address to private, transport protocol, port 1900 numbers), information given by NTLP's message routing information and 1901 further authentication credentials. 1903 3.7 Selecting Opportunistic Addresses for REA 1905 As with all other message types, REA messages need a reachable final 1906 destination IP address. But as many applications do not provide a 1907 destination IP address in the first place, there is a need to choose 1908 a destination address for REA messages. This destination address can 1909 be the final target, but for applications which do not provide an 1910 upfront address, the destination address has to be chosen 1911 independently. Choosing the 'correct' destination IP address may be 1912 difficult and it is possible there is no 'right answer'. [15] shows 1913 choices for SIP and this section provides some hints about choosing a 1914 good destination IP address. 1916 1. Public IP address of the data sender: 1917 * Assumption: 1918 + The data receiver already learned the IP address of the 1919 data sender (e.g., via a third party). 1920 * Problems: 1921 + The data sender might also be behind a NAT. In this case 1922 the public IP address of the data receiver is the IP 1923 address allocated at this NAT. 1924 + Due to routing asymmetry it might be possible that the 1925 routes taken by a) the data sender and the application 1926 server b) the data sender and NAT B might be different, 1927 this could happen in a network deployment such as in 1928 Figure 14. As a consequence it might be necessary to 1929 advertise a new (and different) external IP address within 1930 the application (which may or may not allow that) after 1931 using NSIS to establish a NAT binding. 1932 2. Public IP address of the data receiver: 1933 * Assumption: 1934 + The data receiver already learned his externally visible IP 1935 address (e.g., based on the third party communication). 1936 * Problems: 1937 + Communication with a third party is required. 1938 3. IP address of the Application Server: 1939 * Assumption: 1940 + An application server (or a different third party) is 1941 available. 1942 * Problems: 1943 + If the NSIS signaling message is not terminated at the NAT 1944 of the local network then an NSIS unaware application 1945 server might discard the message. 1946 + Routing might not be optimal since the route between a) the 1947 data receiver and the application server b) the data 1948 receiver and the data sender might be different. 1950 4. NATFW NSLP Message Components 1952 A NATFW NSLP message consists of a NSLP header and one or more 1953 objects following the header. The NSLP header is common for all 1954 NSLPs and objects are Type-Length-Value (TLV) encoded using big 1955 endian (network ordered) binary data representations. Header and 1956 objects are aligned to 32 bit boundaries and object lengths that are 1957 not multiples of 32 bits must be padded to the next higher 32 bit 1958 multiple. 1960 The whole NSLP message is carried as payload of a NTLP message. 1962 Note that the notation 0x is used to indicate hexadecimal numbers. 1964 4.1 NSLP Header 1966 The NSLP header is common to all NSLPs and is the first part of all 1967 NSLP messages. It contains two fields, the NSLP message type and a 1968 reserved field. The total length is 32 bits. The layout of the NSLP 1969 header is defined by Figure 22. 1971 0 16 31 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | NSLP message type | reserved | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 Figure 22: Common NSLP header 1978 The reserved field MUST be set to zero in the NATFW NSLP header 1979 before sending and MUST be ignored during processing of the header. 1980 Note that other NSLPs use this field as a flag field. 1982 4.2 NSLP message types 1984 The message types identify requests and responses. Defined messages 1985 types are: 1986 o 0x0101 : CREATE 1987 o 0x0102 : RESERVE-EXTERNAL-ADDRESS(REA) 1988 o 0x0104 : UCREATE 1989 o 0x0108 : QUERY 1990 o 0x0201 : RESPONSE 1991 o 0x0301 : NOTIFY 1993 4.3 NSLP Objects 1995 NATFW NSLP objects use a common header format defined by Figure 23. 1996 The object header contains two fields, the NSLP object type and the 1997 object length. Its total length is 32 bits. 1999 0 1 2 3 2000 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 Figure 23: Common NSLP object header 2007 The length is the total length of the object without the object 2008 header. The unit is a word, consisting of 4 octets. The particular 2009 values of type and length for each NSLP object are listed in the 2010 subsequent sections that define the NSLP objects. The two leading 2011 bits of the NSLP object header are used to signal the desired 2012 treatment for objects whose treatment has not been defined in this 2013 memo (see [1], Section 3.2), i.e., the Object Type has not been 2014 defined. NATFW NSLP uses a subset of the categories defined in 2015 GIMPS: 2016 o AB=00 ("Mandatory"): If the object is not understood, the entire 2017 message containing it must be rejected with an error indication. 2018 o AB=01 ("Optional"): If the object is not understood, it should be 2019 deleted and then the rest of the message processed as usual. 2020 o AB=10 ("Forward"): If the object is not understood, it should be 2021 retained unchanged in any message forwarded as a result of message 2022 processing, but not stored locally. 2023 The combination AB=11 ("Refresh") MUST NOT be used since the NATFW 2024 NSLP refreshes its state end-to-end and not locally. Fields marked 2025 with 'r' are reserved for future use. 2027 The following sections do not repeat the common NSLP object header, 2028 they just do state the type and the length. 2030 4.3.1 Session Lifetime Object 2032 The session lifetime object carries the requested or granted lifetime 2033 of a NATFW NSLP session measured in seconds. The Message refresh 2034 rate value is set by default to 0xFFFF and only set to a specific 2035 value when an intermediate node changes the message lifetime and 2036 informs the upstream node about the recommended message refresh rate. 2038 Type: NATFW_LT 2039 Length: 1 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | NATFW NSLP session lifetime | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | NATFW NSLP message refresh rate | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 Figure 24: Lifetime object 2049 4.3.2 External Address Object 2051 The external address object can be included in RESPONSE messages 2052 (Section 4.4.3) only. 2054 Type: NATFW_EXT_IPv4 2055 Length: 2 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | port number | reserved | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | IPv4 address | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 Figure 25: External Address Object for IPv4 addresses 2065 Type: NATFW_EXT_IPv6 2066 Length: 5 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | port number | reserved | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 | | 2072 + + 2073 | | 2074 + IPv6 address + 2075 | | 2076 + + 2077 | | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 Figure 26: External Address Object for IPv6 addresses 2082 Please note that the field 'port number' MUST be set to 0 if only an 2083 IP address has been reserved, for instance, by a traditional NAT. A 2084 port number of 0 MUST be ignored in processing this object. 2086 4.3.3 Extended Flow Information Object 2088 In general, flow information is kept at the NTLP level during 2089 signaling. The message routing information of the NTLP carries all 2090 necessary information. Nevertheless, some additional information may 2091 be required for NSLP operations. The 'extended flow information' 2092 object carries this additional information about action to be taken 2093 on the installed policy rules and subsequent numbers of policy rules. 2095 Type: NATFW_EXT_FLOW 2096 Length: 1 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | rule action | reserved | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 Figure 27: Extended Flow Information 2104 These fields are defined for the policy rule object: 2105 o Rule action: This field indicates the action for the policy rule 2106 to be activated. Allowed values are 'allow' (0x01) and 'deny' 2107 (0x02) 2109 4.3.4 Response Code Object 2111 This object carries the response code, which may be indications for 2112 either a successful request or failed request depending on the value 2113 of the 'response code' field. 2115 Type: NATFW_RESPONSE 2116 Length: 1 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | response code | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 Figure 28: Response Code Object 2124 TBD: Define response classes, success codes and error codes. 2125 Possible error classes are: 2126 o Policy rule errors 2127 o Authentication and Authorization errors 2128 o NAT 2129 Currently errors defined in this memo are: 2130 o lifetime too big 2131 o lifetime not acceptable 2132 o no NAT here 2133 o no reservation found 2134 o requested external address from outside 2135 o re-authorization needed 2136 o routing change detected 2138 4.3.5 Proxy Support Type Object 2140 This object indicates that proxy mode support is required. Either in 2141 a REA message or CREATE message. 2143 Type: NATFW_RESP_TYPE 2144 Length: 0, only object header 2146 EDITOR's NOTE: This is quite a short object and probably better moved 2147 to a flag somewhere. 2149 4.3.6 Message Sequence Number Object 2151 This object is used to correlate a response to a request message. 2153 Type: NATFW_RESP_MSN 2154 Length: 1 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | message sequence number | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 Figure 29: Message Sequence Number Object 2162 4.3.7 Bound Session ID Object 2164 This object carries a session ID and is used for QUERY messages only. 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | bound session ID | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 Figure 30: Bound Session ID Object 2172 This object is used when a session owner queries multiple session, 2173 every session would be indicated with the bound session ID object. 2175 4.3.8 Data Sender Information Object 2177 Type: NATFW_DSINFO_IPv4 2178 Length: 1 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | port number | reserved | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | IPv4 address | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 Figure 31: Data Sender's IPv4 Address Object 2188 Type: NATFW_DSINFO_IPv6 2189 Length: 1 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | port number | reserved | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | | 2195 + + 2196 | | 2197 + IPv6 address + 2198 | | 2199 + + 2200 | | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 Figure 32: ata Sender's IPv6 Address Object for IPv6 addresses 2205 4.4 Message Formats 2207 This section defines the content of each NATFW NSLP message type. 2208 The message types are defined in Section 4.2. First, the request 2209 messages are defined with their respective objects to be included in 2210 the message. Second, the response messages are defined with their 2211 respective objects to be included. 2213 Basically, each message is constructed of NSLP header and one or more 2214 NSLP objects. The order of objects is not defined, meaning that 2215 objects may occur in any sequence. Objects are marked either with 2216 mandatory [M] or optional [O]. Where [M] implies that this 2217 particular object MUST be included within the message and where [O] 2218 implies that this particular object is OPTIONAL within the message. 2220 Each section elaborates the required settings and parameters to be 2221 set by the NSLP for the NTLP, for instance, how the message routing 2222 information is set. 2224 4.4.1 CREATE 2226 The CREATE request message is used to create NSLP sessions and to 2227 create policy rules. Furthermore, CREATE messages are used to 2228 refresh sessions and to delete them. 2230 The CREATE message carries these objects: 2231 o Lifetime object [M] 2232 o Extended flow information object [M] 2233 o Message sequence number object [M] 2234 o Proxy support object [O] 2235 The message routing information in the NTLP MUST be set to DS as 2236 source address and DR as destination address. All other parameters 2237 MUST be set according the required policy rule. 2239 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) 2241 The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to target 2242 a NAT and to allocated an external IP address and possibly port 2243 number, so that the initiator of the REA request has a public 2244 reachable IP address/port number. 2246 The REA request message carries these objects: 2247 o Lifetime object [M] 2248 o Message sequence number object [M] 2249 o Extended flow information object [M] 2250 o Proxy support object [O] 2251 o Data sender information object [O] 2253 The REA message needs special NTLP treatment. First of all, REA 2254 messages travel the wrong way, from the DR towards DS. Second, the 2255 DS' address used during the signaling may be not the actual DS (see 2256 Section 3.7). Therefore, the NTLP flow routing information is set to 2257 DR as initiator and DS as responders, a special field is given in the 2258 NTLP: The signaling destination. 2260 4.4.3 RESPONSE 2262 RESPONSE messages are responses to CREATE, REA, UCREATE, and QUERY 2263 messages. 2265 The RESPONSE message carries these objects: 2266 o Lifetime object [M] 2267 o Response code object [M] 2268 o External address object [O]([M] for success responses to REA) 2270 This message is routed upstream. 2272 EDITOR's note: Text says that this section is defining the behavior 2273 depending on the response type. 2275 4.4.4 QUERY 2277 QUERY messages are used for diagnosis purposes. 2279 The QUERY message carries these objects: 2280 o Response object [M] 2281 o Message sequence number object [M] 2282 o Bound session ID [O] 2284 This message is routed downstream. 2286 4.4.5 NOTIFY 2288 The NOTIFY messages is used to report asynchronous events happening 2289 along the signaled path to other NATFW NSLP nodes. 2291 The NOTIFY message carries this object: 2292 o Response code object with NOTIFY code [M]. 2294 The message routing information in the NTLP MUST be set to DS as 2295 source address and DR as destination address, forwarding direction is 2296 upstream. The session id object must be set to the corresponding 2297 session that is effected by this asynchronous event. 2299 4.4.6 UCREATE 2301 TBD: XYX. 2303 5. NATFW NSLP NTLP Requirements 2305 The NATFW NSLP requires the following capabilities from the NTLP: 2306 o Ability to detect that the NSIS Responder does not support NATFW 2307 NSLP. This capability is key to launching the proxy mode behavior 2308 as described in Section 3.3.7 and [13]. 2309 o Detection of NATs and their support of the NSIS NATFW NSLP. If 2310 the NTLP discovers that the NSIS host is behind an NSIS aware NAT, 2311 the NR will send REA messages to the opportunistic address. If 2312 the NTLP discovers that the NSIS host is behind a NAT that does 2313 not support NSIS then the NSIS host will need to use a separate 2314 NAT traversal mechanism. 2315 o Message origin authentication and message integrity protection 2316 o Detection of routing changes 2317 o Protection against malicious announcement of fake path changes, 2318 this is needed to mitigate a threat discussed in Section 7 of [6] 2320 6. NSIS NAT and Firewall Transition Issues 2322 NSIS NAT and Firewall transition issues are premature and will be 2323 addressed in a separate draft (see [13]). An update of this section 2324 will be based on consensus. 2326 7. Security Considerations 2328 Security is of major concern particularly in case of Firewall 2329 traversal. This section provides security considerations for the 2330 NAT/Firewall traversal and is organized as follows: 2332 Section 7.1 describes the framework assumptions with regard to the 2333 assumed trust relationships between the participating entities. This 2334 subsection also motivates a particular authorization model. 2336 Security threats that focus on NSIS in general are described in [6] 2337 and they are applicable to this document. Within Section 7.2 we 2338 extend this threat investigation by considering NATFW NSLP specific 2339 threats. Based on the security threats we list security 2340 requirements. 2342 Finally we illustrate how the security requirements that were created 2343 based on the security threats can be fullfilled by specific security 2344 mechanisms. These aspects will be elaborated in Section 7.3. 2346 7.1 Trust Relationship and Authorization 2348 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 2349 and is, as such, not a two-party protocol. This fact requires more 2350 thoughts about scenarios, trust relationships and authorization 2351 mechanisms. Trust relationships and authorization are very important 2352 for the protocol machinery and they are closely related to each other 2353 in the sense that a certain degree of trust is required to authorize 2354 a particular action. For any action (e.g. create/delete pinholes), 2355 authorization is very important due to the nature of middleboxes. 2356 More problematic scenarios are described in Appendix A. 2358 Different types of trust relationships may affect different 2359 categories of middleboxes. As explained in [21], establishment of a 2360 financial relationship is typically very important for QoS signaling, 2361 whereas financial relationships are less directly of interest for 2362 NATFW middlebox signaling. It is therefore not particularly 2363 surprising that there are differences in the nature and level of 2364 authorization likely to be required in a QoS signaling environment 2365 and in NATFW middlebox signaling. Typically NATFW signaling requires 2366 authorization to configure firewalls or to modify NAT bindings. The 2367 outcome of the authorization is either allowed or disallowed whereas 2368 QoS signaling might just indicate that a lower QoS reservation is 2369 allowed. 2371 Different trust relationships that appear in middlebox signaling 2372 environments are described in the subsequent sub-sections. As a 2373 comparison with other NSIS signaling application it might be 2374 interesting to mention that QoS signaling relies on peer-to-peer 2375 trust relationships and authorization between neighboring nodes or 2376 neighboring networks. These type of trust relationships turn out to 2377 be simpler for a protocol. However, there are reasons to believe 2378 that this is not the only type of trust relationship found in today's 2379 networks. 2381 7.1.1 Peer-to-Peer Trust Relationship 2383 Starting with the simplest scenario, it is assumed that neighboring 2384 nodes trust each other. The required security association to 2385 authenticate and to protect a signaling message is either available 2386 (after manual configuration), or has been dynamically established 2387 with the help of an authentication and key exchange protocol. If 2388 nodes are located closely together, it is assumed that security 2389 association establishment is easier than establishing it between 2390 distant nodes. It is, however, difficult to describe this 2391 relationship generally due to the different usage scenarios and 2392 environments. Authorization heavily depends on the participating 2393 entities, but for this scenario, it is assumed that neighboring 2394 entities trust each other (at least for the purpose of policy rule 2395 creation, maintenance, and deletion). Note that Figure 33 does not 2396 illustrate the trust relationship between the end host and the access 2397 network. 2399 +------------------------+ +-------------------------+ 2400 |Network A | | Network B| 2401 | +---------+ +---------+ | 2402 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 2403 | | | box 1 | Trust | box 2 | | | 2404 | | +---------+ Relationship +---------+ | | 2405 | | Trust | | Trust | | 2406 | | Relationship | | Relationship | | 2407 | | | | | | 2408 | +--+---+ | | +--+---+ | 2409 | | Host | | | | Host | | 2410 | | A | | | | B | | 2411 | +------+ | | +------+ | 2412 +------------------------+ +-------------------------+ 2414 Figure 33: Peer-to-Peer Trust Relationship 2416 7.1.2 Intra-Domain Trust Relationship 2418 In larger corporations, often more than one middlebox is used to 2419 protect or serve different departments. In many cases, the entire 2420 enterprise is controlled by a security department, which gives 2421 instructions to the department administrators. In such a scenario, a 2422 peer-to-peer trust-relationship might be prevalent. Sometimes it 2423 might be necessary to preserve authentication and authorization 2424 information within the network. As a possible solution, a 2425 centralized approach could be used, whereby an interaction between 2426 the individual middleboxes and a central entity (for example a policy 2427 decision point - PDP) takes place. As an alternative, individual 2428 middleboxes could exchange the authorization decision with another 2429 middlebox within the same trust domain. Individual middleboxes 2430 within an administrative domain should exploit their trust 2431 relationship instead of requesting authentication and authorization 2432 of the signaling initiator again and again. Thereby complex protocol 2433 interactions are avoided. This provides both a performance 2434 improvement without a security disadvantage since a single 2435 administrative domain can be seen as a single entity. Figure 34 2436 illustrates a network structure which uses a centralized entity. 2438 +-----------------------------------------------------------+ 2439 | Network A | 2440 | +---------+ +---------+ 2441 | +----///--------+ Middle- +------///------++ Middle- +--- 2442 | | | box 2 | | box 2 | 2443 | | +----+----+ +----+----+ 2444 | +----+----+ | | | 2445 | | Middle- +--------+ +---------+ | | 2446 | | box 1 | | | | | 2447 | +----+----+ | | | | 2448 | | | +----+-----+ | | 2449 | | | | Policy | | | 2450 | +--+---+ +-----------+ Decision +----------+ | 2451 | | Host | | Point | | 2452 | | A | +----------+ | 2453 | +------+ | 2454 +-----------------------------------------------------------+ 2456 Figure 34: Intra-domain Trust Relationship 2458 7.1.3 End-to-Middle Trust Relationship 2460 In some scenarios, a simple peer-to-peer trust relationship between 2461 participating nodes is not sufficient. Network B might require 2462 additional authorization of the signaling message initiator. If 2463 authentication and authorization information is not attached to the 2464 initial signaling message then the signaling message arriving at 2465 Middlebox 2 would result in an error message being created, which 2466 indicates the additional authorization requirement. In many cases 2467 the signaling message initiator is already aware of the additionally 2468 required authorization before the signaling message exchange is 2469 executed. Replay protection is a requirement for authentication to 2470 the non-neighboring middlebox, which might be difficult to accomplish 2471 without adding additional roundtrips to the signaling protocol (e.g., 2472 by adding a challenge/response type of message exchange). 2474 Figure 35 shows the slightly more complex trust relationships in this 2475 scenario. 2477 +--------------------+ +---------------------+ 2478 | Network A | Trust |Network B | 2479 | | Relationship | | 2480 | +---------+ +---------+ | 2481 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 2482 | | | box 1 | +-------+ box 2 | | | 2483 | | +---------+ | +---------+ | | 2484 | |Trust | | | Trust | | 2485 | |Relationship | | | Relationship| | 2486 | | | | | | | 2487 | +--+---+ | | | +--+---+ | 2488 | | Host +----///----+------+ | | Host | | 2489 | | A | |Trust | | B | | 2490 | +------+ |Relationship | +------+ | 2491 +--------------------+ +---------------------+ 2493 Figure 35: End-to-Middle Trust Relationship 2495 7.2 Security Threats and Requirements 2497 This section describes NATFW specific security threats and 2498 requirements. 2500 7.2.1 Attacks related to authentication and authorization 2502 The NSIS message which installs policy rules at a middlebox is the 2503 CREATE message. The CREATE message travels from the Data Sender (DS) 2504 toward the Data Receiver (DR). The packet filter or NAT binding is 2505 marked as pending by the middleboxes along the path. If it is 2506 confirmed with a success RESPONSE message from the DR, the requested 2507 policy rules on the middleboxes are installed to allow the traversal 2508 of a data flow. 2510 +-----+ +-----+ +-----+ 2511 | DS | | MB | | DR | 2512 +-----+ +-----+ +-----+ 2513 | | | 2514 | CREATE | CREATE | 2515 |-------------------->+-------------------->| 2516 | | | 2517 | Succeeded/Error | Succeeded/Error | 2518 |<--------------------+<--------------------| 2519 | | | 2520 ==========================================> 2521 Direction of data traffic 2523 Figure 36: CREATE Mode 2525 In this section we will consider some simple scenarios for middlebox 2526 configuration: 2527 o Data Sender (DS) behind a firewall 2528 o Data Sender (DS) behind a NAT 2529 o Data Receiver (DR) behind a firewall 2530 o Data Receiver (DR) behind a NAT 2532 A real-world scenario could include a combination of these 2533 firewall/NAT placements, such as, a DS and/or a DR behind a chain of 2534 NATs and firewalls. 2536 Figure 37 shows one possible scenario: 2538 +-------------------+ +--------------------+ 2539 | Network A | | Network B | 2540 | | | | 2541 | +-----+ | //-----\\ | +-----+ | 2542 | | MB2 |--------+----| INET |----+--------| MB3 | | 2543 | +-----+ | \\-----// | +-----+ | 2544 | | | | | | 2545 | +-----+ | | +-----+ | 2546 | | MB1 | | | | MB4 | | 2547 | +-----+ | | +-----+ | 2548 | | | | | | 2549 | +-----+ | | +-----+ | 2550 | | DS | | | | DR | | 2551 | +-----+ | | +-----+ | 2552 +-------------------+ +--------------------+ 2554 MB: Middle box (NAT or Firewall or a combination) 2555 DS: Data Sender 2556 DR: Data Receiver 2558 Figure 37: Several middleboxes per network 2560 7.2.1.1 Data Sender (DS) behind a firewall 2562 +------------------------------+ 2563 | | 2564 | +-----+ create +-----+ 2565 | | DS | --------------> | FW | 2566 | +-----+ +-----+ 2567 | | 2568 +------------------------------+ 2570 DS sends a CREATE message to request the traversal of a data flow. 2572 It is up to network operators to decide how far they can trust users 2573 inside their networks. However, there are several reasons why they 2574 should not. 2576 The following attacks are possible: 2577 o DS could open a firewall pinhole with a source address different 2578 from its own host. 2579 o DS could open firewall pinholes for incoming data flows that are 2580 not supposed to enter the network. 2581 o DS could request installation of any policy rules and allow all 2582 traffic go through. 2584 SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize 2585 the neighboring NAT/FW NSLP node which requests an action. 2586 Authentication and authorization of the initiator SHOULD be 2587 provided to NATs and Firewalls along the path. 2589 7.2.1.2 Data Sender (DS) behind a NAT 2591 The case 'DS behind a NAT' is analogous to the case 'DS behind a 2592 firewall'. 2594 Figure 39 illustrates such a scenario: 2596 +------------------------------+ 2597 | | 2598 | +------+ CREATE | 2599 | | NI_1 | ------\ +-----+ CREATE +-----+ 2600 | +------+ \------> | NAT |-------->| MB | 2601 | +-----+ +-----+ 2602 | +------+ | 2603 | | NI_2 | | 2604 | +------+ | 2605 +------------------------------+ 2607 Figure 39: Several NIs behind a NAT 2609 In this case the middlebox MB does not know who is the NSIS Initiator 2610 since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware). 2611 Authentication needs to be provided by other means such as the NSLP 2612 or the application layer. 2614 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that 2615 the neighboring NAT/FW NSLP node is authorized to request an 2616 action. Authentication and authorization of the initiator (which 2617 is the DR in this scenario) to the middleboxes (via another NSIS 2618 aware middlebox) SHOULD be provided. 2620 7.2.1.3 Data Receiver (DR) behind a firewall 2622 In this case a CREATE message comes from an entity DS outside the 2623 network towards the DR inside the network. 2625 +------------------------------+ 2626 | | 2627 +-----+ CREATE +-----+ CREATE +-----+ | 2628 | DS | -------------> | FW | -------------> | DR | | 2629 +-----+ <------------- +-----+ <------------- +-----+ | 2630 success RESPONSE | success RESPONSE | 2631 | | 2632 +------------------------------+ 2634 Since policy rules at middleboxes must only be installed after 2635 receiving a successful response it is necessary that the middlebox 2636 waits until the Data Receiver DR confirms the request of the Data 2637 Sender DS with a success RESPONSE message. This is, however, only 2638 necessary 2639 o if the action requested with the CREATE message cannot be 2640 authorized and 2641 o if the middlebox is still forwarding the signaling message towards 2642 the end host (without state creation/deletion/modification). 2644 This confirmation implies that the data receiver is expecting the 2645 data flow. 2647 At this point we differentiate two cases: 2648 1. DR knows the IP address of the DS (for instance because of some 2649 previous application layer signaling) and is expecting the data 2650 flow. 2651 2. DR might be expecting the data flow (for instance because of some 2652 previous application layer signaling) but does not know the IP 2653 address of the Data Sender DS. 2655 For the second case, Figure 41 illustrates a possible attack: an 2656 adversary Mallory M could be sniffing the application layer signaling 2657 and thus knows the address and port number where DR is expecting the 2658 data flow. Thus it could pretend to be DS and send a CREATE message 2659 towards DR with the data flow description (M -> DR). Since DR does 2660 not know the IP address of DS, it is not able to recognize that the 2661 request is coming from the "wrong guy". It will send a success 2662 RESPONSE message back and the middlebox will install policy rules 2663 that will allow Mallory M to inject its data into the network. 2665 Application Layer signaling 2666 <------------------------------------> 2667 / \ 2668 / +-----------------\------------+ 2669 / | \ | 2670 +-----+ +-----+ +-----+ | 2671 | DS | -> | FW | | DR | | 2672 +-----+ / +-----+ +-----+ | 2673 CREATE / | | 2674 +-----+ / +-------------------------------+ 2675 | M |---------- 2676 +-----+ 2678 Figure 41: DR behind a firewall with an adversary 2680 Network administrators will probably not rely on a DR to check the IP 2681 address of the DS. Thus we have to assume the worst case with an 2682 attack such as in Figure 41. Many operators might not allow NSIS 2683 signaling message to traverse the firewall in Figure 41 without 2684 proper authorization. In this case the threat is not applicable. 2686 SECURITY REQUIREMENT: A binding between the application layer and the 2687 NSIS signaling SHOULD be provided. 2689 7.2.1.4 Data Receiver (DR) behind a NAT 2691 When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS 2692 (REA) message to get a public reachable address that can be used as a 2693 contact address by an arbitrary data sender if the DR was unable to 2694 restrict the future data sender. The NAT reserves an external 2695 address and port number and sends them back to DR. The NAT adds an 2696 address mapping entry in its reservation list which links the public 2697 and private addresses as follows: 2699 (DR_ext <=> DR_int) (*). 2701 The NAT sends a RESPONSE message with the external address' object 2702 back to the DR with the address DR_ext. DR informs DS about the 2703 public address that it has recently received, for instance, by means 2704 of application layer signaling. 2706 When a data sender sends a CREATE message towards DR_ext then the 2707 message will be forwarded to the DR. The data sender might want to 2708 update the NAT binding stored at the edge-NAT to make it more 2709 restrictive. 2711 We assume that the adversary Mallory M obtains the contact address 2712 (i.e., external address and port) allocated at the NAT possibly by 2713 eavesdropping on the application layer signaling and sends a CREATE 2714 message. As a consequence Mallory would be able to communicate with 2715 DR (if M is authorized by the edge-NAT and if the DR accepts CREATE 2716 and returns a RESPONSE. 2718 Application Layer signaling 2719 <------------------------------------> 2720 / \ 2721 / +-----------------\------------+ 2722 / | REA \ | 2723 +-----+ +-----+ <----------- +-----+ | 2724 | DS | -> | NAT | -----------> | DR | | 2725 +-----+ / +-----+ rtn_ext_addr +-----+ | 2726 CREATE / | | 2727 +-----+ / +-------------------------------+ 2728 | M |---------- 2729 +-----+ 2731 SECURITY REQUIREMENT: The DR MUST be able to specify which data 2732 sender are allowed to traverse the NAT in order to be forwarded to 2733 DRs address. 2735 7.2.1.5 NSLP Message Injection 2737 Malicious hosts, located either off-path or on-path, could inject 2738 arbitrary NATFW NSLP messages into the signaling path, causing 2739 several problems. These problems apply when no proper authorization 2740 and authentication scheme is available. 2742 By injecting a bogus CREATE message with lifetime set to zero, a 2743 malicious host could try to teardown NATFW NSLP session state 2744 partially or completely on a data path, causing a service 2745 interruption. 2747 By injecting a bogus responses or NOTIFY message, for instance, 2748 timeout, a malicious host could try to teardown NATFW NSLP session 2749 state as well. This could affect the data path partially or totally, 2750 causing a service interruption. 2752 SECURITY REQUIREMENT: Messages, such as TRIGGER, can be misused by 2753 malicious hosts, and therefore need to be authorized. 2755 7.2.2 Denial-of-Service Attacks 2757 In this section we describe several ways how an adversary could 2758 launch a Denial of service (DoS) attack on networks running NSIS for 2759 middlebox configuration to exhaust their resources. 2761 7.2.2.1 Flooding with CREATE messages from outside 2763 7.2.2.1.1 Attacks due to NSLP state 2765 A CREATE message requests the NSLP to store state information such as 2766 a NAT binding or a policy rule. 2768 The policy rules requested in the CREATE message will be installed at 2769 the arrival of a confirmation from the Data Receiver with a success 2770 RESPONSE message. A successful RESPONSE message includes the session 2771 ID. So the NSLP looks up the NSIS session and installs the requested 2772 policy rules. 2774 An adversary from outside could launch a DoS attack with arbitrary 2775 CREATE messages. For each of these messages the middlebox needs to 2776 store state information such as the policy rules to be loaded, i.e., 2777 the middlebox could run out of memory. This kind of attack is also 2778 mentioned in [6] Section 4.8. 2780 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 2781 'create-session' message before storing state information. 2783 7.2.2.1.2 Attacks due to authentication complexity 2785 This kind of attack is possible if authentication is based on 2786 mechanisms that require computing power, for example, digital 2787 signatures. 2789 For a more detailed treatment of this kind of attack, the reader is 2790 encouraged to see [6]. 2792 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 2793 denial of service attacks based on authentication or key 2794 management mechanisms. 2796 7.2.2.1.3 Attacks to the endpoints 2798 The NATFW NSLP requires firewalls to forward NSLP messages, a 2799 malicious node may keep sending NSLP messages to a target. This may 2800 consume the access network resources of the victim, drain the battery 2801 of the victim's terminal and may force the victim to pay for the 2802 received although undesired data. 2804 This threat may be more particularly be relevant in networks where 2805 access link is a limited resource, for instance in cellular networks, 2806 and where the terminal capacities are limited. 2808 SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able 2809 to block unauthorized signaling message, if this threat is a 2810 concern. 2812 7.2.2.2 Flooding with REA messages from inside 2814 Although we are more concerned with possible attacks from outside the 2815 network, we need also to consider possible attacks from inside the 2816 network. 2818 An adversary inside the network could send arbitrary 2819 RESERVE-EXTERNAL-ADDRESS messages. At a certain point the NAT will 2820 run out of port numbers and the access for other users to the outside 2821 will be disabled. 2823 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 2824 creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, 2825 the NAT/FW NSLP implementation MUST prevent denial of service 2826 attacks involving the allocation of an arbitrary number of NAT 2827 bindings or the installation of a large number of packet filters. 2829 7.2.3 Man-in-the-Middle Attacks 2831 Figure 43 illustrates a possible man-in-the-middle attack using the 2832 RESERVE-EXTERNAL-ADDRESS (REA) message. This message travels from DR 2833 towards the public Internet. The message might not be intercepted 2834 because there are no NSIS aware middleboxes. 2836 Imagine such an NSIS signaling message is then intercepted by an 2837 adversary Mallory (M). M returns a faked RESPONSE message whereby 2838 the adversary pretends that a NAT binding was created. This NAT 2839 binding is returned with the RESPONSE message. Malory might insert 2840 it own IP address in the response, the IP address of a third party or 2841 the address of a black hole. In the first case, the DR thinks that 2842 the address of Mallory M is its public address and will inform the DS 2843 about it. As a consequence, the DS will send the data traffic to 2844 Mallory M. 2846 The data traffic from the DS to the DR will re-directed to Mallory M. 2847 M will be able to read, modify or block the data traffic (if the 2848 end-to-end communication itself does not experience protection). 2849 Eavesdropping and modification is only possible if the data traffic 2850 is itself unprotected. 2852 +-----+ +-----+ +-----+ 2853 | DS | | M | | DR | 2854 +-----+ +-----+ +-----+ 2855 | | | 2856 | | REA | 2857 | | <------------------ | 2858 | | | 2859 | | RESPONSE | 2860 | | ------------------> | 2861 | | | 2862 | data traffic | | 2863 |===============>| data traffic | 2864 | |====================>| 2866 Figure 43: MITM attack using the RESERVE-EXTERNAL-ADDRESS message 2868 SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW 2869 NSLP MUST be provided. To ensure that only legitimate nodes along 2870 the path act as NSIS entities the initiator MUST authorize the 2871 responder. In the example in Figure 43 the firewall FW must 2872 perform an authorization with the neighboring entities. 2874 7.2.4 Message Modification by non-NSIS on-path node 2876 An unauthorized on-path node along the path towards the destination 2877 could easily modify, inject or just drop an NSIS message. It could 2878 also hijack or disrupt the communication. 2880 SECURITY REQUIREMENT: Message integrity, replay protection and data 2881 origin authentication between neighboring NAT/FW NSLPs MUST be 2882 provided. 2884 7.2.5 Message Modification by malicous NSIS node 2886 Message modification by a NSIS node that became malicious is more 2887 serious. An adversary could easily create arbitrary pinholes or NAT 2888 bindigs. For example: 2890 o NATs need to modify the source/destination of the data flow in the 2891 'create session' message. 2892 o Each middlebox along the path may change the requested lifetime in 2893 the CREATE message to fit their needs and/or local policy. 2895 SECURITY REQUIREMENT: None. Malicous NSIS NATs and Firewalls will 2896 not be addressed. 2898 7.2.6 Session Modification/Deletion 2900 The Session ID is included in signaling messages as a reference to 2901 the established state. If an adversary is able to obtain the Session 2902 Identifier for example by eavesdropping on signaling messages, it 2903 would be able to add the same Session Identifier to a new signaling 2904 message and effect some modifications. 2906 Consider the scenario described in Figure 44. Here an adversary 2907 pretends to be 'DS in mobility'. The signaling messages start from 2908 the DS and go through a series of routers towards the DR. We assume 2909 that an off-path adversary is connected to one of the routers along 2910 the old path (here Router 3). We also assume that the adversary 2911 knows the Session ID of the NSIS session initiated by the DS. 2912 Knowing the Session ID, the adversary now sends signalling messages 2913 towards the DR. When the signaling message reaches Router3 then 2914 existing state information can be modified or even deleted. The 2915 adversary can modify or delete the established reservation causing 2916 unexpected behavior for the legitimate user. The source of the 2917 problem is that the Router 3 (cross-over router) is unable to decide 2918 whether the new signaling message was initiated from the owner of the 2919 session. In this scenario, the adversary need not even be located in 2920 the DS-DR path. This problem and the solution approaches are 2921 described in more detail in [23]. 2923 Session ID(SID-x) 2924 +--------+ +--------+ 2925 +-------->--------+ Router +-------->+ DR | 2926 Session ID(SID-x)| | 4 | | | 2927 +---+----+ +--------+ +--------+ 2928 | Router | 2929 +------+ 3 +******* 2930 | +---+----+ * 2931 | * 2932 | Session ID(SID-x) * Session ID(SID-x) 2933 +---+----+ +---+----+ 2934 | Access | | Access | 2935 | Router | | Router | 2936 | 1 | | 2 | 2937 +---+----+ +---+----+ 2938 | * 2939 | Session ID(SID-x) * Session ID(SID-x) 2940 +----+------+ +----+------+ 2941 | DS | | Adversary | 2942 | | | | 2943 +-----------+ +-----------+ 2945 Figure 44: State Modification by off-path adversary 2947 As a summary, an off-path adversary's knowledge of Session-ID could 2948 cause session modification/deletion. 2950 SECURITY REQUIREMENT: The initiator MUST be able to demonstrate 2951 ownership of the session it wishes to modify. 2953 7.2.6.1 Misuse of mobility in NAT handling 2955 Another kind of session modification is related to mobility 2956 scenarios. NSIS allows end hosts to be mobile, it is possible that 2957 an NSIS node behind a NAT needs to update its NAT binding in case of 2958 address change. Whenever a host behind a NAT initiates a data 2959 transfer, it is assigned an external IP and port number. In typical 2960 mobility scenarios, the DR might also obtain a new address according 2961 to the topology and it should convey its new IP address to the NAT. 2962 The NAT is assumed to modify these NAT bindings based on the new IP 2963 address conveyed by the endhost. 2965 Public Private Address 2966 Internet space 2968 +----------+ +----------+ 2969 +----------| NAT |------------------|End host | 2970 | | | | 2971 +----------+ +----------+ 2972 | 2973 | +----------+ 2974 \--------------------|Malicious | 2975 |End host | 2976 +----------+ 2977 data traffic 2978 <======================== 2980 Figure 45: Misuse of mobility in NAT binding 2982 A NAT binding can be changed with the help of NSIS signalling. When 2983 a DR moves to a new location and obtains a new IP address, it sends 2984 an NSIS signalling message to modify the NAT binding. It would use 2985 the Session-ID and the new flow-id to update the state. The NAT 2986 updates the binding and the DR continues to receive the data traffic. 2987 Consider the scenario in Figure 45 where an the endhost(DR) and the 2988 adversary are behind a NAT. The adversary pretending that it is the 2989 end host could generate a spurious signaling message to update the 2990 state at the NAT. This could be done for these purposes: 2991 Connection hijacking by redirecting packets to the attacker as in 2992 Figure 46 2993 Third party flooding by redirecting packets to arbitrary hosts 2994 Service disruption by redirecting to non-existing hosts 2995 +----------+ +----------+ +----------+ 2996 | NAT | |End host | |Malicious | 2997 | | | | |End host | 2998 +----------+ +----------+ +----------+ 2999 | | | 3000 | Data Traffic | | 3001 |--------->----------| | 3002 | | Spurious | 3003 | | NAT binding update | 3004 |---------<----------+--------<------------| 3005 | | | 3006 | Data Traffic | | 3007 |--------->----------+-------->------------| 3008 | | | 3010 Figure 46: Connection Hijacking 3012 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 3013 authenticated, authorized, integrity protected and replay 3014 protected between neighboring NAT/FW NSLP nodes. 3016 7.2.7 Misuse of unreleased sessions 3018 Assume that DS (N1) initiates NSIS session with DR (N2) through a 3019 series of middleboxes as in Figure 47. When the DS is sending data 3020 to DR, it might happen that the DR disconnects from the network 3021 (crashes or moves out of the network in mobility scenarios). In such 3022 cases, it is possible that another node N3 (which recently entered 3023 the network protected by the same firewall) is assigned the same IP 3024 address that was previously allocated to N2. The DS could take 3025 advantage of the firewall policies installed already, if the refresh 3026 interval time is very high. The DS can flood the node (N3), which 3027 will consume the access network resources of the victim forcing it to 3028 pay for unwanted traffic as shown in Figure 48. Note that here we 3029 make the assumption that the data receiver has to pay for receiving 3030 data packets. 3032 Public Internet 3033 +--------------------------+ 3034 | | 3035 +-------+ CREATE +---+-----+ +-------+ | 3036 | |-------------->------| |---->---| | | 3037 | N1 |--------------<------| FW |----<---| N2 | | 3038 | | success RESPONSE | | | | | 3039 | |==============>======| |====>===| | | 3040 +-------+ Data Traffic +---+-----+ +-------+ | 3041 | | 3042 +--------------------------+ 3044 Figure 47: Before mobility 3046 Public Internet 3047 +--------------------------+ 3048 | | 3049 +-------+ +---+-----+ +-------+ | 3050 | | | | | | | 3051 | N1 |==============>======| FW |====>===| N3 | | 3052 | | Data Traffic | | | | | 3053 +-------+ +---+-----+ +-------+ | 3054 | | 3055 +--------------------------+ 3057 Figure 48: After mobility 3059 Also, this threat is valid for the other direction as well. The DS 3060 which is communicating with the DR may disconnect from the network 3061 and this IP address may be assigned to a new node that had recently 3062 entered the network. This new node could pretend to be the DS and 3063 send data traffic to the DR in conformance with the firewall policies 3064 and cause service disruption. 3066 SECURITY REQUIREMENT: Data origin authentication is needed to 3067 mitigate this threat. In order to allow firewalls to verify that 3068 a legitimate end host transmitted the data traffic data origin 3069 authentication is required. This is, however, outside the scope 3070 of this document. Hence, there are no security requirements 3071 imposed by this section which will be addressed by the NATFW NSLP. 3073 7.2.8 Data traffic injection 3075 In some environments, such as enterprise networks, it is still common 3076 to perform authorization for access to a service based on the source 3077 IP address of the service requestor. There is no doubt that this by 3078 itself represents a security weakness.Hence by spoofing a connection, 3079 an attacker is able to reach the target machines, using the existing 3080 firewall rules. 3082 The adversary is able to inject its own data traffic in conformance 3083 with the firewall policies simultaneously along with the genuine DS. 3085 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 3086 non-cryptographic packet filters no security requirement needs to 3087 be created for the NAT/FW NSLP. Techniques such as ingress 3088 filtering (described below) and data origin authentication (such 3089 as provided with IPsec based VPNs) can help mitigate this threat. 3090 This issue is, however, outside the scope of this document. 3092 Ingress Filtering: Consider the scenario shown in Figure 49. In this 3093 scenario the DS is behind a router (R1) and a malicious node (M) is 3094 behind another router (R2). The DS communicates with the DR through 3095 a firewall (FW). The DS initiates NSIS signaling and installs 3096 firewall policies at FW. But the malicious node is also able to send 3097 data traffic using DS's source address. If R2 implements ingress 3098 filtering, these spoofed packets will be blocked. But this ingress 3099 filtering may not work in all scenarios. If both the DS and the 3100 malicious node are behind the same router, then the ingress filter 3101 will not be able to detect the spoofed packets as both the DS and the 3102 malicious node are in the same address range. 3104 +-----------------------------------+ 3105 | +------------------+ | 3106 | | +-------+ +---+---+ | 3107 | | | DS +>--+ R1 +->+ | 3108 | | | | | | | | 3109 | | +-------+ +---+---+ | | 3110 | | | | | 3111 | +------------------+ | +---+---+ +-------+ 3112 | | | | | | 3113 | +---+ FW +-->--| DR | 3114 | +------------------+ ****| |*****| | 3115 | | | * +---+---+ +-------+ 3116 | | +-------+ +---+---+ * | 3117 | | | M | | R2 | * | 3118 | | | |***| |*** | 3119 | | +-------+ +---+---+ | 3120 | +------------------+ | 3121 +-----------------------------------+ 3123 ---->---- = genuine data traffic 3124 ********* = spoofed data traffic 3126 Figure 49: Ingress filtering 3128 7.2.9 Eavesdropping and traffic analysis 3130 By collecting NSLP messages, an adversary is able to learn policy 3131 rules for packet filters and knows which ports are open. It can use 3132 this to inject its own data traffic due to the IP spoofing capability 3133 as already mentioned in Section 7.2.8. 3135 An adversary could learn authorization tokens included in CREATE 3136 messages and use them to launch replay-attacks or to create a session 3137 with its own address as source address. (cut-and-paste attack) 3139 As shown in Section 4.3 of [23] one possible solution for the session 3140 ownership problem is confidentiality protection of signaling messages 3142 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 3143 mandate the usage of confidentiality protection since an adversary 3144 can also eavesdrop on data traffic. In the context of a 3145 particular security solutions (e.g., authorization tokens) it 3146 might be necessary to offer confidentiality protection. 3147 Confidentiality protection also needs to be offered to the refresh 3148 period. 3150 7.3 Security Framework for the NAT/Firewall NSLP 3152 Based on the identified threats a list of security requirements has 3153 been created. 3155 7.3.1 Security Protection between neighboring NATFW NSLP Nodes 3157 Based on the analyzed threats it is necessary to provide, between 3158 neighboring NATFW NSLP nodes, the following mechanism: provide 3159 o data origin authentication 3160 o replay protection 3161 o integrity protection and 3162 o optionally confidentiality protection 3164 To consider the aspect of authentication and key exchange the 3165 security mechanisms provided in [1] between neighboring nodes MUST be 3166 enabled when sending NATFW signaling messages. The proposed security 3167 mechanisms at GIMPS provide support for authentication and key 3168 exchange in addition to denial of service protection. Depending on 3169 the chosen protocol, support for flexible authentication protocols 3170 could be provided. The mandatory support for security, demands the 3171 usage of C-MODE for the delivery of data packets and the usage of 3172 D-MODE only to discover the next NATFW NSLP aware node along the 3173 path. 3175 7.3.2 Security Protection between non-neighboring NATFW NSLP Nodes 3177 Based on the security threats and the listed requirements it was 3178 noted that some scenarios also demand authentication and 3179 authorization of a NATFW signaling entity (including the initiator) 3180 towards a non-neighboring node. This mechanism mainly demands entity 3181 authentication. Additionally, security protection of certain 3182 payloads MAY be required between non-neighboring signaling entities 3183 and the Cryptographic Message Syntax (CMS) [17] SHOULD be used. CMS 3184 can be used 3185 o This might be, for example, useful to authenticate and authorize a 3186 user towards a middlebox and vice versa. 3187 o If objects have to be protected between certain non-neighboring 3188 NATFW NSLP nodes. 3190 Details about the identifiers, replay protection and the usage of a 3191 dynamic key management with the help of CMS is for further study. In 3192 some scenarios it is also required to use authorization token. Their 3193 purpose is to associate two different signalling protocols (e.g., SIP 3194 and NSIS) and their authorization decision. These tokens are 3195 obtained by non-NSIS protocols, such as SIP or as part of network 3196 access authentication. When a NAT or Firewall along the path 3197 receives the token it might be verified locally or passed to the AAA 3198 infrastructure. 3200 Examples of authorization tokens or assertions can be found in RFC 3201 3520 [29] and RFC 3521 [30]. More recent work on authorization token 3202 alike mechanisms is Security Assertion Markup Language (SAML). For 3203 details about SAML see [31], [32] and [33]. Figure 50 shows an 3204 example of this protocol interaction. An authorization token is 3205 provided by the SIP proxy, which acts as the assertion generating 3206 entity and gets delivered to the end host with proper authentication 3207 and authorization. When the NATFW signalling message is transmitted 3208 towards the network, the authorization token is attached to the 3209 signalling messages to refer to the previous authorization decision. 3210 The assertion verifying entity needs to process the token or it might 3211 be necessary to interact with the assertion granting entity using 3212 HTTP (or other protocols). As a result of a successful authorization 3213 by a NATFW NSLP node, the requested action is executed and later a 3214 RESPONSE message is generated. 3216 +----------------+ Trust Relationship +----------------+ 3217 | +------------+ |<.......................>| +------------+ | 3218 | | Protocol | | | | Assertion | | 3219 | | requesting | | HTTP, SIP Request | | Granting | | 3220 | | authz | |------------------------>| | Entity | | 3221 | | assertions | |<------------------------| +------------+ | 3222 | +------------+ | Artifact/Assertion | Entity Cecil | 3223 | ^ | +----------------+ 3224 | | | ^ ^| 3225 | | | . || HTTP, 3226 | | | Trust . || other 3227 | API Access | Relationship. || protocols 3228 | | | . || 3229 | | | . || 3230 | | | v |v 3231 | v | +----------------+ 3232 | +------------+ | | +------------+ | 3233 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3234 | | using authz| | Assertion/Artifact | | Verifying | | 3235 | | assertion | | ----------------------- | | Entity | | 3236 | +------------+ | | +------------+ | 3237 | Entity Alice | <---------------------- | Entity Bob | 3238 +----------------+ RESPONSE +----------------+ 3240 Figure 50: Authorization Token Usage 3242 Threats against the usage of authorization tokens have been mentioned 3243 in [6] and also in Section 7.2. Hence, it is required to provide 3244 confidentiality protection to avoid allowing an eavesdropper to learn 3245 the token and to use it in another session (replay attack). The 3246 token itself also needs to be protected against tempering. 3248 7.3.3 End-to-End Security 3250 As part of the threat analysis we concluded that end-to-end security 3251 is not required and, if used, would be difficult to deploy. 3252 Furthermore, it might be difficult to use the suitable identifiers 3253 and to establish the necessary infrastructure for this propose. 3255 The only reasonable end-to-end security protection needed within NSIS 3256 seems to be a binding between an NSIS signaling session and 3257 application layer session. This aspect is, however, for further 3258 study. 3260 In order to solicit feedback from the IETF community on some hard 3261 security problems for path-coupled NATFW signaling a more detailed 3262 description in [20] is available. 3264 8. Open Issues 3266 The NATFW NSLP has a series of related documents discussing several 3267 other aspects of path-coupled NATFW signaling, including security 3268 [20], migration (i.e., traversal of nsis unaware NATs) [13], 3269 intra-realm signaling [14], and inter-working with SIP [15]. 3270 Summaries of the outcomes from these documents may be added, 3271 depending on WG feedback, to a later version of this draft. 3273 A more detailed list of open issue can be found at: 3274 https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/index 3276 It is intended to add an overview figure for all NATFW NSLP building 3277 blocks into the next version of this memo. Figure 51 sketches the 3278 overview 3279 +------------------+ 3280 |Security Policies | 3281 | Server | 3282 +--------^---------+ 3283 | 3284 +--------------------------------|----------------------+ 3285 | +---------+ +-----------V----+ +-------+| 3286 | |Firewall |<-----> | |<------>| NAT || 3287 | |Engine | | Security policy| | Engine|| 3288 | +----^----+ | Table/Cache | +-^-----+| 3289 | | | ^ | | | 3290 | | +---- --------|--+ | | 3291 | +--|---------------------------|-------------|--+ | 3292 | | V NATFW NSLP V V | | 3293 | | | | 3294 | +-----------------------------------------------+ | 3295 | +--------------------------------------------------+| 3296 | | GIMPS || 3297 | | || 3298 | +--------------------------------------------------+| 3299 | +---------+ +-------+ +------+ +-------+ +------+| 3300 | | TCP | | UDP | | DCCP | | SCTP | | ICMP || 3301 | +---------+ +-------+ +------+ +-------+ +------+| 3302 | +-----------------------------+ +--------------------| 3303 | | IPv4 | | IPv6 | 3304 | +-----------------------------+ +--------------------| 3305 +-------------------------------------------------------+ 3307 Figure 51: NATFW NSLP Building Blocks 3309 9. Contributors 3311 We would like to thank the following individuals for their 3312 contributions to this document: 3313 o Marcus Brunner and Henning Schulzrinne for work on work on IETF 3314 drafts which lead us to start with this document. 3315 o Miquel Martin for his help on the initial version of this 3316 document. 3317 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3318 NAT/Firewall Threats draft. 3319 o Elywn Davies for his help to make this document more readable. 3321 10. References 3323 10.1 Normative References 3325 [1] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for 3326 Signaling", Internet-Draft draft-ietf-nsis-ntlp-04, October 3327 2004. 3329 10.2 Informative References 3331 [2] Hancock, R., "Next Steps in Signaling: Framework", 3332 Internet-Draft draft-ietf-nsis-fw-07, December 2004. 3334 [3] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 3335 April 2004. 3337 [4] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 3338 Quality-of-Service signaling", 3339 Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004. 3341 [5] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 3342 Rayhan, "Middlebox communication architecture and framework", 3343 RFC 3303, August 2002. 3345 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 3346 Internet-Draft draft-ietf-nsis-threats-06, October 2004. 3348 [7] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 3349 (NAT) Terminology and Considerations", RFC 2663, August 1999. 3351 [8] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 3352 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 3354 [9] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 3355 RFC 3234, February 2002. 3357 [10] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, 3358 "DNS extensions to Network Address Translators (DNS_ALG)", 3359 RFC 2694, September 1999. 3361 [11] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 3362 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3363 Specification", RFC 2205, September 1997. 3365 [12] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 3366 Herzog, S. and R. Hess, "Identity Representation for RSVP", 3367 RFC 3182, October 2001. 3369 [13] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 3370 Tschofenig, "NAT/Firewall NSLP Migration Considerations", 3371 Internet-Draft draft-aoun-nsis-nslp-natfw-migration-02, July 3372 2004. 3374 [14] Aoun, C., "NATFirewall NSLP Intra-realm considerations", 3375 Internet-Draft draft-aoun-nsis-nslp-natfw-intrarealm-01, July 3376 2004. 3378 [15] Martin, M., "SIP NSIS Interactions for NAT/Firewall Traversal", 3379 Internet-Draft draft-martin-nsis-nslp-natfw-sip-01, July 2004. 3381 [16] Tschofenig, H., "Extended QoS Authorization for the QoS NSLP", 3382 Internet-Draft draft-tschofenig-nsis-qos-ext-authz-00, July 3383 2004. 3385 [17] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 3386 August 2002. 3388 [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3389 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 3390 Session Initiation Protocol", RFC 3261, June 2002. 3392 [19] Ohba, Y., "Problem Statement and Usage Scenarios for PANA", 3393 Internet-Draft draft-ietf-pana-usage-scenarios-06, April 2003. 3395 [20] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security 3396 Problems", 3397 DRAFT draft-tschofenig-nsis-natfw-security-problems-00.txt, 3398 July 2004. 3400 [21] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. 3401 Schulzrinne, "NSIS Authentication, Authorization and Accounting 3402 Issues", March 2003. 3404 [22] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 3405 Traversal of VPN Gateways", 3406 DRAFT draft-ietf-mobileip-vpn-problem-statement-req-02.txt, 3407 April 2003. 3409 [23] Tschofenig, H., "Security Implications of the Session 3410 Identifier", Internet-Draft draft-tschofenig-nsis-sid-00, June 3411 2003. 3413 [24] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 3414 Simple Traversal of User Datagram Protocol (UDP) Through 3415 Network Address Translators (NATs)", RFC 3489, March 2003. 3417 [25] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 3418 Lear, "Address Allocation for Private Internets", BCP 5, 3419 RFC 1918, February 1996. 3421 [26] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 3422 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 3423 Waldbusser, "Terminology for Policy-Based Management", 3424 RFC 3198, November 2001. 3426 [27] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 3427 Internet-Draft draft-rosenberg-midcom-turn-06, October 2004. 3429 [28] Tschofenig, H., "Using SAML for SIP", 3430 Internet-Draft draft-tschofenig-sip-saml-02, December 2004. 3432 [29] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session 3433 Authorization Policy Element", RFC 3520, April 2003. 3435 [30] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 3436 Set-up with Media Authorization", RFC 3521, April 2003. 3438 [31] Maler, E., Philpott, R. and P. Mishra, "Bindings and Profiles 3439 for the OASIS Security Assertion Markup Language (SAML) V1.1", 3440 September 2003. 3442 [32] Maler, E., Philpott, R. and P. Mishra, "Assertions and Protocol 3443 for the OASIS Security Assertion Markup Language (SAML) V1.1", 3444 September 2003. 3446 [33] Maler, E. and J. Hughes, "Technical Overview of the OASIS 3447 Security Assertion Markup Language (SAML) V1.1", March 2004. 3449 Authors' Addresses 3451 Martin Stiemerling 3452 Network Laboratories, NEC Europe Ltd. 3453 Kurfuersten-Anlage 36 3454 Heidelberg 69115 3455 Germany 3457 Phone: +49 (0) 6221 905 11 13 3458 Email: stiemerling@netlab.nec.de 3459 URI: http://www.stiemerling.org 3460 Hannes Tschofenig 3461 Siemens AG 3462 Otto-Hahn-Ring 6 3463 Munich 81739 3464 Germany 3466 Phone: 3467 Email: Hannes.Tschofenig@siemens.com 3468 URI: http://www.tschofenig.com 3470 Cedric Aoun 3471 Nortel/ENST Paris 3472 France 3474 Email: cedric.aoun@nortel.com 3476 Appendix A. Problems and Challenges 3478 This section describes a number of problems that have to be addressed 3479 for NSIS NAT/Firewall. Issues presented here are subject to further 3480 discussions. These issues might be also of relevance to other NSLP 3481 protocols. 3483 A.1 Missing Network-to-Network Trust Relationship 3485 Peer-to-peer trust relationship, as shown in Figure 33, is a very 3486 convenient assumption that allows simplified signaling message 3487 processing. However, it might not always be applicable, especially 3488 between two arbitrary access networks (over a core network where 3489 signaling messages are not interpreted). Possibly peer-to-peer trust 3490 relationship does not exist because of the large number of networks 3491 and the unwillingness of administrators to have other network 3492 operators to create holes in their Firewalls without proper 3493 authorization. 3495 +----------------------+ +--------------------------+ 3496 | | | | 3497 | Network A | | Network B | 3498 | | | | 3499 | +---------+ Missing +---------+ | 3500 | +-///-+ Middle- | Trust | Middle- +-///-+ | 3501 | | | box 1 | Relation- | box 2 | | | 3502 | | +---------+ ship +---------+ | | 3503 | | | or | | | 3504 | | | Authorization| | | 3505 | | | | | | 3506 | | Trust | | Trust | | 3507 | | Relationship | | Relationship | | 3508 | | | | | | 3509 | | | | | | 3510 | | | | | | 3511 | +--+---+ | | +--+---+ | 3512 | | Host | | | | Host | | 3513 | | A | | | | B | | 3514 | +------+ | | +------+ | 3515 +----------------------+ +--------------------------+ 3517 Figure 52: Missing Network-to-Network Trust Relationship 3519 Figure 52 illustrates a problem whereby an external node is not 3520 allowed to manipulate (create, delete, query, etc.) packet filters at 3521 a Firewall. Opening pinholes is only allowed for internal nodes or 3522 with a certain authorization permission. Hence the solution 3523 alternatives in Section 3.3.2 focus on establishing the necessary 3524 trust with cooperation of internal nodes. 3526 A.2 Relationship with routing 3528 The data path is following the "normal" routes. The NAT/FW devices 3529 along the data path are those providing the service. In this case 3530 the service is something like "open a pinhole" or even more general 3531 "allow for connectivity between two communication partners". The 3532 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 3533 does not need to determine what middleboxes or in what order the data 3534 flow will go through. 3536 Creating NAT bindings modifies the path of data packets between two 3537 end points. Without NATs involved, packets flow from endhost to 3538 endhost following the path given by the routing. With NATs involved, 3539 this end-to-end flow is not directly possible, because of separated 3540 address realms. Thus, data packets flow towards the external IP 3541 address at a NAT (external IP address may be a public IP address). 3542 Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with 3543 routing - instead they only follow the path of the data packets. 3545 A.3 Affected Parts of the Network 3547 NATs and Firewalls are usually located at the edge of the network, 3548 whereby other signaling applications affect all nodes along the path. 3549 One typical example is QoS signaling where all networks along the 3550 path must provide QoS in order to achieve true end-to-end QoS. In 3551 the NAT/Firewall case, only some of the domains/nodes are affected 3552 (typically access networks), whereas most parts of the networks and 3553 nodes are unaffected (e.g., the core network). 3555 This fact raises some questions. Should an NSIS NTLP node intercept 3556 every signaling message independently of the upper layer signaling 3557 application or should it be possible to make the discovery procedure 3558 more intelligent to skip nodes. These questions are also related to 3559 the question whether NSIS NAT/FW should be combined with other NSIS 3560 signaling applications. 3562 A.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls 3564 Backward compatibility is a key for NSIS deployments, as such the 3565 NSIS protocol suite should be sufficiently robust to allow traversal 3566 of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ). 3568 NSIS NATFW NSLP's backward compatibility issues are different than 3569 the NSIS QoS NSLP backward compatibility issues, where an NSIS 3570 unaware QoS gate will simply forward the QoS NSLP message. An NSIS 3571 unaware Firewall rejects NSIS messages, since Firewalls typically 3572 implement the policy "default to deny". 3574 The NSIS backward compatibility support on none NSIS aware Firewall 3575 would typically consist of configuring a static policy rule that 3576 allows the forwarding of the NSIS protocol messages (either protocol 3577 type if raw transport mode is used or transport port number in case a 3578 transport protocol is used). 3580 For NATs backward compatibility is more problematic since signaling 3581 messages are forwarded (at least in one direction), but with a 3582 changed IP address and changed port numbers. The content of the NSIS 3583 signaling message is, however, unchanged. This can lead to 3584 unexpected results, both due to embedded unchanged local scoped 3585 addresses and none NSIS aware Firewalls configured with specific 3586 policy rules allowing forwarding of the NSIS protocol (case of 3587 transport protocols are used for the NTLP). NSIS unaware NATs must 3588 be detected to maintain a well-known deterministic mode of operation 3589 for all the involved NSIS entities. Such a "legacy" NAT detection 3590 procedure can be done during the NSIS discover procedure itself. 3592 Based on experience it was discovered that routers unaware of the 3593 Router Alert IP option [RFC 2113] discarded packets, this is 3594 certainly a problem for NSIS signaling. 3596 A.5 Authentication and Authorization 3598 For both types of middleboxes, Firewall and NAT security is a strong 3599 requirement. Authentication and authorization means must be 3600 provided. 3602 For NATFW signaling applications it is partially not possible to do 3603 authentication and authorization based on IP addresses. Since NATs 3604 change IP addresses, such an address based authentication and 3605 authorization scheme would fail. 3607 A.6 Directional Properties 3609 There two directional properties that need to be addressed by the 3610 NATFW NSLP: 3611 o Directionality of the data 3612 o Directionality of NSLP signaling 3614 Both properties are relevant to NATFW NSLP aware NATs and Firewalls. 3616 With regards to NSLP signaling directionality: As stated in the 3617 previous sections, the authentication and authorization of NSLP 3618 signaling messages received from hosts within the same trust domain 3619 (typically from hosts located within the security perimeter delimited 3620 by Firewalls) is normally simpler than received messages sent by 3621 hosts located in different trust domains. 3623 The way NSIS signaling messages enters the NSIS entity of a Firewall 3624 (see Figure 2) might be important, because different policies might 3625 apply for authentication and admission control. 3627 Hosts deployed within the secured network perimeter delimited by a 3628 Firewall, are protected from hosts deployed outside the secured 3629 network perimeter, hence by nature the Firewall has more restrictions 3630 on flows triggered from hosts deployed outside the security 3631 perimeter. 3633 A.7 Addressing 3635 A more general problem of NATs is the addressing of the end-point. 3636 NSIS signaling message have to be addressed to the other end host to 3637 follow data packets subsequently sent. Therefore, a public IP 3638 address of the receiver has to be known prior to sending an NSIS 3639 message. When NSIS signaling messages contain IP addresses of the 3640 sender and the receiver in the signaling message payloads, then an 3641 NSIS entity must modify them. This is one of the cases, where a NSIS 3642 aware NATs is also helpful for other types of signaling applications 3643 e.g., QoS signaling. 3645 A.8 NTLP/NSLP NAT Support 3647 It must be possible for NSIS NATs along the path to change NTLP 3648 and/or NSLP message payloads, which carry IP address and port 3649 information. This functionality includes the support of providing 3650 mid-session and mid-path modification of these payloads. As a 3651 consequence these payloads must not be reordered, integrity protected 3652 and/or encrypted in a non peer-to-peer fashion (e.g., end-to-middle, 3653 end-to-end protection). Ideally these mutable payloads must be 3654 marked (e.g., a protected flag) to assist NATs in their effort of 3655 adjusting these payloads. 3657 A.9 Combining Middlebox and QoS signaling 3659 In many cases, middlebox and QoS signaling has to be combined at 3660 least logically. Hence, it was suggested to combine them into a 3661 single signaling message or to tie them together with the help of 3662 some sort of data connection identifier, later on referred as Session 3663 ID. This, however, has some disadvantages such as: 3665 - NAT/FW NSLP signaling affects a much small number of NSIS nodes 3666 along the path (for example compared to the QoS signaling). 3668 - NAT/FW signaling might show different signaling patterns (e.g., 3669 required end-to-middle communication). 3671 - The refresh interval is likely to be different. 3673 - The number of error cases increase as different signaling 3674 applications are combined into a single message. The combination of 3675 error cases has to be considered. 3677 A.10 Inability to know the scenario 3679 In Section 2 a number of different scenarios are presented. Data 3680 receiver and sender may be located behind zero, one, or more 3681 Firewalls and NATs. Depending on the scenario, different signaling 3682 approaches have to be taken. For instance, data receiver with no 3683 NAT and Firewall can receive any sort of data and signaling without 3684 any further action. Data receivers behind a NAT must first obtain a 3685 public IP address before any signaling can happen. The scenario 3686 might even change over time with moving networks, ad-hoc networks or 3687 with mobility. 3689 NSIS signaling must assume the worst case and cannot put 3690 responsibility to the user to know which scenario is currently 3691 applicable. As a result, it might be necessary to perform a 3692 "discovery" periodically such that the NSIS entity at the end host 3693 has enough information to decide which scenario is currently 3694 applicable. This additional messaging, which might not be necessary 3695 in all cases, requires additional performance, bandwidth and adds 3696 complexity. Additional, information by the user can provide 3697 information to assist this "discovery" process, but cannot replace 3698 it. 3700 Appendix B. Object ID allocation for testing 3702 TBD. 3704 Appendix C. Acknowledgments 3706 We would like to acknowledge: Vishal Sankhla and Joao Girao for their 3707 input to this draft; and Reinaldo Penno for his comments on the 3708 initial version of the document. Furthermore, we would like thank 3709 Elwyn Davies for his valuable help and input. 3711 Intellectual Property Statement 3713 The IETF takes no position regarding the validity or scope of any 3714 Intellectual Property Rights or other rights that might be claimed to 3715 pertain to the implementation or use of the technology described in 3716 this document or the extent to which any license under such rights 3717 might or might not be available; nor does it represent that it has 3718 made any independent effort to identify any such rights. Information 3719 on the procedures with respect to rights in RFC documents can be 3720 found in BCP 78 and BCP 79. 3722 Copies of IPR disclosures made to the IETF Secretariat and any 3723 assurances of licenses to be made available, or the result of an 3724 attempt made to obtain a general license or permission for the use of 3725 such proprietary rights by implementers or users of this 3726 specification can be obtained from the IETF on-line IPR repository at 3727 http://www.ietf.org/ipr. 3729 The IETF invites any interested party to bring to its attention any 3730 copyrights, patents or patent applications, or other proprietary 3731 rights that may cover technology that may be required to implement 3732 this standard. Please address the information to the IETF at 3733 ietf-ipr@ietf.org. 3735 Disclaimer of Validity 3737 This document and the information contained herein are provided on an 3738 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3739 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3740 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3741 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3742 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3745 Copyright Statement 3747 Copyright (C) The Internet Society (2005). This document is subject 3748 to the rights, licenses and restrictions contained in BCP 78, and 3749 except as set forth therein, the authors retain all their rights. 3751 Acknowledgment 3753 Funding for the RFC Editor function is currently provided by the 3754 Internet Society.