idnits 2.17.00 (12 Aug 2021) /tmp/idnits18812/draft-aoun-nsis-nslp-natfw-migration-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 821. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 837), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 19, 2004) is 6508 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) == Unused Reference: 'RFC3304' is defined on line 758, but no explicit reference was found in the text == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. 'NSISNATFW') -- No information found for draft-draft-ietf-nsis-ntlp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NTLP' == Outdated reference: A later version (-02) exists of draft-fessi-nsis-natfw-threats-01 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-ipsec-nat-t-ike has been published as RFC 3947 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-01 == Outdated reference: draft-ietf-ipsec-udp-encaps has been published as RFC 3948 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group C. Aoun 2 Internet-Draft Nortel Networks 3 Expires: January 17, 2005 H. Tschofenig 4 Siemens 5 M. Stiemerling 6 NEC 7 July 19, 2004 9 NATFW NSLP Migration Considerations 10 draft-aoun-nsis-nslp-natfw-migration-02 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 17, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document discusses migration issues towards NSIS NAT/FW NSLP 44 enabled NATs and Firewalls. In particular traversal of NSIS unaware 45 NATs and NSIS proxy scenarios are addressed. This document will 46 serve as input to the NSIS NATFW NSLP document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Traversal of NSIS unaware NATs . . . . . . . . . . . . . . . . 5 55 3.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.3 Class 1 NAT Handling . . . . . . . . . . . . . . . . . . . 6 58 3.4 Class 2 NAT Handling . . . . . . . . . . . . . . . . . . . 6 59 3.5 Class 3 NAT Handling . . . . . . . . . . . . . . . . . . . 7 60 3.6 Class 4 NAT Handling . . . . . . . . . . . . . . . . . . . 9 61 3.7 Dealing with NSIS unaware NATs (Class 4 NAT Handling) . . 10 63 4. NSIS Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . 14 65 5. NSIS unaware Firewall Traversal . . . . . . . . . . . . . . . 17 67 6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . . . 18 69 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 73 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 79 11.2 Informative References . . . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 83 Intellectual Property and Copyright Statements . . . . . . . . 25 85 1. Introduction 87 This document discusses migration issues which are caused by the 88 incremental deployment of NSIS NAT/Firewall NSLP nodes. As such, it 89 is not only relevant for the NAT/FW NSLP but also for other NSLPs, 90 such as the QoS NSLP. 92 o The overall NSIS protocol suite (including the NAT/FW NSLP) is 93 impacted by NSIS unaware NATs and Firewalls. This document covers 94 the impacts as well as some suggestions to ease the deployments of 95 the NSIS protocol suite until the installed base of NATs and 96 Firewalls migrates to NSIS. Section 3 addresses this issue. 98 o The NAT/FW NSLP should allow an end host supporting NSIS to 99 operate properly without the need for supporting true end-to-end 100 NSIS signaling to its application correspondent. This is very 101 practical during the initial phases of the NSIS migration and is 102 applicable in simple network topologies. In the early phases of 103 the NSIS NAT/FW NSLP migration, this situation will occur quite 104 frequently, and hence this scenario must be supported. Section 4 105 is addresses this scenario. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 The terminology used in this document is defined in [NSISNATFW]. 115 3. Traversal of NSIS unaware NATs 117 3.1 Abstract 119 This section aims to describe different NAT handling classes in NSIS, 120 and the relationship between different solutions provided in various 121 NSIS documents. After a short introduction in Section 3.2, different 122 NAT classes are discussed in Section 3.2. Various NAT scenarios are 123 described in Section 3.3, in Section 3.4, in Section 3.5, and in 124 Section 3.6. Section 3.7 covers the details of addressing NSIS 125 unaware NATs. 127 3.2 Introduction 129 In the past, mainly two approaches have been used for establishing 130 NAT bindings: 132 Static configuration This type of NAT bindings is typically used to 133 allow inbound initiated communications. Ephemeral binds are often 134 not established or required. 136 Dynamic configuration: Dynamic NAT binding creation can be 137 categorized into one of the following three categories: 139 * Implicit creation by outbound initiated communications. In 140 this case, the translated address and port are selected from a 141 configured address and port pool. 143 * Explicit creation by an Application Layer Gateway (ALG) either 144 via an API call (if the NAT and the ALG are co-located) or 145 otherwise via a separate protocol. 147 * Separate signaling protocols which request the creation of a 148 NAT binding. 150 An alternative classification can be done by considering the trigger 151 for the creation of a NAT binding. In many cases an outbound data 152 packet itself is used to cause the allocation of a NAT binding. 153 Alternatively, a signaling protocol can be used to establish the same 154 goal by directly addressing the NAT itself. The Midcom and the NSIS 155 working group are trying to develop protocols of the latter category. 157 To address the broad scope of NAT handling, this document tries to 158 describe the design considerations for the work in the NSIS WG. An 159 important impact for the design is caused by the introduction of the 160 two layer architecture, by intermediaries, and by NSIS unaware NATS. 162 Four classes of NAT functionality can be distinguished in NSIS. 164 These are described in the following sub-sections. 166 3.3 Class 1 NAT Handling 168 We refer to Class 1 NAT handling if NATs or Firewalls implement the 169 NAT/Firewall NSLP. 171 Router 2+ 172 Host A NAT Firewall 173 +--------+ +--------+ +--------+ 174 | NE | | NE | | NE | 175 |+------+| |+------+| |+------+| 176 ||QoS+ || ||QoS+ || ||QoS+ || 177 ||NAT-FW|| ||NAT-FW|| ||NAT-FW|| 178 ||NSLP || ||NSLP || ||NSLP || 179 |+------+| |+------+| |+------+| 180 | || | | || | | || | 181 |+------+| |+------+| |+------+| 182 ==||NTLP ||=========||NTLP ||=======||NTLP ||====> 183 |+------+| |+------+| |+------+| 184 +--------+ +--------+ +--------+ 186 Figure 1: Class 1 NAT Handling 188 The NSIS working group decided to work on two NSLP client layer 189 applications: QoS and NAT/Firewall NSLP. The NAT/Firewall NSLP 190 assumes that a NAT or a Firewall implements the signaling application 191 (i.e., NTLP and NAT/Firewall NSLP implementation). [NSISNATFW] 192 describes the signaling mechanisms in more detail. 194 3.4 Class 2 NAT Handling 196 In Figure 2, a number of QoS NSLP nodes are shown, with one of the 197 NSIS nodes being a NAT device. In this scenario, we assume that the 198 NAT device does not contain a NAT/Firewall NSLP implementation. 199 Incremental deployment can lead to such a configuration. A question 200 raised by this scenario is whether the NSIS implementation (the NTLP 201 for example) should offer a minimal NAT implementation which would 202 allow it to request a NAT binding to update the flow identifier. 204 Host A NAT Router 2 205 +--------+ +--------+ +--------+ 206 | NE | | NE | | NE | 207 |+------+| |+------+| |+------+| 208 ||QoS || ||QoS || ||QoS || 209 ||NSLP || ||NSLP || ||NSLP || 210 || || || || || || 211 |+------+| |+------+| |+------+| 212 | || | | || | | || | 213 |+------+| |+------+| |+------+| 214 ==||NTLP ||=========||NTLP ||=======||NTLP ||====> 215 |+------+| |+------+| |+------+| 216 +--------+ +--------+ +--------+ 218 Figure 2: Class 2 NAT Handling 220 There is some desire to allow an NSLP signaling message exchange 221 (e.g., QoS signaling) to work properly even in the presence of NAT. 222 In this scenario, no NAT/Firewall NSLP implementation is available at 223 the NAT, and the end host might not trigger an NAT/Firewall NSLP 224 exchange. For some cases, the signaling message contains sufficient 225 information to create a NAT binding based on the flow identifier in 226 the NTLP layer. If additional security mechanisms have to be 227 provided by the NAT/Firewall NSLP, then that approach will fail 228 since, for example, a QoS NSLP will not be able to provide those 229 mechanisms. 231 Another question of interest is whether it is possible to combine a 232 NAT/Firewall signaling message with a QoS signaling message into a 233 single protocol message (or to at least combine them using a shared 234 session identifier). Error handling might be more complex because in 235 addition to dealing with errors of the individual signaling 236 applications, it will be necessary to deal with errors resulting from 237 the combined applications. 239 3.5 Class 3 NAT Handling 241 We refer to Class 3 NAT handling if there is a NAT along the path 242 which intercepts all NSIS signaling messages, but which does not 243 contain the desired NSLP implementation. In Figure 3a, Host A 244 signals for a QoS NSLP, but NAT 2 only offers an NTLP implementation. 245 This NTLP could modify a flow identifier, if it is not integrity 246 protected or encrypted. NAT 1 was already considered in Section 3.4. 248 Host A NAT 1 Router 2 249 +--------+ +--------+ +--------+ 250 | NE | | NE | | NE | 251 |+------+| |+------+| |+------+| 252 ||QoS || ||QoS || ||QoS || 253 ||NSLP || ||NSLP || NAT 2 ||NSLP || 254 || || || || +--------+ || || 255 |+------+| |+------+| | NE | |+------+| 256 | || | | || | | | | || | 257 |+------+| |+------+| |+------+| |+------+| 258 ==||NTLP ||===||NTLP ||===||NTLP ||===||NTLP ||==> 259 |+------+| |+------+| |+------+| |+------+| 260 +--------+ +--------+ +--------+ +--------+ 262 Figure 3: Class 3a NAT Handling 264 Intermediaries make NSIS signaling message handling more complex. To 265 avoid these problems it is possible to build functionality into the 266 NTLP to make intermediate nodes to be invisible for NSIS signaling. 268 As a solution, it is suggested to make the discovery message (C-Mode) 269 or the D-Mode in general cleverer to "discover" only those nodes 270 which implement the desired NSLP functionality. (This was already 271 discussed in the past.) 273 This requires indicating which NSLP functionality the signaling 274 message is looking for along the path. A discovery message might, 275 for example, want to know the next NSIS node along the path which 276 supports a QoS NSLP implementation. It is for further study, whether 277 a more fine-granular discovery is required (e.g., a QoS NSLP node 278 which supports a certain QoS model). IANA registration would be 279 required for the NSLPs as well as for QoS models. 281 Efficiency is an important issue here. An NSIS node which does not 282 implement a certain NSLP application must be able to quickly 283 distinguish whether it is interested in a message or not. Whether to 284 encode the necessary information into a router alert option, into UDP 285 port numbers, the Time-to-Live field, or into an IP protocol number 286 was discussed in the past. 288 As a minor variation of the scenario described in Figure 3, it is 289 possible that the end host does not contain a NAT/Firewall 290 implementation, but the network itself provides a NAT/Firewall 291 solution as shown in Figure 4. 293 +----------------------------------------+ 294 | Edge | 295 Host A | Router 1 Router 2 NAT/FW | 296 +--------+ +--------+ +--------+ +--------+ 297 | NE | | NE | | NE | | NE | 298 |+------+| |+------+| |+------+| |+------+| 299 ||QoS || ||QoS+ || ||QoS+ || ||[QoS+]|| 300 ||NSLP || ||NAT-FW|| ||NSLP || ||NAT-FW|| 301 || || ||NSLP || || || ||NSLP || 302 |+------+| |+------+| |+------+| |+------+| 303 | || | | || | | || | | || | 304 |+------+| |+------+| |+------+| |+------+| 305 =||NTLP ||==||NTLP ||======||NTLP ||======||NTLP ||=> 306 |+------+| |+------+| |+------+| |+------+| 307 +--------+ +--------+ +--------+ +--------+ 308 | Administrative Domain | 309 +----------------------------------------+ 311 Figure 4: Class 3b NAT Handling 313 The main advantage of the approach described in Figure 4 is the 314 incremental deployment meaning that an administrative domain equips 315 its NATs/Firewalls with NAT/Firewall NSLP implementations even though 316 the end host might not support it. Note that the NAT/FW device might 317 not offer the QoS NSLP implementation. The NAT/Firewall NSLP enabled 318 Edge Router 1 might create a NAT binding or open a firewall pinhole 319 based on an incoming QoS signaling message (even though the end host 320 is not NAT/Firewall NSLP aware). It is also able to create NAT/ 321 Bindings at the NAT/FW device independently of a signaling exchange. 322 Such a signaling exchange might be necessary if the NAT/Firewall is 323 not equipped with the NSLP application signaled by the end host - in 324 our example this would mean that the NAT/FW would not run a QoS NSLP 325 implementation. 327 3.6 Class 4 NAT Handling 329 We refer to a scenario as Class 4 NAT handling scenario if a NAT is 330 within the path which does not understand NSIS at all. 332 Host A Router 2 333 +--------+ +--------+ 334 | NE | | NE | 335 |+------+| |+------+| 336 ||QoS || ||QoS || 337 ||NSLP || ||NSLP || 338 || || NAT || || 339 |+------+| +--------+ |+------+| 340 | || | |+------+| | || | 341 |+------+| ||Plain || |+------+| 342 ==||NTLP ||=========||NAT ||=======||NTLP ||==== 343 |+------+| |+------+| |+------+| 344 +--------+ +--------+ +--------+ 346 Figure 5: Class 4 NAT Handling 348 To allow NSIS signaling messages to traverse an NSIS unaware NAT, it 349 is required that they are sent in non-raw IP mode. This is necessary 350 to allow NAPT to perform modification of the transport protocol port 351 numbers. For an IPsec protected signaling message, UDP encapsulation 352 MUST be used. If IKE or IKEv2 [I-D.ietf-ipsec-ikev2] is used, then 353 NAT traversal functionality is necessary to dynamically detect the 354 presence of a NAT. The relevant work in this area can be found in 355 [I-D.ietf-ipsec-nat-t-ike], in [I-D.ietf-ipsec-ikev2] and in 356 [IPSECNAT]. 358 3.7 Dealing with NSIS unaware NATs (Class 4 NAT Handling) 360 This section describes NSIS signaling in a Class 4 NAT handling 361 scenario. It is in general not possible to reuse the NAT binding 362 created with the NSIS signaling also for the data traffic. An 363 exception is a NAT which maps the source IP address of all outgoing 364 IP packets to the same external public IP address (without modifying 365 the port number). In order to update the flow identifier, the NSIS 366 NSLP daemon has to interact with a NAT in a non-NSIS fashion (such as 367 STUN [STUN] or a MIDCOM protocol), or to reuse an "NSIS-STUN-alike" 368 mechanism. We will describe the "NSIS-STUN-alike" mechanism in this 369 section. 371 In many cases it might be sufficient to detect the presence of an 372 NSIS unaware NAT. This might be useful for those cases where the 373 NSLP would break in such cases. The NSIS unaware NAT discovery 374 functionality could be a built-in feature of the NTLP [NTLP], 375 allowing its usage on any NE regardless of the supported NSLPs. In 376 order to discover a NAT the following procedure can be applied to 377 D-mode messages (which includes also discovery messages). 379 The initiator of the discovery message includes the source IP address 380 and the source port of the transmitted message into the signaling 381 message payload. 383 An NSIS unaware NAT then modifies the source IP address (and possibly 384 the source port) of the NSIS signaling message. This procedure 385 represents typical NAT handling. The responder of the discovery 386 message will notice the modification by comparing information in the 387 IP header with the content of the discovery message. If both are 388 equal then no NAT was present. If the responder sees a deviation, 389 then an NSIS unaware NAT was located along the path. The responder 390 returns the source IP address and port number as a payload in the 391 discovery reply message. Unfortunately, the information found does 392 not help to update the flow identifier for the data traffic. 394 Traversing an NSIS unaware NAT (from inside to outside) dynamically 395 creates a NAT binding. Please note that only a NAT binding for the 396 signaling traffic is created. More complexity is introduced by 397 creating NAT bindings for data traffic. It seems to be reasonable 398 that neighboring NSIS nodes control the NAT and also the Firewall (of 399 the same administrative domain) via MIDCOM protocols, such as SNMPv3. 400 The usage of SNMPv3 for this purpose is simple but requires the NSIS 401 unaware NAT to implement this protocol. 403 Another option is to include an "NSIS-STUN-alike" mechanism into NSIS 404 which has the property of an in-band signaling mechanism. Ideally 405 NSIS signaling messages should look like regular data traffic to 406 experience the same treatment as data traffic. The discovery 407 mechanisms is thereby an important part which we will investigate in 408 more detail. Discovery messages are addressed to the same IP address 409 as the data traffic. The source IP address can, however, be the 410 source IP address of the data traffic, or the source IP address of 411 the signaling message, in which case it would be equal to the IP 412 address of the NSIS node transmitting it. The source port can be 413 either equal to the source port number of the transmitted data 414 traffic, or to the source port of the transmitting NSIS daemon. 415 Setting the source port to the port number of the application traffic 416 makes it very difficult for the NSIS daemon to intercept the response 417 to a discovery message. Further investigations are required to 418 verify its practicability. But this step would be very important 419 since responses need to be addressed to the port number which was 420 modified by the NAT (see symmetric NATs). It is suggested to set the 421 destination port number to the port number of the data traffic 422 destination. The Router Alert Option will allow an NSIS node to 423 intercept the message and to distinguish it from a regular data 424 packet. But note that this is only true for D-mode messages. For 425 C-Mode messages, an additional problem is created if the transport 426 layer protocol of the data traffic does not match the transport 427 protocol of the signaling traffic. Furthermore, it seems to be very 428 difficult for an end host to distinguish the data traffic from the 429 signaling traffic. If we can assume that the discovery message 430 exchange is (for most parts) indistinguishable from data traffic, 431 then this exchange can be used by NSIS signaling messages and data 432 traffic to traverse an NSIS unaware NAT. This, however, additionally 433 assumes that only flows are signaled, rather than aggregates. 435 If no means of controling the NAT are available, then the STUN 436 protocol [STUN] can be used. The usage of STUN and other protocols 437 (such as TURN [I-D.rosenberg-midcom-turn]) should be investigated in 438 future versions of this document. 440 In Figure 6, we consider a scenario where an NSIS aware initiator 441 also hosts a STUN implementation. Note that more complex topologies 442 are possible but not investigated in detail in this section. 444 +---------------------------------------+ 445 | | +--------+ 446 | +----------+ | | STUN | 447 | |Apps | | | Server | 448 | +----------+ +---+| +--------+ 449 | | STUN | |NAT|| 450 | | CLIENT | | || 451 | |__________| +---+| 452 | |ANY_NSLP | | 453 | | NI/NR | | 454 | +----------+ | 455 | Host A | 456 +---------------------------------------+ 458 Figure 6: STUN usage for NSIS unaware NATs 460 Within Host A, shown in Figure 6, the NSIS API could invoke the 461 services of the STUN client upon determination that an NSIS unaware 462 NAT is on the path. NSLPs, such as a QoS NSLP, would use the STUN 463 returned global scoped address for the flow identifier of the NSIS 464 signaling message. If some NSLPs are between Host A and the NSIS 465 unaware NAT, then a wrong flow identifier would be communicated to 466 these devices. This might be problematic for a QoS NSLP and would 467 not really provide a solution. Without learning a globally routable 468 IP address via STUN, the correct flow identifier (i.e. the private 469 IP address) would be installed between Host A and the NSIS unaware 470 NAT, but a wrong flow identifier between the NAT and the destination 471 host, since the private IP address used as flow identifier is not 472 converted to a public IP address. 474 The consequences might be different if STUN is used by an entity 475 along the path and not the end host. Figure 4 shows such an example. 476 This impact needs to be studied in more detail in a future version of 477 this document. 479 4. NSIS Proxy Mode 481 When NSIS NAT/FW signaling will start to be deployed, it is quite 482 possible that an NI sends an NSIS message without having an NR to 483 respond to it. The NATFW NSLP should be able to handle this type of 484 deployments. NSIS NATFW NSLP signaling for a data receiver behind a 485 NAT already has just a local scope (the REA message is not forwarded 486 beyond the edge NAT, see [NSISNATFW]). This mechanism only works for 487 data receivers behind a NAT, but not for data receivers behind a 488 firewall. 490 Since the purpose of this section is to discuss how end to end 491 signaled messages are handled when no NRs are available on the 492 end-host, only Firewalls (the NFs) are discussed within the example 493 networks. 495 The local trust domain (from an NI perspective) has at least one NSIS 496 aware Firewall, there is no NR on the far end, nor an NSIS aware NAT 497 or Firewall. Goal of this exchange is to keep NSIS signaling local 498 within network A. The solution of this approach is similar to 499 [lrsvp], but the NSIS messages do not include any scoping 500 information. 502 Figure 7 shows this scenario graphically. 504 +-----------------------+ +--------------------+ 505 |+----------+ | | +----------+ 506 ||App client| | | |App client| 507 ||NI/NR | FW++ | ,---------. | +----------+ 508 |+----------+ ''''''' The net ---. Host B | 509 | Host A | `---------' | | 510 | | | | 511 | Network A | | Network B | 512 +-----------------------+ +--------------------+ 514 Figure 7: Implicit localized signaling 516 To terminate the NSIS signaling exchange within Network A, two 517 approaches are feasible: explicit and implicit scoping. With 518 explicit scoping, Host A has to indicate that the NSIS signaling 519 message should terminate locally. With implicit scoping, the NI 520 simply sends its firewall policy rule creation message. The message 521 traverses the first NF (its own firewall), but there is no NR to 522 respond back. As a consequence a timer will expire since no response 523 message is received. The last NF will respond back to the NI with a 524 notification that NSIS signaling had to terminate somewhere along the 525 path without reaching the NR. Using the network deployment shown in 526 Figure 7, the message exchange in Figure 8 takes place. 528 Host A Host B 529 NI FW++ Expected NR 530 | | | 531 |1-NSIS Init msg | | 532 |----------------> | | 533 | |2-NSIS Init msg | 534 | | +---------------> | 535 | | |NATFW NSLP ON | 536 | | | | 537 | | | | 538 | | | | 539 | | | Timeout | 540 3-NSIS Init msg Ack| V | 541 |No NR | | 542 |<.................| | 544 Figure 8: Detecting the last NSIS peer 546 Figure 9 provides the message sequences when more than one NSIS aware 547 NAT or Firewall is deployed within the same trust domain. Upon 548 determination of a previous NSIS hop, an NSIS aware node will notify 549 the previous NSIS hop of its existence to avoid launching the timer 550 that triggers sending of an NSIS message back to the NI. The current 551 NTLP message association establishment procedures supports this 552 behavior. The last NF on the path will launch the timer since no 553 valid downstream NSIS neighbor responded back. 555 Trust domain A Trust domain B 556 <..........................................> <--------> 557 Host A Host B 558 NI FW++ FW++ Expected NR 559 | | | | 560 | NSIS Init msg | | | 561 | ----------------> | NSIS Init msg | | 562 | | ---------------> | NSIS Init msg | 563 | | NATFW NSLP ON |---------------->| 564 | | | | with Token | 565 | | Valid . | NATFW NSLP ON | 566 | | NSIS Neighbor | | | 567 | |<-----------------| | | 568 | |----------------->| | Timeout | 569 | | Ack | | | 570 | | | | | 571 | | | | | 572 | | | | | 573 | | | V | 574 | | <................+ | 575 | | NSIS Init msg Ack| | 576 | NSIS Init msg Ack | No NR | | 577 | No NR | | | 578 | <.................| | | 580 Figure 9: Detecting the last NSIS peer (multiple FWs) 582 5. NSIS unaware Firewall Traversal 584 In case an NSIS unaware firewall is traversed by NSIS messages, NSIS 585 messages should be allowed to go through it, as well as the exchanged 586 data flows between the user applications. This is not necessarily an 587 obvious task to perform in case the NSIS messages cannot be 588 identified by the NSIS unaware firewall. The same applies to the 589 user application data flows. 591 NSIS message identification should be supported by existing 592 firewalls. 593 Currently firewalls support flow identification by using the 5 tuple 594 or a sub-set of it. The authors are still expecting feedback from 595 firewall vendors to see if we can assume that existing firewalls will 596 not drop packets including the Router Alert Option (RAO) [RFC2113]. 597 In case existing firewalls drop packets with the router alert option 598 set, then the RAO should not be the only element used to identify 599 packets to be dropped. 601 User application data flow identification should be deterministic at 602 a specific address and port range level. This means that the 603 application uses a combination of an address and specific transport 604 port range.This combination should be configured on the firewall. 606 In case a NAT is deployed on the path and it is NSIS-NATFW, the 607 assigned bind should be consistent with policy rules configured in 608 the NSIS unaware firewall. 610 Even though the deployed Firewall is not NSIS aware, the application 611 data would still be forwarded if existing interim solutions were 612 used, such as a mix of stateless policy rules and flow based states 613 with initial packets sent in the outbound direction (from inside a 614 trust domain to outside the trust domain). 616 6. NATFW NSLP NTLP requirements 618 In this section we list two requirements for the NTLP raised by this 619 document. 621 o When NSIS signaling is used in the presence of NSIS unware NATs, 622 then raw IP MUST NOT be used. Network address and port 623 translation requires transport layer identifiers as means to 624 direct inbound traffic to the right recipient. 626 o For the traveral of NSIS unaware NATs, UDP is more likely to be 627 supported than DCCP or SCTP. 629 o If IPsec is used to secure NSIS signaling messages, then UDP 630 encapsulation for IPsec protected packets (see [IPSECNAT]) MUST be 631 used to ensure that IPsec does not break. IKE with extensions or 632 IKEv2 is able to detect the presence of a NAT along the path. 634 7. Conclusion 636 To handle NAT devices properly it is necessary to address the 637 different NAT handling scenarios individually: 639 The impact of intermediaries causes complexity for signaling message 640 handling. It is therefore recommended to avoid Class 2 and Class 3 641 NAT handling scenarios by incorporating additional knowledge into the 642 discovery message. 644 Class 4 NAT handling requires some interaction with other protocols 645 such as MIDCOM or STUN. The ability to reuse the NTLP discovery 646 mechanisms to create NAT bindings for the signaling and the data 647 traffic is briefly outlined but requires more investigations. 649 To deal with firewalls it is also necessary to 651 o allow the NSIS signaling message to pass, and 653 o also to create pinholes for subsequent data traffic. 655 This is mainly an authorization problem and requires depends on the 656 environment where NSIS is used. 658 It is important to keep in mind to differentiate NAT bindings for the 659 signaling traffic and those for the data traffic. This separation is 660 necessary since the NSIS signaling message and the subsequent data 661 traffic are different in terms of the flow identifier observed by the 662 NAT. The same is true for firewall pinholes. 664 8. Security Considerations 666 This document discusses various security issues for NAT/Firewall 667 signaling in migration scenarios. 669 Two important security threats are worth being highlighted: 671 o The proxy mode of operation, described in Section 4, demands the 672 property that NSIS signaling messages terminate somewhere along 673 the path. This functionality should allow NSIS to capture 674 additional scenarios not envisioned by RSVP. As a consequence it 675 makes it very hard to allow end-to-end security mechanisms to be 676 applied. These end-to-end security mechanisms have been proposed 677 to enable delayed authorization by both end hosts, and to tie the 678 NSIS end-to-end signaling together with application layer 679 signaling. The same is true if NSIS signaling is triggered by a 680 node other than the end host. 682 o Providing mechanisms to traverse NSIS unaware NATs also has 683 security implications. The impact can be related to an NSIS 684 signaling message, or even to the data traffic (based on signaling 685 of the flow identifier). Section 3 provides the details of 686 traversal of NSIS unaware NATs. An adversary along the path (a 687 non-NSIS node) is able to redirect NSIS signaling to another NSIS 688 node to cause denial of service attacks. If an adversary is 689 additionally able to modify the flow identifier, then it is 690 possible to cause NSIS to create an arbitrary policy rule which 691 would allow the adversary to inject traffic from an arbitrary 692 location. Note that an adversary along the path is always able to 693 cause denial of service attacks by dropping or delaying signaling 694 messages. Furthermore, it is also able to inject data packets, 695 but only with a flow identifier chosen by the signaling initiator, 696 and possibly modified by an NSIS aware NAT along the path. 698 Further security considerations can be found in [NSISNATFW] and 699 [I-D.fessi-nsis-natfw-threats]. 701 9. Contributors 703 We would like to thank Marcus Brunner and Miquel Martin for their 704 contribution to this draft. 706 10. Acknowledgements 708 We would like to thank Joachim Kross for this comments to this draft. 710 11. References 712 11.1 Normative References 714 [NSISNATFW] 715 Stiemerling, M., Martin, M., Tschofenig, H. and C. Aoun, 716 "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 717 DRAFT draft-ietf-nsis-nslp-natfw-03.txt, July 2004. 719 [NTLP] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 720 Messaging Protocol for Signaling", 721 draft-draft-ietf-nsis-ntlp-00 (work in progress), May 722 2004. 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", March 1997. 727 11.2 Informative References 729 [I-D.fessi-nsis-natfw-threats] 730 Martin, A., Stiemerling, M., Thiruvengadam, S., 731 Tschofenig, H. and C. Aoun, "Security Threats for the 732 NATFW NSLP", DRAFT draft-fessi-nsis-natfw-threats-01.txt, 733 July 2004. 735 [I-D.ietf-ipsec-ikev2] 736 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 737 draft-ietf-ipsec-ikev2-14 (work in progress), May 2004, 738 . 740 [I-D.ietf-ipsec-nat-t-ike] 741 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 742 draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 743 2004, . 745 [I-D.rosenberg-midcom-turn] 746 Rosenberg, J., "Traversal Using Relay NAT (TURN)", 747 draft-rosenberg-midcom-turn-01 (work in progress), March 748 2003. 750 [IPSECNAT] 751 A. Huttunen et all, A., "UDP Encapsulation of IPsec 752 Packets", DRAFT draft-ietf-ipsec-udp-encaps-07.txt, Jan 753 2003. 755 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 756 1997. 758 [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore, 759 "Middlebox Communications (midcom) Protocol Requirements", 760 RFC 3304, August 2002. 762 [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, 763 "STUN - Simple Traversal of User Datagram Protocol (UDP) 764 Through Network Address Translators (NATs)", RFC 3489, 765 March 2003. 767 [lrsvp] Manner, J., "Localized RSVP", draft-manner-lrsvp-03 (work 768 in progress), January 2004. 770 Authors' Addresses 772 Cedric Aoun 773 Nortel Networks 775 France 777 EMail: cedric.aoun@nortelnetworks.com 779 Hannes Tschofenig 780 Siemens AG 781 Otto-Hahn-Ring 6 782 Munich 81739 783 Germany 785 Phone: 786 EMail: Hannes.Tschofenig@siemens.com 787 URI: 789 Martin Stiemerling 790 Network Laboratories, NEC Europe Ltd. 791 Kurfuersten-Anlage 36 792 Heidelberg 69115 793 Germany 795 Phone: +49 (0) 6221 905 11 13 796 EMail: stiemerling@ccrle.nec.de 797 URI: 799 Intellectual Property Statement 801 The IETF takes no position regarding the validity or scope of any 802 Intellectual Property Rights or other rights that might be claimed to 803 pertain to the implementation or use of the technology described in 804 this document or the extent to which any license under such rights 805 might or might not be available; nor does it represent that it has 806 made any independent effort to identify any such rights. Information 807 on the procedures with respect to rights in RFC documents can be 808 found in BCP 78 and BCP 79. 810 Copies of IPR disclosures made to the IETF Secretariat and any 811 assurances of licenses to be made available, or the result of an 812 attempt made to obtain a general license or permission for the use of 813 such proprietary rights by implementers or users of this 814 specification can be obtained from the IETF on-line IPR repository at 815 http://www.ietf.org/ipr. 817 The IETF invites any interested party to bring to its attention any 818 copyrights, patents or patent applications, or other proprietary 819 rights that may cover technology that may be required to implement 820 this standard. Please address the information to the IETF at 821 ietf-ipr@ietf.org. 823 Disclaimer of Validity 825 This document and the information contained herein are provided on an 826 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 827 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 828 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 829 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 830 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 831 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 833 Copyright Statement 835 Copyright (C) The Internet Society (2004). This document is subject 836 to the rights, licenses and restrictions contained in BCP 78, and 837 except as set forth therein, the authors retain all their rights. 839 Acknowledgment 841 Funding for the RFC Editor function is currently provided by the 842 Internet Society.