idnits 2.17.00 (12 Aug 2021) /tmp/idnits41863/draft-aoun-nsis-nslp-natfw-migration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 25 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 269: '... NSIS NATFW NSLP MUST ensure that upon...' 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 (October 20, 2003) is 6788 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: '12' is defined on line 952, 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. '1') -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '2') (Obsoleted by RFC 6724) == Outdated reference: A later version (-02) exists of draft-camarillo-mmusic-alt-01 == Outdated reference: A later version (-02) exists of draft-camarillo-mmusic-alt-01 -- Duplicate reference: draft-camarillo-mmusic-alt, mentioned in '5', was also mentioned in '4'. == Outdated reference: A later version (-02) exists of draft-camarillo-mmusic-alt-01 -- Duplicate reference: draft-camarillo-mmusic-alt, mentioned in '6', was also mentioned in '5'. -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '7') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '8') (Obsoleted by RFC 4566) == Outdated reference: A later version (-03) exists of draft-rosenberg-sipping-nat-scenarios-00 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-01 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group C. Aoun 3 Internet-Draft Nortel Networks 4 Expires: April 19, 2004 M. Brunner 5 M. Stiemerling 6 M. Martin 7 NEC 8 H. Tschofenig 9 Siemens 10 October 20, 2003 12 NATFirewall NSLP migration and intra-realm communication 13 considerations 14 draft-aoun-nsis-nslp-natfw-migration-00 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 19, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This document discusses NAT/FW migration to support the NSIS NAT/FW 45 NSLP as well as intra-realm communications considerations. The 46 document will serve as input to the NSIS NATFW NSLP document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. NSIS Responder address selection for intra realm 53 communications optimization . . . . . . . . . . . . . . . 4 54 2.1 Potential solutions to the problem . . . . . . . . . . . . 5 55 2.1.1 Intra realm solution protocol operation impacts . . . . . 6 56 2.1.2 Intra realm solution application protocols impacts . . . . 7 58 3. NATFW NSLP migration analysis . . . . . . . . . . . . . . 8 59 3.1 Global scoped address determination with NSIS unaware 60 NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.2 Analysis of unilateral NSIS signaling . . . . . . . . . . 13 62 3.3 Co-existence with existing NAT traversal mechanisms . . . 19 63 3.4 NSIS protocol traversal of NSIS Unaware Firewalls and 64 NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 65 3.4.1 NSIS protocol traversal of NSIS Unaware Firewalls . . . . 20 66 3.4.1.1 NSIS protocol traversal of a mix of NSIS Unaware 67 Firewalls and NSIS aware NATs . . . . . . . . . . . . . . 20 68 3.4.1.2 NSIS protocol traversal of NSIS Unaware NATs . . . . . . . 21 70 4. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . 22 72 5. Security Considerations . . . . . . . . . . . . . . . . . 23 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 24 76 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 25 78 Normative References . . . . . . . . . . . . . . . . . . . 26 80 Informative References . . . . . . . . . . . . . . . . . . 27 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28 84 Intellectual Property and Copyright Statements . . . . . . 30 86 1. Introduction 88 Whether interim NAT and Firewall traversal mechanisms will already be 89 deployed in networks or not, it is important to understand NSIS NATFW 90 NSLP co-existence with non-NSIS aware NATs and Firewalls until their 91 migration to NSIS would have been accomplished. The NSIS NATFW NSLP 92 responder provides the NSIS NATFW NSLP Initiator with its address, in 93 some cases the NSIS responder may have several addresses: a (or 94 several) global scoped address and its locally scoped address(es). 95 Which address does it provide to the NSIS initiator? This document 96 will cover both the above issues and serve as input to the NSIS NATFW 97 NSLP main document. 99 2. NSIS Responder address selection for intra realm communications 100 optimization 102 An NSIS Element hosting an NSIS NATFW NSLP may have more than one 103 address, its local scoped address(es) and global scoped address(es). 104 A default address selection that priorities arbitrarily a global 105 scoped address over a local scoped address may imply none optimal 106 routing for communications between NSIS elements hosted within the 107 same addressing realm. 109 In Figure 1 the arbitrary selection of the global scoped address, 110 works properly to receive NSIS signaling from Host B. However in 111 deployment scenario shown in Figure 2, host A and host C end-up 112 communicating through their local MB1 middlebox resulting in a non 113 optimal data path with all its implications (additional delay, 114 additional bandwidth in certain parts of the network infrastructure, 115 etc ...). 117 +---------------------+ +--------------------+ 118 | | | | 119 | Host A | ,-----------. | Host B | 120 | +-----+| ,-'The NET `-. | | 121 | | MB1 |+-- --+ | 122 | +-----+| `-. ,-' | | 123 | | `-----------' | | 124 | | | | 125 +---------------------+ +--------------------+ 127 MB: Middle box (NAT or Firewall or a combination) 128 Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities 129 Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities 131 Figure 1 133 +---------------------+ +--------------------+ 134 | | | | 135 | Host A`-. | ,-----------. | Host B | 136 | `. +-----+| ,-'The NET `-. | | 137 | i.. MB1 |+-- --+ | 138 | Host C_.-'' +-----+| `-. ,-' | | 139 | | `-----------' | | 140 | | | | 141 +---------------------+ +--------------------+ 143 MB: Middle box (NAT or Firewall or a combination) 144 Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities 145 Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities 146 Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities 148 Figure 2 150 2.1 Potential solutions to the problem 152 There are two ways to deal with this non-optimal routing of packets 153 for intra-realm communications between NSIS entities. The NSIS 154 Responder should either: 156 1. Decide based on local decision, which address to provide to the 157 NI to signal it or, 159 2. Let the far end NSIS Initiator decide which address to select 160 based on the NSIS Responder's provided addresses 162 (1) lets the NSIS Responder decide on its own, which address to 163 provide based on certain hints, which may not be the most optimal 164 decision since the NSIS Responder may not have sufficient knowledge 165 about the NSIS Initiator at the time of delivering its address to the 166 responder. In most cases none arbitrary local decision for address 167 selection requires to know about the far end host, which is not 168 always practical. 170 An example of such local based address selection is the IPv6 default 171 address selection mechanism ([2]) where an IPv6 (or IPv6/v4) node has 172 to select which source and destination address to pick in order to 173 communicate with a far end node. The mechanism relies on receiving 174 input from the local resolver (DNS client or local hosts file) about 175 the far end node . In the context of multimedia applications (and 176 probably others as well), the NSIS Initiator is provided the NSIS 177 Responder contact information (includes IP address and transport port 178 [1] via the user application protocols (example: SIP, H.323 etc ...). 179 Within that specific context, the NSIS Responder does not have 180 sufficient information about the NSIS Initiator to provide it a valid 181 address. 183 Hence it can not decide successfully in all cases which address to 184 provide to the NSIS Initiator. Hence (2) is more efficient as it 185 requires the NSIS Responder to provide all its addresses (local 186 scoped and global scoped ones) to the NSIS Initiator. As a result, 187 the NSIS Initiator will need to decide on which address to signal the 188 NSIS Responder among all the provided ones. One possible way for the 189 NSIS Initiator to decide from which address it will send NSIS 190 signaling to the NSIS Responder and which NSIS Responder address to 191 use is to check on which address the NSIS responder will reply back. 192 An existing proposal [3] discusses the usage of (2) for SIP User 193 Agents (SIP UA), the SIP UA will probe the far end SIP UA to see from 194 which address it will response back. In [3], the STUN protocol [7] is 195 used to check the responsiveness of the far end host. In [6], the 196 reverse routability used to check which address to respond to 197 counters RTP DOS attacks. The same required reverse routability could 198 be achieved by the NSIS NATFW NSLP. 200 ****Include message sequences in the next iteration of the 201 discussion******* 203 In the context of NSIS, the NSIS protocol itself should be used as 204 the probing mechanism. 205 Consequently the NSIS Initiator will send simultaneously several NSIS 206 messages towards the NSIS Responder, one message per provided 207 address. 208 The following occur during the process: 210 o In case the NSIS Responder and Initiator are located within the 211 same addressing realm, the NSIS Responder should receive a 212 response from all the addresses to which it has sent NSIS 213 messages. The NSIS Initiator will then choose the local scoped 214 address as the destination address for messages destined to the 215 NSIS Responder. 217 o In case the NSIS Responder and Initiator are not located within 218 the same addressing realm, the NSIS Initiator would only receive a 219 response from the valid global scope address. In event that there 220 is another NE within the network that has the same local scoped 221 address as the originally targeted NSIS Responder, the wrongly 222 targeted NSIS Responder should send back an error or discard the 223 message (the later would be preferable). 225 2.1.1 Intra realm solution protocol operation impacts 227 As opposed to the normal NSIS mode of operation, an NI that has 228 already a security association with the neighboring NE on the path to 229 a specific NR would need to verify that the target local scoped NR 230 address is the same as one already cached in its NSIS neighbor table 231 cache (association of Next hop NE with the target NR table).This 232 would be required to avoid any confusion with an NSIS node that could 233 be hosted within the same addressing realm and that would have the 234 same local scoped address. 235 There is a potential threat where an malicious NE with the same local 236 scoped address as the target NR respond back positively to the NSIS 237 message and consequently hijack the data flow. This threat could be 238 counter-measured by proper cryptographic authentication of the NSIS 239 Responder response by using keying material provided by the 240 application signaling (assuming that it was secured). 242 The procedure requiring an NSIS Initiator to send NSIS messages to 243 several NR addresses, requires that the NI sends his NSIS messages at 244 the same time to avoid impacting real-time sensitive applications. In 245 case the response to the message sent to the global scoped is 246 received first, it could potentially be used as a hint that no 247 response will be received from the NR's local scoped address. Hence 248 there is no point to continue to delay the address selection process 249 and proceed with the NSIS protocol operations. In case the first 250 response is received from a local scoped address and has been 251 authenticated with the keying material provided by the application 252 signaling protocol then the address selection process ends, and the 253 NSIS protocol operations continue. 255 2.1.2 Intra realm solution application protocols impacts 257 The proposed intra realm path optimization proposal requiring an NR 258 to provide several data recipient addresses within the application 259 protocol, has obviously a certain impact on the application protocol. 260 [5] discusses the impact to SDP [8] and should be used by all the 261 application protocols using SDP. A similar approach should be 262 followed by other protocols, not using SDP, including H.323 [9] and 263 others requiring usage of NSIS with multiple addresses for the NR. 265 3. NATFW NSLP migration analysis 267 This section goes through a detailed analysis of the NATFW NSLP 268 transition challenges and its possible solutions. The conception of 269 the NSIS NATFW NSLP MUST ensure that upon its deployments in 270 networks, it should not disrupt applications using interim NAT and 271 Firewall traversal mechanisms. 272 In addition: 274 o The NATFW NSLP should ensure that an NR would not always be 275 required to have minimal service, particularly when the NI has a 276 simple network configuration without asymmetric route issues. In 277 the early phases of the NSIS NATFW NSLP migration, this situation 278 will be quite frequent and hence this scenario must be supported. 280 o The NSIS protocol should be designed to traverse non-NSIS aware 281 NATs and Firewalls, to allow usage of non NAT and Firewall related 282 NSLP (Qos NSLP for example). As the reader will notice in the 283 subsequent sections NRs behind 285 o It is advised for an NSIS aware NAT and Firewall implementation to 286 keep its existing currently used stateful behavior (depending on 287 its applicability) until the transition to NSIS has ended (in 288 order to have a smoother transition). 290 Several deployment scenario will be considered within this analysis, 291 for simplicity the discussed scenario cover at most two Middleboxes 292 on the path between the NI and NR. In Figure 3, a total of 144 293 deployment scenario could be possible only the ones having an NI or 294 NR (only when there is a NAT) are considered. Implied but not shown 295 scenario within Figure 5 are ones in the NI column or NR row. 296 Obviously not all the scenario will be covered in this section, only 297 the most interesting scenario are discussed in the next sections. A 298 check list will be added later on in the annex of the next iteration 299 of the analysis. 301 `.-----+------+-------+-------+--------+------+-------+ 302 | `NR | NAT | FW |NATFW | NAT++ |FW++ |NATFW++| 303 |NI `. |NE+NAT|NE+FW |NE+NATFW NE |NE | NE | 304 |``````|``````|```````|```````|````````|``````|```````| 305 | |Sc2 | |Sc10 |Sc14 | |Sc22 | 306 |NAT |Sc3 |Sc7 |Sc11 |Sc15 |Sc19 |Sc23 | 307 |NE+NAT|Sc4 |Sc8 |Sc12 |Sc16 |Sc20 |Sc24 | 308 |````````````````````````````````````````````````````` 309 | |Sc26 | |Sc34 |Sc38 | |Sc46 | 310 | FW |Sc27 |Sc31 |Sc35 |Sc39 |Sc43 |Sc47 | 311 | NE+FW|Sc28 |Sc32 |Sc36 |Sc40 |Sc44 |Sc48 | 312 ''''''''''''''''''''''''''''''''''''''''''''''''''''''' 313 | |Sc50 | |Sc58 |Sc62 | |Sc70 | 314 |NATFW |Sc51 |Sc55 |Sc59 |Sc63 |Sc67 |Sc71 | 315 NE+NATFW Sc52 |Sc56 |Sc60 |Sc64 |Sc68 |Sc72 | 316 ''''''''''''''''''''''''''''''''''''''''''''''''''''''' 317 | |Sc74 | |Sc82 |Sc86 | |Sc94 | 318 | NAT++|Sc75 |Sc79 |Sc83 |Sc87 |Sc91 |Sc95 | 319 | NE |Sc76 |Sc80 |Sc84 |Sc88 |Sc92 |Sc96 | 320 +------+------+-------+-------+--------+------+-------+ 321 | |Sc98 | |Sc106 |Sc110 | | Sc118 | 322 |FW++ |Sc99 | Sc103 |Sc107 |Sc111 |Sc115 | Sc119 | 323 |NE |Sc100 | Sc104 |Sc108 |Sc112 |Sc116 | Sc120 | 324 +------+------+-------+-------+--------+------+-------+ 325 | |Sc122 | |Sc130 | Sc134 | | Sc142 | 326 |NATFW++ Sc123| Sc127 |Sc131 | Sc135 | Sc139| Sc143 | 327 | NE | Sc124| Sc128 |Sc132 | Sc136 | Sc140| Sc144 | 328 +------+------+-------+-------+--------+------+-------+ 330 Figure 3 332 Scxyz: Scenario number xyz 333 NAT : NSIS Unaware NAT 334 NE : NSIS Entity with NI and NR functions 335 NE+NAT: NE hosted within a network connected to the NSIS unaware 336 NAT FW : NSIS Unaware Firewall 337 NE+FW: NE hosted within a network protected by an NSIS Unaware FW 338 NATFW: NSIS Unaware NAT and Firewall hosted within the same Middlebox 339 NE+NATFW: NE hosted within a network protected by an NSIS Unaware 340 NATFW 341 NAT++: NSIS Aware NAT 342 NAT++NE: NE hosted within a network connected to an NAT++ 343 FW++ : NSIS Aware FW 344 FW++NE: NE hosted within a network connected to a FW++ 345 NATFW++: NSIS Aware NATFW 346 NATFW++NE: NE hosted within a network connected to a NATFW++ 347 Every cell in Figure 3 is the combination of the NI's network and the 348 NR's network. Deployments scenario, where there are no NI and NR, no 349 NI (without an NR with a NAT), are not shown. For example: 351 `.-----+------+ 352 | `NR | NAT | 353 |NI `. |NE+NAT| 354 |````` :``````| 355 | NAT |Sc2 | 356 |NE+NAT|Sc3 | 357 | |Sc4 | 359 Figure 4 361 Scenario 1: NAT x NAT is not considered as there is no NI and no NR 362 with a NAT 363 Scenario 2: NAT x NE+NAT is considered as there is an NR with a NAT 364 (even if it is not NSIS aware) 365 Scenario 3: NE+NAT x NAT, is considered since there is an NI as part 366 of the NE functions 367 Scenario 4: NE+NAT x NE+NAT, is considered since there is an NI as 368 part of the NE functions 369 The same logic is applicable to all the cells in Figure 3 370 For simplicity only network deployments are shown with a maximum of 2 371 MBs on the path between the NI and the NR. Handled scenario within 372 the NI column or NR raw are the ones having an NI or NR. In the next 373 sections, we shall go through the various issues that are specific to 374 the scenario mentioned in Figure 3. 376 3.1 Global scoped address determination with NSIS unaware NATs 378 This section discusses the potentional role that an NE with a NATFW 379 NSLP could still have to determine a global scoped address translated 380 by a none NSIS aware NAT. Upon detection that the NE is attached to a 381 network hosting an NSIS unaware NAT, it could have the two 382 alternatives, either: 384 1. The NSIS API could invoke the services of a STUN client [7] as 385 shown is Figure 7, this would allow applications using UDP 386 transport to work (only applicable for cone NAT [7]). 388 +---------------------------------------+ 389 | | +--------+ 390 | +----------+ | | STUN | 391 | |Apps | | | Server | 392 | +----------+ +---+| +--------+ 393 | | STUN | |NAT|| 394 | | CLIENT | | || 395 | |__________| +---+| 396 | |NATFW NSLP| | 397 | | NI/NR | | 398 | +----------+ | 399 | Host A | 400 +---------------------------------------+ 401 Figure 5 403 2. The NE could send, through the NSIS unaware NAT, a bind request 404 message towards a network entity hosting a simplified NR function 405 responding to the message with the translated address. The 406 translated address and port would correspond to the translated 407 source address and port of the received NSIS message by the NE. 408 This translated address and port information would only be useful 409 for UDP transported data, and would imply that the NSIS protocol 410 would be sent from the same address and port as the data flows. 411 This behavior implies a change to the protocol operations, since 412 the NTLP does not normally require transport protocol changes for 413 a given NSLP (at least for now); the other implied modification 414 is to support a minimum set of operations on the responding NE 415 hosting the NATFW NSLP. The minimum set of operations would 416 consist of the ability to authenticate the NE, providing the 417 translated address and port, and support of UDP transport (as 418 well as TCP if certificates need to be sent first). This 419 mechanism would only be applicable to cone NATs [7]. 421 +---------------------------------------+ 422 | | +--------+ 423 + +----------+ | |NATFW | 424 | |Apps | | | NSLP-NR| 425 | +----------+ +---+| +--------+ 426 | |NATFW NSLP| |NAT|| 427 | | NI/NR | | || 428 | +----------+ +---+| 429 | Host A | 430 | | 431 +---------------------------------------+ 433 Figure 6 435 +-----------------+ 436 ___________| NSIS aware NAT |_________ 437 | | Determination | | 438 NSIS | +-----------------+ | NSIS 439 Aware | | Unaware 440 | | 441 | | 442 V V 444 +-------------------+ +------------+ 445 |Proceed with | If not UDP |Used data | 446 |normal NR operation| +--------|transport | 447 +-------------------+ | |protocol | 448 | +------------+ 449 | | If UDP 450 V | 451 +-------------+ | 452 |Log error | | 453 |to app layer | | 454 +-------------+ V 455 +-------------+ 456 | Invoke STUN | 457 | Client | 458 +------+------+ 459 | 460 | 461 | 462 V 463 +------------+ 464 | Send STUN | 465 | binding | 466 | request | 467 +-----+------+ 468 | 469 V 470 +-------------------------+ 471 |Standard STUN operations | 472 +-------------------------+ 474 Figure 7 476 +-----------------+ 477 ___________| NSIS aware NAT |_________ 478 | | Determination | | 479 NSIS | +-----------------+ | NSIS 480 Aware | | Unaware 481 | | 482 | | 483 V +------------+ 484 +-------------------+ If not UDP |Used data | 485 |Proceed with | +--------|transport | 486 |normal NR operation| | |protocol | 487 +-------------------+ | +------------+ 488 | | If UDP 489 V | 490 +-------------+ | 491 |Log error | V 492 |to app layer | +------------+ 493 +-------------+ |Send bind | 494 |create msg | 495 |over UDP | 496 +-----+------+ 497 | 498 | 499 V 500 +-------+------------+-----+ 501 | Simplified NE to respond | 502 | with observed translated | 503 | address and port | 504 +--------------+-----------+ 505 | 506 | 507 | 508 +---------------------+ 509 | NR to provide | 510 | translated address | 511 | to app layer | 512 +---------------------+ 514 Figure 8 516 3.2 Analysis of unilateral NSIS signaling 518 When NSIS NAT/FW signaling will start to be deployed, it is quite 519 possible that an NI sends an NSIS message without having an NR to 520 respond to it. The NATFW NSLP should have the ability to have a 521 mechanism that would allow it to handle this type of deployments. 522 NSIS NATFW NSLP signaling for NAT binds is already local within the 523 trust domain, however this is not the case with firewall signaling 524 that should be end to end. 526 There are three interesting cases to be analyzed: 528 1. The local trust domain (from an NI perspective) has at least one 529 NSIS aware Firewall, there is no NR on the far end as well as no 530 NSIS aware NAT or Firewall. 532 +-----------------------+ +--------------------+ 533 |+----------+ | | +----------+ 534 ||App client| | | |App client| 535 ||NI/NR | FW++ | ,---------. | +----------+ 536 |+----------+ ''''''' The net ---. Host B | 537 | Host A | `---------' | | 538 | | | | 539 | Net A | | Net B | 540 +-----------------------+ +--------------------+ 542 Figure 9 544 2. The local trust domain has no NSIS aware Firewall, there is no NR 545 at the far end but there is at least an NSIS aware firewall with 546 which the local NI has no direct trust relation (which implies an 547 authorization issue and possibly authentication issues). 549 +-----------------------+ +--------------------+ 550 |+----------+ | | +----------+ 551 ||App client| | | |App client| 552 ||NI/NR | | ,---------. | FW++ +----------+ 553 |+----------+ ''''''' The net ---. Host B | 554 | Host A | `---------' | | 555 | | | | 556 | Net A | | Net B | 557 +-----------------------+ +--------------------+ 559 Figure 10 561 3. The local trust domain (from an NI perspective) has at least one 562 Firewall, there is no NR on the far end but there is at least one 563 NSIS aware Firewall with which the local NI has no direct trust 564 relation (which implies an authorization issue and possibly 565 authentication issues). 567 +-----------------------+ +--------------------+ 568 |+----------+ | | +----------+ 569 ||App client| | | |App client| 570 ||NI/NR | FW++ | ,---------. | FW++ +----------+ 571 |+----------+ ''''''' The net ---. Host B | 572 | Host A | `---------' | | 573 | | | Net B | 574 | Net A | | | 575 +-----------------------+ +--------------------+ 577 Figure 11 579 In 1), the NI sends its firewall policy rule creation message, it 580 traverses the first NF (its own firewall) but there is no NR to 581 respond back. If we consider to have a response timer on the last NF 582 being traversed by an NATFW NSLP message then if no response is 583 received to the NSIS message, the last NF will respond back to the NI 584 with a notification of no far end NR response. This will imply that 585 the signaling will be scoped to the last NF on the path that 586 responded back. Using the network deployment shown in Figure 9, the 587 following mode of operation would apply: 589 Host A Host B 590 NI FW++ Expected NR 591 | | | 592 |1-NSIS Init msg | | 593 |----------------> | | 594 | |2-NSIS Init msg | 595 | | +---------------> | 596 | | |NATFW NSLP ON | 597 | | | | 598 | | | | 599 | | | | 600 | | | Timeout | 601 3-NSIS Init msg Ack| V | 602 |No NR | | 603 |<.................| | 605 Figure 12 607 When more than one NSIS aware NAT or Firewall is deployed within the 608 same trust domain, upon determination of a previous NSIS hop, an NSIS 609 aware node will notify the previous NSIS hop of its existence to 610 avoid launching the timer that triggers the sending of an NSIS 611 message back to the NI. The last NF on the path will launch the timer 612 since no valid NSIS neighbor was sent to it. 614 Trust domain A Trust domain B 615 <..........................................> <--------> 616 Host A Host B 617 NI FW++ FW++ Expected NR 618 | | | | 619 | NSIS Init msg | | | 620 | ----------------> | NSIS Init msg | | 621 | | ---------------> | NSIS Init msg | 622 | | NATFW NSLP ON |---------------->| 623 | | | | with Token | 624 | | Valid . | NATFW NSLP ON | 625 | | NSIS Neighbor | | | 626 | |<-----------------| | | 627 | |----------------->| | Timeout | 628 | | Ack | | | 629 | | | | | 630 | | | | | 631 | | | | | 632 | | | V | 633 | | <................+ | 634 | | NSIS Init msg Ack| | 635 | NSIS Init msg Ack | No NR | | 636 | No NR | | | 637 | <.................| | | 639 Figure 13 641 In 2), the NI sends its firewall policy rule creation message, it 642 traverses the FW hosted in Host B's network, but host A is not 643 authorized to install a policy rule unless the policy rule creation 644 is approved by a trusted entity within Net B. Unfortunately Host B 645 was not yet upgraded to support the NATFW NSLP, another entity needs 646 to authorize the policy rule installation. 647 Potentially a trusted third party already aware of the application 648 session held between Host A and Host B could provide an authorization 649 token to Host A [13], the token would be encapsulated within the 650 NATFW NSLP message and would allow the NSIS aware Firewall in Net B 651 to authorize Host A's requested policy rule to be installed. This 652 approach would obviously require to put in place a mechanism to 653 provide the authorization token to Host A. The token could be 654 requested by the NI and included in the NSLP signaling by default or 655 after receiving an error message from the far end NSIS aware Firewall 656 indicating that authorization data is required. The authorization 657 token would need to be associated with the identity of the NI, 658 associating the authorization token with an IP address is not 659 sufficient, a proper mechanism should be put in place to allow proper 660 authentication of the legal token user. The next revision of the 661 discussion will cover in more details this aspect. 663 +---------------+ 664 | Authorization|1-Generate Token 665 | mediator | 666 .'--------------+ 667 .' \ 668 2-Provide .-' \ 669 Token .' \ 670 .' \ 671 .' \4-Check token 672 .-' \ validity 673 +-----------.'----------+ ++----------------+ 674 |+--------.'+ | | \ +----------+ 675 ||App client| | | \ |App client| 676 ||NI/NR +-------. | ,-=.----.-. | FW++ +----------+ 677 |+----------+ `---------'The net `-------- Host B | 678 | Host A | `---------' | | 679 | | 3-Send | | 680 | | NSLP msg with | | 681 +-----------------------+ Token +-----------------+ 683 Figure 14 685 Trust domain A Trust domain B 686 <........................> <---------------------> 687 Host A Host B 688 NI FW FW++ Expected NR 689 | | | | 690 | NSIS Init msg | | | 691 | ------------------+----------------> | | 692 | | | NSIS Init msg | 693 | | | +-------------->| 694 | | | NATFW NSLP ON | 695 | | NSIS ERROR . | 696 | <....................................| | 697 | |Need Authorization| | 698 | NSIS Init msg | | | 699 | ------------------------------------>| | 700 | with Token | | | 701 | | | NSIS Init msg | 702 | | |---------------->| 703 | | | | with Token | 704 | | Valid + | NATFW NSLP ON | 705 | | NSIS Neighbor | | | 706 | |<-----------------| | Timeout | 707 | |----------------->| | | 708 | NSIS Init msg Ack | Ack | | | 709 | No NR | <................| V | 710 | <.................| NSIS Init msg Ack| | 711 | | No NR | | 713 Figure 15 715 In 3),the NI sends its message to the non-existing NR at host B, it 716 traverses the first NSIS aware Firewall, the policy rule installation 717 succeeds; the message continues to be forwarded until it reaches the 718 2nd NATFW NSLP aware firewall. 719 In case no authorization material is provided in the NSLP message, 720 the Firewall will send an error message notifying the NI to send 721 authorization data. If the NI can't send any authorization data, then 722 it will decide to scope the NSIS signaling message to the last NF on 723 which the state installation succeeded. 725 Trust domain A Trust domain B 726 <........................> <---------------------> 727 Host A Host B 728 NI FW++ FW++ Expected NR 729 | | | | 730 | NSIS Init msg | | | 731 | ----------------> | NSIS Init msg | | 732 | | +--------------> | | 733 | | NATFW NSLP ON | | 734 | | | | 735 | | NSIS ERROR . | 736 | |<.................| | 737 | |Need Authorization| | 738 | NSIS Init msg | | | 739 | ----------------> | | | 740 | Scoped to last | | | 741 | succeeded state | | | 742 |installation hop | | | 743 | | | | 744 | | | | 745 | NSIS Init msg Ack | | | 746 | No NR | | | 747 | <.................| | | 749 Figure 16 751 Since the signaling is unilateral (no NI available to do the 752 installation for the other direction), the installed policy rules 753 should be bi-directional. Although bi-directional policy rules could 754 be problematic as discussed in [1], it is the only solution available 755 when no remote NI would be available. 757 3.3 Co-existence with existing NAT traversal mechanisms 759 Section 3.1 discussed how a NATFW NE could be used when an NSIS 760 un-aware NAT is deployed within the network infrastructure. This 761 section discusses how the NATFW NSLP could co-exist with interim NAT 762 traversal mechanisms [10]. In Figure 17, a STUN client (Host A) [7], 763 an NE (host B), a host using a Media Proxy [10] and host using a TURN 764 client [11] co-exist in the same network with a NATFW NSLP aware NAT. 765 There are no reasons for the existing mechanisms to be mutually 766 exclusive every host could continue using the existing interim 767 solutions, meanwhile the unilateral NSIS signaling would be used 768 until both ends support the NSIS NATFW NSLP. 770 +---------------------------+ 771 | _|__1______.STUN Server 772 |STUN Client ----'''''''''' | 773 | Host A | App server 774 | 2 _..NAT++ | .-' 775 | NI/NR __.--'' | 3 .'+ 776 | Host B -'' | Media Proxy.-' 777 | | 778 | | 779 | Host C | 780 | 4 | 781 | Turn Client---------------+---------- TURN Server 782 | Host D | 783 | | 784 +---------------------------+ 786 Figure 17 788 3.4 NSIS protocol traversal of NSIS Unaware Firewalls and NATs 790 3.4.1 NSIS protocol traversal of NSIS Unaware Firewalls 792 In case an NSIS unaware firewall is traversed by NSIS messages, NSIS 793 messages should be allowed to go through it, as well as the exchanged 794 data flows between the user application clients. This is not 795 necessarily an obvious task to perform in case the NSIS messages 796 can't be identified by the NSIS unaware firewall. Same applies for 797 the user application data flows. 799 NSIS message identification should be supported by existing 800 firewalls. 801 Currently firewalls support flow identification by using the 5 tuple 802 or a sub-set of it. We can not assume that the firewall will support 803 the router alert option [14], hence it should not be the only element 804 of the used identification filter. 806 User application data flow identification, should be deterministic at 807 a specific address and port range level. This means that the 808 application clients uses a combination of an address and specific 809 transport port range. This combination should be configured on the 810 firewall. 812 +-----------------------+ ++-------------------+ 813 | | | +-----+ 814 |+------+ | | | AC | 815 ||AC | | ,-=.----.-. | |NI/NR| 816 ||NI/NR + Qos++ -----'The net ----Qos++ FW +-----+ 817 |+------+ | `---------' | Host B | 818 | Host A | | | 819 | | | | 820 +-----------------------+ +--------------------+ 821 FW: NSIS unaware FW 822 Qos++: NE with Qos NSLP 824 Figure 18 826 3.4.1.1 NSIS protocol traversal of a mix of NSIS Unaware Firewalls and 827 NSIS aware NATs 829 In case a NAT is deployed on the path and it is NSIS-NATFW, the 830 assigned bind should be consistent with policy rules configured with 831 the NSIS unaware firewall. 833 +-----------------------+ ++-------------------+ 834 | | | +-----+ 835 |+------+ | | | AC | 836 ||AC | | ,-=.----.-. | |NI/NR| 837 ||NI/NR + NATFW++ Qos++------'The net `----Qos++ FW +-----+ 838 |+------+ | `---------' | Host B | 839 | Host A | | | 840 | | | | 841 +-----------------------+ +--------------------+ 842 FW: NSIS unaware FW 843 Qos++: NE with Qos NSLP 844 NATFW++: NSIS aware NATFW 845 Policy rules configured on the NSIS unaware FW to allow 846 specific filters for NSIS signaling and user Application data flows 848 Figure 19 850 Even though the deployed FW is not NSIS aware, the application data 851 would still be forwarded if existing interim solutions were used such 852 as a mix of stateless policy rules and flow based states with initial 853 packets sent in the outbound direction (inside to outside a trust 854 domain). 856 3.4.1.2 NSIS protocol traversal of NSIS Unaware NATs 858 NATs create an address bind state for flows having well known 859 patterns part of a predefined filter matching expression. In most 860 cases the patterns consist of the protocol number within the IP 861 header and transport port numbers. When a packet flow has different 862 paterns within in its filter matching expression, not all NATs will 863 be able to forward the packets. When several NEs are deployed behind 864 NATs, a mandatory demultiplexing field is required for the NSIS 865 protocol in order to match a source or destination to another source 866 or destination. Prior to the NSIS protocol, NATs had to work with 867 IPSEC before IPSEC UDP encapsulation was used ([4]), the SPI 868 parameter was used as demultiplexing field, but this capability was 869 not native in all NATs. Hence IPSEC had to wait for UDP encapsulation 870 to be be forwarded through consumer market NATs. The learned lesson 871 is that the best approach for the NSIS protocol to be backward 872 compatible with existing NATs, would be to be transported over 873 existing transport protocols and not to be sent as raw IP payload. 875 4. NATFW NSLP NTLP requirements 877 The NATFW NSLP transition requires the NTLP to change transport 878 protocol to UDP when the data is transported over UDP, as discussed 879 in Section 3.1. 881 If the valid next neighbor determination described in Section 3.2, is 882 applicable to other NSLPs it would potentially make sense to have a 883 part of it incorporated in the NTLP. Further investigation would be 884 required to define what should be done in the NTLP (NSLP independent) 885 and what should be done within the NSLP. 887 The NATFW NSLP does not have any next NSIS hop failure detection 888 mechanism, the NSLP relies on the the NTLP layer for this capability. 890 NTLP security requirements: TBD 892 5. Security Considerations 894 Section Section 3.2 and [1] discuss the security considerations for 895 the NSIS NATFW NSLP. 897 6. IANA Considerations 899 There are no IANA considerations defined in this document. 901 7. Open Issues 903 Need to close on: the intra-realm security issues, the editorial 904 issues, linking the authorization token with the NI cryptographic 905 authentification mechanisms, NTLP required NAT handling capabilities. 907 Normative References 909 [1] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H., 910 Schulzrinne, H. and C. Aoun, "A NAT/Firewall NSIS Signaling 911 Layer Protocol (NSLP)", DRAFT draft-ietf-nsis-nslp-natfw-00.txt, 912 October 2003. 914 Informative References 916 [2] Draves, R., "Default Address Selection for Internet Protocol 917 version 6 (IPv6)", RFC 3484, February 2003. 919 [3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 920 Methodology for Network Address Translator (NAT) Traversal for 921 the Session Initiation Protocol (SIP)", DRAFT 922 draft-rosenberg-sipping-ice-01.txt, June 2003. 924 [4] A. Huttunen et all, A., "UDP Encapsulation of IPsec Packets", 925 DRAFT draft-camarillo-mmusic-alt-01.txt, Jan 2003. 927 [5] Camarillo, J. and J. Rosenberg, "The Alternative Semantics for 928 the Session Description Protocol Grouping Framework", DRAFT 929 draft-camarillo-mmusic-alt-01.txt, June 2003. 931 [6] Rosenberg, J., "The Real Time Transport Protocol (RTP) Denial 932 of Service (Dos) Attack and its Prevention", DRAFT 933 draft-camarillo-mmusic-alt-01.txt, June 2003. 935 [7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 936 Simple Traversal of User Datagram Protocol (UDP) Through 937 Network Address Translators (NATs)", RFC 3489, March 2003. 939 [8] Handley, M. and V. Jacobson, "SDP: Session Description 940 Protocol", RFC 2327, April 1998. 942 [9] ITU-T SG16, "Packet-based multimedia communications systems", 943 ITU-T H.323, November 2000. 945 [10] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for 946 SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in 947 progress), November 2001. 949 [11] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 950 draft-rosenberg-midcom-turn-01 (work in progress), March 2003. 952 [12] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore, 953 "Middlebox Communications (midcom) Protocol Requirements", RFC 954 3304, August 2002, . 956 [13] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 957 Set-up with Media Authorization", RFC 3521, April 2003, 958 . 960 [14] Katz, D., "IP Router Alert Option", RFC 2113, February 1997, 961 . 963 Authors' Addresses 965 Cedric Aoun 966 Nortel Networks 968 France 970 EMail: cedric.aoun@nortelnetworks.com 972 Marcus Brunner 973 Network Laboratories, NEC Europe Ltd. 974 Kurfuersten-Anlage 36 975 Heidelberg 69115 976 Germany 978 Phone: +49 (0) 6221 905 11 29 979 EMail: brunner@ccrle.nec.de 980 URI: http://www.brubers.org/marcus 982 Martin Stiemerling 983 Network Laboratories, NEC Europe Ltd. 984 Kurfuersten-Anlage 36 985 Heidelberg 69115 986 Germany 988 Phone: +49 (0) 6221 905 11 13 989 EMail: stiemerling@ccrle.nec.de 990 URI: 992 Miquel Martin 993 Network Laboratories, NEC Europe Ltd. 994 Kurfuersten-Anlage 36 995 Heidelberg 69115 996 Germany 998 Phone: +49 (0) 6221 905 11 16 999 EMail: miquel.martin@ccrle.nec.de 1000 URI: 1002 Hannes Tschofenig 1003 Siemens AG 1004 Otto-Hahn-Ring 6 1005 Munich 81739 1006 Germany 1008 Phone: 1009 EMail: Hannes.Tschofenig@siemens.com 1010 URI: 1012 Intellectual Property Statement 1014 The IETF takes no position regarding the validity or scope of any 1015 intellectual property or other rights that might be claimed to 1016 pertain to the implementation or use of the technology described in 1017 this document or the extent to which any license under such rights 1018 might or might not be available; neither does it represent that it 1019 has made any effort to identify any such rights. Information on the 1020 IETF's procedures with respect to rights in standards-track and 1021 standards-related documentation can be found in BCP-11. Copies of 1022 claims of rights made available for publication and any assurances of 1023 licenses to be made available, or the result of an attempt made to 1024 obtain a general license or permission for the use of such 1025 proprietary rights by implementors or users of this specification can 1026 be obtained from the IETF Secretariat. 1028 The IETF invites any interested party to bring to its attention any 1029 copyrights, patents or patent applications, or other proprietary 1030 rights which may cover technology that may be required to practice 1031 this standard. Please address the information to the IETF Executive 1032 Director. 1034 Full Copyright Statement 1036 Copyright (C) The Internet Society (2003). All Rights Reserved. 1038 This document and translations of it may be copied and furnished to 1039 others, and derivative works that comment on or otherwise explain it 1040 or assist in its implementation may be prepared, copied, published 1041 and distributed, in whole or in part, without restriction of any 1042 kind, provided that the above copyright notice and this paragraph are 1043 included on all such copies and derivative works. However, this 1044 document itself may not be modified in any way, such as by removing 1045 the copyright notice or references to the Internet Society or other 1046 Internet organizations, except as needed for the purpose of 1047 developing Internet standards in which case the procedures for 1048 copyrights defined in the Internet Standards process must be 1049 followed, or as required to translate it into languages other than 1050 English. 1052 The limited permissions granted above are perpetual and will not be 1053 revoked by the Internet Society or its successors or assignees. 1055 This document and the information contained herein is provided on an 1056 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1057 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1058 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1059 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1060 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1062 Acknowledgment 1064 Funding for the RFC Editor function is currently provided by the 1065 Internet Society.