idnits 2.17.00 (12 Aug 2021) /tmp/idnits63032/draft-pashalidis-nsis-gimps-nattraversal-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1733. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 9 instances of lines with non-RFC2606-compliant FQDNs 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 105: '...re NAT - a GaNAT MAY implement a numbe...' RFC 2119 keyword, line 120: '...lements GIST and MAY also implement a ...' RFC 2119 keyword, line 168: '...e sequel. A GaNAT MAY also support at...' RFC 2119 keyword, line 181: '... GaNAT MUST implement a policy accor...' RFC 2119 keyword, line 317: '... MUST follow the transparent approac...' (13 more instances...) 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 24, 2005) is 6053 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: 'UDP HEADER' on line 828 == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') == 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. '2') Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS A. Pashalidis 3 Internet-Draft H. Tschofenig 4 Expires: April 27, 2006 Siemens 5 October 24, 2005 7 NAT Traversal for GIST 8 draft-pashalidis-nsis-gimps-nattraversal-01.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 April 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes how different types of Network Address 42 Translator (NAT) interact with the General Internet Signalling 43 Transport (GIST) protocol. The purpose of this interaction is for 44 signalling traffic to traverse the NATs in a way that preserves its 45 semantics with respect to the data flows it corresponds to. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 11 53 5. Transparent NAT traversal for GIST . . . . . . . . . . . . . . 13 54 5.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 13 55 5.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 18 56 5.3. NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 21 57 5.4. Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 25 58 6. Non-transparent NAT traversal . . . . . . . . . . . . . . . . 26 59 6.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 26 60 6.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 30 61 6.3. GIST peer processing . . . . . . . . . . . . . . . . . . . 34 62 7. GIST-unaware NATs . . . . . . . . . . . . . . . . . . . . . . 36 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 64 8.1. Service Denial Attacks . . . . . . . . . . . . . . . . . . 39 65 8.2. Network Intrusions . . . . . . . . . . . . . . . . . . . . 40 66 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 68 11. Normative References . . . . . . . . . . . . . . . . . . . . . 43 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 70 Intellectual Property and Copyright Statements . . . . . . . . . . 45 72 1. Introduction 74 Network Address Translators (NATs) modify certain fields in the IP 75 header of the packets that traverse them. In the context of 76 signalling as specified by the General Internet Signalling Transport 77 (GIST) protocol [1], this behaviour may lead to the installation of 78 state at network nodes that may be inconsistent and meaningless with 79 respect to the actual traffic that traverses these nodes. 81 This document describes how GIST signalling messages traverse NATs in 82 a way that preserves the consistency of state that is installed in 83 the network with respect to the data flows to which the signalling 84 messages refer. As the mechanisms that are described in this 85 document exclusively operate at the GIST layer, they are transparent 86 to signalling applications. The document is organised as follows. 87 The next section introduces the terminology that is used throughout 88 this document. Section 3 provides a detailed discussion of the NAT 89 traversal problem and highlights certain design decisions that have 90 to be taken when addressing the problem. Section 4 lists the 91 assumptions on which the proposed mechanisms are based. Section 5 92 presents the proposed mechanisms for "transparent" NAT traversal, and 93 ??? presents the proposed mechanisms where such protection is 94 required. 96 2. Terminology 98 The terminology, abbreviations and notational conventions that are 99 used throughout the document are as follows. 101 o DR: Data Responder, as defined in [1] 103 o DS: Data Sender, as defined in [1] 105 o GaNAT: GIST-aware NAT - a GaNAT MAY implement a number of NSLPs. 107 o GIST: General Internet Messaging Protocol for Signalling [1] 109 o NAT: Network Address Translator 111 o NI: NSIS Initiator, as defined in [1] 113 o NR: NSIS Responder, as defined in [1] 115 o NSIS: Next Steps in Signalling: The name of the IETF working group 116 that specified the family of signalling protocols of which this 117 specification is also a member. The term NSIS is also used to 118 refer to this family of signalling protocols as a whole. 120 o GIST-aware: Implements GIST and MAY also implement a number of 121 NSLPs. 123 o GIST-unaware: GIST-unaware, does not implement any NSLP. 125 o NSLP: NSIS Signalling Layer Protocol, as defined in [1] 127 o downstream: as defined in [1] 129 o upstream: as defined in [1] 131 o MRI: Message Routing Information, as defined in [1] 133 o NLI.IA: Interface Address field of the Network Layer Information 134 header field, as defined in [1] 136 o <- : Assignment operator. The quantity to the right of the 137 operator is assigned to the variable to its left. 139 o A.B: Element B of structure A. Example: [IP 140 header].SourceIPAddress denotes the source IP address of an IP 141 header. 143 o [data item]: This notation indicates that "data item" is a single 144 identifier of a data structure. (Square brackets do not denote 145 optional arguments in this document.) 147 3. Problem Statement 149 According to [1], all GIST messages between two peers carry IP 150 addresses in order to define the data flow to which the signalling 151 refers. Moreover, certain GIST messages also carry the IP address of 152 the sending peer, in order to enable the receiving peer to address 153 subsequent traffic to the sender. Packets that cross an addressing 154 boundary, say from addressing space S1 to S2, have the IP addresses 155 in the IP header translated from space S1 to S2 by the NAT; if GIST 156 payloads are not translated in a consistent manner, the MRI in a GIST 157 packet that crosses the boundary, e.g. from address space S1 to S2, 158 refers to a flow that does not exist in S2. In fact, the flow may be 159 invalid in S2 because at the IP address that belongs to S1 may not be 160 routable or invalid in S2. Moreover, the IP address of the sending 161 peer may also be not routable or invalid in the addressing space of 162 the receiving peer. The purpose of this document is to describe a 163 way for GIST messages to be translated in a way that is consistent 164 with the translation that NATs apply to the IP headers of both 165 signalling and data traffic. 167 A NAT may either be GIST-unaware or GIST-aware. We denote a GIST- 168 aware NAT as a GaNAT in the sequel. A GaNAT MAY also support at 169 least one NSLP. Note that there exists an NSLP, namely the NATFW 170 NSLP [2], that specifically addresses NAT traversal for data flows. 171 Inevitably, the NATFW NSLP also provides the necessary mechanisms for 172 the related signalling to traverse the NATs involved. Consider a 173 GaNAT that supports both the NATFW NSLP, and the NAT traversal 174 extension to GIST that is specified in this document. Suppose now 175 that a GIST QUERY message arrives at this GaNAT that contains the 176 NSLP identifier (NSLPID) of the NATFW NSLP. A question that arises 177 is whether the GaNAT should use the GIST NAT traversal extension 178 defined in this document, or the NATFW NSLP mechanism, in order to 179 provide "NAT traversal" for both the signalling message and the data 180 flow to which it refers. The answer to this question is that such a 181 GaNAT MUST implement a policy according to which method is used in 182 preference to the other. Note, however, that, should the GaNAT 183 prefer the GIST NAT traversal to NATFW NSLP, then it will happen, if 184 no on-path GaNATs exist that prefer the NATFW NSLP, that the 185 downsteam NATFW peer will be unable to discover any downstream NATFW 186 NSLP peers. This may make the entire NATFW session obsolete. 188 Clearly, if a GaNAT does not implement the NATFW NSLP, then the only 189 way for the signalling and the data flow to traverse that GaNAT, is 190 for the necessary mechanisms to operate on the GIST layer. The same 191 holds when the NSLP that is being signalled is an NSLP other than the 192 NATFW NSLP. Enabling NAT traversal in presicely these circumstances 193 is the motivation of this specification. 195 In general, a given data flow between a data sender (DS) and a data 196 receiver (DR) may have to traverse a number of NATs, some of which 197 may be GIST-and-NATFW-aware, some may be GIST-aware, and some may be 198 GIST-unaware. Additionally, NSLP signalling for such a data flow may 199 be required to traverse through a subset of those NATs. Whether or 200 not the routing inftrastructure and state of the network causes the 201 signalling for such a data flow to traverse the same NATs as the flow 202 depends, among other things, on which NSLP is being signalled. While 203 signalling of the QoS NSLP, for example, might not traverse any of 204 the NATs that are traversed by the data flow, the signalling of the 205 NATFW NSLP traverses at least those NATs that implement the NATFW 206 NSLP (otherwise the signalling path would no longer be coupled to the 207 data path, as this coupling is defined by the GIST QUERY/RESPONSE 208 discovery mechanism for the "path coupled" Message Routing Method). 209 It is desirable that the NAT traversal extension for GIST provides 210 NAT traversal for every possible combination of NATs, either on the 211 data or the signalling path, in a secure manner. 213 Due to the GIST QUERY/RESPONSE discovery mechanism (according to 214 which QUERY messages are simply forwarded if the current node does 215 not support the required NSLP), two GIST nodes typically identify 216 themselves as NSLP peers only if they both implement the same NSLP. 217 This means that, if one or more NATs that are unaware of this NSLP 218 are between them, then the two NSLP peers are not able to discover 219 each other at all. This is because, even in the unlikely event that 220 the NAT bindings that are necessary for the GIST traffic to traverse 221 the in-between NAT(s) exist, the NLI.IA field included in the 222 RESPONSE message sent by the downstream GIST peer is invalid (or the 223 IP address is unreachable) in the address space of the upstream GIST 224 peer. In order to overcome this limitation, either the two peers 225 need to cope with the in-between NAT(s), or, if the NAT(s) are 226 GaNATs, they (the GaNATs) need to apply additional processing in 227 order to transparently create and maintain consistency between the 228 information in the header of GIST signalling messages and the 229 information in the IP header of the data traffic. Additionally, if 230 NSLP-aware NATs are on the data path, then these NATs should process 231 NSLP traffic in a way that preserves consistency after address 232 translation. This processing deviates from the processing of NSLP- 233 aware non-NAT nodes. In the following sections we specify mechanisms 234 that aim to overcome the limitation of two adjacent GIST peers not 235 being able to execute an NSLP in the presence of in-between NAT(s). 237 Note that a number of different situations has to be dealt with, 238 depending on the level of NSIS support by a NAT. The following 239 combinations of NATs that are located between two adjacent GIST peers 240 are considered. 242 o all NAT(s) are GIST-unaware 244 o all NAT(s) are (NSLP-unaware) GaNAT(s) 246 o all NAT(s) are NSLP-aware 248 o a combination of the above NAT types. 250 The approach taken in this document is to propose separate mechanisms 251 for the traversal of each of the above type of NAT. If NATs that 252 belong to multiple types exist on the path between two adjacent NSLP 253 peers, the proposed mechanisms should work in combination. Thus, 254 traversal of multiple NATs of different types should not require 255 further specification from a functional perspective. However, 256 security issues that arise due to the combination of NAT types may 257 have to be considered. 259 A GIST-unaware NAT cannot tell data and signalling traffic apart. 260 The installation of the NAT binding for the signalling traffic in 261 such a NAT occurs typically independently from the installation of 262 the NAT binding for the data traffic. Furthermore, as the NAT cannot 263 associate the signalling and the data traffic in any way, it cannot 264 indicate that an association exists between the two NAT bindings. 265 Therefore, in the presence of such a NAT, GIST nodes that are located 266 on either side of the NAT have to cope with the NAT without 267 assistance from the NAT. This would typically require initially 268 discovering the NAT and subsequently establishing an association 269 between between the MRI in the signalling messages and the translated 270 IP header in the data traffic. Due to the variety of behaviours that 271 a GIST-unaware NAT may exhibit, establishing this association is a 272 non-trivial task. Therefore, traversal of such (i.e. GIST-unaware) 273 NATs is considered a special case and is further discussed in 274 Section 7. 276 Traversal of GaNAT(s) is comperatively more straightforward. This is 277 because, based on the MRI in a given incoming GIST message, a GaNAT 278 can identify the data flow to which the message refers. It can then 279 check its NAT binding cache and determine the translation that is 280 (or, if no NAT binding for the flow exists yet, will be) applied to 281 the IP header of the data flow. The GaNAT can then include 282 sufficient information about this translation into the signalling 283 message, such that its receiver (i.e. the GIST peer that receives the 284 data traffic after network address translation has been applied) can 285 map the signalling message to the data flow. 287 There exist a variety of ways for a GaNAT to encode the 288 abovementioned information into signalling messages. In this 289 document the following two ways are considered. 291 1. Non-transparent apprach: The GaNAT includes an additional "NAT 292 Traversal" payload (see section A.3.8 of [1]) into the GIST 293 header of the GIST QUERY message. This "NAT Traversal" payload 294 is echoed by the GIST responder on the other side of the NAT. 295 Both peers use the information in this payload in order to map 296 subsequent signalling messages to the data flows they refer to. 298 2. Transparent approach: The GaNAT replaces GIST header fields in a 299 way that is consistent with the translation it applies to the 300 data traffic, as necessary. The GaNAT does this GIST QUERY and 301 RESPONSE messages, for D-mode as well as for C-mode messages 302 throughout the duration of the signalling session. 304 The second approach being "transparent" means that a GaNAT that 305 follows this approach remains completely transparent to the GIST 306 peers that are located either side of it. Thus, this approach works 307 even if these GIST peers do not support the NAT traversal object for 308 GIST (as described in section 7.2 of [1]). Unfortunately though, the 309 transparent approach does not work if the GaNAT is NSLP-unaware and 310 if signalling traffic is to be cryptographically protected between 311 the two GIST peers that are located either side of the GaNAT. If, 312 however, the GaNAT is NSLP-aware, then cryptographic protection is 313 terminated at the GaNAT (i.e. the GaNAT is a GIST peer itself). In 314 this scenario, it is clearly preferable for the GaNAT to follow the 315 transparent approach, rather than to include a NAT Traversal object. 316 Thus, if a GaNAT acts as a GIST peer for a signalling session, it 317 MUST follow the transparent approach, as described in Section 5.3. 318 However, due to the fact that the transparent approach does not work 319 if signalling is to be cryptographically protected, a GaNAT MUST also 320 implement the non-transparent approach (for the case where an NSLP is 321 signalled that the GaNAT does not support), unless the GaNAT is going 322 to be used only in deployments where cryptographic protection of 323 signalling traffic is not a requirement. 325 Note that a GaNAT MAY implement both approaches. If such a GaNAT is 326 NSLP-unaware, it can then adopt the correct behaviour, based on 327 whether or not cryptographic protection is required for the 328 signalling traffic between two GIST peers. If such protection is 329 required, the GaNAT MUST adopt the mechanisms that follow the non- 330 transparent approach; if it is not, it MAY follow the mechanisms 331 implementing the transparent approach. The GaNAT can tell whether or 332 not cryptographic protection is required from the stack proposals 333 that are exchanged in the GIST QUERY and RESPONSE messages; inclusion 334 of IPsec or TLS proposals amounts to cryptographic protection being 335 required. 337 Regardless of which approach is taken, after a GIST response passes 338 through an NSLP-unaware GaNAT, the GaNAT should expect a messaging 339 association to be set up between the two involved GIST peers. For 340 this to happen, the GaNAT has to allow traffic to traverse it. From 341 a security perspective, the GaNAT should allow the minimum necessary 342 traffic types to traverse. Additionally, the amount of per 343 signalling session state that is allocated at a GaNAT should be 344 minimised for reasons of efficiency and resistance to service denial 345 attacks. For these reasons, it makes sense for the GaNAT to be able 346 to predict with certainty which of the GIST responder's stack 347 proposal will be used by the initiator for the establishement of a 348 messaging association. This can be accomplished by having the GaNAT 349 modify the stack configuration object in the GIST RESPONSE as it 350 passes though it such that the initiator is forced to use a 351 particular stack proposal and, if applicable, a particular transport 352 layer destination port. 354 The reason why it is preferable for the GaNAT to modify only the 355 stack configuration data object (as opposed to the stack proposal 356 object) is that the GIST responder expects its original stack 357 proposal to be included in the GIST CONFIRM message. The initiator 358 would not be able to echo that object as it would not have seen it 359 and, if signalling messages are cryptographically protected, then the 360 GaNAT cannot replace the stack proposal in the GIST CONFIRM message 361 with the one the responder expects, without causing cryptographic 362 checks to fail at the responder. Thus, the approach taken in this 363 document is for the GaNAT to render invalid all but one stack 364 configuration data objects in the GIST RESPONSE message. How this is 365 done depends on the format of this object. If, for example, it 366 contains transport layer port numbers, it is rendered invalid by 367 setting these numbers to zero. 369 A question arises due to the fact that the stack proposal carried by 370 a GIST QUERY may include multiple proposals of which some provide 371 cryptographic protection for signalling traffic and some do not. 372 Which behaviour should a GaNAT that supports both approaches assume 373 in this case? In order to provide maximise the probability that 374 cryptographic protection is going to used, the GaNAT MUST follow the 375 non-transparent approach in this case. 377 4. Assumptions 379 The discussion in this document is based on the following 380 assumptions. 382 1. No IP addresses and port numbers are carried in the payloads of 383 an NSLP. 385 2. The path taken by the signalling traffic between those GIST peers 386 that have GaNATs in between is such that the responses to packets 387 that a GaNAT sends on given interface arrive on the same 388 interface (if such responses are sent at all). 390 3. The path taken by signalling traffic remains fixed between the 391 two GIST peers, as far as the in-between GaNATs are concerned. 392 That is, we assume that signalling traffic traverses the same 393 GaNAT(s) until at least one of the following conditions is met. 395 * The NSIS state that is installed at the two GIST peers 396 expires. 398 * The NSIS state that is installed at the two GIST peers is 399 refreshed using a GIST QUERY. 401 * A new GIST QUERY/RESPONSE exchange takes place due to other 402 reasons, e.g. a detected route change. 404 Note that this assumption is not necessarily met by "normal" data 405 path coupled signalling. This is because, under "normal" data 406 path coupled signalling, the signalling traffic is "coupled" to 407 the data traffic at nodes that decide to act as GIST peers. 408 Thus, under "normal" path coupled signalling, it is not an error 409 condition (e.g. a reason to trigeer a "route change"), for 410 example, if the set of on-path nodes, which do not act as GIST 411 peers, changes, as long as adjacent GIST peers remain the same. 413 4. The data flow traverses the same set of GaNATs as the signalling 414 traffic. By assumption 3, this set of GaNATs is fixed until the 415 next GIST QUERY/RESPONSE procedure is executed. 417 +-----+ 418 +----+GaNAT|-----+ 419 | | A | | 420 | +-----+ | 421 +------+ +------+ +--+---+ +------+ 422 +--+ | GIST | | IP | | IP | | GIST | +--+ 423 |DS+-+peer 1+--+router| |router+--+peer 2+-+DR| 424 +--+ +------+ +---+--+ +--+---+ +------+ +--+ 425 | +-----+ | 426 | |GaNAT| | 427 +----+ B +-----+ 428 +-----+ 430 Figure 1: Network with more than one NAT at an addressing boundary 432 Figure 1 illustrates the importance of assumptions (3) and (4). With 433 regard to that figure, suppose that a (D-mode) signalling session has 434 been setup between the two adjacent GIST peers 1 and 2 and that both 435 signalling and data traffic follows the path GIST peer 1 -> IP router 436 -> GaNAT A -> IP router -> GIST peer 2. Suppose now that, after some 437 time, GIST peer 1 decides to set up a C-mode connection with peer 2. 438 Suppose moreover that the left IP router decides to forward the 439 C-mode signalling traffic on the link towards GaNAT B. Thus, 440 signalling traffic now follows the alternative path GIST peer 1 -> IP 441 router -> GaNAT B -> IP router -> GIST peer 2. Note that this change 442 in forwarding between the two adjacent GIST peers does not trigger a 443 "route change" at the GIST layer because (a) it does not necessarily 444 destroy the adjacency of peer 1 and 2 and (b) it does not necassarily 445 destroy the coupling of the path taken by signalling traffic to that 446 taken by data traffic (at GIST nodes). Nevertheless, assumptions (3) 447 and (4) mandate that this situation does not occur. However, even if 448 such a situation occurs, the mechanisms described in this document 449 may still work as state expires after a certain timeout period. 451 If assumption (1) does not hold, the NSLP has to provide additional 452 mechanisms for the traversal of (Ga)NATs. These mechanisms must be 453 compatible with the mechanisms employed by GIST. Assumptions (2), 454 (3) and (4) hold if, at an addressing boundary, only one NAT exists. 455 Due to security and management reasons, this is likely to be the case 456 in many settings. 458 5. Transparent NAT traversal for GIST 460 This section describes the operation of GaNATs that implement the 461 transparent approach listed in Section 3. Note that the GaNAT may 462 follow this approach only if it is unaware of the NSLP that is being 463 signalled, and when no cryptographic protection of signalling data is 464 requested by the two NSLP peers. 466 Note that we have to deal with two types of GaNATs, namely those that 467 are located at the NSIS initiator (NI-side), and those that are 468 located at the NSIS responder (NR-side). This distinction arises due 469 to the fact that NI-side and NR-side GaNATs obtain the destination IP 470 address for forwarded packets in different ways. 472 5.1. NI-side NSLP-unaware GaNATs 474 This section describes the "transparent" operation of an NI-side, 475 NSLP-unaware GaNAT. 477 For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT 478 executes the following algorithm. 480 1. If P has a RAO followed by the GIST header with an NSLP ID that 481 is not supported, it is identified as a GIST QUERY. In this case 482 the GaNAT performs the following. 484 1. We denote P as GQ. It looks at the stack proposal ST in GQ. 485 If it indicates that cryptographic protection is required, 486 the mechanism that is applies is the one described in ???. 488 2. The GaNAT remembers GQ along with the interface on which it 489 arrived. We call this interface the "upstream link". 491 3. It searches its table of existing NAT bindings against 492 entries that match the GQ.MRI. A matching entry means that 493 the data flow, to which the signalling refers, already 494 exists. 496 1. If a matching entry is found, the GaNAT looks at which 497 link the packets of the data flow are forwarded; we call 498 this link the "downstream" link. Further, the GaNAT 499 checks how the headers of the data flow (IP addresses, 500 port numbers, etc) are translated according to this NAT 501 binding. We denote [IP header].SourceIPAddress used on 502 the downstream link as IPGaNATds, and the source port 503 number used to forward the data traffic as SPNDTGaNATds. 504 The NAT may also use a different source port number when 505 forwarding signalling traffic. This port number is 506 denoted as SPNSTGaNATds. 508 2. If no matching entry is found, the GaNAT determines, 509 based on its routing table, the link on which packets 510 that match GQ.MRI (excluding GQ.MRI.SourceIPAddress) 511 would be forwarded. We call this link the "downstream 512 link". Then, the GaNAT acquires an IP address for itself 513 on the downstream link. (This address could be dynamic 514 or static.) This address will be used to forward both 515 signalling and data traffic on the downstream link. If 516 it also performs port translation, the GaNAT also 517 acquires a source port number for the data traffic on the 518 downstream link. This will be used with the NAT binding, 519 if such a binding will be established for the data 520 traffic at a later stage, and is denoted as SPNDTGaNATds. 521 The signalling traffic packets may also be forwarded 522 using the a different source port number as the incoming 523 packets. We denote the acquired IP address as IPGaNATds 524 and the source port number for the signalling traffic as 525 SPNSTGaNATds. 527 Issues: The reason why the GaNAT may also assign a 528 different source port number to the signalling traffic, 529 is to enable the GaNAT to demultiplex (i.e. forward to 530 the correct internal address) the signalling responses 531 that arrive from downstream. Of course, a GaNAT does not 532 need to actually change the source port of signalling 533 traffic; it can always use SPNSTGaNATds the same port as 534 in the incoming packet. Such a GaNAT may use the GIST 535 session ID in order to demultiplex the traffic that 536 arrives from the downstream direction. It is unclear 537 which of the two approaches is preferable. 539 4. It creates a new GIST QUERY packet GQ', as follows. 541 1. GQ' <- GQ 543 2. GQ'.MRI.SourceIPAddress <- IPGaNATds 545 3. GQ'.MRI.SourcePortNumber <- SPNDTGaNATds 547 4. GQ'.[IP header].SourceIPAddress <- IPGaNATds 549 5. GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds 551 6. GQ'.NLI.IA <- IPGaNATds 552 7. GQ'.S <- true 554 5. It remembers GQ and GQ', the fact that they are associated, 555 and the associated upstream and downstream links. (Note: The 556 GaNAT does not have to remember the entire packets; for 557 simplicity of exposition, however, we assume it does. An 558 implementation SHOULD discard at this point all information 559 that is not used later.) 561 6. It forwards GQ' on the downstream link. 563 2. Otherwise, if P carries an [IP header].DestinationIPAddress that 564 belongs to the GaNAT, and if it is identified as a GIST response 565 in D-mode with an NSLP ID that is not supported, the GaNAT does 566 the following (P is denoted as GR). 568 1. It searches for a matching GQ' in its buffer. A GR is said 569 to match a GQ' if they carry the same cookie value. If none 570 is found, GR is discarded. Otherwise, the GaNAT may also 571 perform further consistency checks on a matching GR/GQ' pair, 572 such as checking that they contain the same session IDs, 573 MRIs, NSLP IDs. If consistency checks succeed, the GaNAT 574 constructs a new GIST response GR', as follows. 576 1. GR' <- GR 578 2. GR'.MRI <- GQ.MRI, where GQ is the packet associated with 579 GQ'(as remembered previously), and GQ' is the packet that 580 matches the received GR. 582 3. GR'.[IP header].SourceIPAddress <- IPGaNATus, where 583 IPGaNATus = GQ.[IP header].DestinationIPAddress. 585 4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA 587 5. GP'.S <- true. 589 6. It inspects the stack proposals in GR' and the 590 corresponding GQ' to see if the upstream GIST peer has a 591 choice of more than one possible stack. If such a choice 592 exists, the GaNAT removes as many stack proposals from 593 GR' as necessary, until only one stack can be chosen by 594 the upstream peer for the messaging association. We 595 denote this stack as ST. The GaNAT remembers this ST and 596 its association with GQ, GQ', GR, GR'. We say that, in 597 this case, the GaNAT "installs" the ST. 599 2. It forwards GR' on the upstream link. 601 3. If no NAT binding for the data traffic was found in step 602 1.3.2, the GaNAT now installs a NAT binding (for the 603 unidirectional data traffic) which says that "a packet K that 604 arrives on the upstream link and for which it holds that 606 + K.[IP 607 header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, 609 + K.[IP header].Protocol=GQ.MRI.Protocol, and 611 + K.[TCP/UDP header].SourcePort=GQ.MRI.SourcePort 613 should be forwarded on the downstream link, with [IP 614 header].SourceIPAddress = IPGaNATds. 616 Issues: there is a question of whether this NAT binding 617 should also enable data traffic in the opposite direction to 618 traverse the NAT; in order to be able to demultiplex upstream 619 traffic that carries data that belongs to different flows, 620 the GaNAT should keep the necessary per-flow state. From a 621 signalling point of view, however, upstream data traffic that 622 corresponds (on the application level) to the downstream flow 623 to which this GIST session refers, is a separate flow for 624 which, depending on the application, there may or there may 625 not exist a signalling session. If such a signalling session 626 exists, then the GaNAT acts as an NR-side GaNAT for this 627 session. Thus, during the processing of this signalling care 628 has to be taken not to establish a NAT binding for a flow for 629 which a NAT binding already exists. Finally, security issues 630 arise when traffic, for which no signalling exists, is 631 allowed to traverse a GaNAT. 633 Another issue is about refreshing the NAT binding. A NAT 634 binding that was established as a result of GIST signalling 635 should remain in place for as long as the associated GIST 636 state in the GaNAT remains valid. If GIST signalling refers 637 to a NAT binding that already exists, then the timeout of the 638 NAT binding should occur according to the NAT policy, in a 639 manner independent from GIST processing. (If signalling 640 persists after the deletion of a NAT binding, then the NAT 641 binding may be re-installed and then timed out together with 642 GIST state). 644 3. Otherwise, if P.[IP header].DestinationIPAddress belongs to the 645 GaNAT, and if P carries the transport protocol and port numbers 646 indicated by some stack proposal ST that has previously been 647 installed by the GaNAT, and if P has arrived on either the 648 upstream or the downstream interface that is associated with ST, 649 then P is said to "match" ST. For such a packet, the GaNAT does 650 the following. If P is expected to contain a GIST header, then 651 the GaNAT check whether or not the bits where the GIST header is 652 expected, consitute a valid GIST header. If not, P is silently 653 discarded. Otherwise, the GaNAT constructs an outgoing packet P' 654 as follows (the variables used below refer to those stored 655 together with ST). 657 1. P' <- P 659 2. If P has arrived on the upstream link, then 661 1. P'.[IP header].SourceIPAddress <- IPGaNATds 663 2. P'.MRI <- GQ'.MRI 665 3. P'.NLI.IA <- IPGaNATus 667 4. The GaNAT forwards P' on the downstream link. 669 3. else (if P has arrived on the downstream link) 671 1. P'.[IP header].SourceIPAddress <- IPGaNATus 673 2. P'.MRI <- GQ.MRI 675 3. P'.NLI.IA <- IPGaNATus 677 4. The GaNAT forwards P' on the upstream link. 679 Note that the GaNAT can determine the location in a packet 680 where a GIST header is expected. If, for example, the packet 681 is a UDP packet, then the GIST header should follow 682 immediately after the UDP header. If the packet is a TCP 683 packet, then the GaNAT can determine the location where the 684 GIST heaer should start by counting the number of NSLP 685 payload bits that followed the end of the previous GIST 686 header. The start of the next GIST header is expected at the 687 position where the previous GIST message, including NSLP 688 payload, ends. The GaNAT can tell where this message ends 689 from the LENGTH field inside the previous GIST header. It 690 should be noted here that, in order to correctly count the 691 bits, the GaNAT may have to keep track of TCP sequence 692 numbers, and thereby be aware of the correct ordering of 693 packets. However, the GaNAT only has to keep buffers that 694 are as long as the LENGTH field inside the previous GIST 695 header (and possibly up to one MTU size more than that). 697 Also note that some TCP packets P may not be expected to 698 contain any GIST header (this happens when the NSLP payload 699 from a previous packet stretches over several packets). For 700 those packets, the GaNAT only applies the transformation in 701 the IP header. Finally, note that a GIST header may start a 702 packet but finish in another. If such a packet is received 703 by the GaNAT, it MUST buffer the entire packet, until the 704 packet is received where the GIST header completes. It can 705 then apply the required processing and forward both packets. 707 4. Otherwise, if P matches a (data) NAT binding, the GaNAT applies 708 normal NAT processing and forwards the packet on the 709 corresponding link. 711 5. Otherwise, P is silently discarded. 713 Brief discussion of the algorithm: The fact that the GaNAT replaces 714 the NSLP peer's NLI.IA with its own IP address (in both directions), 715 causes the two GIST peers to send subsequent signalling messages to 716 the GaNAT, in the belief that they talk to the their adjacent peer. 717 The GaNAT transparently forwards the signalling traffic and 718 appropriately translates the fields in the GIST header, in a way that 719 is consistent with the translation it applies to the data traffic. 721 Note that, according to this mechanism, the size of an outgoing GIST 722 message is always the same as the size of its corresponding incoming 723 GIST message. Finally note that the MRI that the NR sees indicates 724 as destination address the IP address of the DR (as expected), but as 725 source address it indicates the is IPGaNATds of the GaNAT that is 726 closest to the NR. 728 5.2. NR-side NSLP-unaware GaNATs 730 The case of NR-side GaNATs is more subtle, since, in this setting, 731 the DS does not learn the IP address of the DR (which is assumed to 732 be on the same side of the GaNATs as the NR) and the NI does not 733 learn the address of the NR. In this setting we assume that each NR- 734 side GaNAT that is in between two GIST peers, a priori knows a 735 routable IP address of the downstream GaNAT. The last GaNAT of this 736 chain is assumed to know the IP address of the DR. In order to 737 clarify this assumption, see, for example, Figure 2. In this figure, 738 GaNAT A is assumed to know the IP address of GaNAT B, GaNAT B is 739 assumed to know the IP address of GaNAT C, and GaNAT C is assumed to 740 know the IP address of the DR. A given GaNAT that knows such an 741 address, in effect anticipates to receive a signalling message from 742 the upstream direction that refers to a data flow that terminates in 743 a downstream node. In other words, such a GaNAT may typically have 744 already a NAT binding in place for the data traffic. We call the IP 745 address of the next downstream GaNAT (or, if the GaNAT is the last in 746 the chain, the address of the DR) the "pending" IP address. In the 747 following description it is denoted by IPNext. How IPNext is made 748 known to each GaNAT (e.g. how the NAT binding for the data traffic is 749 installed in the GaNAT) is outside the scope of this document. 751 +--+ +------+ +-----+ +-----+ +-----+ +------+ +--+ +--+ 752 +NI+--+ GIST +---+GaNAT+---+GaNAT+---+GaNAT+---+ GIST +--+NR+--+DR| 753 +--+ |peer 1| | A | | B | | C | |peer 2| +--+ +--+ 754 +------+ +-----+ +-----+ +-----+ +------+ 756 Figure 2: Network with NR-side GaNATs (the public Internet is assumed 757 to be between NI and GIST peer 1) 759 For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT 760 executes the following algorithm. 762 1. If P has a RAO followed by the GIST header with the NSLP ID 763 indicates an unsupported NSLP, it is identified as a GIST QUERY. 764 In this case the GaNAT does the following. 766 1. We denote P as GQ. The GaNAT looks at the stack proposal ST 767 in GQ. If it indicates that cryptographic protection is 768 required, the algorithm that is executed is the one described 769 in section Section 6 below. 771 2. The GaNAT remembers GQ along with the link on which it 772 arrived. We call this link the "upstream" link. 774 3. The GaNAT determines whether or not this GIST QUERY is 775 anticipated, i.e. if a pending IPNext exists that matches 776 this GIST QUERY. A pending IPNext is said to "match" a GIST 777 QUERY, if [this condition is an open issue!] If no pending 778 IPNext is also matching, P is discarded (it is a question 779 whether or not an error message should be sent). Otherwise, 780 additional checks may be performed (e.g. a DSInfo object may 781 have to be checked against the GQ). If these checks fail, P 782 is discarded. Otherwise, the GaNAT performs the following. 784 4. It searches its table of existing NAT bindings against 785 entries that match the GQ.MRI. A matching entry means that 786 the data flow, to which the signalling refers, already 787 exists. 789 + If a matching entry is found, the GaNAT looks at which 790 link the packets of the data flow are forwarded; we call 791 this link the "downstream" link. Further, the GaNAT 792 checks how the headers of the data flow (IP addresses, 793 port numbers, etc) are translated according to this NAT 794 binding. We denote [IP header].SourceIPAddress used on 795 the downstream link as IPGaNATds, and the source port 796 number as SPNDTGaNATds. Note that the [IP 797 header].DestinationIPAddress of this NAT binding should be 798 equal to IPNext. If it is not, this should be handled as 799 an auditive error condition. The GaNAT may also assign a 800 new source port number to signalling traffic, which is 801 denoted as SPNSTGaNATds. 803 + If no matching entry is found, the GaNAT determines, based 804 on its routing table, the link on which packets that match 805 GQ.MRI (excluding GQ.MRI.SourceIPAddress and where 806 GQ.MRI.DestinationIPAddress is replaced with IPNext) would 807 be forwarded. We call this link the "downstream" link. 808 Then, the GaNAT acquires an IP address for itself on the 809 downstream link. (This address could be dynamic or 810 static.) Depending on its type, the GaNAT may also 811 acquire source port numbers for the translation of data 812 traffic. We denote the acquired IP address as IPGaNATds 813 and the source port numbers for data and signalling 814 traffic as SPNDTGaNATds and SPNSTGaNATds respectively. 816 5. It creates a new GIST QUERY packet GQ', as follows. 818 1. GQ' <- GQ 820 2. GQ'.MRI.SourceIPAddress <- IPGaNATds 822 3. GQ'.MRI.DestinationIPAddress <- IPNext. 824 4. GQ'.MRI.SourcePort <- SPNDTGaNATds. 826 5. GQ'.[IP header].SourceIPAddress <- IPGaNATds 828 6. GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds 830 7. GQ'.[IP header].Destination_IP_Address <- IPNext 832 8. GQ'.NLI.IA <- IPGaNATds. 834 9. GQ'.S <- true 836 6. It remembers GQ, GQ' the fact that they are associated, and 837 the associated upstream and downstream links (interfaces). 839 7. It forwards GQ' on the downstream link. 841 Steps 2,3, 4 and 5 of the algorithm are analogous to the 842 corresponding steps of the algorithm executed by NSLP-unaware, NI- 843 side GaNATs, which was described in Section 5.1. 845 5.3. NSLP-aware GaNATs 847 The difference of NSLP-aware GaNATs and NSLP-unaware GaNATs is that 848 the former perform NSLP processing in addition to the processing of 849 the NSLP-unaware GaNATs. Another way to see this is by observing 850 that NSLP-aware GaNATs should provide an "MRI translation service" 851 (MRITS) in addition to normal GIST and NSLP processing. The 852 motivation behind the MRITS is for GIST to hide from the NSLP that 853 signalling messages traverse an addressing boundary. In other words, 854 the purpose of the MRITS is to make the NSLP believe that it is 855 operating in a single IP addressing space. When and how the MRITS is 856 invoked for a particular packet depends on (i) the direction of the 857 packet (i.e. downstream or upstream) and (ii) the location of the 858 GaNAT (i.e. NI-side or NR-side). It should also be noted that 859 certain NSLP layer tasks must be carried out in consistency with the 860 placement of the MRITS. This is to prevent events triggered by the 861 NSLP to cause installation of inconsistent state. In order to 862 clarify this, consider the scenario of the QoS NSLP running in a 863 GaNAT that operates according to the mechanisms described in this 864 section. Since the GaNAT only presents a single addressing space to 865 the NSLP (say, the internal addressing space), the packet classifier 866 of the GaNAT's QoS provisioning subsystem should classify packets 867 based on internal addresses only (i.e. it should first translate 868 packets that carry external addresses and then classify them). 869 Whether the MRITS presents internal-only or external-only addresses 870 to the NSLP is not significant, as long as NSLP layer operations are 871 carried out consistently. In the remainder of this section we 872 present the case where internal addresses are presented to the NSLP. 874 The MRITS is obviously invoked only on GIST packets that carry an 875 NSLP identifier that corresponds to an NSLP that the GaNAT actually 876 supports. Also, for non-GIST packets, normal NAT behaviour applies. 877 Although the MRITS is part of GIST processing, in order to clarify 878 our discussion, we view it as a somewhat separate processing step 879 (i.e. like a subroutine). For NI-side, NSLP-aware GaNATs, it holds 880 that 881 o for a GIST/NSLP packet that is to be forwarded on the downstream 882 link of an NI-side GaNAT, the MRITS is invoked after the packet 883 has been processed by the NSLP and before it is given to GIST, and 885 o for a GIST/NSLP packet that is received on the downstream link, 886 the MRITS is invoked after GIST processing and before the packet 887 is given to the NSLP. 889 The converse holds for NR-side NSLP-aware GaNATs. In particular, 891 o for a GIST/NSLP packet that is to be forwarded on the upstream 892 link of an NI-side GaNAT, the MRITS is invoked after the packet 893 has been processed by the NSLP and before it is given to GIST, and 895 o for a GIST/NSLP packet that is received on the upstream link, the 896 MRITS is invoked after GIST processing and before NSLP processing. 898 Figure 3 illustrates this idea. 900 +----------------+ +----------------+ 901 | +------+ | | +------+ | 902 | | NSLP | | | | NSLP | | 903 | +-+---++ | | +-+--+-+ | 904 | | | | | | | | 905 | | +-+---+ | | +----++ | | 906 | | |MRITS| | | |MRITS| | | 907 | | +---+-+ | | ++----+ | | 908 | | | | | | | | 909 | +-+-----+-+ | | ++------+-+ | 910 | | GIST | | | | GIST | | 911 u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s 912 -----+----+ +-----+----- -----+---+ +-----+----- 913 link +----------------+ link link +----------------+ link 914 NI-side NR-side 915 NSLP-aware NSLP-aware 916 GaNAT GaNAT 918 Figure 3: Operation of the MRI Translation Service 920 The reason for this construction is to give the NSLP the impression 921 that it works only with flows that originate and terminate in the 922 internal address space. We now describe the operation of the MRITS 923 and GIST in NSLP-aware GaNATs. An NI-side NSLP-aware GaNAT operates 924 according to the following rules. 926 1. When the NSLP asks for a message to be sent towards the 927 downstream GIST peer, the MRITS does the following (IPGaNATds and 928 SPNDTGaNATds are obtained similarly to the case of an NSLP- 929 unaware GaNAT). 931 1. MRI.SourceIPAddress <- IPGaNATds 933 2. MRI.SourcePort <- SPNDTGaNATds 935 2. Additionally, GIST performs the following on the resulting packet 936 before it is forwarded on the downstream link (SPNSTGaNATds is 937 obtained similarly to the case of an NSLP-unaware GaNAT). 939 1. [IP header].SourceIPAddress <- IPGaNATds 941 2. [UDP/TCP header].SourcePort <- SPNSTGaNATds 943 3. NLI.IA <- IPGaNATds 945 4. S <- true 947 3. If a message is received on the downstream link, the MRITS does 948 the following before the NSLP is invoked. 950 1. MRI.SourceIPAddress <- IPflow 952 2. MRI.SourcePort <- SPNDTGaNATus, where IPflow is the IP 953 address of the DS (as seen by the GaNAT) and SPNDTGaNATus is 954 the destination port number used in the original MRI. 956 4. If, after NSLP processing, a message is to be forwarded on the 957 upstream link, GIST performs the following processing (note that 958 no MRITS processing takes place in this case). 960 1. [IP header].SourceIPAddress <- IPGaNATus 962 2. [IP header].DestinationIPAddress <- IPpeer 964 3. NLI.IA <- IPGaNATus 966 4. S <- true, where IPGaNATus is the GaNATs IP address for the 967 upstream link, IPpeer is the IPaddress of the NI (or the next 968 GaNAT in the upstream direction), and IPflow is the IP 969 address of the DS (as seen by the GaNAT). The GaNAT is 970 assumed to determine the correct IPGaNATus and IPpeer from 971 previous communications and in cooperation with GIST. 972 [Issue: how exactly should IPGaNATus, IPpeer and IPflow be 973 resolved; i.e. what exactly should the GaNAT remember?] 975 An NR-side NSLP-aware GaNAT operates according to the following 976 rules. 978 1. If the packet is received on the upstream link, the MRITS does 979 the following, before the NSLP is notified. 981 1. P.MRI.SourceIPAddress <- IPGaNATds 983 2. P.MRI.DestinationIPAddress <- IPNext, where IPGaNATds is the 984 GaNAT's IP address for the downstream link and IPNext is the 985 address of the DR. IPNext is obtained in a way similar to 986 the case of an NSLP-unaware GaNAT. 988 2. If, after NSLP processing, a message is to be forwarded on the 989 downstream link, GIST performs the following processing (note 990 that no MRITS processing takes place in this case). 992 1. [IP header].SourceIPAddress <- IPGaNATds 994 2. [IP header].DestinationIPAddress <- IPNext 996 3. NLI.IA <- IPGaNATds 998 4. S <- true, where IPGaNATds is the GaNATs IP address for the 999 downstream link, IPNext is the IP address of the DR (or the 1000 next GaNAT in the downstream direction). The GaNAT is 1001 assumed to determine the correct IPNext in a way similar to 1002 the case of an NSLP-unaware GaNAT. 1004 3. When the NSLP asks for a message to be sent towards the upstream 1005 GIST peer, the MRITS does the following. 1007 1. MRI.SourceIPAddress <- IPflow 1009 2. MRI.Destination_IP_Address <- IPGaNATus 1011 4. Additionally, GIST performs the following on the resulting packet 1012 before it is forwarded on the downstream link. 1014 1. [IP header].SourceIPAddress <- IPGaNATus 1016 2. [IP header].DestinationIPAddress <- IPpeer 1018 3. NLI.IA <- IPGaNATus 1020 4. S <- true, where IPGaNATus is the GaNATs IP address for the 1021 upstream link, IPpeer is the IP address of the NI (or the 1022 next GaNAT in the upstream direction), and IPflow is the IP 1023 address of the DS. The GaNAT is assumed to determine the 1024 correct IPGaNATus and IPpeer fields from previous 1025 communications and in cooperation with GIST. [question: how 1026 exactly should IPGaNATus and IPpeer be resolved; i.e. what 1027 exactly should the GaNAT remember]? 1029 5.4. Combination of NSLP-aware and NSLP-unaware GaNATs 1031 In the absence of an adversary, a combination of NSLP-aware and NSLP- 1032 unaware GaNATs should work without further specification. However, 1033 in the presence of an adversary, additional security issues may arise 1034 from the combination. These issues may introduce opportunities for 1035 attack that do not exist in setting where the on-path GaNATs are 1036 either all NSLP-aware or all NSLP-unaware. 1038 6. Non-transparent NAT traversal 1040 This section discusses the "non-transparent" operation for GaNAT 1041 traversal at the GIST layer, i.e. the first approach listed in 1042 Section 3. For this approach, the behaviour of both the GaNAT and 1043 the GIST peers is defined. As with the transparent approach, the 1044 case of the in-between GaNAT(s) being located at the NI-side is 1045 different from that of NR-side GaNATs. Note that the mechanisms in 1046 this section apply only to NSLP-unware GaNATs. 1048 The GaNAT informs the NSLP peers about its presence during the GIST 1049 discovery process. This information enables the NSLP peers to map 1050 the translated data flow to the signalling messages, and to 1051 consistently translate the MRI, so that the NSLP only "sees" the 1052 correct MRI. Cryptographic protection of signalling messages can be 1053 supported with this approach because the GaNAT only modifies the GIST 1054 QUERY and REPONSE messages, which are never cryptographically 1055 protected in their entirety. 1057 In this approach, the GaNAT embeds a new GIST payload type into the 1058 GIST QUERY. This payload encodes the aforementioned information, and 1059 we call this payload type the "NAT Traversal Object" (NTO). The NTO 1060 is an optional payload in the GIST header of a GIST QUERY, and is 1061 added, and processed, by the GaNAT(s) through which the QUERY 1062 traverses. The information in the NTO must enable the two NSLP peers 1063 to locally translate the MRI in the same way as if it were 1064 consistently and transparently translated by the in-between GaNAT(s). 1065 Note that there may be more than one GaNAT between the two NSLP 1066 peers. The format of the NTO follows the format of the object in the 1067 GIST common header. In particular, the NTO is preceded by a TLV 1068 common header, as defined in [1]. The A and B flags are both set to 1069 0 in this header, indicating that support for the NTO is mandatory. 1070 The type value is TBD. The NTO is defined as in section A.3.8 of 1071 [1]. 1073 6.1. NI-side NSLP-unaware GaNATs 1075 For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT 1076 executes an algorithm that is equivalent to the following. 1078 1. If P has a RAO followed by the GIST header with an NSLP ID that 1079 is not supported, it is identified as a GIST QUERY. In this case 1080 the GaNAT does the following. 1082 1. We denote P as GQ. The GaNAT looks at the stack proposal ST 1083 in GQ. If it does not include a proposal with cryptographic 1084 protection, the GaNAT MAY choose to follow the approach 1085 described in Section 5.1 above. 1087 2. We call the link on which GQ arrived the "upstream" link. 1089 3. The GaNAT searches its table of existing NAT bindings against 1090 entries that match the GQ.MRI. A matching entry means that 1091 the data flow, to which the signalling refers, already 1092 exists. 1094 + If a matching entry is found, the GaNAT looks at which 1095 link the packets of the data flow are forwarded; we call 1096 this link the "downstream" link. Further, the GaNAT 1097 checks how the headers of the data flow (IP addresses and 1098 port numbers) are translated according to this NAT 1099 binding. 1101 + If no matching entry is found, the GaNAT determines, based 1102 on its routing table, the link on which packets that match 1103 GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be 1104 forwarded. We call this link the "downstream" link. 1105 Then, the GaNAT acquires an IP address and source port for 1106 itself on the downstream link. (This address and port 1107 could be dynamic or static.) 1109 4. We denote [IP header].SourceIPAddress used on the downstream 1110 link as IPGaNATds, and the source port number for the data 1111 and signalling traffic as SPNDTGaNATds and SPNSTGaNATds 1112 respectively. 1114 5. It creates a new GIST QUERY packet GQ', as follows. 1116 1. GQ' <- GQ 1118 2. GQ'.MRI.SourceAddress <- IPGaNATds. 1120 3. GQ'.MRI.SourcePort <- SPNDTGaNATds. 1122 4. GQ'.NLI.IA.<- IPGaNATds. 1124 5. GQ'.[IP header].SourceIPAddress <- IPGaNATds. 1126 6. GQ'.[UDP header].SourcePort <- SPNSTGaNATds. 1128 7. GQ'.S <- true. 1130 8. It checks whether or not an NTO was included in GQ. 1132 - If none was included, it creates a new NTO as follows 1133 and adds it to GQ'. 1135 o NTO.[NAT Count] <- 1. 1137 o NTO.MRI <- GQ.MRI. 1139 o NTO.[List of translated objects] <- [type of MRI], 1140 [type of NLI], [type of SCD] 1142 o NTO.opaque information for NAT 1 <- GQ.[IP 1143 header].SourceAddress, [link identifier of upstream 1144 link]. 1146 - If one was included, it replaces certain fields and 1147 appends new fields into the NTO, as follows, and adds 1148 the resulting object to GQ'. 1150 o NTO.[NAT Count] <- i, where i is the current [NAT 1151 count] value increased by one. 1153 o NTO.[List of translated objects] <- [type of MRI], 1154 [type of NLI], [type of STD] 1156 o NTO.[opaque information replaced by NAT i] <- 1157 GQ.[IP header].SourceAddress, [LinkID of upstream 1158 link]. 1160 9. It forwards GQ' on the downstream link. Note: The 1161 encoding of the information that the GaNAT encodes into 1162 the NTO.[opaque information replaced by NAT i] field is a 1163 local implementation issue. 1165 2. Otherwise, if P carries an [IP header].DestinationIPAddress that 1166 belongs to the GaNAT, and if it is identified as a GIST RESPONSE 1167 packet in datagram mode with an NSLP ID that is not supported, 1168 the GaNAT does the following (P is denoted as GR). 1170 1. If P does not contain an NTO, the GaNAT forwards it as usual 1171 without further processing. Otherwise, the GaNAT selects the 1172 information encoded by it in the [opaque information replaced 1173 by NAT] field of the embedded NTO, denoted by IPAddressToSend 1174 and LinkID. If multiple [opaque information replaced by NAT] 1175 fields are present in the NTO, the GaNAT uses the last one in 1176 the list. It then constructs a new GIST response GR', as 1177 follows (note that no changes are made to the MRI). 1179 1. GR' <- GR 1181 2. GR'.[IP header].DestinationIPAddress <- IPAddressToSend. 1183 3. GR'.NTO.[NAT Count] <- current value minus one. 1185 4. Remove the last [opaque information replaces by NAT i] 1186 field from GR'.NTO 1188 5. GR'.S <- true. 1190 2. It forwards GR' on the upstream link, i.e. the link 1191 identified by LinkID. 1193 3. The GaNAT SHOULD now invalidate all but one stack 1194 configuration objects in the stack proposal in GR'. This is 1195 done so that the quering node can only chose that one 1196 proposal, and that therefore only one NAT binding must be 1197 installed for the signalling traffic to traverse the GaNAT. 1198 The GaNAT SHOULD keep valid the strongest, in terms of 1199 security, stack proposal. We denote this proposal as PR. 1201 4. The GaNAT now installs a NAT binding for the signalling 1202 traffic which says that "a packet K that arrives on the 1203 upstream link and for which it holds that 1205 + K.[IP header].SourceIPAddress=IPAddressToSend, 1207 + K.[IP header].Protocol=PR.Protocol, and 1209 + K.[TCP/UDP header].DestinationPort=PR.[Destination Port] 1211 should be forwarded on the downstream link (i.e. on the link 1212 on which GR arrived), with [IP header].SourceIPAddress = 1213 IPGaNATds. 1215 5. If no NAT binding for the data traffic was found in step 1216 1.3.2, the GaNAT now installs a NAT binding (for the 1217 unidirectional data traffic) which says that "a packet K that 1218 arrives on the upstream link and for which it holds that 1220 + K.[IP header].DestinationIPAddress=GQ'.NTO.MRI.Destination 1221 IPAddress, 1223 + K.[IP header].Protocol=GQ'.NTO.MRI.Protocol, and 1225 + K.[TCP/UDP header].PortNumbers=GQ'.NTO.MRI.PortNumbers 1227 should be forwarded on the downstream link (i.e. the link on 1228 which GR arrived), with [IP header].SourceIPAddress = 1229 IPGaNATds and [UDP/TCP header].SourcePort=SPDTGaNATds. 1231 Issues: there is a question of whether this NAT binding 1232 should also enable data traffic in the opposite direction to 1233 traverse the NAT; in order to be able to demultiplex upstream 1234 traffic that carries data that belongs to different flows, 1235 the GaNAT should keep the necessary per-flow state. From a 1236 signalling point of view, however, upstream data traffic that 1237 corresponds (on the application level) to the downstream flow 1238 to which this GIST session refers, is a separate flow for 1239 which, dependent on the application, there may or there may 1240 not exist a signalling session. If such a signalling session 1241 exists, then the GaNAT acts as an NR-side GaNAT for this 1242 session. Thus, during the processing of this signalling, 1243 care has to be taken not to establish a NAT binding for a 1244 flow for which a NAT binding already exists. Finally, 1245 security issues may arise when traffic, for which no 1246 signalling exists, is allowed to traverse a GaNAT. 1248 3. Otherwise, if P matches an existing NAT binding, normal NAT 1249 processing is applied. 1251 4. Otherwise, P is silently discarded. 1253 6.2. NR-side NSLP-unaware GaNATs 1255 As is the case with NR-side NSLP-unaware GaNATs that follow the 1256 "transparent" approach, an NR-side NSLP-unaware GaNAT that follows 1257 the "non-transparent" approach must know a "pending" IP address and, 1258 depending on the scenario, also a destination port number, as 1259 described in Section 5.2. This IP address and destination port 1260 number are denoted as IPNext and PortNext respectively. How they are 1261 made known to the GaNAT is outside the scope of this document. Note, 1262 however, that a typical scenario would be that the GaNAT has an 1263 existing NAT binding for the data flow in place from where this 1264 information can be derived. 1266 For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT 1267 executes the following algorithm. 1269 1. If P has a RAO followed by a GIST header with an unsupported 1270 NSLPID, and is identified as a GIST QUERY, the GaNAT does the 1271 following. 1273 1. We denote P as GQ. The GaNAT looks at the stack proposal ST 1274 in GQ. If it indicates that no cryptographic protection is 1275 required, the GaNAT MAY choose to follow the "transparent" 1276 approach as described in Section 5.2 above. 1278 2. If GQ.[IP header].[Destination Address] is not bound to the 1279 link on which GQ arrived, the GaNAT silently discards the 1280 packet. 1282 3. The GaNAT determines whether or not this GIST QUERY is 1283 anticipated, i.e. if a pending IPNext and PortNext exists. 1284 One way of determining whether or not a pending IPNext and 1285 PortNext exists is checking whether or not a NAT binding for 1286 the data traffic, as this is defined by the MRI in the GIST 1287 QUERY, exists in the NAT binding cache. If one exists, then 1288 IPNext and PortNext is the address and port number to which 1289 the data traffic is sent after translation. If no pending 1290 IPNext is found, GQ is discarded (it is an open issue whether 1291 or not an error message should be sent). Otherwise, 1292 additional checks may be performed (e.g. a DSInfo object may 1293 have to be checked against the GQ). If these checks fail, GQ 1294 is discarded. Otherwise, the GaNAT performs the following. 1296 4. We call the link on which GQ arrived the "upstream" link. 1297 The GaNAT aquires an IP address for itself for the upstream 1298 link (this could be a static or a dynamic IP address). This 1299 address is denoted IPGaNATus. The GaNAT will use this 1300 address as a source IP address in order to send subsequent 1301 signalling messages to the upstream direction. If the GaNAT 1302 is an edge NAT, IPGaNATus will typically coincide with the 1303 destination IP address of the (original) MRI in the GIST 1304 QUERY. 1306 5. The GaNAT searches its table of existing NAT bindings against 1307 entries that match the GQ.MRI. A matching entry means that 1308 the data flow, to which the signalling refers, already 1309 exists. 1311 + If a matching entry is found, the GaNAT determines the 1312 link on which the packets of the data flow are forwarded; 1313 we call this link the "downstream" link. Further, the 1314 GaNAT checks how the headers of the data flow (IP 1315 addresses, port numbers) are translated according to this 1316 NAT binding. Note that the [IP 1317 header].DestinationIPAddress of this NAT binding should be 1318 equal to IPNext. If it is not, this should be handled as 1319 an auditive error condition. (This check is done as a 1320 consistency check.) 1322 + If no matching entry is found, the GaNAT determines, based 1323 on its routing table, the link on which packets that match 1324 GQ.MRI (where GQ.MRI.DestinationIPAddress is replaced with 1325 IPNext) would be forwarded. We call this link the 1326 "downstream" link. 1328 6. It creates a new GIST QUERY packet GQ', as follows. 1330 1. GQ' <- GQ 1332 2. GQ'.MRI.DestinationAddress <- IPNext. 1334 3. GQ'.MRI.DestinationPort <- PortNext. 1336 4. GQ'.[IP header].DestinationIPAddress <- IPNext. 1338 5. It checks whether or not an NTO was included in GQ. 1340 - If none was included, it creates a new NTO as follows 1341 and adds it to GQ'. 1343 o NTO.[NAT Count] <- 1. 1345 o NTO.MRI <- GQ.MRI. 1347 o NTO.[List of translated objects] <- [type of MRI], 1348 [type of NLI], [type of SCD] 1350 o NTO.opaque information for NAT 1 <- IPGaNATus, 1351 [link identifier of upstream link]. 1353 - If one was included, it replaces certain fields and 1354 appends new fields into the NTO, as follows, and adds 1355 the resulting object to GQ'. 1357 o NTO.[NAT Count] <- i, where i is the current [NAT 1358 count] value increased by one. 1360 o NTO.[List of translated objects] <- [type of MRI], 1361 [type of NLI], [type of SCD] 1363 o NTO.[opaque information replaced by NAT i] <- 1364 IPGaNATus, [LinkID of upstream link]. 1366 6. It forwards GQ' on the downstream link. Note: The 1367 encoding of the information that the GaNAT encodes into 1368 the NTO.[opaque information replaced by NAT i] field is a 1369 local implementation issue. 1371 2. Otherwise, if P is identified as a GIST RESPONSE packet in 1372 datagram mode with an NSLP ID that is not supported, the GaNAT 1373 does the following (P is denoted as GR). 1375 1. If P does not contain an NTO, the GaNAT forwards it as usual 1376 without further processing. Otherwise, the GaNAT selects the 1377 information encoded by it in the [opaque information replaced 1378 by NAT] field of the embedded NTO, denoted by IPGaNATus and 1379 LinkID. If multiple [opaque information replaced by NAT] 1380 fields are present in the NTO, the GaNAT uses the last one in 1381 the list. The GaNAT then constructs a new GIST response GR', 1382 as follows (note that no changes are made to the MRI). 1384 1. GR' <- GR 1386 2. GR'.[IP header].SourceIPAddress <- IPGaNATus. 1388 3. GR'.MRI.NLI.IA <- IPGaNATus. 1390 4. Remove the last [opaque information replaced by NAT i] 1391 field from GR'.NTO. 1393 5. GR'.S <- true. 1395 2. The GaNAT SHOULD now invalidate all but one stack 1396 configuration objects in the stack proposal in GR'. This is 1397 done so that the quering node can only chose that one 1398 proposal, and that therefore only one NAT binding must be 1399 installed for the signalling traffic to traverse the GaNAT. 1400 The GaNAT SHOULD keep valid the strongest, in terms of 1401 security, stack proposal. We denote this proposal as PR. If 1402 PR.[Destination Port] is already used by the GaNAT as a port 1403 in order to demultiplex an existing signalling flow, the 1404 GaNAT reserves a port SIGPORT (that it will use as a source 1405 port for UDP/TCP signalling traffic that it will send on the 1406 upstream link) and replaces PR.[Destination Port] with 1407 SIGPORT. Otherwise it sets SIGPORT=PR.[Destination Port]. 1408 It then sets GR'.[UDP header].SourcePort <- SIGPORT. 1410 3. It forwards GR' on the upstream link, i.e. the link 1411 identified by LinkID. 1413 4. The GaNAT now installs a NAT binding for the signalling 1414 traffic which says that "a packet K that arrives on the 1415 upstream link and for which it holds that 1417 + K.[IP header].DestinationIPAddress=IPGaNATus, 1419 + K.[IP header].Protocol=PR.Protocol, and 1421 + K.[TCP/UDP header].DestinationPort=SIGPORT 1422 should be forwarded on the downstream link (i.e. on the link 1423 on which GR arrived), with [IP header].DestinationIPAddress = 1424 GR.MRI.NLI.IA and [UDP/TCP 1425 header].DestinationPort=PR.[Destination Port]. 1427 5. If no NAT binding for the data traffic was found in step 1428 1.3.2, the GaNAT may now install a NAT binding (for the 1429 unidirectional data traffic) which says that "a packet L that 1430 arrives on the upstream link and for which it holds that 1432 + L.[IP header].DestinationIPAddress=GR'.NTO.MRI.Destination 1433 IPAddress, 1435 + L.[IP header].Protocol=GR'.NTO.MRI.Protocol, and 1437 + L.[TCP/UDP 1438 header].DestinationPortNumbers=GR'.NTO.MRI.DestinationPort 1440 should be forwarded on the downstream link, with [IP 1441 header].DestinationIPAddress = IPNext and [UDP/TCP 1442 header].DestinationPort=PortNext. 1444 Issues: there is a question of whether this NAT binding 1445 should also enable data traffic in the opposite direction to 1446 traverse the NAT; in order to be able to multiplex upstream 1447 traffic that carries data that belongs to different flows, 1448 the GaNAT should keep the necessary per-flow state. From a 1449 signalling point of view, however, upstream data traffic that 1450 corresponds (on the application level) to the downstream flow 1451 to which this GIST session refers, is a separate flow for 1452 which, dependent on the application, there may or there may 1453 not exist a signalling session. If such a signalling session 1454 exists, then the GaNAT acts as an NI-side GaNAT for this 1455 session. Thus, during the processing of this signalling care 1456 has to be taken not to establish a NAT binding for a flow for 1457 which a NAT binding already exists. Finally, security issues 1458 may arise when traffic, for which no signalling exists, is 1459 allowed to traverse a GaNAT. 1461 3. Otherwise, if P matches an existing NAT binding, normal NAT 1462 processing is applied. 1464 4. Otherwise, P is silently discarded. 1466 6.3. GIST peer processing 1468 In the presence of GaNATs on the signalling path between two NSLP 1469 peers, and if the GaNATs follow the "non-transparent" approach (which 1470 they have to follow in the context of cryptographically protected 1471 signalling), the consistent translation of the GIST header fields 1472 must be carried out by the NSLP peers. The GIST processing that 1473 performs this task, is described in section 7.2 of [1]. 1475 7. GIST-unaware NATs 1477 The following may serve as indications for the existence of an GIST- 1478 unaware NAT between two GIST peers. These indications can only be 1479 detected by the receiver of a GIST message. The first occasion these 1480 indications may be detected is with the reception of a GIST QUERY, 1481 typically by the downstream peer. (Note that != denotes inequality). 1483 o The MRI.SourceIPAddress does not belong to the addressing space of 1484 the receiving peer. 1486 o The MRI.DestinationIPAddress does not belong to the addressing 1487 space of the receiving peer. 1489 o The IP address in the NLI.IA field does not belong to the 1490 addressing space of the receiving peer. 1492 o The D flag of a received GIST packet denotes downstream direction 1493 and the S flag is not set and [IP header].SourceIPAddress != 1494 MRI.SourceIPAddress. 1496 o The D flag of a received GIST packet denotes upstream direction 1497 and the S flag is not set and [IP header].SourceIPAddress != 1498 MRI.DestinationIPAddress. 1500 o This is a GIST QUERY and [IP header].DestinationIPAddress != 1501 MRI.DestinationIPAddress. 1503 Note that these are only indications. In the presence of an 1504 adversary, a GIST peer may be tricked into believing that an GIST- 1505 unaware NAT exists between itself and one of its neighbouring peers, 1506 while in reality this may not be the case. 1508 When a downstream GIST peer detects such an indication, it may notify 1509 the upstream peer about the error. It may include additional 1510 information that enables the upstream peer to construct a GIST packet 1511 in such a way that, after it traverses the GIST-unaware NAT, the IP 1512 addresses in the MRI field and the NLI.IA field are consistent with 1513 those in the IP header (which match the addressing space of the 1514 receiving peer). However, this requires the specification of new 1515 data structures and formats, processing rules, and requires the peers 1516 to maintain additional state. 1518 Unfortunately, this approach is likely to fail in many circumstances. 1519 In order to see this, consider the behaviour of an GIST-unaware NAT 1520 when it receives an IP packet. The packet either 1521 1. matches an existing NAT binding in which case its IP header is 1522 translated and the packet it is forwarded on another link, or 1524 2. matches an existing policy rule which causes a new binding to be 1525 established and then (1) happens, or 1527 3. is discarded because neither (1) nor (2) applies. 1529 With GIST-unaware NATs it is a matter of local policy (i.e. the rules 1530 that exist in case (2) above) whether or not traffic will be allowed 1531 to traverse the NAT. This obviously applies to both signalling and 1532 data traffic, as an GIST-unaware NAT is unable to distinguish the two 1533 types of traffic. It may be the case that GIST node A is unable to 1534 contact GIST node B which is "behind" a NAT, even if communication in 1535 from B to A may be possible because such communication would match a 1536 policy rule; typically, in a scenarios where A is towards the NI and 1537 B is towards the NR, the NAT would have this behaviour. 1539 Another approach to deal with GIST-unaware NATs is similar to the NAT 1540 traversal approach taken by IKEv2, i.e. by encapsulating GIST 1541 messages into UDP datagrams, rather than directly into IP datagrams. 1542 This technique requires the inclusion of additional fields into a 1543 GIST QUERY, as follows. The sender adds (a hash of) its own IP 1544 address and the IP address of what it believes to be the DR into the 1545 GIST payload. The receiver of this GIST messages compares these 1546 addresses to the [IP header].SourceIPAddress and the [IP 1547 header].DestinationIPAddress respectively. If at least one of them 1548 is unequal, the receiver deduces that a NAT is between sender and 1549 receiver. After the detection of a NAT, the remainder of the 1550 communication is encapsulated into UDP datagrams that are addressed 1551 to a specified port. 1553 Unfortunately, the IKEv2 NAT traversal mechanism cannot be used "as 1554 is" for NAT traversal in GIST. This is because of a number of 1555 reasons, including the following. 1557 o The NAT may use an IP address for the forwarding of data traffic 1558 that is different from the IP address it uses to forward GIST 1559 traffic. Since the NAT is GIST-unaware it cannot update the MRI 1560 in the GIST messages such that it matches the translation applies 1561 to the data traffic. Moreover, neither the GIST sending, nor the 1562 GIST receiving peer can perform this update; the sending peer 1563 cannot predict the translation that the NAT will apply, and the 1564 receiving peer does not have enough information to associate data 1565 flows to signalling messages. 1567 o It is unclear whether or not the IKEv2 NAT traversal mechanism 1568 supports cascades of NATs. 1570 o It seems to be inappropriate to use UDP encapsulation for certain 1571 C-mode scenarios. For example, using UDP encapsulation for TCP 1572 C-mode would result in GIST to appear in TCP over UDP over IP. 1574 8. Security Considerations 1576 The mechanisms proposed in this document give rise to a number of 1577 threats that must be considered. In the following, a subset of these 1578 threats is mentioned. 1580 8.1. Service Denial Attacks 1582 As described above, NSLP-unaware GaNATs create some state whenever 1583 they receive a GIST QUERY message. This state is necessary in order 1584 for the GaNAT to be able to map a GIST RESPONSE that arrives from the 1585 downstream direction to the corresponding GIST QUERY and thereby to 1586 perform the required translation. 1588 The threat here is an attacker flooding the GaNAT with maliciously 1589 constructed GIST QUERIES with the aim of exhausting the GaNAT's 1590 memory. The attacker might use a variety of methods to construct 1591 such GIST QUERIES, including the following. 1593 1. Use as [IP header].SourceIPAddress the address of some other node 1594 or an unallocated IP address. This method is also known as IP 1595 spoofing. 1597 2. Use an invalid NSLPID, in order to make sure that all on-path 1598 GaNAT(s) will behave like NSLP-unaware GaNATs. 1600 3. For each packet, use a different value for the cookie field. 1602 4. For each packet, use a different value for the session ID field. 1604 5. Combinations of the above. 1606 How vulnerable a GaNAT is to the above service denial attack depends 1607 on a variaty of factors, including the following. 1609 o The amount of state allocated at the receipt of a GIST QUERY. 1610 This amount may vary depending on whether or not the data flow to 1611 which the signalling refers, already exists (i.e. whether or not 1612 the GaNAT already maintains a NAT binding for it). 1614 o The mechanism that the GaNAT uses to map RESPONSEs to QUERIEs. 1616 o Whether or not the GaNAT acriques dynamic IP addresses and ports 1617 for the downstream link. 1619 In order to decrease the exposure of a GaNAT to service denial 1620 attacks, the following recommendations are made. 1622 o The GaNAT should perform ingress filtering. This limits the 1623 amount of locations from which an attacker can perform IP spoofing 1624 without being detected. 1626 o The GaNAT should allocate the minimum amount of state required at 1627 the reception of a GIST QUERY. 1629 o All state allocated by the GaNAT should timeout according to a 1630 local policy. If the GaNAT detects heavy loads (which may 1631 indicate a service denial attack in progress), the GaNAT should 1632 timeout the state allocated as a result of a received GIST QUERY 1633 quicker, proportionally to the experienced load. 1635 o The installation of a NAT binding for the data traffic (if such a 1636 binding does not exist prior to signalling) should be postponed 1637 until the correct GIST REPONSE traverses the NAT. 1639 The service denial threats mentioned in this section do not apply to 1640 an NSLP-aware GaNAT, as such a GaNAT is required, in accordance with 1641 its local policy, to verify the validity of the cookie(s) before 1642 allocating any state, including the state required by the mechanisms 1643 in this document. 1645 8.2. Network Intrusions 1647 Although the primary goal of a NAT is to perform address translation 1648 between two addressing spaces, NATs are sometimes also used to 1649 provide a security service similar to the security service provided 1650 by firewalls. That is, a NAT can be configured so that it does not 1651 forward packets from the external into the internal network, unless 1652 it determines that the packets belong to a communication session that 1653 was originally initiated from an internal node and are, as such, 1654 solicited. 1656 If an NSLP-unaware GaNAT performs the above security-relevant 1657 function in addition to address translation, then the presence of 1658 GIST signalling and, in particular the mechanisms described in this 1659 document, might allow an adversary cause the installation of NAT 1660 bindings in the GaNAT using these mechansisms. These NAT bindings 1661 would then enable the adversary to inject unsolicited traffic into 1662 the internal network, a capability that it may not have in the 1663 absence of the mechanisms described in this document. 1665 The administrator of an NSLP-unaware GaNAT should therefore make 1666 security-concious decisions regarding the operation of the GaNAT. An 1667 NSLP-aware GaNAT, on the other hand, follows an NSLP policy which 1668 indicates the required security mechanisms. This policy should 1669 account for the fact that this NSLP-aware node performs also NAT and 1670 the associated packet filtering. 1672 9. IAB Considerations 1674 None. 1676 10. Acknowledgements 1678 The authors would like to thank Cedric Aoun, Christian Dickmann, 1679 Robert Hancock, and Martin Stiemerling for their insightful comments. 1680 Furthermore, we would like to mention that this document builds on 1681 top of a previous document regarding migration scenarios. 1683 11. Normative References 1685 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1686 Signalling Transport", draft-ietf-nsis-ntlp-06 (work in 1687 progress), May 2005. 1689 [2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS 1690 Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 1691 (work in progress), May 2005. 1693 Authors' Addresses 1695 Andreas Pashalidis 1696 Siemens 1697 Otto-Hahn-Ring 6 1698 Munich, Bavaria 81739 1699 Germany 1701 Email: Andreas.Pashalidis@siemens.com 1703 Hannes Tschofenig 1704 Siemens 1705 Otto-Hahn-Ring 6 1706 Munich, Bavaria 81739 1707 Germany 1709 Email: Hannes.Tschofenig@siemens.com 1711 Intellectual Property Statement 1713 The IETF takes no position regarding the validity or scope of any 1714 Intellectual Property Rights or other rights that might be claimed to 1715 pertain to the implementation or use of the technology described in 1716 this document or the extent to which any license under such rights 1717 might or might not be available; nor does it represent that it has 1718 made any independent effort to identify any such rights. Information 1719 on the procedures with respect to rights in RFC documents can be 1720 found in BCP 78 and BCP 79. 1722 Copies of IPR disclosures made to the IETF Secretariat and any 1723 assurances of licenses to be made available, or the result of an 1724 attempt made to obtain a general license or permission for the use of 1725 such proprietary rights by implementers or users of this 1726 specification can be obtained from the IETF on-line IPR repository at 1727 http://www.ietf.org/ipr. 1729 The IETF invites any interested party to bring to its attention any 1730 copyrights, patents or patent applications, or other proprietary 1731 rights that may cover technology that may be required to implement 1732 this standard. Please address the information to the IETF at 1733 ietf-ipr@ietf.org. 1735 Disclaimer of Validity 1737 This document and the information contained herein are provided on an 1738 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1739 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1740 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1741 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1742 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1745 Copyright Statement 1747 Copyright (C) The Internet Society (2005). This document is subject 1748 to the rights, licenses and restrictions contained in BCP 78, and 1749 except as set forth therein, the authors retain all their rights. 1751 Acknowledgment 1753 Funding for the RFC Editor function is currently provided by the 1754 Internet Society.