idnits 2.17.1 draft-aoun-nsis-nslp-natfw-intrarealm-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 720. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 736), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** 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 : ---------------------------------------------------------------------------- == There are 16 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 180 has weird spacing: '...om A at a.b....' == Line 314 has weird spacing: '...message provi...' -- 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 7220 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: 'ExtADD' on line 504 == Unused Reference: '13' is defined on line 641, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '1') == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '2') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '3') == Outdated reference: A later version (-06) exists of draft-ietf-nsis-threats-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-threats (ref. '4') == Outdated reference: A later version (-02) exists of draft-fessi-nsis-natfw-threats-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '6') (Obsoleted by RFC 6724) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-01 == Outdated reference: A later version (-02) exists of draft-camarillo-mmusic-alt-01 -- Duplicate reference: draft-camarillo-mmusic-alt, mentioned in '9', was also mentioned in '8'. == Outdated reference: A later version (-02) exists of draft-aoun-nsis-nslp-natfw-migration-01 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '11') (Obsoleted by RFC 4566) == Outdated reference: A later version (-03) exists of draft-rosenberg-sipping-nat-scenarios-00 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '14') (Obsoleted by RFC 5389) Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 13 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: January 17, 2005 H. Tschofenig 5 Siemens 6 M. Stiemerling 7 M. Brunner 8 M. Martin 9 NEC 10 July 19, 2004 12 NAT/Firewall NSLP Intra-Realm Considerations 13 draft-aoun-nsis-nslp-natfw-intrarealm-01 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 17, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 This document discusses NAT/FW NSLP issues and solutions for cases 47 where NATFW NSLP NEs within the same addressing realm communicate 48 with each other. The document will serve as input to the NSIS NAT/FW 49 NSLP document to meet these intra-realm communications' requirements. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem statement . . . . . . . . . . . . . . . . . . . . . 5 59 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 63 6. Application Signaling Protocol Impacts . . . . . . . . . . . 15 65 7. NATFW NSLP required extensions . . . . . . . . . . . . . . . 16 67 8. Perfomance considerations . . . . . . . . . . . . . . . . . 19 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 71 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 21 73 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 13.1 Normative References . . . . . . . . . . . . . . . . . . . 24 79 13.2 Informative References . . . . . . . . . . . . . . . . . . 24 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 83 Intellectual Property and Copyright Statements . . . . . . . 27 85 1. Introduction 87 The NSIS NATFW NSLP responder provides the NSIS NATFW NSLP Initiator 88 with its address, in some cases the NSIS responder may have several 89 addresses: one (or several) global scoped address and its locally 90 scoped address(es). 92 The following question arises: Which address does it provide to the 93 NSIS initiator? 95 This document will cover the NSIS Responder address selection as well 96 as the impact on applications and the NSIS protocol suite. The 97 document will serve as input to the NSIS WG documents. 99 2. Terminology 101 The terminology used in this document is defined in [1]. 103 3. Problem statement 105 An NSIS Element hosting an NSIS NATFW NSLP may have more than one 106 address, its local scoped address(es) and global scoped address(es). 107 A default address selection that priorities a global scoped address 108 over a local scoped address arbitrarily may imply non-optimal routing 109 for communication between NSIS elements hosted within the same 110 addressing realm. For certain NAT/Firewall implementations it is not 111 only a matter of path optimization: if a global scoped address is 112 used to reach an internal host, the NSIS messages may get dropped due 113 to a conflict with the anti-spoofing rules on the NAT/Firewall NE, 114 hence no communication could be established. 116 In Figure 1 the arbitrary selection of the global scoped address, 117 works properly to receive NSIS signaling from Host B. However in 118 deployment scenario shown in Figure 2, host A and host C end-up 119 communicating through their local MB1 middlebox resulting in a non 120 optimal data path with all its implications (for example, additional 121 delay or additional bandwidth consumption in certain parts of the 122 network). 124 +---------------------+ +--------------------+ 125 | +------+ | | +------+ | 126 | |Host A| | ,-----------. | |Host B| | 127 | +------+ +-----+| ,-' Public `-. | +------+ | 128 | | MB1 |+-- Internet --+ | 129 | +-----+| `-. ,-' | | 130 | | `-----------' | | 131 |Network A | | Network B| 132 +---------------------+ +--------------------+ 134 MB: Middle box (NAT or Firewall or a combination) 135 Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities 136 Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities 138 Figure 1: Intra-Realm Signaling Scenario 140 +---------------------+ +--------------------+ 141 |+------+ | | +------+ | 142 ||Host A|-. | ,-----------. | |Host B| | 143 |+------+ `. +-----+| ,-' Public `-. | +------+ | 144 |+------+ i.. MB1 |+-- Internet --+ | 145 ||Host C|.-'' +-----+| `-. ,-' | | 146 |+------+ | `-----------' | | 147 | | | Network B| 148 |Network A | +--------------------+ 149 +---------------------+ 151 MB: Middle box (NAT or Firewall or a combination) 152 Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities 153 Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities 154 Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities 156 Figure 2: Intra-Realm Signaling Scenario 158 Figure 3 and Figure 4, show clearly the impact when the global scoped 159 address is used to signal an NE within the same addressing realm. 160 Figure 3 show how host A will use the Reserve External Address 161 message (defined in [1] to get its global scoped address (i.e. the 162 external address), same happens to host B. Figure 4 shows how the 163 CREATE/RESPONSE messages (defined in [1]) are exchanged to host B/A 164 global addresses and the impact on the data path. 166 Host C Host A MB1 App server/proxy 167 10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d 168 | | REA | | 169 | | -------------> | | 170 | | RESPONSE | | 171 | | <------------- | | 172 | | External | | 173 | |Address=a.b.c.e | | 174 | | start-app with C | 175 | | ==============================> | 176 | | from A at a.b.c.e | 177 | | | | 178 | start-app with C | | 179 | <============================================= | 180 | from A at a.b.c.e | | 181 | | | 182 | REA | | 183 | -----------------------> | | 184 | RESPONSE | | 185 | <------------------------ | | 186 | External Address= a.b.c.e | | 187 | | | 188 | start-app with C ACK C:a.b.c.e | 189 | ==========================================> | 190 | from A at a.b.c.e | 192 --- NATFW NSLP signaling 194 === User Application signaling (SIP, H323, MGCP, MEGACO etc) 196 Figure 3: Message flow for routing via the Middlebox 198 Host C Host A MB1 App server/proxy 199 10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d 200 | | CREATE | | 201 | | -------------> |--, | 202 | | | | | 203 | | | | | 204 | | CREATE | | | 205 | <---------------------------- |<-' | 206 | RESPONSE | | | 207 | ----------------------------> |--, | 208 | | RESPONSE | | | 209 | |<------------- |<-' | 210 | | | | 211 | App signaling | | 212 | continues ... | 213 | <==============================================> | 214 | <================================> | 215 |<+++++++++++++++++++++++++++++++++ | 216 | | App data | | | 217 | |<++++++++++++++++++ | 218 | | | | 219 | | | | 221 ---- NATFW NSLP signaling 223 ==== User Application signaling (SIP, H323, MGCP, MEGACO etc) 225 Figure 4: NSIS signaling for routing via the Middlebox 227 4. Solution Approaches 229 There are two ways to deal with this non-optimal routing of packets 230 for intra-realm communications between NSIS entities. The NSIS 231 Responder could either: 232 1. Use a local policy to decide which address to provide to the NSIS 233 Initiator 234 2. Make all addresses available to the NSIS Initiator to let it 235 decide which address to use 237 Approach (1) lets the NSIS Responder decide on its own, which address 238 to provide based on certain hints, which may not be the most optimal 239 decision since the NSIS Responder may not have sufficient knowledge 240 about the NSIS Initiator at the time of delivering its address via 241 user applications. In most cases local decision for address 242 selection requires knowledge about the far end host. This might not 243 always be practical. 245 An example of such local based address selection is the IPv6 default 246 address selection mechanism (see [6]) where an IPv6 (or IPv6/v4) node 247 has to select which source and destination address to pick in order 248 to communicate with a far end node. The mechanism relies on 249 receiving input from the local resolver (DNS client or local hosts 250 file) about the far end node. In the context of multimedia 251 applications (and probably others as well), this address selection 252 mechanism will not be sufficient since the far end application device 253 is not necessarily known (the resolver client may return the 254 address(es) of the application signaling and not the addresses of the 255 actual application data flow recipient). Hence it can not decide 256 successfully in all cases which address to provide to the NSIS 257 Initiator. 259 Approach (2) is more efficient as it requires the NSIS Responder to 260 provide all its addresses (local scoped and global scoped ones) to 261 the NSIS Initiator. The NSIS Initiator needs to decide which address 262 to use. One possible way for the NSIS Initiator to decide which NSIS 263 Responder address to use is to check which address the NSIS responder 264 will reply back. This security mechanism is typically referred as 265 return-routability check. ICE [7] discusses the usage of approach 266 (2) for SIP User Agents (SIP UA) whereby the SIP UA will probe the 267 far end SIP UA to see from which address it will send a response back 268 to the probe. ICE [7] uses the STUN protocol [14] for the 269 return-routability check. In [9] the reverse routability, provided 270 by the STUN response, is used to check which address to respond to 271 counter RTP Denial of Service attacks. The same reverse routability 272 check could be achieved by the NSIS NATFW NSLP. 274 In the context of NSIS, the NSIS protocol itself should be used as 275 the probing mechanism. Consequently, the NSIS Initiator will 276 simultaneously send several NSIS messages towards the NSIS Responder, 277 one message per provided address. Figure 5 and Figure 6 show 278 approach (2) graphically. 280 Host C Host A MB1 App server/proxy 281 10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d 282 | | REA | | 283 | | -------------> | | 284 | | RESPONSE | | 285 | | <------------- | | 286 | |External Address| | 287 | | a.b.c.e | | 288 | | start-app with C | 289 | | ==============================> | 290 | | from A at 10.1.2.2,a.b.c.e | 291 | | 292 | start-app with C | | 293 | <============================================= | 294 | from A at 10.1.2.2,a.b.c.e | 295 | | 296 | REA | | 297 | -----------------------> | | 298 | RESPONSE | | 299 | <------------------------ | | 300 | External Address=a.b.c.e | | 301 | | | 302 | start-app with C ACK C:10.1.2.3,a.b.c.e | 303 | ==========================================> | 304 | from A at 10.1.2.2,a.b.c.e | 305 ' ' ' 306 ---- NATFW NSLP signaling 308 ==== User Application signaling (SIP, H323, MGCP, MEGACO etc) 310 Figure 5: Message flow for optimal routing 312 In Figure 5 Host A (same one as in Figure 2) uses a Reserve External 313 Address (REA) message which is intercepted by the edge NAT (in this 314 case MB1). The edge NAT responds with a RESPONSE message providing 315 the External Address (the global scoped address) to host A. Host A, 316 collects all available addresses where it could receive application 317 data, and then informs its application server that it wishes to 318 communicate with Host C while receiving data on the global and local 319 scoped address (and ports), 10.1.2.2 and a.b.c.e. The same will 320 happen with Host C, and Host C will be able to respond with the 321 application protocol to Host A about its data recipient addresses 322 (local and global scoped ones). Figure 6 shows how the CREATE 323 messages are simultaneously sent by A to all the returned addresses 324 for C. Host A receives both CREATE ACKs, the local scoped address 325 will therefore be considered as the address to use to send NSIS NATFW 326 messages to C. The problem is that an NSIS host might not be able to 327 distinguish a global scoped address from a local scoped address. To 328 cope with that problem, the following method is proposed: 330 The NATFW NSLP will have a NAT counter object, inserted in CREATE 331 messages and echoed back within CREATE responses. Every time an NSIS 332 aware NAT is traversed the NAT counter object is incremented. When 333 the NI host receives several RESPONSE messages, it will compare the 334 received NAT counter objects, the NR that responded with the smallest 335 NAT count will be the NR with which the NI will continue 336 communicating with. 338 In Figure 6, since no NSIS aware NAT (one returned NAT counter was 0) 339 and no Firewalls (NTLP layer [2] confirmed that there was no NATFW 340 NSLP intermediaries) are on the path between host A and host C (when 341 using the local scoped addresses), host A would either send a DELETE 342 message or let the NSIS state expire on its own; the NATFW NSLP 343 protocol is sufficiently robust to handle both. The behavior is left 344 to implementors and network administrators, since it has performance 345 implications. 347 Host C Host A MB1 App server/proxy 348 10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e 349 | | CREATE 2 | | 350 | CREATE 1 | -------------> |--, | 351 | <------------| NAT count=0 | | | 352 |RESPONSE1 | | |NAT count=1 | 353 | ------------>| | | | 354 |NAT count=0 | | | | 355 | CREATE 2 | | | 356 | <---------------------------- |<-' | 357 | RESPONSE 2 | | | 358 | ----------------------------> |--, | 359 | | RESPONSE 2 | | | 360 | |<------------- |<-' | 361 | | NAT count=1 | | 362 | App signaling | 363 | continues ... | 364 <==============================================> | 365 <================================> | 366 |+++++++++++> | | 367 | App data | | 368 |<+++++++++++ | | 369 | exchanges | | 370 | | | 371 | 373 ---- NATFW NSLP signaling 375 ==== User Application signaling (SIP, H323, MGCP, MEGACO etc) 377 Figure 6: NSIS signaling for optimal (intra realm) routing 379 With regard to the message flow in Figure 6 we can distinguish 380 between the following cases: 381 o In case that the NSIS Responder and the NSIS Initiator are located 382 within the same addressing realm, the NSIS Responder should 383 receive a response from all the addresses to which an NSIS message 384 was sent. The NSIS Initiator will then choose the address from 385 which RESPONSE message was returned with the smallest NAT counter, 386 as the destination address for messages destined to the NSIS 387 Responder. 388 o In case that the NSIS Responder and the NSIS Initiator are not 389 located within the same addressing realm, the NSIS Initiator would 390 only receive a response from the valid global scope address. In 391 case there is another NE within the network that has the same 392 local scoped address as the originally targeted NSIS Responder, 393 the wrongly targeted NSIS Responder should send back an error or 394 discard the message (the later would be preferable), Section 5 395 discusses the related security implications for this behavior. 396 This requires that the NR knows if it is the intended recipient, 397 this knowledge could be provided by the user application which is 398 aware of the application context requiring the establishment of an 399 NSIS session. However this assumption is no longer valid during 400 migration phases where a proxy operation mode is required ([1] and 401 [10]). 403 5. Security Considerations 405 Deployments having NRs with local scoped and global scoped address, 406 are subject to the same threats as the ones discussed in [4], [5] and 407 [3] as well as to the potential threat where a malicious NE with the 408 same local scoped address as the target NR respond back positively to 409 the NSIS message and consequently hijack the data flow. 411 This threat could be counter-measured by requiring the NR to respond 412 back with a challenge response information communicated by the 413 application signaling (assuming that the application was secured). 414 This type of end-to-end security mechanism (irrespectively which 415 degree of security it offers) have an impact on NSIS signaling 416 protocol and on the application layer protocol. If the responding NE 417 is not the application end host then the protocol operation is made 418 more complicated since the NE would have to act on behalf of the 419 application end host. This would be the case when the application 420 end host does not yet support the NATFW NSLP (this is the case of the 421 proxy mode scenario discussed in [1] and [10]). 423 To avoid the leakage of network topology information, when the CREATE 424 message is leaving the network the network Edge NAT or Edge Firewall 425 supporting the NATFW NSLP will need to remove the NAT count object. 427 6. Application Signaling Protocol Impacts 429 The proposed intra realm path optimization proposal requires that an 430 NR provides several data recipient addresses within the application 431 protocol, has obviously a certain impact on the application protocol. 432 In addition the application signaling needs to provide a challenge 433 response allowing the NR to respond back properly. This information 434 either need to be added to the application protocols or existing 435 protocol fields need to be used (preferred way). 437 Certain applications already provide the ability to advertise several 438 recipient addresses, [8] discusses the impact to SDP [11] and should 439 be used by all the application protocols using SDP. A similar 440 approach should be followed by other protocols, not using SDP, 441 including H.323 [12] and others requiring usage of NSIS with multiple 442 addresses for the NR.In addition [7] proposes the usage of a 443 challenge response parameter within SDP in the context of 444 applications using SIP, a similar approach should be used for other 445 applications. 447 7. NATFW NSLP required extensions 449 As shown in Section 4, to solve the intra-realm problem a new object 450 is required for the NATFW NSLP, a NAT count object. It is suggested 451 that this parameter be used in all CREATE messages ([1]). 453 Another required change for the NATFW NSLP are more of behavioral 454 type: 456 None Edge-NAT NATs traversed by REA messages: when the Edge NAT 457 responds to REA messages, these NATs will add to the RESPONSE message 458 an External Address object. This new behavior will allow the support 459 of several level of NATs, as shown in Figure 7, in the network while 460 supporting the intra-realm solution (approach 2) discussed in Section 461 4. 463 When the Edge NAT responds to REA messages, these NATs will add to 464 the RESPONSE message an External Address object. This new behavior 465 will allow the support of several level of NATs in the network, as 466 shown in Figure 7, Figure 8 and Figure 9, while supporting the 467 intra-realm solution (approach 2) discussed in Section 4. 469 +-----------------------------------+ 470 | 10/8 + 471 | Host A`-. 192.168.2/24 + ,-----------. 472 | 10.1.2.2 `. +-----+ +-----+ ,-'The NET `-. 473 | i.. MB1 |+-------| MB2 +- - 474 | Host C_.-'' +----- +-----+ `-. ,-' 475 | 10.1.2.3 Host B + `-----------' 476 | 192.168.2.30 + 477 +-----------------------------------+ 479 MB: NSIS NATFW NSLP aware NATFW 480 Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities 481 Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities 482 Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities 484 Figure 7: Nested NATs intra-realm communications support 486 Host A MB1 Host B MB2 App server/proxy 487 10.1.2.3 192.168.2.2 192.168.2.30 192.168.2.4 a.b.c.d 488 | | REA | |a.b.c.e | 489 |------------------------------------>| | 490 |RESPONSE[ExtADD, RESPONSE[ExtADD] | | 491 | ExtADD]-------------------- | | 492 |<----------- ExtADD=a.b.c.e | | 493 |ExtADD=a.b.c.e | | | 494 |ExtADD=192.168.2.2 start-app with B| | 495 |================================================> | 496 | from A at: 10.1.2.3,a.b.c.e,192.168.2.2 | 497 | | | | | 498 | | | start-App with B | 499 | | |<================== | 500 | | from A at: 10.1.2.3,a.b.c.e,192.168.2.2 501 | | | | | 502 | | | REA | | 503 | | |------->| | 504 | | RESPONSE[ExtADD] | 505 | | +<-------| | 506 | | |ExtADD=a.b.c.e | 507 | | | | | | 508 | start-App with B ACK B:a.b.c.e,192.168.2.30 509 | | |====================>| 510 | | from A at: 10.1.2.3,a.b.c.e,192.168.2.2 512 Figure 8: Nested NATs intra-realm message sequences: REA and NR 513 address advertisement 515 Host A MB1 Host B MB2 App server/proxy 516 10.1.2.3 192.168.2.2 192.168.2.30 192.168.2.4 a.b.c.d 517 | CREATE1 | | |a.b.c.e | 518 |------------>| | | | 519 | |CREATE1[NAT count=1] | | 520 | |------------->| | | 521 | | RESPONSE[NAT count=1] | | 522 | |<-------------| | | 523 | RESPONSE[NATcount=1] | | | 524 |<------------| | | | 525 | | | | | 526 | CREATE2 | | | | 527 |------------>|CREATE2[NAT count=1] | | 528 | | -------------------------+ | 529 | | CREATE2[NAT count=2]| NAT count=2.2.2 530 | | |<----------- | 531 | | | | | 532 | RESPONSE[NATcount=2] | | 533 | |<-------------| | | 534 | RESPONSE[NATcount=2] | | | 535 |<------------| | | | 537 Figure 9: Nested NATs intra-realm message sequences: CREATE and 538 RESPONSE exchanges 540 8. Perfomance considerations 542 The procedure requiring an NSIS Initiator to send NSIS messages to 543 several NR addresses, requires that the NI sends his NSIS messages at 544 the same time to avoid impacting real-time sensitive applications. 545 In case that the response to the message sent to the global scoped is 546 received first, it could potentially be used as a hint that no 547 response will be received from the NR's local scoped address. Hence 548 there is no point to continue to delay the address selection process 549 and proceed with the NSIS protocol operations. This assumption may 550 not be always applicable depending on the network topology and 551 network load at the moment of the protocol message exchanges. In 552 case the first response is received from a local scoped address and 553 has succefuly provided the challenge response maerial (Section 5) 554 provided by the application signaling protocol then the address 555 selection process ends, and the NSIS protocol operations continue. 557 9. IANA Considerations 559 There are no IANA considerations defined in this document. 561 10. Open issues 563 o Get agreement on solving the problem and its associated security 564 issue, is the challenge response sufficient?. 565 o Get feedback on which parameter is used within certain application 566 protocols (SIP, MEGACO, MGCP, H323) as the challenge response 567 parameter 568 o Where should the NSIS challenge response be done? within the NTLP 569 or the NSLP? if done in the NSLP several messaging associations 570 would have been established for no reasons, hence it seems more 571 interesting that the challenge response be handled at the NTLP 572 level. 574 11. Conclusion 576 Approach (2) provides a reasonable solution to the intra-realm 577 communication problem, while introducing a NATFW NSLP new object to 578 be added within CREATE messages. Although a new threat is added, its 579 mitigation is very similar to other NATFW NSLP threats discussed in 580 [5] hence no additional extensions would be required when this 581 solution is used. 583 12. Acknowledgments 585 The idea of using a NAT count object came out of discussions with 586 Georg Kullgren and Kenneth Sundell. Thanks to Elwyn Davies for his 587 comments on the draft. 589 13. References 591 13.1 Normative References 593 [1] Stiemerling, M., Martin, M., Tschofenig, H. and C. Aoun, "A NAT/ 594 Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT 595 draft-ietf-nsis-nslp-natfw-03.txt, July 2004. 597 [2] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 598 Messaging Protocol for Signaling", DRAFT 599 draft-ietf-nsis-ntlp-03.txt, November 2004. 601 [3] Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 602 Quality-of-Service signaling", DRAFT 603 draft-ietf-nsis-qos-nslp-03.txt, May 2004. 605 [4] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 606 DRAFT draft-ietf-nsis-threats-01.txt, January 2003. 608 [5] Fessi, A., Brunner, M., Stiemerling, M., Thiruvengadam, S., 609 Tschofenig, H. and C. Aoun, "Security Threats for the NAT/ 610 Firewall NSLP", DRAFT draft-fessi-nsis-natfw-threats-01.txt, 611 July 2004. 613 13.2 Informative References 615 [6] Draves, R., "Default Address Selection for Internet Protocol 616 version 6 (IPv6)", RFC 3484, February 2003. 618 [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 619 Methodology for Network Address Translator (NAT) Traversal for 620 Multimedia Session Establishment Protocols", 621 draft-ietf-mmusic-ice-01 (work in progress), February 2004. 623 [8] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for 624 the Session Description Protocol Grouping Framework", 625 draft-camarillo-mmusic-alt-02 (work in progress), October 2003. 627 [9] Rosenberg, J., "The Real Time Transport Protocol (RTP) Denial 628 of Service (Dos) Attack and its Prevention", DRAFT 629 draft-camarillo-mmusic-alt-01.txt, June 2003. 631 [10] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 632 Tschofenig, "NAT/Firewall NSLP Migration Considerations", DRAFT 633 draft-aoun-nsis-nslp-natfw-migration-01.txt, Februar 2004. 635 [11] Handley, M. and V. Jacobson, "SDP: Session Description 636 Protocol", RFC 2327, April 1998. 638 [12] ITU-T SG16, "Packet-based multimedia communications systems", 639 ITU-T H.323, November 2000. 641 [13] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for 642 SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in 643 progress), November 2001. 645 [14] Rosenberg et al, J., "STUN - Simple Traversal of User Datagram 646 Protocol (UDP) Through Network Address Translators (NATs)", RFC 647 3489, March 2003. 649 Authors' Addresses 651 Cedric Aoun 652 Nortel Networks 654 France 656 EMail: cedric.aoun@nortelnetworks.com 658 Hannes Tschofenig 659 Siemens AG 660 Otto-Hahn-Ring 6 661 Munich 81739 662 Germany 664 Phone: 665 EMail: Hannes.Tschofenig@siemens.com 666 URI: 668 Martin Stiemerling 669 Network Laboratories, NEC Europe Ltd. 670 Kurfuersten-Anlage 36 671 Heidelberg 69115 672 Germany 674 Phone: +49 (0) 6221 905 11 13 675 EMail: stiemerling@ccrle.nec.de 676 URI: 678 Marcus Brunner 679 Network Laboratories, NEC Europe Ltd. 680 Kurfuersten-Anlage 36 681 Heidelberg 69115 682 Germany 684 Phone: +49 (0) 6221 905 11 29 685 EMail: brunner@ccrle.nec.de 686 URI: http://www.brubers.org/marcus 688 Miquel Martin 689 Network Laboratories, NEC Europe Ltd. 690 Kurfuersten-Anlage 36 691 Heidelberg 69115 692 Germany 694 Phone: +49 (0) 6221 905 11 16 695 EMail: miquel.martin@ccrle.nec.de 696 URI: 698 Intellectual Property Statement 700 The IETF takes no position regarding the validity or scope of any 701 Intellectual Property Rights or other rights that might be claimed to 702 pertain to the implementation or use of the technology described in 703 this document or the extent to which any license under such rights 704 might or might not be available; nor does it represent that it has 705 made any independent effort to identify any such rights. Information 706 on the procedures with respect to rights in RFC documents can be 707 found in BCP 78 and BCP 79. 709 Copies of IPR disclosures made to the IETF Secretariat and any 710 assurances of licenses to be made available, or the result of an 711 attempt made to obtain a general license or permission for the use of 712 such proprietary rights by implementers or users of this 713 specification can be obtained from the IETF on-line IPR repository at 714 http://www.ietf.org/ipr. 716 The IETF invites any interested party to bring to its attention any 717 copyrights, patents or patent applications, or other proprietary 718 rights that may cover technology that may be required to implement 719 this standard. Please address the information to the IETF at 720 ietf-ipr@ietf.org. 722 Disclaimer of Validity 724 This document and the information contained herein are provided on an 725 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 726 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 727 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 728 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 729 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 730 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 732 Copyright Statement 734 Copyright (C) The Internet Society (2004). This document is subject 735 to the rights, licenses and restrictions contained in BCP 78, and 736 except as set forth therein, the authors retain all their rights. 738 Acknowledgment 740 Funding for the RFC Editor function is currently provided by the 741 Internet Society. 743 <