idnits 2.17.1 draft-pashalidis-nsis-gimps-nattraversal-05.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 1870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1894. 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 110: '...re NAT - a GaNAT MAY implement a numbe...' RFC 2119 keyword, line 130: '...lements GIST and MAY also implement a ...' RFC 2119 keyword, line 180: '...e sequel. A GaNAT MAY also support at...' RFC 2119 keyword, line 339: '... MUST follow the transparent approac...' RFC 2119 keyword, line 341: '...aphically protected, a GaNAT MUST also...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 780 has weird spacing: '... to be betwe...' -- 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 6137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-13 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-14 Summary: 4 errors (**), 0 flaws (~~), 6 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 Siemens 5 July 8, 2007 7 GIST NAT Traversal 8 draft-pashalidis-nsis-gimps-nattraversal-05.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 a number of mechanisms for the implementation 42 of the General Internet Signalling Transport (GIST) protocol [1] on 43 different types of Network Address Translator (NAT). The focus of 44 these mechanisms is the interaction of GIST with the address 45 translation function of the NAT, and their purpose is to enable GIST 46 hosts that are located on either side of the NAT to correctly 47 interpret signalling messages with respect to the data traffic they 48 refer to. The purpose of this document is to provide guidance to 49 people that implement GIST and NSLPs on both NAT and non-NAT nodes. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 5. Transparent NAT traversal for GIST . . . . . . . . . . . . . . 13 58 5.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 13 59 5.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 19 60 5.3. NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 21 61 5.4. Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 25 62 6. Non-transparent NAT traversal for GIST . . . . . . . . . . . . 27 63 6.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 27 64 6.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 32 65 6.3. GIST peer processing . . . . . . . . . . . . . . . . . . . 38 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 67 7.1. Service Denial Attacks . . . . . . . . . . . . . . . . . . 41 68 7.2. Network Intrusions . . . . . . . . . . . . . . . . . . . . 42 69 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 44 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 71 10. Normative References . . . . . . . . . . . . . . . . . . . . . 46 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 73 Intellectual Property and Copyright Statements . . . . . . . . . . 48 75 1. Introduction 77 Network Address Translators (NATs) modify certain fields in the IP 78 and transport layer header of the packets that traverse them. In the 79 context of signalling as specified by the General Internet Signalling 80 Transport (GIST) protocol [1], this behaviour may lead to the 81 installation of state at network nodes that may be inconsistent and 82 meaningless with respect to the data traffic that traverses these 83 nodes. 85 This document describes mechanisms that can be used in order for GIST 86 signalling messages to traverse NATs in a way that preserves the 87 consistency of state that is installed in the network with respect to 88 the data flows to which the signalling messages refer. As the 89 mechanisms that are described in this document exclusively operate at 90 the GIST layer, they are transparent to signalling applications. The 91 document is organised as follows. The next section introduces the 92 terminology that is used throughout this document. Section 3 93 provides a detailed discussion of the NAT traversal problem and 94 highlights certain design decisions that have to be taken when 95 addressing the problem. Section 4 lists the assumptions on which the 96 subsequently proposed mechanisms are based. The mechanisms are 97 described in Section 5 and Section 6. Finally, Section 7 presents 98 some security issues that arise in conjunction with the mechanisms 99 described in this document. 101 2. Terminology 103 The terminology, abbreviations and notational conventions that are 104 used throughout the document are as follows. 106 o DR: Data Receiver, same as Flow Receiver as defined in [1] 108 o DS: Data Sender, same as Flow Sender as defined in [1] 110 o GaNAT: GIST-aware NAT - a GaNAT MAY implement a number of NSLPs. 112 o GIST: General Internet Messaging Protocol for Signalling [1] 114 o NAT: Network Address Translator 116 o NI: NSIS Initiator; this is the GIST node (as defined in [1]) that 117 initiates a signalling session for a given NSLP. The NI may or 118 may not be identical to the DS or the DR. 120 o NR: NSIS Responder; this is the GIST node (as defined in [1]) that 121 acts as the last in a sequence of nodes that participate in a 122 given signalling session. The NR may or may not be identical to 123 the DR or the DS. 125 o NSIS: Next Steps in Signalling: The name of the IETF working group 126 that specified the family of signalling protocols of which this 127 document is also a member. The term NSIS is also used to refer to 128 this family of signalling protocols as a whole. 130 o GIST-aware: Implements GIST and MAY also implement a number of 131 NSLPs. 133 o GIST-unaware: GIST-unaware, does not implement any NSLP. The term 134 is synonymous to NSIS-unaware. 136 o NSLP: NSIS Signalling Layer Protocol, as defined in [1] 138 o downstream: as defined in [1] 140 o upstream: as defined in [1] 142 o MRI: Message Routing Information, as defined in [1] 144 o NLI.IA: Interface Address field of the Network Layer Information 145 object, as defined in [1] 147 o NSLP: Network Signalling Layer Protocol 148 o <- : Assignment operator. The quantity to the right of the 149 operator is assigned to the variable to its left. 151 o A.B: Element B of structure A. Example: [IP 152 header].SourceIPAddress denotes the source IP address of an IP 153 header. 155 o [data item]: This notation indicates that "data item" is a single 156 identifier of a data structure. (Square brackets do not denote 157 optional arguments in this document.) 159 3. Problem Statement 161 According to [1], all GIST messages between two peers carry IP 162 addresses in order to define the data flow to which the signalling 163 refers. Moreover, certain GIST messages also carry the IP address of 164 the sending peer, in order to enable the receiving peer to address 165 subsequent traffic to the sender. Packets that cross an addressing 166 boundary, say from addressing space S1 to S2, have the IP addresses 167 in the IP header translated from space S1 to S2 by the NAT; if GIST 168 payloads are not translated in a consistent manner, the MRI in a GIST 169 packet that crosses the boundary, e.g. from address space S1 to S2, 170 refers to a flow that does not exist in S2. In fact, the flow may be 171 invalid in S2 because at the IP address that belongs to S1 may not be 172 routable or invalid in S2. Moreover, the IP address of the sending 173 peer may also be not routable or invalid in the addressing space of 174 the receiving peer. The purpose of this document is to describe a 175 way for GIST messages to be translated in a way that is consistent 176 with the translation that NATs apply to the IP headers of the data 177 traffic. 179 A NAT may either be GIST-unaware or GIST-aware. We refer to a GIST- 180 aware NAT as a "GaNAT" in the sequel. A GaNAT MAY also support at 181 least one NSLP. Note that there exists an NSLP, namely the NATFW 182 NSLP [2], that specifically addresses NAT traversal for data flows. 183 Inevitably, the NATFW NSLP also provides the necessary mechanisms for 184 the related signalling to traverse the involved NATs. Consider a 185 GaNAT that supports both the NATFW NSLP, and the NAT traversal 186 mechanism that is described in this document (which operates at the 187 GIST layer). Suppose now that a GIST QUERY message arrives at this 188 GaNAT that contains the NSLP identifier (NSLPID) of the NATFW NSLP. 189 A question that arises is whether the GaNAT should use the GIST-layer 190 NAT traversal mechanism (described in this document), or the NATFW 191 NSLP mechanism, in order to provide "NAT traversal" for both the 192 signalling message and the data flow to which it refers. The answer 193 to this question is that a GaNAT should implement a policy according 194 to which one method is used in preference to the other. Note that, 195 however, if the GaNAT prefers GIST-layer NAT traversal, then it may 196 happen, if no on-path GaNATs exist that prefer the NATFW NSLP, that 197 no downstream NATFW NSLP peers are discovered. This may make the 198 entire NATFW session obsolete. It is therefore anticipated that the 199 NATFW NSLP will be the preferred NAT traversal mechanism in most 200 circumstances. 202 However, in certain cicumstances it may be desirable for GIST 203 signalling messages to traverse a NAT, and not desirable or possible 204 to use the NATFW NSLP for this purpose. Examples of such 205 circumstances are the following. 207 o GaNATs that do not implement the NATFW NSLP are on the path taken 208 by GIST signalling messages. This situation may arise during 209 incremental deployment of the signalling protocols that are 210 developed by the NSIS working group. 212 o GaNATs that implement the NATFW NSLP are on the path taken by GIST 213 signalling messages that refer to a given data flow. However, the 214 NSLP that is being signalled is *not* the NATFW NSLP and there 215 exists no NATFW signalling session for the data flow in question. 217 Describing NAT traversal for GIST signalling messages in the above 218 circumstances is the subject matter of this document. 220 In general, a given data flow between a data sender (DS) and a data 221 receiver (DR) may have to traverse a number of NATs, some of which 222 may be GIST-and-NATFW-aware, some may be GIST-aware, and some may be 223 GIST-unaware. Additionally, NSLP signalling for such a data flow may 224 be required to traverse through a subset of those NATs. Whether or 225 not the routing infrastructure and state of the network causes the 226 signalling for such a data flow to traverse the same NATs as the flow 227 depends, among other things, on which NSLP is being signalled. While 228 signalling of the QoS NSLP, for example, might not traverse any of 229 the NATs that are traversed by the data flow, the signalling of the 230 NATFW NSLP traverses at least those NATs that implement the NATFW 231 NSLP (otherwise the signalling path would no longer be coupled to the 232 data path, as this coupling is defined by the GIST QUERY/RESPONSE 233 discovery mechanism for the "path coupled" Message Routing Method). 234 It is desirable that the GIST-layer NAT traversal provides NAT 235 traversal for every possible combination of NATs, either on the data 236 or the signalling path, in a secure manner. 238 Due to the GIST QUERY/RESPONSE discovery mechanism (according to 239 which QUERY messages are simply forwarded if the current node does 240 not support the required NSLP), two GIST nodes typically identify 241 themselves as NSLP peers only if they both implement the same NSLP. 242 If one or more NATs that are unaware of this NSLP are between them, 243 then the two NSLP peers are not able to discover each other at all. 244 This is because, even in the unlikely event that the NAT bindings 245 that are necessary for the GIST traffic to traverse the in-between 246 NAT(s) exist, the NLI.IA field included in the RESPONSE message sent 247 by the downstream peer is invalid (or the IP address is unreachable) 248 in the address space of the upstream peer. In order to overcome this 249 limitation, either the two peers need to cope with the in-between 250 NAT(s), or, if the NAT(s) are GaNATs, they (the GaNATs) need to apply 251 additional processing in order to transparently create and maintain 252 consistency between the information in the header of GIST signalling 253 messages and the information in the IP header of the data traffic. 254 Additionally, if NSLP-aware NATs are on the data path, then these 255 NATs should process NSLP traffic in a way the preserves consistency 256 after address translation. This processing deviates from the 257 processing of NSLP-aware non-NAT nodes. The following sections 258 describe how to overcome the limitation of two adjacent NSLP peers 259 not being able to execute the NSLP in the presence of in-between 260 NAT(s). 262 A number of different variations are possible, depending on the level 263 of NSIS support by the in-between NAT(s). The following combinations 264 of NATs that are located between two adjacent NSLP peers are 265 considered. 267 o all NAT(s) are NSLP-unaware GaNAT(s) 269 o all NAT(s) are NSLP-aware 271 The approach taken in this document is to propose separate mechanisms 272 for the traversal of each of the above type of NAT. If NATs that 273 belong to multiple types exist on the path between two adjacent NSLP 274 peers, the proposed mechanisms should work in combination. Thus, 275 traversal of multiple NATs of different types should not require 276 further specification from a functional perspective. However, 277 security issues that arise due to the combination of NAT types may 278 have to be considered. 280 A GIST-unaware NAT cannot tell data and signalling traffic apart. 281 The installation of the NAT binding for the signalling traffic in 282 such a NAT occurs typically independently from the installation of 283 the NAT binding for the data traffic. Furthermore, as the NAT cannot 284 associate the signalling and the data traffic, it cannot indicate 285 that an association exists between the two NAT bindings. Therefore, 286 in the presence of such a NAT, non-NAT GIST nodes that are located on 287 either side of the NAT have to cope with the NAT without assistance 288 from the NAT. This would typically require initially discovering the 289 NAT and subsequently establishing an association between between the 290 MRI in the signalling messages and the translated IP header in the 291 data traffic. Due to the variety of behaviours that a GIST-unaware 292 NAT may exhibit, establishing this association is a non-trivial task. 293 Therefore, traversal of such (i.e. GIST-unaware) NATs is considered 294 a special case and is outside the scope of this version of this 295 document. 297 Traversal of GaNAT(s) is comparatively more straightforward. This is 298 because, based on the MRI in a given incoming GIST message, a GaNAT 299 can identify the data flow to which the message refers. It can then 300 check its NAT binding cache and determine the translation that is 301 (or, if no NAT binding for the flow exists yet, will be) applied to 302 the IP header of the data flow. The GaNAT can then include 303 sufficient information about this translation into the signalling 304 message, such that its receiver (i.e. the GIST peer that receives the 305 data traffic after network address translation has been applied) can 306 map the signalling message to the data flow. 308 There exist a variety of ways for a GaNAT to encode the above- 309 mentioned information into signalling messages. In this document the 310 following two ways are considered. 312 1. Non-transparent approach: The GaNAT includes an additional "NAT 313 Traversal" payload (see section A.3.8 of [1]) into the GIST 314 header of the GIST QUERY message. This "NAT Traversal" payload 315 is echoed by the GIST responder on the other side of the NAT. 316 The responder (which is assumed to be located on the "other side" 317 of the NAT) uses the information in this payload in order to map 318 subsequent signalling messages to the data flows they refer to. 320 2. Transparent approach: The GaNAT replaces GIST header fields in a 321 way that is consistent with the translation it applies to the 322 data traffic, as necessary. The GaNAT does this for GIST QUERY 323 and RESPONSE messages, for D-mode as well as for C-mode messages 324 throughout the duration of the signalling session. 326 The second approach being "transparent" means that a GaNAT that 327 follows this approach remains completely transparent to the GIST 328 peers that are located either side of it. Thus, this approach works 329 even if these GIST peers do not support the NAT traversal object for 330 GIST (as described in [1]). Unfortunately though, the transparent 331 approach does not work if the signalling traffic is to be 332 cryptographically protected between the two GIST peers that are 333 located either side of the GaNAT, and the GaNAT is NSLP-unaware. If, 334 however, the GaNAT is NSLP-aware, then cryptographic protection is 335 terminated at the GaNAT (i.e. the GaNAT is a GIST peer itself). In 336 this scenario, it is clearly preferable for the GaNAT to follow the 337 transparent approach, rather than to include a NAT Traversal object. 338 Thus, if a GaNAT acts as a GIST peer for a signalling session, it 339 MUST follow the transparent approach, as described in Section 5.3. 340 However, due to the fact that the transparent approach does not work 341 if signalling is to be cryptographically protected, a GaNAT MUST also 342 implement the non-transparent approach (for the case where an NSLP is 343 signalled that the GaNAT does not support), unless the GaNAT is going 344 to be used only in deployments where cryptographic protection of 345 signalling traffic is not a requirement. 347 Note that a GaNAT MAY implement both approaches. If such a GaNAT is 348 NSLP-unaware, it can then adopt the desired behaviour, based on 349 whether or not cryptographic protection is required for the 350 signalling traffic between two GIST peers. If such protection is 351 required, the GaNAT MUST adopt the mechanisms that follow the non- 352 transparent approach; if it is not, it MAY follow the mechanisms 353 implementing the transparent approach. The GaNAT can tell whether or 354 not cryptographic protection is required from the stack proposal in 355 the GIST QUERY and RESPONSE messages; inclusion of IPsec or TLS 356 proposals amounts to cryptographic protection being required. 358 4. Assumptions 360 The discussion in this document is based on the following 361 assumptions. 363 1. No IP addresses and port numbers are carried in the payloads of 364 an NSLP. If this is not the case, then the NSLP has to provide 365 additional mechanisms for the traversal of (Ga)NATs. These 366 mechanisms must be compatible the mechanisms described in this 367 document. Note that the NATFW NSLP is an exception to this rule 368 in that it does not need to be compatible with the mechanisms 369 described in this document. This is because the GIST-layer NAT 370 traversal mechanisms described in this document and the NATFW 371 NSLP are mutually exclusive (i.e. it is not permissible that a 372 given (Ga)NAT applies both GIST-layer NAT traversal and NATFW 373 NSLP processing to the messages that belong to the same 374 signalling session). 376 2. The path taken by the signalling traffic between those GIST peers 377 that have GaNATs in between is such that the responses to packets 378 that a GaNAT sends on a given interface arrive on the same 379 interface (if such responses are sent at all). 381 3. The path taken by signalling traffic remains fixed between the 382 two GIST peers, as far as the in-between GaNATs are concerned. 383 That is, we assume that signalling traffic traverses the same 384 GaNAT(s) until at least one of the following conditions is met. 386 * The NSIS state that is installed at the two GIST peers 387 expires. 389 * The NSIS state that is installed at the two GIST peers is 390 refreshed using a GIST QUERY. 392 * A new GIST QUERY/RESPONSE exchange takes place due to other 393 reasons, e.g. a detected route change. 395 Note that this assumption is not necessarily met by "normal" data 396 path coupled signalling. This is because, under "normal" data 397 path coupled signalling, the signalling traffic is "coupled" to 398 the data traffic at nodes that decide to act as GIST peers. 399 Thus, under "normal" path coupled signalling, it is not an error 400 condition (e.g. a reason to trigger a "route change"), for 401 example, if the set of on-path nodes, which do not act as GIST 402 peers, changes, as long as adjacent GIST peers remain the same. 404 4. The data flow traverses the same set of GaNATs as the signalling 405 traffic. By assumption 3, this set of GaNATs is fixed until the 406 next GIST QUERY/RESPONSE procedure is executed. 408 +-----+ 409 +----+GaNAT|-----+ 410 | | A | | 411 | +-----+ | 412 +------+ +------+ +--+---+ +------+ 413 +--+ | GIST | | IP | | IP | | GIST | +--+ 414 |DS+-+peer 1+--+router| |router+--+peer 2+-+DR| 415 +--+ +------+ +---+--+ +--+---+ +------+ +--+ 416 | +-----+ | 417 | |GaNAT| | 418 +----+ B +-----+ 419 +-----+ 421 Figure 1: Network with more than one NAT at an addressing boundary 423 Figure 1 illustrates the importance of assumptions (3) and (4). With 424 regard to that figure, suppose that a (D-mode) signalling session has 425 been setup between the two adjacent GIST peers 1 and 2 and that both 426 signalling and data traffic follows the path GIST peer 1 -> IP router 427 -> GaNAT A -> IP router -> GIST peer 2. Suppose now that, after some 428 time, GIST peer 1 decides to set up a C-mode connection with peer 2. 429 Suppose moreover that the left IP router decides to forward the 430 C-mode signalling traffic on the link towards GaNAT B. Thus, 431 signalling traffic now follows the alternative path GIST peer 1 -> IP 432 router -> GaNAT B -> IP router -> GIST peer 2. Note that this change 433 in forwarding between the two adjacent GIST peers does not trigger a 434 "route change" at the GIST layer because (a) it does not necessarily 435 destroy the adjacency of peer 1 and 2 and (b) it does not necessarily 436 destroy the coupling of the path taken by signalling traffic to that 437 taken by data traffic (at GIST nodes). Nevertheless, assumptions (3) 438 and (4) mandate that this situation does not occur. However, even if 439 such a situation occurs, the mechanisms described in this document 440 may still work as state expires after a certain timeout period. 442 Assumptions (2), (3) and (4) hold if, at an addressing boundary, only 443 one NAT exists. Due to security and management reasons, this is 444 likely to be the case in many settings. 446 5. Transparent NAT traversal for GIST 448 This section describes the operation of GaNATs that implement the 449 transparent approach listed in Section 3. An NSLP-aware GaNAT MUST 450 follow this approach, as described in Section 5.3. An NSLP-unaware 451 GaNAT MAY follow this approach, as described in Section 5.1 and 452 Section 5.2, only if no cryptographic protection of signalling data 453 is requested by the two NSLP peers. 455 Note that two types of NSLP-unaware GaNAT have to be dealt with, 456 namely those that are located at the NSIS initiator (NI-side), and 457 those that are located at the NSIS responder (NR-side). This 458 distinction arises due to the fact that NI-side and NR-side GaNATs 459 obtain the destination IP address of the downstream GIST peer in 460 different ways. 462 5.1. NI-side NSLP-unaware GaNATs 464 This section describes the "transparent" operation of an NI-side, 465 NSLP-unaware GaNAT. 467 For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT 468 executes the following algorithm. 470 1. If P has a RAO followed by the GIST header with an NSLP ID that 471 is not supported, and if P is identified as a GIST QUERY, the 472 GaNAT performs the following. 474 1. We denote P by GQ. The GaNAT looks at the stack proposal in 475 GQ. If it includes a proposal with cryptographic protection, 476 the mechanism that is applied is the one described 477 Section 6.1. 479 2. The GaNAT remembers GQ along with the interface on which it 480 arrived. We call this interface the "upstream link". 482 3. It searches its table of existing NAT bindings against 483 entries that match the GQ.MRI. A matching entry means that 484 the data flow, to which the signalling refers, already 485 exists. 487 + If a matching entry is found, the GaNAT looks at which 488 link the packets of the data flow are forwarded; we call 489 this link the "downstream" link. Further, the GaNAT 490 checks how the headers of the data flow (IP addresses and 491 port numbers) are translated according to this NAT 492 binding. We denote the source IP address of translated 493 data packets by IPds, and their [Transport layer 494 header].SourcePort by SPDTds. 496 + If no matching entry is found, the GaNAT determines, based 497 on its routing table, the link on which packets that match 498 GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be 499 forwarded. We call this link the "downstream" link. 500 Then, the GaNAT acquires an IP address and source port for 501 itself on the downstream link, denoted by IPds and SPDTds 502 respectively. This address and port could be dynamic or 503 static, and will be used (among other things) for the 504 installation of a NAT binding for the data traffic in the 505 future. 507 4. The GaNAT aquires a source port number for the version of the 508 GIST QUERY that will be forwarded over the downstream link. 509 We denote this port by SPSTds. (There is no requirement that 510 SPSTds must be different from GQ.[UDP Header].SourcePort.) 512 Issues: The reason why the GaNAT may also assign a different 513 source port number to the signalling traffic, is to enable 514 the GaNAT to demultiplex (i.e. forward to the correct 515 internal address) the signalling responses that arrive from 516 the downstream direction. Of course, a GaNAT does not need 517 to actually change the source port of signalling traffic; it 518 can always use SPSTds the same port as in the incoming 519 packet. Such a GaNAT may use the GIST session ID in order to 520 demultiplex (i.e. forward to the correct internal address) 521 the traffic that arrives from the downstream direction. It 522 is unclear which of the two approaches is preferable. 524 5. It creates a new GIST QUERY packet GQ', as follows. 526 1. GQ' <- GQ 528 2. GQ'.MRI.SourceIPAddress <- IPds 530 3. GQ'.MRI.SourcePortNumber <- SPDTds 532 4. GQ'.[IP header].SourceIPAddress <- IPds 534 5. GQ'.[UDP header].SourcePort <- SPSTds 536 6. GQ'.NLI.IA <- IPds 538 7. GQ'.S <- true 540 6. It remembers GQ and GQ', the fact that they are associated, 541 and the associated upstream and downstream links. (Note: The 542 GaNAT does not have to remember the entire packets; for 543 simplicity of exposition, however, we assume it does. An 544 implementation SHOULD discard at this point all information 545 that is not used later.) 547 7. It forwards GQ' on the downstream link. 549 2. Otherwise, if P carries an [IP header].DestinationIPAddress that 550 belongs to the GaNAT, and if it is identified as a GIST RESPONSE 551 in D-mode with an NSLP ID that is not supported, the GaNAT does 552 the following (P is denoted by GR). 554 1. It searches for a matching GQ' in its buffer. A GQ' is said 555 to match a GR if they carry the same cookie value. If none 556 is found, GR is discarded. Otherwise, the GaNAT may also 557 perform further consistency checks on a matching GR/GQ' pair, 558 such as checking that they contain the same session IDs, 559 MRIs, NSLP IDs. If consistency checks fail, GR is discarded. 560 Otherwise, the GaNAT constructs a new GIST RESPONSE GR', as 561 follows. 563 1. GR' <- GR 565 2. GR'.MRI <- GQ.MRI, where GQ is the packet associated with 566 GQ' (as remembered previously), and GQ' is the packet 567 that matches the received GR. 569 3. GR'.[IP header].SourceIPAddress <- IPus, where IPus is an 570 IP address that is bound to the upstream link. 572 4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA 574 5. GR'.[UDP header].DestinationPort <- GQ.[UDP 575 header].SourcePort 577 6. GR'.NLI.IA <- IPus 579 7. GR'.S <- true 581 8. The GaNAT inspects the Stack-Configuration-Data object in 582 GR' and the corresponding GQ' in order to check whether 583 or not the upstream NSLP peer can select one of multiple 584 transport layer protocol/destination port number 585 combinations for the establishment of a messaging 586 association. If multiple choices exist, the GaNAT 587 invalidates as many transport layer protocol/port number 588 combination proposals from GR' as necessary, until the 589 upstream NSLP peer can only initiate the establishment of 590 a messaging association with the downstream NSLP peer 591 using a single transport layer protocol/destination port 592 number combination. This invalidation is done by setting 593 the D-flag in those MA-Protocol-Options fields that carry 594 the port number proposals that are to be invalidated. 595 Note that, by setting the D-flag in a particular MA- 596 Protocol-Option field, the GaNAT may also invalidate the 597 associated transport layer protocol and security (e.g. 598 TLS) proposal. The actions of the GaNAT MUST NOT result 599 in the strongest, in terms of security, proposal to be 600 invalidated. In the end, the NAT will expect the 601 upstream NSLP peer to use a particular combination of 602 transport layer protocol and destination port (and 603 possibly other details that are associated with the valid 604 proposal) for the establishment of the messaging 605 association. We call this combination the "stack 606 proposal expected by the NAT" and denote it by ST. The 607 GaNAT remembers this ST, its association with GQ, GQ', 608 GR, GR', and the upstream and downstream links. By doing 609 so, the GaNAT is said to "install" the ST. 611 2. It forwards GR' on the upstream link. 613 3. If no NAT binding for the data traffic was found in step 614 1.3.2, the GaNAT now installs a NAT binding (for the 615 unidirectional data traffic) which says that "a packet K that 616 arrives on the upstream link and for which it holds that 618 + K.[IP 619 header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, 621 + K.[IP header].Protocol=GQ.MRI.Protocol, and 623 + K.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers 625 should be forwarded on the downstream link, with [IP 626 header].SourceIPAddress = IPds and [Transport layer 627 header].SourcePort=SPDTds". 629 Issues: there is a question of whether this NAT binding 630 should also enable data traffic in the opposite direction to 631 traverse the NAT; in order to be able to demultiplex upstream 632 traffic that carries data that belongs to different flows, 633 the GaNAT should keep the necessary per-flow state. From a 634 signalling point of view, however, upstream data traffic that 635 corresponds (on the application level) to the downstream flow 636 to which this GIST session refers, is a separate flow for 637 which, depending on the application, there may or there may 638 not exist a signalling session. If such a signalling session 639 exists, then the GaNAT acts as an NR-side GaNAT for this 640 session. Thus, during the processing of this signalling care 641 has to be taken not to establish a NAT binding for a flow for 642 which a NAT binding already exists. Moreover, security 643 issues may arise when traffic, for which no signalling 644 exists, is allowed to traverse a GaNAT. 646 Another issue is about refreshing the NAT binding. A NAT 647 binding that was established as a result of GIST signalling 648 should remain in place for as long as the associated GIST 649 state in the GaNAT remains valid. If GIST signalling refers 650 to a NAT binding that already exists, then the timeout of the 651 NAT binding should occur according to the NAT policy, in a 652 manner independent from GIST processing. (If signalling 653 persists after the deletion of a NAT binding, then the NAT 654 binding may be re-installed and then timed out together with 655 GIST state). 657 3. Otherwise, if P.[IP header].DestinationIPAddress belongs to the 658 GaNAT, and if P carries the transport protocol and destination 659 port number indicated by some stack ST that has previously been 660 installed by the GaNAT, and if P has arrived on either the 661 upstream or the downstream interface that is associated with ST, 662 then P is said to "match" ST. For such a packet, the GaNAT does 663 the following. If P is expected to contain a GIST header, then 664 the GaNAT checks whether or not the bits where the GIST header is 665 expected, constitute a valid GIST header. If they do not, P is 666 silently discarded. If all is in order, the GaNAT constructs an 667 outgoing packet P' as follows (the variables used below refer to 668 those stored in association with ST). 670 1. P' <- P 672 2. If P has arrived on the upstream link, then 674 1. P'.[IP header].SourceIPAddress <- IPds 676 2. P'.[IP header].DestinationIPAddress <- GR.NLI.IA 678 3. P'.MRI <- GQ'.MRI 680 4. P'.NLI.IA <- IPds 682 5. The GaNAT forwards P' on the downstream link. 684 3. else (if P has arrived on the downstream link) 686 1. P'.[IP header].SourceIPAddress <- IPus 688 2. P'.[IP header].DestinationIPAddress <- GQ.NLI.IA 690 3. P'.MRI <- GQ.MRI 692 4. P'.NLI.IA <- IPus 694 5. The GaNAT forwards P' on the upstream link. 696 Note that the GaNAT can determine the location in a packet 697 where a GIST header is expected. If, for example, the packet 698 is a UDP packet, then the GIST header should follow 699 immediately after the UDP header. If the packet is a TCP 700 packet, then the GaNAT can determine the location where the 701 GIST header should start by counting the number of NSLP 702 payload bits that followed the end of the previous GIST 703 header. The start of the next GIST header is expected at the 704 position where the previous GIST message, including NSLP 705 payload, ends. The GaNAT can tell where this message ends 706 from the LENGTH field inside the previous GIST header. It 707 should be noted here that, in order to correctly count the 708 bits, the GaNAT may have to keep track of TCP sequence 709 numbers, and thereby be aware of the correct ordering of 710 packets. However, the GaNAT only has to keep buffers that 711 are as long as the LENGTH field inside the previous GIST 712 header (and possibly up to one MTU size more than that). 714 Also note that some TCP packets P may not be expected to 715 contain any GIST header (this happens when the NSLP payload 716 from a previous packet stretches over several packets). For 717 those packets, the GaNAT only applies the transformation in 718 the IP header. Finally, note that a GIST header may start a 719 packet but finish in another. If such a packet is received, 720 the GaNAT MUST buffer that packet, until the packet is 721 received where the GIST header completes. It can then apply 722 the required processing and forward both packets. 724 4. Otherwise, if P matches a (data) NAT binding, the GaNAT applies 725 normal NAT processing and forwards the packet on the 726 corresponding link. 728 5. Otherwise, P is subjected to normal NAT processing. That is, P 729 is either silently discarded or it causes the installation of a 730 (data) NAT binding. 732 Brief discussion of the algorithm: The fact that the GaNAT replaces 733 the NSLP peers' NLI.IA with its own IP address (in both directions), 734 causes the GIST peers to send subsequent signalling messages to the 735 GaNAT, in the belief that they talk to their adjacent NSLP peer. The 736 GaNAT transparently forwards the signalling traffic and appropriately 737 translates the fields in the GIST header, in a way that is consistent 738 with the translation it applies to the data traffic. 740 Note that, according to this mechanism, the size of outgoing GIST 741 messages is always the same as the size of corresponding incoming 742 GIST messages. Also note that the MRI that the NR sees indicates as 743 destination address the IP address of the DR (as expected), but as 744 source address it sees indicates the IPds of the GaNAT that is 745 closest to the NR. 747 5.2. NR-side NSLP-unaware GaNATs 749 The case of NR-side GaNATs is more subtle, since, in this setting, 750 the DS does not learn the IP address of the DR (which is assumed to 751 be on the same side of the GaNATs as the NR) and the NI does not 752 learn the address of the NR. In this setting we assume that each NR- 753 side GaNAT that is in between two GIST peers, a priori knows a 754 routable IP address of the next downstream GaNAT. The last GaNAT of 755 this chain is assumed to know the IP address of the DR. In order to 756 clarify this assumption, see, for example, Figure 2. In this figure, 757 GaNAT A is assumed to know the IP address of GaNAT B, GaNAT B is 758 assumed to know the IP address of GaNAT C, and GaNAT C is assumed to 759 know the IP address of the DR. A given GaNAT that knows such an 760 address, in effect anticipates to receive a signalling message from 761 the upstream direction that refers to a data flow that terminates in 762 a downstream node. In other words, such a GaNAT may typically have 763 already a NAT binding in place for the data traffic. We call the IP 764 address of the next downstream GaNAT (or, if the GaNAT is the last in 765 the chain, the address of the DR) the "pending" IP address and denote 766 it by IPNext. The GaNAT may also have a destination port associated 767 with IPNext. If IPNext is derived from an existing data traffic NAT 768 binding, then this port is typically the destination port after 769 translation from that binding. This port, if known, is denoted 770 PortNext. How IPNext and PortNext are made known to each GaNAT (e.g. 771 how the NAT binding for the data traffic is installed in the GaNAT) 772 is outside the scope of this document. 774 +--+ +------+ +-----+ +-----+ +-----+ +------+ +--+ +--+ 775 +NI+--+ NSLP +---+GaNAT+---+GaNAT+---+GaNAT+---+ NSLP +--+NR+--+DR| 776 +--+ |peer 1| | A | | B | | C | |peer 2| +--+ +--+ 777 +------+ +-----+ +-----+ +-----+ +------+ 779 Figure 2: Network with NR-side GaNATs (the public Internet is assumed 780 to be between NI and NSLP peer 1) 782 For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT 783 executes the following algorithm. 785 1. If P has a RAO followed by the GIST header with the NSLP ID 786 indicates an unsupported NSLP, and if it is identified as a GIST 787 QUERY, the GaNAT does the following. 789 1. We denote P by GQ. The GaNAT looks at the stack proposal in 790 GQ. If it indicates that cryptographic protection is 791 required, the algorithm that is executed is the one described 792 in section Section 6 below. 794 2. The GaNAT remembers GQ along with the link on which it 795 arrived. We call this link the "upstream" link. 797 3. The GaNAT determines whether or not this GIST QUERY is 798 anticipated, i.e. if a pending IPNext (and possibly PortNext) 799 exists that matches this GIST QUERY. A pending IPNext is 800 said to "match" a GIST QUERY, if [this condition is an open 801 issue!] If no pending IPNext is matching, P is discarded (it 802 is a question whether or not an error message should be 803 sent). Otherwise, additional checks may be performed (e.g. 804 something like a DSInfo object may have to be checked against 805 the GQ). If these checks fail, P is discarded. Otherwise, 806 the GaNAT performs the following. 808 4. It searches its table of existing NAT bindings against 809 entries that match the GQ.MRI. A matching entry means that 810 the data flow, to which the signalling refers, already 811 exists. 813 + If a matching entry is found, the GaNAT looks at which 814 link the packets of the data flow are forwarded; we call 815 this link the "downstream" link. Further, the GaNAT 816 checks how the IP and transport layer headers of the data 817 flow are translated according to this NAT binding. Note 818 that the [IP header].DestinationIPAddress and [Transport 819 layer header].DestinationPort of this NAT binding should 820 be equal to IPNext and PortNext respectively. If they are 821 not, this should be handled as an auditive error 822 condition. 824 + If no matching entry is found, the GaNAT determines, based 825 on its routing table, the link on which packets that match 826 GQ.MRI (excluding GQ.MRI.SourceIPAddress and where 827 GQ.MRI.DestinationIPAddress is replaced with IPNext) would 828 be forwarded. We call this link the "downstream" link. 830 5. The GaNAT acquires an IP address for itself on the downstream 831 link. (This address could be dynamic or static.) Depending 832 on its type, the GaNAT may also acquire a UDP source port 833 number for the version of the GIST QUERY that will be 834 forwarded to the downstream direction. We denote the 835 acquired IP address and source port number by IPds SPSTds 836 respectively. The GaNAT then constructs a new GIST QUERY 837 packet GQ', as follows. 839 1. GQ' <- GQ 841 2. GQ'.MRI.DestinationIPAddress <- IPNext. 843 3. GQ'.MRI.DestinationPort <- PortNext. 845 4. GQ'.NLI.IA <- IPds. 847 5. GQ'.[IP header].SourceIPAddress <- IPds. 849 6. GQ'.[IP header].DestinationIPAddress <- IPNext. 851 7. GQ'.[UDP header].SourcePort <- SPSTds. 853 8. GQ'.S <- true 855 6. It remembers GQ, GQ', the fact that they are associated, and 856 the associated upstream and downstream links (interfaces). 858 7. It forwards GQ' on the downstream link. 860 The remaining steps of the algorithm are analogous to the 861 corresponding steps of the algorithm executed by NSLP-unaware, NI- 862 side GaNATs, which was described in Section 5.1. 864 5.3. NSLP-aware GaNATs 866 The difference of NSLP-aware GaNATs and NSLP-unaware GaNATs is that 867 the former perform NSLP processing in addition to the processing of 868 the NSLP-unaware GaNATs. Another way to see this is by observing 869 that NSLP-aware GaNATs should provide an "MRI translation service" 870 (MRITS) in addition to normal GIST and NSLP processing. The MRITS 871 operates at the GIST layer. The motivation behind this is to hide 872 from the NSLP that signalling messages traverse an addressing 873 boundary. In other words, the purpose of the MRITS is to make the 874 NSLP believe that it is operating in a single IP addressing space. 875 When and how the MRITS is invoked for a particular packet depends on 876 (i) the direction of an incoming message (i.e. downstream or 877 upstream) and (ii) the location of the GaNAT (i.e. NI-side or NR- 878 side). It should also be noted that certain NSLP layer tasks must be 879 carried out in consistency with the placement of the MRITS. This is 880 to prevent events triggered by the NSLP to cause installation of 881 inconsistent state. In order to clarify this, consider the scenario 882 of the QoS NSLP running in a GaNAT that operates according to the 883 mechanisms described in this section. Since the GaNAT only presents 884 a single addressing space to the NSLP (say, the internal addressing 885 space), the packet classifier of the GaNAT's QoS provisioning 886 subsystem should classify data packets based on internal addresses 887 only (i.e. it should first translate packets that carry external 888 addresses and then classify them). Whether the MRITS presents 889 internal-only or external-only addresses to the NSLP is not 890 significant, as long as NSLP layer operations are carried out 891 consistently. In the remainder of this section we present the case 892 where internal addresses are presented to the NSLP. 894 The MRITS is obviously invoked only on GIST packets that carry an 895 NSLP identifier that corresponds to an NSLP that the GaNAT 896 implements. For non-GIST packets, normal NAT behaviour applies. 897 Although the MRITS is part of GIST processing, in order to clarify 898 the exposition, we view it as a somewhat separate processing step 899 (i.e. like a subroutine) that is executed in addition to GIST, as 900 this is specified in [1]. For NI-side, NSLP-aware GaNATs, it holds 901 that 903 o for a GIST/NSLP packet that is to be forwarded on the downstream 904 link of an NI-side GaNAT, the MRITS is invoked after the packet 905 has been processed by the NSLP and before it is given to GIST, and 907 o for a GIST/NSLP packet that is received on the downstream link, 908 the MRITS is invoked after GIST processing and before the packet 909 is given to the NSLP. 911 The converse holds for NR-side NSLP-aware GaNATs. In particular, 913 o for a GIST/NSLP packet that is to be forwarded on the upstream 914 link of an NI-side GaNAT, the MRITS is invoked after the packet 915 has been processed by the NSLP and before it is given to GIST, and 917 o for a GIST/NSLP packet that is received on the upstream link, the 918 MRITS is invoked after GIST processing and before NSLP processing. 920 Figure 3 illustrates this idea. 922 +----------------+ +----------------+ 923 | +------+ | | +------+ | 924 | | NSLP | | | | NSLP | | 925 | +-+---++ | | +-+--+-+ | 926 | | | | | | | | 927 | | +-+---+ | | +----++ | | 928 | | |MRITS| | | |MRITS| | | 929 | | +---+-+ | | ++----+ | | 930 | | | | | | | | 931 | +-+-----+-+ | | ++------+-+ | 932 | | GIST | | | | GIST | | 933 u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s 934 -----+----+ +-----+----- -----+---+ +-----+----- 935 link +----------------+ link link +----------------+ link 936 NI-side NR-side 937 NSLP-aware NSLP-aware 938 GaNAT GaNAT 940 Figure 3: Operation of the MRI Translation Service 942 The reason for this construction is to give the NSLP the impression 943 that it works only with flows that originate and terminate in the 944 internal address space. We now describe the operation of the MRITS 945 and GIST in NSLP-aware GaNATs. An NI-side NSLP-aware GaNAT operates 946 according to the following rules. 948 1. When the NSLP asks for a message to be sent towards the 949 downstream GIST peer, the MRITS does the following (IPds and 950 SPDTds are obtained similarly to the case of an NSLP-unaware 951 GaNAT). 953 1. MRI.SourceIPAddress <- IPds 955 2. MRI.SourcePort <- SPDTds 957 2. Additionally, GIST performs the following on the resulting packet 958 before it is forwarded on the downstream link (SPSTds is obtained 959 similarly to the case of an NSLP-unaware GaNAT). 961 1. [IP header].SourceIPAddress <- IPds 962 2. [UDP/TCP header].SourcePort <- SPSTds 964 3. NLI.IA <- IPds 966 4. S <- true 968 3. If a message is received on the downstream link, the MRITS does 969 the following before the NSLP is invoked. 971 1. MRI.SourceIPAddress <- IPflow 973 2. MRI.SourcePort <- SPDTus, where IPflow is the IP address of 974 the DS (as seen by the GaNAT) and SPDTus is the destination 975 port number used in the original MRI. 977 4. If, after NSLP processing, a message is to be forwarded on the 978 upstream link, GIST performs the following processing (note that 979 no MRITS processing takes place in this case). 981 1. [IP header].SourceIPAddress <- IPus 983 2. [IP header].DestinationIPAddress <- IPpeer 985 3. NLI.IA <- IPus 987 4. S <- true, where IPus is the GaNATs IP address for the 988 upstream link, IPpeer is the IP address of the NI (or the 989 next GaNAT in the upstream direction), and IPflow is the IP 990 address of the DS (as seen by the GaNAT). The GaNAT is 991 assumed to determine the correct IPus and IPpeer from 992 previous communications and in cooperation with GIST. 993 [Issue: how exactly should IPus, IPpeer and IPflow be 994 resolved; i.e. what exactly should the GaNAT remember?] 996 An NR-side NSLP-aware GaNAT operates according to the following 997 rules. 999 1. If the packet is received on the upstream link, the MRITS does 1000 the following, before the NSLP is notified. 1002 1. P.MRI.SourceIPAddress <- IPds 1004 2. P.MRI.DestinationIPAddress <- IPNext, where IPds is the 1005 GaNAT's IP address for the downstream link and IPNext is the 1006 address of the DR. IPNext is obtained in a way similar to 1007 the case of an NSLP-unaware GaNAT. 1009 2. If, after NSLP processing, a message is to be forwarded on the 1010 downstream link, GIST performs the following processing (note 1011 that no MRITS processing takes place in this case). 1013 1. [IP header].SourceIPAddress <- IPds 1015 2. [IP header].DestinationIPAddress <- IPNext 1017 3. NLI.IA <- IPds 1019 4. S <- true, where IPds is the GaNATs IP address for the 1020 downstream link, IPNext is the IP address of the DR (or the 1021 next GaNAT in the downstream direction). The GaNAT is 1022 assumed to determine the correct IPNext in a way similar to 1023 the case of an NSLP-unaware GaNAT. 1025 3. When the NSLP asks for a message to be sent towards the upstream 1026 peer, the MRITS does the following. 1028 1. MRI.SourceIPAddress <- IPflow 1030 2. MRI.Destination_IP_Address <- IPus 1032 4. Additionally, GIST performs the following on the resulting packet 1033 before it is forwarded on the downstream link. 1035 1. [IP header].SourceIPAddress <- IPus 1037 2. [IP header].DestinationIPAddress <- IPpeer 1039 3. NLI.IA <- IPus 1041 4. S <- true, where IPus is the GaNATs IP address for the 1042 upstream link, IPpeer is the IP address of the NI (or the 1043 next GaNAT in the upstream direction), and IPflow is the IP 1044 address of the DS. The GaNAT is assumed to determine the 1045 correct IPus and IPpeer fields from previous communications 1046 and in cooperation with GIST. [question: how exactly should 1047 IPus and IPpeer be resolved; i.e. what exactly should the 1048 GaNAT remember]? 1050 5.4. Combination of NSLP-aware and NSLP-unaware GaNATs 1052 In the absence of an adversary, a combination of NSLP-aware and NSLP- 1053 unaware GaNATs should work without further specification. However, 1054 in the presence of an adversary, additional security issues may arise 1055 from the combination. These issues may introduce opportunities for 1056 attack that do not exist in setting where the on-path GaNATs are 1057 either all NSLP-aware or all NSLP-unaware. 1059 6. Non-transparent NAT traversal for GIST 1061 This section discusses the "non-transparent" operation for GaNAT 1062 traversal at the GIST layer, i.e. the first approach listed in 1063 Section 3. For this approach the behaviour of both the GaNAT and the 1064 GIST peers is defined. As with the transparent approach, the case of 1065 the in-between GaNAT(s) being located at the NI-side is different 1066 from that of NR-side GaNATs. Note that the mechanisms in this 1067 section apply only to NSLP-unware GaNATs. 1069 The GaNAT informs the NSLP peers about its presence during the GIST 1070 discovery process. This information enables the NSLP peers to map 1071 the translated data flow to the signalling messages, and to 1072 consistently translate the MRI, so that the NSLP only "sees" the 1073 correct MRI. Cryptographic protection of signalling messages can be 1074 supported with this approach because the GaNAT only modifies the GIST 1075 QUERY and RESPONSE messages, which are never cryptographically 1076 protected in their entirety. 1078 In this approach, the GaNAT embeds a "NAT Traversal Object" (NTO) 1079 payload type into the GIST QUERY. The NTO encodes the aforementioned 1080 information and is an optional payload in the GIST header of a GIST 1081 QUERY. It is added, and processed, by the GaNAT(s) through which the 1082 QUERY traverses. The information in the NTO enables the two NSLP 1083 peers to locally translate the MRI in the same way as if it were 1084 consistently and transparently translated by the in-between GaNAT(s). 1085 Note that there may be more than one GaNAT between the two NSLP 1086 peers. The format of the NTO follows the format of the object in the 1087 GIST common header. In particular, the NTO is preceded by a TLV 1088 common header, as defined in [1]. The A and B flags are both set to 1089 0 in this header, indicating that support for the NTO is mandatory. 1090 The type value is TBD. The NTO is defined as in section A.3.8 of 1091 [1]. 1093 6.1. NI-side NSLP-unaware GaNATs 1095 For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT 1096 executes an algorithm that is equivalent to the following. 1098 1. If P has a RAO followed by the GIST header with an NSLP ID that 1099 is not supported, and if it is identified as a GIST QUERY, the 1100 GaNAT does the following. 1102 1. We denote P by GQ. The GaNAT looks at the stack proposal in 1103 GQ. If it does not include any proposal with cryptographic 1104 protection, the GaNAT MAY choose to follow the approach 1105 described in Section 5.1 above. 1107 2. The GaNAT remembers GQ along with the link on which it 1108 arrived. We call this link the "upstream" link. 1110 3. The GaNAT searches its table of existing NAT bindings against 1111 entries that match the GQ.MRI. A matching entry means that 1112 the data flow, to which the signalling refers, already 1113 exists. 1115 + If a matching entry is found, the GaNAT looks at which 1116 link the packets of the data flow are forwarded; we call 1117 this link the "downstream" link. Further, the GaNAT 1118 checks how the headers of the data flow (IP addresses and 1119 port numbers) are translated according to this NAT 1120 binding. We denote the source IP address of translated 1121 data packets by IPds, and their [Transport layer 1122 header].SourcePort by SPDTds. 1124 + If no matching entry is found, the GaNAT determines, based 1125 on its routing table, the link on which packets that match 1126 GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be 1127 forwarded. We call this link the "downstream" link. 1128 Then, the GaNAT acquires an IP address and source port for 1129 itself on the downstream link, denoted by IPds and SPDTds 1130 respectively. This address and port could be dynamic or 1131 static, and will be used (among other things) for the 1132 installation of a NAT binding for the data traffic in the 1133 future. 1135 4. The GaNAT aquires a source port number for the version of the 1136 GIST QUERY that will be forwarded over the downstream link. 1137 We denote this port by SPSTds. (There is no requirement that 1138 SPSTds must be different from GQ.[UDP Header].SourcePort.) 1140 5. It creates a new GIST QUERY packet GQ', as follows. 1142 1. GQ' <- GQ 1144 2. GQ'.MRI.SourceIPAddress <- IPds 1146 3. GQ'.MRI.SourcePortNumber <- SPDTds 1148 4. GQ'.NLI.IA.<- IPds. 1150 5. GQ'.[IP header].SourceIPAddress <- IPds. 1152 6. GQ'.[UDP header].SourcePort <- SPSTds. 1154 7. GQ'.S <- true. 1156 8. It checks whether or not an NTO was included in GQ. 1158 - If none was included, it creates a new NTO as follows 1159 and adds it to GQ'. Note that the MRI field of the 1160 NTO is taken from GQ. 1162 o NTO.[NAT Count] <- 1. 1164 o NTO.MRI <- GQ.MRI. 1166 o NTO.[List of translated objects] <- [type of NLI] 1168 o NTO.opaque information replaced by NAT 1 <- 1169 GQ.NLI.IA, GQ.[UDP header].SourcePort, LinkID, 1170 where LinkID represents the upstream link. 1172 - If one was included, it replaces certain fields and 1173 appends new fields into the NTO, as follows, and adds 1174 the resulting object to GQ'. Note that the MRI field 1175 of the NTO is not modified. 1177 o NTO.[NAT Count] <- i, where i is the current [NAT 1178 count] value increased by one. 1180 o NTO.[List of translated objects] <- [type of NLI] 1182 o NTO.opaque information replaced by NAT i <- 1183 GQ.NLI.IA, GQ.[UDP header].SourcePort, LinkID, 1184 where LinkID represents the upstream link. 1186 9. It remembers GQ, GQ', the fact that they are associated, 1187 and the associated upstream and downstream links. 1189 10. It forwards GQ' on the downstream link. 1191 2. Otherwise, if P carries an [IP header].DestinationIPAddress that 1192 belongs to the GaNAT, and if it is identified as a GIST RESPONSE 1193 with an NSLP ID that is not supported, the GaNAT does the 1194 following (P is denoted by GR). 1196 1. If P does not contain an NTO, the GaNAT discards it without 1197 further processing. Otherwise, it searches for a matching 1198 GQ' in its buffer. A GQ' is said to be matching if it 1199 carries the same cookie value. If none is found, GR is 1200 discarded. Otherwise, the GaNAT should also make sure that 1201 the session ID in GR is the same as in GQ', that the NSLP IDs 1202 match, and that GR arrived on the downstream link. If these 1203 consistency checks fail, GR should be discarded. Otherwise, 1204 the GaNAT constructs a new GIST RESPONSE GR', as follows 1205 (note that no changes are made to the MRI). 1207 1. GR' <- GR 1209 2. The GaNAT selects the information that it encoded in the 1210 [opaque information replaced by NAT i] field of the 1211 embedded NTO, denoted by IPAddressToSend, 1212 PortAddressToSend and LinkID, where i is the current 1213 value of [NAT Count] as indicated in the NTO. 1215 3. GR'.[IP header].DestinationIPAddress <- IPAddressToSend. 1217 4. GR'.[UDP header].DestinationPort=PortAddressToSend. 1219 5. GR'.NTO.[NAT Count] <- reduce by one. 1221 6. GR'.S <- true. 1223 2. The GaNAT inspects the Stack-Configuration-Data object in GR 1224 and the corresponding GQ' in order to check whether or not 1225 the upstream NSLP peer can select one of multiple transport 1226 layer protocol/destination port number combinations for the 1227 establishment of a messaging association. If multiple 1228 choices exist, the GaNAT invalidates as many transport layer 1229 protocol/port number combination proposals from GR' as 1230 necessary, until the upstream NSLP peer can only initiate the 1231 establishment of a messaging association with the downstream 1232 NSLP peer using a single transport layer protocol/destination 1233 port number combination. This invalidation is done by 1234 setting the D-flag in those MA-Protocol-Options fields that 1235 carry the port number proposals that are to be invalidated. 1236 Note that, by setting the D-flag in a particular MA-Protocol- 1237 Option field, the GaNAT may also invalidate the associated 1238 transport layer and security protocol (e.g. TCP/TLS) 1239 proposal. The actions of the GaNAT MUST NOT result in the 1240 strongest, in terms of security, proposal to be invalidated. 1241 In the end, the NAT will expect the upstream NSLP peer to use 1242 a particular combination of transport layer protocol and 1243 destination port (and possibly other details that are 1244 associated with the valid proposal) for the establishment of 1245 the messaging association. We call this combination the 1246 "stack proposal expected by the NAT" and denote it by ST. 1247 The GaNAT remembers this ST, its association with GQ, GQ', 1248 GR, GR', and the upstream and downstream links. By doing so, 1249 the GaNAT is said to "install" ST. 1251 3. It forwards GR' on the link identified by LinkID. 1253 4. The GaNAT now installs a NAT binding for the signalling 1254 traffic that is exchanged over a messaging association which 1255 says that "a packet K that arrives on the upstream link and 1256 for which it holds that 1258 + K.[IP header].DestinationIPAddress=GR.NLI.IA,, 1260 + K.[IP header].Protocol=ST.Protocol, and 1262 + K.[Transport layer 1263 header].DestinationPort=ST.DestinationPort 1265 should be forwarded on the downstream link, with [IP 1266 header].SourceIPAddress = IPds and [UDP/TCP 1267 header].DestinationPort=SIGPort, where SIGPort is a port that 1268 the GaNAT allocates for use as a source port for signalling 1269 traffic. 1271 5. The GaNAT now installs a NAT binding for the UDP-encapsulated 1272 signalling traffic which says that "a packet M that arrives 1273 on the upstream link and for which it holds that 1275 + M.[IP header].DestinationIPAddress=GR.NLI.IA, 1277 + M.[IP header].Protocol=UDP, and 1279 + M.[UDP header].DestinationPort=GIST well-known port 1281 should be forwarded on the downstream link, with [IP 1282 header].SourceIPAddress = IPds. Note that this is a special 1283 type of NAT binding, in that the source port in M may vary 1284 from one incoming message to another. This is why each 1285 packet M may be mapped by the GaNAT to a different source 1286 port. Translation in the upstream direction must be applied 1287 consistently, and timeouts must also be selected 1288 appropriately. That is, the overall binding must be timed 1289 out together with the GIST state that is associated with this 1290 session. However, each incoming packet M that matches this 1291 binding causes the installation of a "sub"-binding (in the 1292 sense that a new port mapping may occur) that will typically 1293 time out faster. 1295 6. If no NAT binding for the data traffic was found in step 1296 1.3.2, the GaNAT now installs a NAT binding (for the 1297 unidirectional data traffic) which says that "a packet L that 1298 arrives on the upstream link and for which it holds that 1299 + L.[IP 1300 header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, 1302 + L.[IP header].Protocol=GQ.MRI.Protocol, and 1304 + L.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers 1306 should be forwarded on the downstream link, with [IP 1307 header].SourceIPAddress = IPds and [UDP/TCP 1308 header].SourcePort=SPDTds. 1310 Issues: there is a question of whether this NAT binding 1311 should also enable data traffic in the opposite direction to 1312 traverse the NAT; in order to be able to demultiplex upstream 1313 traffic that carries data that belongs to different flows, 1314 the GaNAT should keep the necessary per-flow state. From a 1315 signalling point of view, however, upstream data traffic that 1316 corresponds (on the application level) to the downstream flow 1317 to which this GIST session refers, is a separate flow for 1318 which, dependent on the application, there may or there may 1319 not exist a signalling session. If such a signalling session 1320 exists, then the GaNAT acts as an NR-side GaNAT for this 1321 session. Thus, during the processing of this signalling care 1322 has to be taken not to establish a NAT binding for a flow for 1323 which a NAT binding already exists. Finally, security issues 1324 arise when traffic, for which no signalling exists, is 1325 allowed to traverse a GaNAT. 1327 3. Otherwise, if P matches an existing NAT binding, normal NAT 1328 processing is applied. 1330 4. Otherwise, P is subjected to normal NAT processing. That is, P 1331 is either silently discarded or it causes the installation of a 1332 (data) NAT binding. 1334 6.2. NR-side NSLP-unaware GaNATs 1336 As is the case with NR-side NSLP-unaware GaNATs that follow the 1337 "transparent" approach, an NR-side NSLP-unaware GaNAT that follows 1338 the "non-transparent" approach must know a "pending" IP address and 1339 optionally destination port number, as described in Section 5.2. 1340 This IP address and destination port number are denoted by IPNext and 1341 PortNext respectively. How they are made known to the GaNAT is 1342 outside the scope of this document. Note, however, that a typical 1343 scenario would be that the GaNAT has an existing NAT binding in place 1344 from where this information can be derived. 1346 For every incoming IP packet P, an NSLP-unaware, NR-side GaNAT 1347 executes the following algorithm. 1349 1. If P carries an [IP header].DestinationIPAddress that belongs to 1350 the GaNAT, if it has a RAO followed by the GIST header with an 1351 unsupported NSLPID, and if it is identified as a GIST QUERY, the 1352 GaNAT does the following. 1354 1. We denote P by GQ. The GaNAT looks at the stack proposal in 1355 GQ. If it does not include any proposal with cryptographic 1356 protection, the GaNAT MAY choose to follow the "transparent" 1357 approach as described in Section 5.2 above. 1359 2. If GQ.[IP header].DestinationIPAddress, denoted by IPus in 1360 the sequel, is not bound to the link on which GQ arrived, the 1361 GaNAT silently discards the packet. Otherwise, it remembers 1362 GQ along with the link on which it arrived. We call this 1363 link the "upstream" link. 1365 3. The GaNAT determines whether or not this GIST QUERY is 1366 anticipated, i.e. if a pending IPNext and PortNext exists. 1367 One way of determining whether or not a pending IPNext and 1368 PortNext exists is checking whether or not a NAT binding for 1369 the data traffic, as this is defined by the MRI in the GIST 1370 QUERY, exists in the NAT binding cache. If one exists, then 1371 IPNext and PortNext is the address and destination port 1372 number on which this traffic is forwarded. If no pending 1373 IPNext is found, then GQ is discarded (it is a question 1374 whether or not an error message should be sent). Otherwise, 1375 additional checks may be performed (e.g. a DSInfo object may 1376 have to be checked against the GQ). If these checks fail, GQ 1377 is discarded. Otherwise, the GaNAT performs the following. 1379 4. It searches its table of existing NAT bindings against 1380 entries that match GQ.MRI. A matching entry means that the 1381 data flow, to which the signalling refers, already exists. 1383 + If a matching entry is found, the GaNAT looks at which 1384 link the packets of the data flow are forwarded; we call 1385 this link the "downstream" link. Further, the GaNAT 1386 checks how the headers of the data flow (IP addresses, 1387 port numbers) are translated according to this NAT 1388 binding. Note that the [IP header].DestinationIPAddress 1389 and DestinationPort in this NAT binding should be equal to 1390 IPNext and PortNext respectively. If they are not, this 1391 should be handled as an auditive error condition. (This 1392 check is done as a consistency check.) 1394 + If no matching entry is found, the GaNAT determines, based 1395 on its routing table, the link on which packets that match 1396 GQ.MRI (where GQ.MRI.DestinationIPAddress is replaced with 1397 IPNext) would be forwarded. We call this link the 1398 "downstream" link. 1400 5. It creates a new GIST QUERY packet GQ', as follows. 1402 1. GQ' <- GQ 1404 2. GQ'.MRI.DestinationIPAddress <- IPnext 1406 3. GQ'.MRI.DestinationPortNumber <- PortNext 1408 4. GQ'.[IP header].DestinationIPAddress <- IPnext 1410 5. GQ'.[UDP header].DestinationPort <- GIST well-known port 1411 (TBD) 1413 6. It checks whether or not an NTO was included in GQ. 1415 - If none was included, it creates a new NTO as follows 1416 and adds it to GQ'. Note that the MRI field of the 1417 NTO is taken from GQ. 1419 o NTO.[NAT Count] <- 1. 1421 o NTO.MRI <- GQ.MRI. 1423 o NTO.opaque information for NAT 1 <- LinkID of 1424 upstream link. 1426 - If one was included, it replaces certain fields and 1427 appends new fields into the NTO, as follows, and adds 1428 the resulting object to GQ'. Note that the MRI field 1429 of the NTO is not modified. 1431 o NTO.[NAT Count] <- i, where i is the current [NAT 1432 count] value increased by one. 1434 o NTO.opaque information replaced by NAT i <- LinkID 1435 of upstream link. 1437 7. It remembers GQ, GQ', the fact that they are associated, 1438 and the associated upstream and downstream links. 1440 8. It forwards GQ' on the downstream link. 1442 2. Otherwise, if P is identified as a GIST RESPONSE packet with an 1443 NSLP ID that is not supported, the GaNAT does the following (P is 1444 denoted by GR). 1446 1. It searches for a matching GQ' in its buffer. A GQ' is said 1447 to be matching if it carries the same cookie value. If none 1448 is found, GR is discarded. Otherwise, the GaNAT should also 1449 make sure that the session ID in GR is the same as in GQ', 1450 that the NSLP IDs match, and that GR arrived on the 1451 downstream link. If these consistency checks fail, GR should 1452 be discarded. Otherwise, the GaNAT constructs a new GIST 1453 RESPONSE GR', as follows. 1455 2. If P does not contain an NTO, the GaNAT discards it without 1456 further processing. Otherwise, the GaNAT constructs a new 1457 GIST RESPONSE GR', as follows (note that no changes are made 1458 to the MRI). 1460 1. GR' <- GR. 1462 2. The GaNAT selects the information that it encoded in the 1463 [opaque information replaced by NAT i] field of the 1464 embedded NTO, denoted by LinkID, where i is the current 1465 value of [NAT Count] as indicated in the NTO. 1467 3. GR'.NLI.IA <- IPus 1469 4. GR'.NTO.[List of translated objects by NAT i] <- [type of 1470 NLI], where i is the current value of [NAT Count] as 1471 indicated in the NTO. 1473 5. GR'.NTO.[NAT Count] <- reduce by one. 1475 6. GR'.[IP header].SourceIPAddress <- IPus (this is the IP 1476 address that is bound to the link identified by LinkID 1477 and must be equal to GQ.[IP header].DestinationIPAddress, 1478 where GQ is the GIST QUERY associated with GQ'). 1480 7. GR'.[UDP header].DestinationPort <- GQ.[UDP 1481 header].SourcePort, where GQ is the GIST QUERY associated 1482 with GQ'. 1484 8. GR'.S <- true. 1486 3. The GaNAT inspects the Stack-Configuration-Data object in GR 1487 and the corresponding GQ' in order to check whether or not 1488 the upstream NSLP peer can select one of multiple transport 1489 layer protocol/destination port number combinations for the 1490 establishment of a messaging association. If multiple 1491 choices exist, the GaNAT invalidates as many transport layer 1492 protocol/port number combination proposals from GR' as 1493 necessary, until the upstream NSLP peer can only initiate the 1494 establishment of a messaging association with the downstream 1495 NSLP peer using a single transport layer protocol/destination 1496 port number combination. This invalidation is done by 1497 setting the D-flag in those MA-Protocol-Options fields that 1498 carry the port number proposals that are to be invalidated. 1499 Note that, by setting the D-flag in a particular MA-Protocol- 1500 Option field, the GaNAT may also invalidate the associated 1501 transport layer and security protocol (e.g. TCP/TLS) 1502 proposal. The actions of the GaNAT MUST NOT result in the 1503 strongest, in terms of security, proposal to be invalidated. 1504 In the end, the NAT will expect the upstream NSLP peer to use 1505 a particular combination of transport layer protocol and 1506 destination port (and possibly other details that are 1507 associated with the valid proposal) for the establishment of 1508 the messaging association. We call this combination the 1509 "stack proposal expected by the NAT" and denote it by ST. 1510 The GaNAT remembers this ST, its association with GQ, GQ', 1511 GR, GR', and the upstream and downstream links. By doing so, 1512 the GaNAT is said to "install" ST. If ST.DestinationPort is 1513 already used by the GaNAT as a destination port in order to 1514 demultiplex an existing flow, the GaNAT reserves a 1515 destination port SIGPORT and modifies the valid port proposal 1516 in GR' such that SIGPORT will be used by the upstream GIST 1517 peer. Otherwise it sets SIGPORT=ST.DestinationPort. 1519 4. It forwards GR' on the link identified by LinkID (i.e. the 1520 upstream link). 1522 5. The GaNAT now installs a NAT binding for the signalling 1523 traffic that is exchanged over a messaging association which 1524 says that "a packet K that arrives on the upstream link and 1525 for which it holds that 1527 + K.[IP header].DestinationIPAddress=IPus (which is equal to 1528 GQ.MRI.DestinationIPAddress and GQ.[IP 1529 header].DestinationIPAddress), 1531 + K.[IP header].Protocol=ST.Protocol, and 1533 + K.[Transport layer header].DestinationPort=SIGPORT 1535 should be forwarded on the downstream link, with [IP 1536 header].DestinationIPAddress = GR.NLI.IA and [Transport layer 1537 header].DestinationPort=ST.DestinationPort. 1539 6. The GaNAT now installs a NAT binding for the UDP-encapsulated 1540 signalling traffic which says that "a packet M that arrives 1541 on the upstream link and for which it holds that 1543 + M.[IP header].DestinationIPAddress=IPus, 1545 + M.[IP header].Protocol=UDP, and 1547 + M.[UDP header].DestinationPort=GIST well-known port 1549 should be forwarded on the downstream link, with [IP 1550 header].SourceIPAddress = GR.NLI.IA". Note that this is a 1551 special type of NAT binding, in that the source port in M may 1552 vary from one incoming message to another. This is why each 1553 packet M may be mapped by the GaNAT to a different source 1554 port. Translation in the upstream direction must be applied 1555 consistently, and timeouts must also be selected 1556 appropriately. That is, the overall binding must be timed 1557 out together with the GIST state that is associated with this 1558 session. However, each incoming packet M that matches this 1559 binding causes the installation of a "sub"-binding (in the 1560 sense that a new port mapping may occur) that will typically 1561 time out faster. 1563 7. If no NAT binding for the data traffic was found in step 1564 1.3.2, the GaNAT now installs a NAT binding (for the 1565 unidirectional data traffic) which says that "a packet L that 1566 arrives on the upstream link and for which it holds that 1568 + L.[IP header].DestinationIPAddress=IPus (which is equal to 1569 GQ.MRI.DestinationIPAddress and GQ.[IP 1570 header].DestinationIPAddress), 1572 + L.[IP header].Protocol=GQ.MRI.Protocol, and 1574 + L.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers 1576 should be forwarded on the downstream link, with [IP 1577 header].DestinationIPAddress = IPNext and [Transport layer 1578 header].DestinationPort=PortNext. 1580 Note: If the GaNAT also allows data traffic to traverse in 1581 the other direction (i.e. in the upstream direction), then 1582 the IP packets of this data traffic MUST have 1583 SourceIPAddress=IPus, SourcePort=GQ.MRI.DestinationPort, 1584 DestinationPort=GQ.MRI.SourcePort, and must be forwarded on 1585 the upstream link. (This applies anyway for GaNATs with only 1586 two links and where each link is bound to a single IP 1587 address. However, for other types of GaNAT care has to be 1588 taken that this restriction is enforced.) 1590 Issues: there is a question of whether this NAT binding 1591 should also enable data traffic in the opposite direction to 1592 traverse the NAT; in order to be able to demultiplex upstream 1593 traffic that carries data that belongs to different flows, 1594 the GaNAT should keep the necessary per-flow state. From a 1595 signalling point of view, however, upstream data traffic that 1596 corresponds (on the application level) to the downstream flow 1597 to which this GIST session refers, is a separate flow for 1598 which, dependent on the application, there may or there may 1599 not exist a signalling session. If such a signalling session 1600 exists, then the GaNAT acts as an NR-side GaNAT for this 1601 session. Thus, during the processing of this signalling care 1602 has to be taken not to establish a NAT binding for a flow for 1603 which a NAT binding already exists. Finally, security issues 1604 arise when traffic, for which no signalling exists, is 1605 allowed to traverse a GaNAT. 1607 3. Otherwise, if P matches an existing NAT binding, normal NAT 1608 processing is applied. 1610 4. Otherwise, P is subjected to normal NAT processing. That is, P 1611 is either silently discarded or it causes the installation of a 1612 (data) NAT binding. 1614 The remaining steps of the algorithm are analogous to the algorithm 1615 of NSLP-unaware, NR-side GaNATs, which was described in the previous 1616 section. 1618 6.3. GIST peer processing 1620 In the presence of GaNATs on the signalling path between two NSLP 1621 peers, and if the GaNATs follow the "non-transparent" approach (which 1622 they have to follow in the context of cryptographically protected 1623 signalling), the consistent translation of the GIST header fields 1624 must be carried out by the NSLP peers. The GIST processing that 1625 performs this task, is described next. Note that this processing is 1626 in addition to the processing described in [1]. Also note that the 1627 processing described in this section applies only to non-NAT nodes. 1629 A GIST peer that receives a GIST QUERY that carries an NSLP ID for a 1630 supported NSLP and an NTO, constructs a GIST RESPONSE according to 1631 [1]. This response is sent to the public address of the last in- 1632 between GaNAT. This address appeared as NLI.NI in the GIST QUERY 1633 (and also as the source address in the IP header). 1635 If local policy allows the installation of state without the 1636 reception of a GIST CONFIRM message, then the responder stores the 1637 NTO carried with the QUERY together with the routing state 1638 information about the querying GIST peer. In particular, the MRI 1639 field of the NTO must be saved in order for the peer to be able to 1640 map subsequently received signalling messages to this signalling 1641 session. 1643 Note that it is not sufficient for the NSLP to exclusively rely on 1644 the NTO.MRI for this purpose. In order to see this, consider two 1645 private addressing domains, A and B, each with a GaNAT at its border, 1646 and a node N in the public internet. In domain A, node N1 has a 1647 communication session with N, and in domain B, node N2 also has a 1648 communication session with N. Suppose that the (private) IP addresses 1649 of N1 and N2 are equal (e.g. 192.168.0.3), and that they both 1650 communicate with N using the same source and destination ports. If 1651 they both have an NSIS signalling session for this data traffic, the 1652 NTO.MRI field in the GIST QUERY of their respective signalling 1653 sessions are identical. If these signalling sessions meet at an NSLP 1654 node that is located "after" the GaNATs, then this NSLP node sees the 1655 same MRI in signalling messages that are received over a messaging 1656 association. In this case, the node must use other information in 1657 the signalling messages (e.g. session ID, source IP address) in order 1658 to map subsequently received signalling messages to existing 1659 sessions. 1661 If local policy demands that no session-specific state is installed 1662 before the reception of a GIST CONFIRM message, then the responder 1663 must encode the information in NTO.MRI and NLI.IA from the GIST QUERY 1664 (and possibly other values such as NSLP ID and an identifier of the 1665 link on which the GIST QUERY arrived) in the responder cookie. Since 1666 this cookie is echoed in the GIST CONFIRM message, the responder can 1667 then delay the installation of the relevant state until it receives 1668 the GIST CONFIRM. The construction of the responder cookie is 1669 implementation-specific, in the sense that it does not raise 1670 interoperability issues. Nevertheless, the cookie must be generated 1671 in a way that meets the requirements listed in section 8.5 of [1], 1672 and in a way that does not introduce additional attacks against the 1673 system. 1675 Two responder cookie construction mechanisms are described in the 1676 sequel. These methods are in addition to those described in section 1677 8.5 of [1], and meet the requirements listed in that section. 1678 Additionally, they enable the responder to authenticate the contents 1679 of the cookie, i.e. to ensure that the cookie was not tampered with 1680 while in transit. This feature is not provided by the cookie 1681 construction mechanisms described in [1]. 1683 Responder cookie generation mechanism 1: Responder cookie = (gennum 1684 || cookie-left || cookie-right), where || denotes concatenation, 1685 cookie-left is computed as ENC (Q-Node NLI, MRI, NSLPID, reception 1686 interface, [timestamp]), and cookie-right is computed as MAC (cookie- 1687 left). ENC denotes a semantically secure symmetric encryption 1688 scheme, and MAC denotes an unforgeable message authentication code 1689 scheme. The responder must use a key with ENC that has been selected 1690 independently from the one used with MAC. Whenever these keys are 1691 refreshed, they MUST be refreshed together. Gennum is the generation 1692 number of the ENC and MAC keys. The timestamp is an optional field. 1693 Policy dictates whether or not it is included in the construction of 1694 the cookie. For example, responders that have a fast enough key 1695 rollover may omit the timestamp. Example algorithms for ENC and MAC 1696 are AES-128 in CBC mode [3], and HMAC-SHA1 [4]. 1698 Responder cookie generation mechanism 2: Responder cookie = (Gennum 1699 || AUTHENC (Q-Node NLI, MRI, NSLPID, reception interface, 1700 [timestamp])) AUTHENC denotes a symmetric authenticated encryption 1701 scheme. Gennum is the generation number of the key used with 1702 AUTHENC. The timestamp is an optional element for the same reason as 1703 above. Example AUTHENC algorithms include the one specified in 1704 RFC3610. 1706 The version of the MRI that the NSLP peers pass to the NSLP is the 1707 one in the header of the GIST QUERY (not the one in the NTO, if one 1708 is present). Whether or not this is a translated MRI depends on the 1709 location of the peer with respect to the in-between GaNAT(s). Note 1710 that the same MRI is used by the responder in signalling messages 1711 that are sent towards the downstream direction. 1713 7. Security Considerations 1715 The mechanisms proposed in this document give rise to a number of 1716 threats that must be considered. In the following, some of these 1717 threats is mentioned. 1719 7.1. Service Denial Attacks 1721 As described above, NSLP-unaware GaNATs create some state whenever 1722 they receive a GIST QUERY message. This state is necessary in order 1723 for the GaNAT to be able to map a GIST RESPONSE that arrives from the 1724 downstream direction to the corresponding GIST QUERY and thereby to 1725 perform the required translation. 1727 The threat here is an attacker flooding the GaNAT with maliciously 1728 constructed GIST QUERIES with the aim of exhausting the GaNAT's 1729 memory. The attacker might use a variety of methods to construct 1730 such GIST QUERIES, including the following. 1732 1. Use as [IP header].SourceIPAddress the address of some other node 1733 or an unallocated IP address. This method is also known as IP 1734 spoofing. 1736 2. Use an invalid NSLPID, in order to make sure that all on-path 1737 GaNAT(s) will behave like NSLP-unaware GaNATs. 1739 3. For each packet, use a different value for the cookie field. 1741 4. For each packet, use a different value for the session ID field. 1743 5. Combinations of the above. 1745 How vulnerable a GaNAT is to the above service denial attack depends 1746 on a variety of factors, including the following. 1748 o The amount of state allocated at the receipt of a GIST QUERY. 1749 This amount may vary depending on whether or not the data flow to 1750 which the signalling refers, already exists (i.e. whether or not 1751 the GaNAT already maintains a NAT binding for it). 1753 o The mechanism that the GaNAT uses to map RESPONSEs to QUERIEs. 1755 o Whether or not the GaNAT acquires dynamic IP addresses and ports 1756 for the downstream link. 1758 In order to decrease the exposure of a GaNAT to service denial 1759 attacks, the following recommendations are made. 1761 o The GaNAT should perform ingress filtering. This limits the 1762 amount of locations from which an attacker can perform IP spoofing 1763 without being detected. 1765 o The GaNAT should allocate the minimum amount of state required at 1766 the reception of a GIST QUERY. 1768 o All state allocated by the GaNAT should timeout according to a 1769 local policy. If the GaNAT detects heavy loads (which may 1770 indicate a service denial attack in progress), the GaNAT should 1771 timeout the state allocated as a result of a received GIST QUERY 1772 quicker, proportionally to the experienced load. 1774 o The installation of a NAT binding for the data traffic (if such a 1775 binding does not exist prior to signalling) should be postponed 1776 until the correct GIST RESPONSE traverses the NAT. 1778 The service denial threats mentioned in this section do not apply to 1779 an NSLP-aware GaNAT, as such a GaNAT is required, in accordance with 1780 its local policy, to verify the validity of the cookie(s) before 1781 allocating any state, including the state required by the mechanisms 1782 in this document. 1784 7.2. Network Intrusions 1786 Although the primary goal of a NAT is to perform address translation 1787 between two addressing spaces, NATs are sometimes also used to 1788 provide a security service similar to the security service provided 1789 by firewalls. That is, a NAT can be configured so that it does not 1790 forward packets from the external into the internal network, unless 1791 it determines that the packets belong to a communication session that 1792 was originally initiated from an internal node and are, as such, 1793 solicited. 1795 If an NSLP-unaware GaNAT performs the above security-relevant 1796 function in addition to address translation, then the presence of 1797 GIST signalling and, in particular the mechanisms described in this 1798 document, might allow an adversary to cause the installation of NAT 1799 bindings in the GaNAT using these mechansisms. These NAT bindings 1800 would then enable the adversary to inject unsolicited traffic into 1801 the internal network, a capability that it might not have in the 1802 absence of the mechanisms described in this document. 1804 The administrator of an NSLP-unaware GaNAT should therefore make 1805 security-conscious decisions regarding the operation of the GaNAT. 1806 An NSLP-aware GaNAT, on the other hand, follows an NSLP policy which 1807 indicates the required security mechanisms. This policy should 1808 account for the fact that this NSLP-aware node performs also NAT and 1809 the associated packet filtering. 1811 8. IAB Considerations 1813 None. 1815 9. Acknowledgements 1817 The authors would like to thank Cedric Aoun, Christian Dickmann, 1818 Robert Hancock, and Martin Stiemerling for their insightful comments. 1819 Furthermore, we would like to mention that this document builds on 1820 top of a previous document regarding migration scenarios. 1822 10. Normative References 1824 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1825 Signalling Transport", draft-ietf-nsis-ntlp-13 (work in 1826 progress), April 2007. 1828 [2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS 1829 Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 1830 (work in progress), March 2007. 1832 [3] "Advanced Encryption Standard (AES)", FIPS PUB 197, 1833 November 2001. 1835 [4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1836 for Message Authentication", RFC 2104, February 1997. 1838 Authors' Addresses 1840 Andreas Pashalidis 1841 NEC 1842 Kurfuersten-Anlage 36 1843 Heidelberg 69115 1844 Germany 1846 Email: Andreas.Pashalidis@netlab.nec.de 1848 Hannes Tschofenig 1849 Siemens 1850 Otto-Hahn-Ring 6 1851 Munich, Bavaria 81739 1852 Germany 1854 Email: Hannes.Tschofenig@siemens.com 1856 Full Copyright Statement 1858 Copyright (C) The IETF Trust (2007). 1860 This document is subject to the rights, licenses and restrictions 1861 contained in BCP 78, and except as set forth therein, the authors 1862 retain all their rights. 1864 This document and the information contained herein are provided on an 1865 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1866 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1867 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1868 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1869 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1870 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1872 Intellectual Property 1874 The IETF takes no position regarding the validity or scope of any 1875 Intellectual Property Rights or other rights that might be claimed to 1876 pertain to the implementation or use of the technology described in 1877 this document or the extent to which any license under such rights 1878 might or might not be available; nor does it represent that it has 1879 made any independent effort to identify any such rights. Information 1880 on the procedures with respect to rights in RFC documents can be 1881 found in BCP 78 and BCP 79. 1883 Copies of IPR disclosures made to the IETF Secretariat and any 1884 assurances of licenses to be made available, or the result of an 1885 attempt made to obtain a general license or permission for the use of 1886 such proprietary rights by implementers or users of this 1887 specification can be obtained from the IETF on-line IPR repository at 1888 http://www.ietf.org/ipr. 1890 The IETF invites any interested party to bring to its attention any 1891 copyrights, patents or patent applications, or other proprietary 1892 rights that may cover technology that may be required to implement 1893 this standard. Please address the information to the IETF at 1894 ietf-ipr@ietf.org. 1896 Acknowledgment 1898 Funding for the RFC Editor function is provided by the IETF 1899 Administrative Support Activity (IASA).