idnits 2.17.00 (12 Aug 2021) /tmp/idnits44749/draft-pashalidis-nsis-gist-legacynats-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 646. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) ** 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 102: '...re NAT - a GaNAT MAY implement a numbe...' RFC 2119 keyword, line 117: '...lements GIST and MAY also implement a ...' RFC 2119 keyword, line 408: '... dictate that P MUST NOT be forwarded...' RFC 2119 keyword, line 415: '... IPTRANS MUST thus be one of the GIS...' RFC 2119 keyword, line 418: '...stream GIST peer MAY also replace [inn...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 8, 2007) is 5424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: A later version (-05) exists of draft-pashalidis-nsis-gimps-nattraversal-03 == Outdated reference: draft-ietf-behave-nat-udp has been published as RFC 4787 == Outdated reference: draft-ietf-behave-rfc3489bis has been published as RFC 5389 == Outdated reference: draft-ietf-behave-turn has been published as RFC 5766 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS A. Pashalidis 2 Internet-Draft NEC 3 Intended status: Informational H. Tschofenig 4 Expires: January 9, 2008 Nokia Siemens Networks 5 July 8, 2007 7 GIST Legacy NAT Traversal 8 draft-pashalidis-nsis-gist-legacynats-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 9, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes an extension to the General Internet 42 Signalling Transport (GIST) protocol that enables the protocol to 43 traverse different types of Network Address Translator (NAT). These 44 NATs are assumed to not support GIST, i.e. to be "legacy" NATs. The 45 purpose of this extension is to enable GIST hosts to correctly 46 interpret signalling messages with respect to the data traffic they 47 refer to, in the presence of such NATs. Note that this extension 48 does not require changes to the format of GIST messages; it merely 49 requires some new behaviour for non-NAT GIST nodes. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Legacy NAT Traversal Mechanism . . . . . . . . . . . . . . . . 7 58 5.1. Traversal of NI-side legacy NATs . . . . . . . . . . . . . 7 59 5.1.1. Treatment of Data Traffic . . . . . . . . . . . . . . 10 60 5.1.2. Treatment of Signalling Traffic . . . . . . . . . . . 12 61 5.1.3. Refreshing NSIS State . . . . . . . . . . . . . . . . 12 62 5.2. Traversal of NR-side legacy NATs . . . . . . . . . . . . . 12 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . . 15 71 1. Introduction 73 Network Address Translators (NATs) modify certain fields in the IP 74 and transport layer header of the packets that traverse them. In the 75 context of signalling as specified by the General Internet Signalling 76 Transport (GIST) protocol [1], this behaviour may lead to the 77 installation of state at network nodes that may be inconsistent and 78 meaningless with respect to the data traffic that traverses these 79 nodes. 81 This document describes an extension to GIST that can be used in 82 order for GIST signalling messages to traverse GIST-unaware NATs in a 83 way that preserves the consistency of state that is installed in the 84 network with respect to the data flows to which the signalling 85 messages refer. As this extension exclusively operates at the GIST 86 layer, it is transparent to signalling applications. The document is 87 organised as follows. The next section introduces the terminology 88 that is used throughout this document. Section 3 provides a detailed 89 discussion of the NAT traversal problem and highlights certain design 90 decisions that have to be taken when addressing the problem. 91 Section 4 lists the assumptions on which the subsequently proposed 92 mechanisms are based. The proposed extension is described in 93 Section 5. 95 2. Terminology 97 The terminology, abbreviations and notational conventions that are 98 used throughout the document are as follows. 100 o DR: Data Receiver, same as Flow Receiver as defined in [1] 101 o DS: Data Sender, same as Flow Sender as defined in [1] 102 o GaNAT: GIST-aware NAT - a GaNAT MAY implement a number of NSLPs. 103 o GIST: General Internet Messaging Protocol for Signalling [1] 104 o NAT: Network Address Translator 105 o NI: NSIS Initiator; this is the GIST node (as defined in [1]) that 106 initiates a signalling session for a given NSLP. The NI may or 107 may not be identical to the DS or the DR. 108 o NR: NSIS Responder; this is the GIST node (as defined in [1]) that 109 acts as the last in a sequence of nodes that participate in a 110 given signalling session. The NR may or may not be identical to 111 the DR or the DS. 112 o NSIS: Next Steps in Signalling: The name of the IETF working group 113 that specified the family of signalling protocols of which this 114 document is also a member. The term NSIS is also used to refer to 115 this family of signalling protocols as a whole. 117 o GIST-aware: Implements GIST and MAY also implement a number of 118 NSLPs. 119 o GIST-unaware: GIST-unaware, does not implement any NSLP. The term 120 is synonymous to NSIS-unaware. 121 o NSLP: NSIS Signalling Layer Protocol, as defined in [1] 122 o downstream: as defined in [1] 123 o upstream: as defined in [1] 124 o MRI: Message Routing Information, as defined in [1] 125 o NLI.IA: Interface Address field of the Network Layer Information 126 object, as defined in [1] 127 o <- : Assignment operator. The quantity to the right of the 128 operator is assigned to the variable to its left. 129 o A.B: Element B of structure A. Example: [IP 130 header].SourceIPAddress denotes the source IP address of an IP 131 header. 132 o [data item]: This notation indicates that "data item" is a single 133 identifier of a data structure. (Square brackets do not denote 134 optional arguments in this document.) 136 3. Problem Statement 138 According to [1], all GIST messages between two peers carry IP 139 addresses in order to define the data flow to which the signalling 140 refers. Moreover, certain GIST messages also carry the IP address of 141 the sending peer, in order to enable the receiving peer to address 142 subsequent traffic to the sender. Packets that cross an addressing 143 boundary, say from addressing space S1 to S2, have the IP addresses 144 in the IP header translated from space S1 to S2 by the NAT; if GIST 145 payloads are not translated in a consistent manner, the MRI in a GIST 146 packet that crosses the boundary, e.g. from address space S1 to S2, 147 refers to a flow that does not exist in S2. In fact, the flow may be 148 invalid in S2 because at the IP address that belongs to S1 may not be 149 routable or invalid in S2. Moreover, the IP address of the sending 150 peer may also be not routable or invalid in the addressing space of 151 the receiving peer. The purpose of this document is to describe an 152 extension that enables GIST messages to be translated in a way that 153 is consistent with the translation that NATs apply to the IP headers 154 of the data traffic. 156 A NAT may be either GIST-unaware or GIST-aware. The traversal of 157 GIST-aware NATs is described in [2] and [3]. The subject matter of 158 this document is the traversal of GIST-unaware NATs. 160 A GIST-unaware NAT cannot tell data and signalling traffic apart. 161 The installation of the NAT binding for the signalling traffic in 162 such a NAT occurs typically independently from the installation of 163 the NAT binding for the data traffic. Furthermore, as the NAT cannot 164 associate the signalling and the data traffic, it cannot indicate 165 that an association exists between the two NAT bindings. Therefore, 166 in the presence of such a NAT, non-NAT GIST nodes that are located on 167 either side of the NAT have to cope with the NAT without assistance 168 from the NAT. This would typically require initially discovering the 169 NAT and subsequently establishing an association between between the 170 MRI in the signalling messages and the translated IP header in the 171 data traffic. Due to the variety of behaviours that a GIST-unaware 172 NAT may exhibit, establishing this association is a non-trivial task. 174 4. Assumptions 176 The discussion in this document is based on the following 177 assumptions. 179 1. No IP addresses and port numbers are carried in the payloads of 180 the NSLP. If this is not the case, then the NSLP has to provide 181 additional mechanisms for the traversal of NATs. These 182 mechanisms must be compatible the mechanisms described in this 183 document. 184 2. The path taken by the signalling traffic between those GIST peers 185 that have GIST-unaware NATs in between is such that the responses 186 to packets that a NAT sends on given interface arrive on the same 187 interface (if such responses are sent at all). 188 3. The path taken by signalling traffic remains fixed between the 189 two GIST peers, as far as the in-between NAT(s) are concerned. 190 That is, we assume that signalling traffic traverses the same set 191 of NATs until at least one of the following conditions is met. 192 * The NSIS state that is installed at the two GIST peers 193 expires. 194 * The NSIS state that is installed at the two GIST peers is 195 refreshed using a GIST QUERY. 196 * A new GIST QUERY/RESPONSE exchange takes place due to other 197 reasons, e.g. a detected route change. 198 Note that this assumption is not necessarily met by "normal" data 199 path coupled signalling. This is because, under "normal" data 200 path coupled signalling, the signalling traffic is "coupled" to 201 the data traffic at nodes that decide to act as GIST peers. 202 Thus, under "normal" path coupled signalling, it is not always an 203 error condition (e.g. a reason to trigger a "route change"), for 204 example, if the set of on-path nodes, which do not act as GIST 205 peers, changes, as long as adjacent GIST peers remain the same. 206 4. The data flow traverses the same set of NATs as the signalling 207 traffic. By assumption 3, this set of NATs is fixed until the 208 next GIST QUERY/RESPONSE procedure is executed. 210 5. The path-coupled routing method is used by the NSLP. (Other 211 routing methods are not considered in this version of this 212 document.) 213 6. The legacy NAT does not drop IP packets with a Router Alert 214 Option (RAO) or an IPv6 extensions header. Furthermore, the RAO 215 or extension header is also present in the forwarded packet. If 216 the NAT does not do this, then there is no way for a GIST QUERY 217 to traverse the NAT, which is a prerequisite for the mechanisms 218 described in this document. 220 +-----+ 221 +----+ NAT |-----+ 222 | | A | | 223 | +-----+ | 224 +------+ +------+ +--+---+ +------+ 225 +--+ | GIST | | IP | | IP | | GIST | +--+ 226 |DS+-+peer 1+--+router| |router+--+peer 2+-+DR| 227 +--+ +------+ +---+--+ +--+---+ +------+ +--+ 228 | +-----+ | 229 | | NAT | | 230 +----+ B +-----+ 231 +-----+ 233 Figure 1: Network with more than one NAT at an addressing boundary 235 Figure 1 illustrates the importance of assumptions (3) and (4). With 236 regard to that figure, suppose that a (D-mode) signalling session has 237 been setup between the two adjacent GIST peers 1 and 2 and that both 238 signalling and data traffic follows the path GIST peer 1 -> IP router 239 -> NAT A -> IP router -> GIST peer 2. Suppose now that, after some 240 time, GIST peer 1 decides to set up a C-mode connection with peer 2. 241 Suppose moreover that the left IP router decides to forward the 242 C-mode signalling traffic on the link towards NAT B. Thus, signalling 243 traffic now follows the alternative path GIST peer 1 -> IP router -> 244 NAT B -> IP router -> GIST peer 2. Note that this change in 245 forwarding between the two adjacent GIST peers does not trigger a 246 "route change" at the GIST layer because (a) it does not necessarily 247 destroy the adjacency of peer 1 and 2 and (b) it does not necessarily 248 destroy the coupling of the path taken by signalling traffic to that 249 taken by data traffic (at GIST nodes). Nevertheless, assumptions (3) 250 and (4) mandate that this situation does not occur. However, even if 251 such a situation occurs, the mechanisms described in this document 252 may still work as state expires after a certain timeout period. 254 Assumptions (2), (3) and (4) hold if, at an addressing boundary, only 255 one NAT exists. Due to security and management reasons, this is 256 likely to be the case in many settings. 258 5. Legacy NAT Traversal Mechanism 260 GIST-unaware NATs do not distinguish between signalling traffic and 261 data traffic. Furthermore, the behaviour of a GIST-unaware NAT with 262 respect to the establishment and the configuration of NAT bindings 263 may vary significantly from one NAT to another [4]. There exists no 264 means by which a GIST peer can predict how such a NAT will configure 265 a future binding. A GIST-unaware NAT allocates the binding that will 266 be used for the data traffic independently from the binding that is 267 used for the signalling traffic. Thereby the mapping of signalling 268 messages to data traffic is destroyed, and cannot be re-established 269 by GIST nodes. 271 The idea of enabling GIST traffic to traverse GIST-unaware NATs is 272 somewhat similar to the mechanisms on which Teredo [6] and the STUN 273 relay service [5], [7] are based. The idea is to tunnel signalling 274 and data traffic over UDP, such that both data and signalling traffic 275 use a single NAT binding. The GIST peer that is located on the other 276 side of the NAT then removes the outer headers and also performs 277 network address translation for both the signalling traffic 278 (including GIST payloads) and the data traffic, in a consistent 279 manner. 281 Note that two types of GIST-unaware NATs have to be dealt with, 282 namely those that are located at the NSIS initiator (NI-side), and 283 those that are located at the NSIS responder (NR-side). This 284 distinction arises due to the fact that NR-side NATs are likely to 285 drop traffic that does not match an existing binding. By contrast, 286 NI-side NATs typically create a new binding if no matching one is 287 found. 289 5.1. Traversal of NI-side legacy NATs 290 +----+ QUERY +----------+ QUERY +----+ 291 | |------>| |------>| | 292 | | RESP. | LEGACY | RESP. | | 293 | |<------| NAT |<------| | 294 data |GIST| | | |GIST| data 295 -----+ |NODE| | | |NODE| +---- 296 | | 1 | +----------------------+ | 2 | | 297 +--+----+-+ UDP TUNNEL +----------+ 298 signl.| | | +----------------------+ | | |signl. 299 -----+ +----+ +----------+ +----+ +---- 301 internal external 302 side side 304 Figure 2: High level overview of NI-side legacy NAT traversal 305 mechanism 307 The following may serve as indications for the existence of one or 308 more GIST-unaware NAT(s) between two GIST peers. For the purposes of 309 the discussion in this section, these peers are called the "upstream" 310 GIST peer (which also happens to be the querying peer) and the 311 "downstream" GIST peer (which also happens to be the responding 312 peer). These indications can only be detected by the receiver of a 313 GIST message, i.e. by the downstream peer. The first occasion these 314 indications may be detected is with the reception of a GIST QUERY 315 where the downstream peer assumes the role of the responder. Note 316 that, by assumption 6, the GIST QUERY is received by the responder. 317 Also note that != denotes inequality. 319 o The MRI.SourceIPAddress does not belong to the addressing space of 320 the responding peer. 321 o The MRI.DestinationIPAddress does not belong to the addressing 322 space of the responding peer. 323 o The IP address in the NLI.IA field does not belong to the 324 addressing space of the responding peer. 325 o The S flag is set and [IP header].SourceIPAddress != NLI.IA. 326 o This is a GIST QUERY and [IP header].DestinationIPAddress != 327 MRI.DestinationIPAddress. 329 Suppose, after detecting one or more of the above, the downstream 330 GIST peer believes that a NAT is located between itself and the 331 sender of the GIST QUERY. If this is indeed the case, then the NAT 332 will have installed a UDP NAT binding as a result of the QUERY 333 passing through it. The downstream GIST node constructs a D-mode 334 RESPONSE according to the following rules. 336 o The [IP header].SourceAddress is set equal to the responder's IP 337 address, i.e. [IP header].SourceAddress is set equal to NLI.IA. 338 o As a result of the above, the S flag in the RESPONSE is set. 339 o The MRI.[Source IP Address] field is replaced with [IP 340 header].SourceAddress of the QUERY, i.e. the public address of the 341 NAT. 342 o One stack proposal is added to the end of the set of proposals 343 that are included in the RESPONSE by default. This last item is a 344 proposal for UDP. It will be used for UDP tunnelling. The GIST 345 node must be prepared to accept IP traffic that is tunneled over 346 UDP on the advertised port. 348 The first of the above measures ensure that, even if the NAT exhibits 349 an "Address and Port Dependent Filtering" behaviour, as defined in 350 [4], the RESPONSE is not dropped by the NAT. Note that this is the 351 most restrictive filtering behaviour, and that, therefore, the 352 mechanism works also with less restrictive NATs. 354 The upstream GIST peer, on reception of the RESPONSE can also deduce 355 that a GIST-unaware NAT is likely to be located between itself and 356 the downstream GIST peer. This is possible because of the 357 discrepancy of SourceAddress in the MRI sent in the QUERY and the one 358 received in the RESPONSE. From that point onwards the upstream GIST 359 peer tunnels both the GIST messages that belong to the current 360 signalling session, and the data traffic to which they refer, over a 361 UDP tunnel that it sets up with the downstream GIST peer on the 362 advertised port. That is, the packets that the upstream GIST peer 363 sends are such that the outer IP header is followed by a UDP header, 364 which is in turn followed by an inner IP header. The same applies to 365 the downstream GIST peer. In order to set up a messaging 366 association, the upstream GIST node removes the last UDP proposal 367 from the set of proposal received in the RESPONSE, and selects a 368 profile as usual. 370 For every packet that the downstream GIST peer receives on the 371 advertised UDP port it checks that [Outer IP header].SourceAddress is 372 equal to [IP header].SourceAddress of the QUERY in response to which 373 the UDP port was advertised (i.e. the public address of the NAT). If 374 this check fails, the packet is silently discarded. Note that, in 375 order to perform this check, the peer needs to allocate some state 376 before a CONFIRM message is received. This state, however, is not 377 necessarily per-session state, and various DoS exposure mitigation 378 techniques can be applied if the peer finds itself heavily loaded. 379 One such measure is to temporarily turn off the support of GIST- 380 unaware NAT traversal. 382 A packet that the downstream peer receives over the tunnel is either 383 a GIST message or a data packet. It is a GIST message if [inner IP 384 header].DestinationAddress belongs to the peer (i.e. is equal to the 385 one advertised in the NLI.IA field), and a data packet otherwise. 386 Note that, if the downstream peer is also the DR, then this 387 distinction does not apply. However, in this case the inner 388 transport layer header can be used to unambiguously determine whether 389 the packet belongs to an established GIST messaging association, or a 390 data flow. 392 5.1.1. Treatment of Data Traffic 394 When the downstream GIST peer receives a data packet P from the 395 upstream GIST peer over the UDP tunnel, it should ensure that the 396 following conditions are met. 398 o The inner [IP header].[transport protocol] field and the inner 399 [Transport layer header].DestinationPort of P matches the MRI of a 400 GIST QUERY in response to which the UDP tunnel parameters were 401 advertised. Note that multiple such GIST queries may exist if the 402 same tunnel is used for multiple signalling sessions (and 403 therefore multiple data flows) between the upstream and the 404 downstream GIST peers. 405 o If the signalling session is to run over a secure connection (e.g. 406 IPsec, TLS), and if required by local policy, then the messaging 407 association has been established. That is, local policy may 408 dictate that P MUST NOT be forwarded until the messaging 409 association establishment has been completed sucessfully. 411 The downstream GIST peer then removes the outer IP and UDP headers, 412 replaces [inner IP header].SourceAddress with an IP address denoted 413 IPTRANS. This IP address must be chosen in a way that ensures that 414 packets sent to IPTRANS will arrive at the downstream GIST peer. 415 IPTRANS MUST thus be one of the GIST peer's own IP addresses 416 (preferably, but not necessarily, bound to the interface over which P 417 will be forwarded), unless in an exceptional situation, explained 418 below. The downstream GIST peer MAY also replace [inner transport 419 header].SourcePort with a different source port, denoted PORTTRANS. 420 The resulting data packet is forwarded according to the peer's 421 routing table. 423 A data packet K that arrives from the downstream direction, which 424 belongs to same bidirectional data flow as P but flows in the 425 opposite direction (i.e. from DR to DS), MUST be mapped to the 426 correct UDP tunnel towards the upstream GIST peer. Moreover, the 427 upstream peer (which is the tunnel endpoint) MUST be able to 428 demultiplex multiple data flows that may arrive over the same tunnel. 429 To this end, the downstream GIST peer MUST use a unique (IPTRANS, 430 PORTTRANS) pair for each tunelled data flow. Note that, in the 431 situation where the number of NATs over which the downstream GIST 432 node entertains tunnels, exceeds the number of IP addresses that the 433 downstream peer may chose IPTRANS from, then the number of tunnels 434 may exceed the number of available (IPTRANS,PORTTRANS) pairs (for a 435 given transport layer protocol). The same may happen in the presence 436 of tunnels over which multiple data flows are tunnelled. In such an 437 exceptional situation, i.e. when the downstream GIST runs out of 438 (IPTRANS, PORTTRANS) pairs (for a given transport layer protocol), 439 then it MAY use the public address of the NAT, behind which the data 440 flow originates, as IPTRANS. It should be noted that, in this case, 441 routing assymmetry on the path that the packet K takes on its way to 442 the downstream GIST node may cause the mechanism to fail, because K 443 may never arrive at the downstream GIST node. 445 When the downstream GIST peer receives a data packet K, it looks at 446 K.[IP header].DestinationAddress, K.[IP header].Protocol, and 447 K.[Transport layer header].DestinationPort. If the downstream GIST 448 node behaves as explained above, this triple uniquely defines the 449 tunnel, even in the presence of multiple NATs (possibly from multiple 450 domains), and multiple tunnels per NAT, as explained above. Before 451 the downstream GIST node forwards K over the tunnel to the upstream 452 GIST node, it MUST translate K.[IP header].DestinationAddress and, if 453 applicable, K.[IP header].DestinationPort according to the 454 translation applied to P. If the aforementioned triple does not match 455 an existing tunnel, then normal processing applies to K (whatever 456 that means at the downstream GIST node). 458 Finally, note that, if the data flow exists before signalling is 459 initiated, then the application may be adversely affected by the 460 mechanism described in this section. This is because, prior to 461 signalling, the DR sees the public address of the NAT as the address 462 of the DS. However, subsequent to signalling (and the associated 463 tunnelling), the DR will see IPTRANS as the address of the DS (and 464 may therefore assume that the DS has changed). In order to avoid 465 this, the downstream GIST peer could use the public address of the 466 NAT as IPTRANS if the data traffic already flows at the time that 467 signalling is initiated. In order, however, to select the correct 468 value for PORTTRANS, the downstream GIST peer must be able to 469 correlate the data traffic before tunneling and after tunnelling. 470 The source port in the inner transport layer header of a tunneled 471 data packet X that belongs to a given flow, is equal to the source 472 port of an non-tunneled data packet X' that belongs to the same flow, 473 if and only if the NAT binding over which X' travels is source port 474 preserving. Unfortunately, legacy NATs do not always install such 475 bindings [4]. It is NOT RECOMMENDED for the downstream GIST peer to 476 assume that NAT bindings are source port preserving. Therefore, the 477 mechanism described in this section assumes that data traffic flows 478 after signalling state has been setup in the network. 480 5.1.2. Treatment of Signalling Traffic 482 The processing of GIST messages that arrive over a UDP tunnel adheres 483 to the usual rules once the outer IP and UDP headers are stripped 484 off. For GIST messages that the downstream GIST peer sends towards 485 the upstream direction, the correct IP/UDP encapsulation must be 486 used. To this end, the peer must keep the necessary state in 487 association with the routing state for the upstream GIST peer. For 488 GIST messages that are sent towards the downstream direction, the 489 GIST peer must also change the MRI such that it reflects the 490 translation for the data traffic. That is, the peer MUST set 491 MRI.SourceIPAddress = IPTRANS and, if applicable, 492 MRI.SourcePort=PORTTRANS. 494 5.1.3. Refreshing NSIS State 496 According to [1], NSIS signalling state must be refreshed regularly. 497 To this end, the NI periodically sends GIST QUERY messages which are 498 forwarded along the data path. When the upstream GIST peer receives 499 such a QUERY (i.e. a QUERY that has the purpose of refreshing 500 signalling state), and if a UDP tunnel already exists for the data 501 traffic to which this QUERY refers to, then the upstream peer MUST 502 send this QUERY as if no tunnel existed, i.e. as described above. 503 This is in order to enable a new GIST node to be identified as the 504 downstream peer. However, the upstream GIST peer SHOULD use the same 505 source port in the refreshing QUERY as in the outer UDP header of the 506 tunnelled packets. This is in order to turn the NSIS refresh 507 mechanism into a mechanism that keeps the UDP NAT binding alive. 508 This is important if no data traffic is sent for an extended period 509 of time. 511 If the downstream GIST peer receives a GIST QUERY for which a tunnel 512 and a GIST messaging association already exists, then it send the 513 response over the existing messaging association, in accordance with 514 [1]. This involves tunnelling the RESPONSE over the tunnel, as 515 descibed above. If the downstream GIST peer receives a GIST QUERY 516 for which a tunnel, but no messaging association exists yet, then, if 517 policy permits, the peer sends the RESPONSE as if no tunnel existed. 518 In this RESPONSE, the peer MAY propose the same tunnel parameters as 519 in the original RESPONSE. 521 5.2. Traversal of NR-side legacy NATs 523 The traversal of NR-side legacy NATs is not as straight-forward as 524 the case of NI-side legacy NAT traversal. This is because an NR-side 525 legacy NAT is likely to block all "unsolicited" incoming traffic. 526 That is, such a NAT is unlikely to install a NAT binding on the basis 527 of a packet that arrives on its public side. Instead, such packets 528 are typically only forwarded towards the private side, if they match 529 an already installed NAT binding. 531 The NR-side legacy NAT traversal mechanism descibed in this document 532 only works with a certain subset of legacy NATs, namely those that 533 are configured with static NAT bindings. In particular, it is 534 assumed that the NR-side legacy NATs are configured to forward all 535 incoming UDP packets that are destined to one of the NAT's public 536 addresses, and which carry destination port number XXX (Editor's 537 note: replace XXX with the well-known port number of GIST), to an 538 internal IP address, denoted IPINT. It is further assumed that IPINT 539 is assigned to a GIST node, denoted INTGIST. It is assumed that 540 INTGIST knows the IP addresses assigned to the legacy NAT, and it is 541 aware of fact that a static binding points to it. 543 A GIST QUERY that arrives at the legacy NAT is now forwarded to 544 INTGIST due to the static binding. INTGIST 546 6. Security Considerations 548 Editor's note: this section will be completed after normative 549 behaviour has been fully specified. 551 7. Acknowledgements 553 The authors would like to thank Robert Hancock and Martin Stiemerling 554 for his insightful comments. 556 8. References 558 8.1. Normative References 560 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 561 Signalling Transport", draft-ietf-nsis-ntlp-13 (work in 562 progress), April 2007. 564 [2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS 565 Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 566 (work in progress), February 2007. 568 [3] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", 569 draft-pashalidis-nsis-gimps-nattraversal-03.txt (work in 570 progress), June 2006. 572 [4] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 573 Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress), 574 May 2006. 576 [5] Rosenberg, J., Tschofenig, H., Huitema, C., Mahy, R., and D. 577 Wing, "Simple Traversal of UDP Through Network Address 578 Translators (NAT) (STUN))", draft-ietf-behave-rfc3489bis-03 579 (work in progress), February 2006. 581 8.2. Informative References 583 [6] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 584 Address Translations (NATs)", RFC 4380, February 2006. 586 [7] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 587 Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in 588 progress), March 2007. 590 Authors' Addresses 592 Andreas Pashalidis 593 NEC 594 Kurfuersten-Anlage 36 595 Heidelberg 69115 596 Germany 598 Email: Andreas.Pashalidis@netlab.nec.de 600 Hannes Tschofenig 601 Nokia Siemens Networks 602 Otto-Hahn-Ring 6 603 Munich, Bavaria 81739 604 Germany 606 Email: Hannes.Tschofenig@nsn.com 608 Full Copyright Statement 610 Copyright (C) The IETF Trust (2007). 612 This document is subject to the rights, licenses and restrictions 613 contained in BCP 78, and except as set forth therein, the authors 614 retain all their rights. 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 619 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 620 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 621 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Intellectual Property 626 The IETF takes no position regarding the validity or scope of any 627 Intellectual Property Rights or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; nor does it represent that it has 631 made any independent effort to identify any such rights. Information 632 on the procedures with respect to rights in RFC documents can be 633 found in BCP 78 and BCP 79. 635 Copies of IPR disclosures made to the IETF Secretariat and any 636 assurances of licenses to be made available, or the result of an 637 attempt made to obtain a general license or permission for the use of 638 such proprietary rights by implementers or users of this 639 specification can be obtained from the IETF on-line IPR repository at 640 http://www.ietf.org/ipr. 642 The IETF invites any interested party to bring to its attention any 643 copyrights, patents or patent applications, or other proprietary 644 rights that may cover technology that may be required to implement 645 this standard. Please address the information to the IETF at 646 ietf-ipr@ietf.org. 648 Acknowledgment 650 Funding for the RFC Editor function is provided by the IETF 651 Administrative Support Activity (IASA).