idnits 2.17.00 (12 Aug 2021) /tmp/idnits28460/draft-pashalidis-nsis-gimps-nattraversal-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1872. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 125: '...lements GIST and MAY also implement a ...' RFC 2119 keyword, line 174: '...e sequel. A GaNAT MAY also support at...' RFC 2119 keyword, line 333: '... MUST follow the transparent approac...' RFC 2119 keyword, line 335: '...aphically protected, a GaNAT MUST also...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 774 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 (June 23, 2006) is 5810 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-nsis-ntlp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS A. Pashalidis 3 Internet-Draft H. Tschofenig 4 Expires: December 25, 2006 Siemens 5 June 23, 2006 7 GIST NAT Traversal 8 draft-pashalidis-nsis-gimps-nattraversal-03.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 December 25, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . 45 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 73 Intellectual Property and Copyright Statements . . . . . . . . . . 47 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 Responder, as defined in [1] 108 o DS: Data 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, as defined in [1] 118 o NR: NSIS Responder, as defined in [1] 120 o NSIS: Next Steps in Signalling: The name of the IETF working group 121 that specified the family of signalling protocols of which this 122 document is also a member. The term NSIS is also used to refer to 123 this family of signalling protocols as a whole. 125 o GIST-aware: Implements GIST and MAY also implement a number of 126 NSLPs. 128 o GIST-unaware: GIST-unaware, does not implement any NSLP. The term 129 is synonymous to NSIS-unaware. 131 o NSLP: NSIS Signalling Layer Protocol, as defined in [1] 133 o downstream: as defined in [1] 135 o upstream: as defined in [1] 137 o MRI: Message Routing Information, as defined in [1] 139 o NLI.IA: Interface Address field of the Network Layer Information 140 object, as defined in [1] 142 o <- : Assignment operator. The quantity to the right of the 143 operator is assigned to the variable to its left. 145 o A.B: Element B of structure A. Example: [IP 146 header].SourceIPAddress denotes the source IP address of an IP 147 header. 149 o [data item]: This notation indicates that "data item" is a single 150 identifier of a data structure. (Square brackets do not denote 151 optional arguments in this document.) 153 3. Problem Statement 155 According to [1], all GIST messages between two peers carry IP 156 addresses in order to define the data flow to which the signalling 157 refers. Moreover, certain GIST messages also carry the IP address of 158 the sending peer, in order to enable the receiving peer to address 159 subsequent traffic to the sender. Packets that cross an addressing 160 boundary, say from addressing space S1 to S2, have the IP addresses 161 in the IP header translated from space S1 to S2 by the NAT; if GIST 162 payloads are not translated in a consistent manner, the MRI in a GIST 163 packet that crosses the boundary, e.g. from address space S1 to S2, 164 refers to a flow that does not exist in S2. In fact, the flow may be 165 invalid in S2 because at the IP address that belongs to S1 may not be 166 routable or invalid in S2. Moreover, the IP address of the sending 167 peer may also be not routable or invalid in the addressing space of 168 the receiving peer. The purpose of this document is to describe a 169 way for GIST messages to be translated in a way that is consistent 170 with the translation that NATs apply to the IP headers of the data 171 traffic. 173 A NAT may either be GIST-unaware or GIST-aware. We refer to a GIST- 174 aware NAT as a "GaNAT" in the sequel. A GaNAT MAY also support at 175 least one NSLP. Note that there exists an NSLP, namely the NATFW 176 NSLP [2], that specifically addresses NAT traversal for data flows. 177 Inevitably, the NATFW NSLP also provides the necessary mechanisms for 178 the related signalling to traverse the involved NATs. Consider a 179 GaNAT that supports both the NATFW NSLP, and the NAT traversal 180 mechanism that is described in this document (which operates at the 181 GIST layer). Suppose now that a GIST QUERY message arrives at this 182 GaNAT that contains the NSLP identifier (NSLPID) of the NATFW NSLP. 183 A question that arises is whether the GaNAT should use the GIST-layer 184 NAT traversal mechanism (described in this document), or the NATFW 185 NSLP mechanism, in order to provide "NAT traversal" for both the 186 signalling message and the data flow to which it refers. The answer 187 to this question is that a GaNAT should implement a policy according 188 to which one method is used in preference to the other. Note that, 189 however, if the GaNAT prefers GIST-layer NAT traversal, then it may 190 happen, if no on-path GaNATs exist that prefer the NATFW NSLP, that 191 no downstream NATFW NSLP peers are discovered. This may make the 192 entire NATFW session obsolete. It is therefore anticipated that the 193 NATFW NSLP will be the preferred NAT traversal mechanism in most 194 circumstances. 196 However, in certain cicumstances it may be desirable for GIST 197 signalling messages to traverse a NAT, and not desirable or possible 198 to use the NATFW NSLP for this purpose. Examples of such 199 circumstances are the following. 201 o GaNATs that do not implement the NATFW NSLP are on the path taken 202 by GIST signalling messages. This situation may arise during 203 incremental deployment of the signalling protocols that are 204 developed by the NSIS working group. 206 o GaNATs that implement the NATFW NSLP are on the path taken by GIST 207 signalling messages that refer to a given data flow. However, the 208 NSLP that is being signalled is *not* the NATFW NSLP and there 209 exists no NATFW signalling session for the data flow in question. 211 Describing NAT traversal for GIST signalling messages in the above 212 circumstances is the subject matter of this document. 214 In general, a given data flow between a data sender (DS) and a data 215 receiver (DR) may have to traverse a number of NATs, some of which 216 may be GIST-and-NATFW-aware, some may be GIST-aware, and some may be 217 GIST-unaware. Additionally, NSLP signalling for such a data flow may 218 be required to traverse through a subset of those NATs. Whether or 219 not the routing infrastructure and state of the network causes the 220 signalling for such a data flow to traverse the same NATs as the flow 221 depends, among other things, on which NSLP is being signalled. While 222 signalling of the QoS NSLP, for example, might not traverse any of 223 the NATs that are traversed by the data flow, the signalling of the 224 NATFW NSLP traverses at least those NATs that implement the NATFW 225 NSLP (otherwise the signalling path would no longer be coupled to the 226 data path, as this coupling is defined by the GIST QUERY/RESPONSE 227 discovery mechanism for the "path coupled" Message Routing Method). 228 It is desirable that the GIST-layer NAT traversal provides NAT 229 traversal for every possible combination of NATs, either on the data 230 or the signalling path, in a secure manner. 232 Due to the GIST QUERY/RESPONSE discovery mechanism (according to 233 which QUERY messages are simply forwarded if the current node does 234 not support the required NSLP), two GIST nodes typically identify 235 themselves as NSLP peers only if they both implement the same NSLP. 236 If one or more NATs that are unaware of this NSLP are between them, 237 then the two NSLP peers are not able to discover each other at all. 238 This is because, even in the unlikely event that the NAT bindings 239 that are necessary for the GIST traffic to traverse the in-between 240 NAT(s) exist, the NLI.IA field included in the RESPONSE message sent 241 by the downstream peer is invalid (or the IP address is unreachable) 242 in the address space of the upstream peer. In order to overcome this 243 limitation, either the two peers need to cope with the in-between 244 NAT(s), or, if the NAT(s) are GaNATs, they (the GaNATs) need to apply 245 additional processing in order to transparently create and maintain 246 consistency between the information in the header of GIST signalling 247 messages and the information in the IP header of the data traffic. 248 Additionally, if NSLP-aware NATs are on the data path, then these 249 NATs should process NSLP traffic in a way the preserves consistency 250 after address translation. This processing deviates from the 251 processing of NSLP-aware non-NAT nodes. The following sections 252 describe how to overcome the limitation of two adjacent NSLP peers 253 not being able to execute the NSLP in the presence of in-between 254 NAT(s). 256 A number of different variations are possible, depending on the level 257 of NSIS support by the in-between NAT(s). The following combinations 258 of NATs that are located between two adjacent NSLP peers are 259 considered. 261 o all NAT(s) are NSLP-unaware GaNAT(s) 263 o all NAT(s) are NSLP-aware 265 The approach taken in this document is to propose separate mechanisms 266 for the traversal of each of the above type of NAT. If NATs that 267 belong to multiple types exist on the path between two adjacent NSLP 268 peers, the proposed mechanisms should work in combination. Thus, 269 traversal of multiple NATs of different types should not require 270 further specification from a functional perspective. However, 271 security issues that arise due to the combination of NAT types may 272 have to be considered. 274 A GIST-unaware NAT cannot tell data and signalling traffic apart. 275 The installation of the NAT binding for the signalling traffic in 276 such a NAT occurs typically independently from the installation of 277 the NAT binding for the data traffic. Furthermore, as the NAT cannot 278 associate the signalling and the data traffic, it cannot indicate 279 that an association exists between the two NAT bindings. Therefore, 280 in the presence of such a NAT, non-NAT GIST nodes that are located on 281 either side of the NAT have to cope with the NAT without assistance 282 from the NAT. This would typically require initially discovering the 283 NAT and subsequently establishing an association between between the 284 MRI in the signalling messages and the translated IP header in the 285 data traffic. Due to the variety of behaviours that a GIST-unaware 286 NAT may exhibit, establishing this association is a non-trivial task. 287 Therefore, traversal of such (i.e. GIST-unaware) NATs is considered 288 a special case and is outside the scope of this version of this 289 document. 291 Traversal of GaNAT(s) is comparatively more straightforward. This is 292 because, based on the MRI in a given incoming GIST message, a GaNAT 293 can identify the data flow to which the message refers. It can then 294 check its NAT binding cache and determine the translation that is 295 (or, if no NAT binding for the flow exists yet, will be) applied to 296 the IP header of the data flow. The GaNAT can then include 297 sufficient information about this translation into the signalling 298 message, such that its receiver (i.e. the GIST peer that receives the 299 data traffic after network address translation has been applied) can 300 map the signalling message to the data flow. 302 There exist a variety of ways for a GaNAT to encode the above- 303 mentioned information into signalling messages. In this document the 304 following two ways are considered. 306 1. Non-transparent approach: The GaNAT includes an additional "NAT 307 Traversal" payload (see section A.3.8 of [1]) into the GIST 308 header of the GIST QUERY message. This "NAT Traversal" payload 309 is echoed by the GIST responder on the other side of the NAT. 310 The responder (which is assumed to be located on the "other side" 311 of the NAT) uses the information in this payload in order to map 312 subsequent signalling messages to the data flows they refer to. 314 2. Transparent approach: The GaNAT replaces GIST header fields in a 315 way that is consistent with the translation it applies to the 316 data traffic, as necessary. The GaNAT does this for GIST QUERY 317 and RESPONSE messages, for D-mode as well as for C-mode messages 318 throughout the duration of the signalling session. 320 The second approach being "transparent" means that a GaNAT that 321 follows this approach remains completely transparent to the GIST 322 peers that are located either side of it. Thus, this approach works 323 even if these GIST peers do not support the NAT traversal object for 324 GIST (as described in [1]). Unfortunately though, the transparent 325 approach does not work if the signalling traffic is to be 326 cryptographically protected between the two GIST peers that are 327 located either side of the GaNAT, and the GaNAT is NSLP-unaware. If, 328 however, the GaNAT is NSLP-aware, then cryptographic protection is 329 terminated at the GaNAT (i.e. the GaNAT is a GIST peer itself). In 330 this scenario, it is clearly preferable for the GaNAT to follow the 331 transparent approach, rather than to include a NAT Traversal object. 332 Thus, if a GaNAT acts as a GIST peer for a signalling session, it 333 MUST follow the transparent approach, as described in Section 5.3. 334 However, due to the fact that the transparent approach does not work 335 if signalling is to be cryptographically protected, a GaNAT MUST also 336 implement the non-transparent approach (for the case where an NSLP is 337 signalled that the GaNAT does not support), unless the GaNAT is going 338 to be used only in deployments where cryptographic protection of 339 signalling traffic is not a requirement. 341 Note that a GaNAT MAY implement both approaches. If such a GaNAT is 342 NSLP-unaware, it can then adopt the desired behaviour, based on 343 whether or not cryptographic protection is required for the 344 signalling traffic between two GIST peers. If such protection is 345 required, the GaNAT MUST adopt the mechanisms that follow the non- 346 transparent approach; if it is not, it MAY follow the mechanisms 347 implementing the transparent approach. The GaNAT can tell whether or 348 not cryptographic protection is required from the stack proposal in 349 the GIST QUERY and RESPONSE messages; inclusion of IPsec or TLS 350 proposals amounts to cryptographic protection being required. 352 4. Assumptions 354 The discussion in this document is based on the following 355 assumptions. 357 1. No IP addresses and port numbers are carried in the payloads of 358 an NSLP. If this is not the case, then the NSLP has to provide 359 additional mechanisms for the traversal of (Ga)NATs. These 360 mechanisms must be compatible the mechanisms described in this 361 document. Note that the NATFW NSLP is an exception to this rule 362 in that it does not need to be compatible with the mechanisms 363 described in this document. This is because the GIST-layer NAT 364 traversal mechanisms described in this document and the NATFW 365 NSLP are mutually exclusive (i.e. it is not permissible that a 366 given (Ga)NAT applies both GIST-layer NAT traversal and NATFW 367 NSLP processing to the messages that belong to the same 368 signalling session). 370 2. The path taken by the signalling traffic between those GIST peers 371 that have GaNATs in between is such that the responses to packets 372 that a GaNAT sends on a given interface arrive on the same 373 interface (if such responses are sent at all). 375 3. The path taken by signalling traffic remains fixed between the 376 two GIST peers, as far as the in-between GaNATs are concerned. 377 That is, we assume that signalling traffic traverses the same 378 GaNAT(s) until at least one of the following conditions is met. 380 * The NSIS state that is installed at the two GIST peers 381 expires. 383 * The NSIS state that is installed at the two GIST peers is 384 refreshed using a GIST QUERY. 386 * A new GIST QUERY/RESPONSE exchange takes place due to other 387 reasons, e.g. a detected route change. 389 Note that this assumption is not necessarily met by "normal" data 390 path coupled signalling. This is because, under "normal" data 391 path coupled signalling, the signalling traffic is "coupled" to 392 the data traffic at nodes that decide to act as GIST peers. 393 Thus, under "normal" path coupled signalling, it is not an error 394 condition (e.g. a reason to trigger a "route change"), for 395 example, if the set of on-path nodes, which do not act as GIST 396 peers, changes, as long as adjacent GIST peers remain the same. 398 4. The data flow traverses the same set of GaNATs as the signalling 399 traffic. By assumption 3, this set of GaNATs is fixed until the 400 next GIST QUERY/RESPONSE procedure is executed. 402 +-----+ 403 +----+GaNAT|-----+ 404 | | A | | 405 | +-----+ | 406 +------+ +------+ +--+---+ +------+ 407 +--+ | GIST | | IP | | IP | | GIST | +--+ 408 |DS+-+peer 1+--+router| |router+--+peer 2+-+DR| 409 +--+ +------+ +---+--+ +--+---+ +------+ +--+ 410 | +-----+ | 411 | |GaNAT| | 412 +----+ B +-----+ 413 +-----+ 415 Figure 1: Network with more than one NAT at an addressing boundary 417 Figure 1 illustrates the importance of assumptions (3) and (4). With 418 regard to that figure, suppose that a (D-mode) signalling session has 419 been setup between the two adjacent GIST peers 1 and 2 and that both 420 signalling and data traffic follows the path GIST peer 1 -> IP router 421 -> GaNAT A -> IP router -> GIST peer 2. Suppose now that, after some 422 time, GIST peer 1 decides to set up a C-mode connection with peer 2. 423 Suppose moreover that the left IP router decides to forward the 424 C-mode signalling traffic on the link towards GaNAT B. Thus, 425 signalling traffic now follows the alternative path GIST peer 1 -> IP 426 router -> GaNAT B -> IP router -> GIST peer 2. Note that this change 427 in forwarding between the two adjacent GIST peers does not trigger a 428 "route change" at the GIST layer because (a) it does not necessarily 429 destroy the adjacency of peer 1 and 2 and (b) it does not necessarily 430 destroy the coupling of the path taken by signalling traffic to that 431 taken by data traffic (at GIST nodes). Nevertheless, assumptions (3) 432 and (4) mandate that this situation does not occur. However, even if 433 such a situation occurs, the mechanisms described in this document 434 may still work as state expires after a certain timeout period. 436 Assumptions (2), (3) and (4) hold if, at an addressing boundary, only 437 one NAT exists. Due to security and management reasons, this is 438 likely to be the case in many settings. 440 5. Transparent NAT traversal for GIST 442 This section describes the operation of GaNATs that implement the 443 transparent approach listed in Section 3. An NSLP-aware GaNAT MUST 444 follow this approach, as described in Section 5.3. An NSLP-unaware 445 GaNAT MAY follow this approach, as described in Section 5.1 and 446 Section 5.2, only if no cryptographic protection of signalling data 447 is requested by the two NSLP peers. 449 Note that two types of NSLP-unaware GaNAT have to be dealt with, 450 namely those that are located at the NSIS initiator (NI-side), and 451 those that are located at the NSIS responder (NR-side). This 452 distinction arises due to the fact that NI-side and NR-side GaNATs 453 obtain the destination IP address of the downstream GIST peer in 454 different ways. 456 5.1. NI-side NSLP-unaware GaNATs 458 This section describes the "transparent" operation of an NI-side, 459 NSLP-unaware GaNAT. 461 For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT 462 executes the following algorithm. 464 1. If P has a RAO followed by the GIST header with an NSLP ID that 465 is not supported, and if P is identified as a GIST QUERY, the 466 GaNAT performs the following. 468 1. We denote P by GQ. The GaNAT looks at the stack proposal in 469 GQ. If it includes a proposal with cryptographic protection, 470 the mechanism that is applied is the one described 471 Section 6.1. 473 2. The GaNAT remembers GQ along with the interface on which it 474 arrived. We call this interface the "upstream link". 476 3. It searches its table of existing NAT bindings against 477 entries that match the GQ.MRI. A matching entry means that 478 the data flow, to which the signalling refers, already 479 exists. 481 + If a matching entry is found, the GaNAT looks at which 482 link the packets of the data flow are forwarded; we call 483 this link the "downstream" link. Further, the GaNAT 484 checks how the headers of the data flow (IP addresses and 485 port numbers) are translated according to this NAT 486 binding. We denote the source IP address of translated 487 data packets by IPds, and their [Transport layer 488 header].SourcePort by SPDTds. 490 + If no matching entry is found, the GaNAT determines, based 491 on its routing table, the link on which packets that match 492 GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be 493 forwarded. We call this link the "downstream" link. 494 Then, the GaNAT acquires an IP address and source port for 495 itself on the downstream link, denoted by IPds and SPDTds 496 respectively. This address and port could be dynamic or 497 static, and will be used (among other things) for the 498 installation of a NAT binding for the data traffic in the 499 future. 501 4. The GaNAT aquires a source port number for the version of the 502 GIST QUERY that will be forwarded over the downstream link. 503 We denote this port by SPSTds. (There is no requirement that 504 SPSTds must be different from GQ.[UDP Header].SourcePort.) 506 Issues: The reason why the GaNAT may also assign a different 507 source port number to the signalling traffic, is to enable 508 the GaNAT to demultiplex (i.e. forward to the correct 509 internal address) the signalling responses that arrive from 510 the downstream direction. Of course, a GaNAT does not need 511 to actually change the source port of signalling traffic; it 512 can always use SPSTds the same port as in the incoming 513 packet. Such a GaNAT may use the GIST session ID in order to 514 demultiplex (i.e. forward to the correct internal address) 515 the traffic that arrives from the downstream direction. It 516 is unclear which of the two approaches is preferable. 518 5. It creates a new GIST QUERY packet GQ', as follows. 520 1. GQ' <- GQ 522 2. GQ'.MRI.SourceIPAddress <- IPds 524 3. GQ'.MRI.SourcePortNumber <- SPDTds 526 4. GQ'.[IP header].SourceIPAddress <- IPds 528 5. GQ'.[UDP header].SourcePort <- SPSTds 530 6. GQ'.NLI.IA <- IPds 532 7. GQ'.S <- true 534 6. It remembers GQ and GQ', the fact that they are associated, 535 and the associated upstream and downstream links. (Note: The 536 GaNAT does not have to remember the entire packets; for 537 simplicity of exposition, however, we assume it does. An 538 implementation SHOULD discard at this point all information 539 that is not used later.) 541 7. It forwards GQ' on the downstream link. 543 2. Otherwise, if P carries an [IP header].DestinationIPAddress that 544 belongs to the GaNAT, and if it is identified as a GIST RESPONSE 545 in D-mode with an NSLP ID that is not supported, the GaNAT does 546 the following (P is denoted by GR). 548 1. It searches for a matching GQ' in its buffer. A GQ' is said 549 to match a GR if they carry the same cookie value. If none 550 is found, GR is discarded. Otherwise, the GaNAT may also 551 perform further consistency checks on a matching GR/GQ' pair, 552 such as checking that they contain the same session IDs, 553 MRIs, NSLP IDs. If consistency checks fail, GR is discarded. 554 Otherwise, the GaNAT constructs a new GIST RESPONSE GR', as 555 follows. 557 1. GR' <- GR 559 2. GR'.MRI <- GQ.MRI, where GQ is the packet associated with 560 GQ' (as remembered previously), and GQ' is the packet 561 that matches the received GR. 563 3. GR'.[IP header].SourceIPAddress <- IPus, where IPus is an 564 IP address that is bound to the upstream link. 566 4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA 568 5. GR'.[UDP header].DestinationPort <- GQ.[UDP 569 header].SourcePort 571 6. GR'.NLI.IA <- IPus 573 7. GR'.S <- true 575 8. The GaNAT inspects the Stack-Configuration-Data object in 576 GR' and the corresponding GQ' in order to check whether 577 or not the upstream NSLP peer can select one of multiple 578 transport layer protocol/destination port number 579 combinations for the establishment of a messaging 580 association. If multiple choices exist, the GaNAT 581 invalidates as many transport layer protocol/port number 582 combination proposals from GR' as necessary, until the 583 upstream NSLP peer can only initiate the establishment of 584 a messaging association with the downstream NSLP peer 585 using a single transport layer protocol/destination port 586 number combination. This invalidation is done by setting 587 the D-flag in those MA-Protocol-Options fields that carry 588 the port number proposals that are to be invalidated. 589 Note that, by setting the D-flag in a particular MA- 590 Protocol-Option field, the GaNAT may also invalidate the 591 associated transport layer protocol and security (e.g. 592 TLS) proposal. The actions of the GaNAT MUST NOT result 593 in the strongest, in terms of security, proposal to be 594 invalidated. In the end, the NAT will expect the 595 upstream NSLP peer to use a particular combination of 596 transport layer protocol and destination port (and 597 possibly other details that are associated with the valid 598 proposal) for the establishment of the messaging 599 association. We call this combination the "stack 600 proposal expected by the NAT" and denote it by ST. The 601 GaNAT remembers this ST, its association with GQ, GQ', 602 GR, GR', and the upstream and downstream links. By doing 603 so, the GaNAT is said to "install" the ST. 605 2. It forwards GR' on the upstream link. 607 3. If no NAT binding for the data traffic was found in step 608 1.3.2, the GaNAT now installs a NAT binding (for the 609 unidirectional data traffic) which says that "a packet K that 610 arrives on the upstream link and for which it holds that 612 + K.[IP 613 header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, 615 + K.[IP header].Protocol=GQ.MRI.Protocol, and 617 + K.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers 619 should be forwarded on the downstream link, with [IP 620 header].SourceIPAddress = IPds and [Transport layer 621 header].SourcePort=SPDTds". 623 Issues: there is a question of whether this NAT binding 624 should also enable data traffic in the opposite direction to 625 traverse the NAT; in order to be able to demultiplex upstream 626 traffic that carries data that belongs to different flows, 627 the GaNAT should keep the necessary per-flow state. From a 628 signalling point of view, however, upstream data traffic that 629 corresponds (on the application level) to the downstream flow 630 to which this GIST session refers, is a separate flow for 631 which, depending on the application, there may or there may 632 not exist a signalling session. If such a signalling session 633 exists, then the GaNAT acts as an NR-side GaNAT for this 634 session. Thus, during the processing of this signalling care 635 has to be taken not to establish a NAT binding for a flow for 636 which a NAT binding already exists. Moreover, security 637 issues may arise when traffic, for which no signalling 638 exists, is allowed to traverse a GaNAT. 640 Another issue is about refreshing the NAT binding. A NAT 641 binding that was established as a result of GIST signalling 642 should remain in place for as long as the associated GIST 643 state in the GaNAT remains valid. If GIST signalling refers 644 to a NAT binding that already exists, then the timeout of the 645 NAT binding should occur according to the NAT policy, in a 646 manner independent from GIST processing. (If signalling 647 persists after the deletion of a NAT binding, then the NAT 648 binding may be re-installed and then timed out together with 649 GIST state). 651 3. Otherwise, if P.[IP header].DestinationIPAddress belongs to the 652 GaNAT, and if P carries the transport protocol and destination 653 port number indicated by some stack ST that has previously been 654 installed by the GaNAT, and if P has arrived on either the 655 upstream or the downstream interface that is associated with ST, 656 then P is said to "match" ST. For such a packet, the GaNAT does 657 the following. If P is expected to contain a GIST header, then 658 the GaNAT checks whether or not the bits where the GIST header is 659 expected, constitute a valid GIST header. If they do not, P is 660 silently discarded. If all is in order, the GaNAT constructs an 661 outgoing packet P' as follows (the variables used below refer to 662 those stored in association with ST). 664 1. P' <- P 666 2. If P has arrived on the upstream link, then 668 1. P'.[IP header].SourceIPAddress <- IPds 670 2. P'.[IP header].DestinationIPAddress <- GR.NLI.IA 672 3. P'.MRI <- GQ'.MRI 674 4. P'.NLI.IA <- IPds 676 5. The GaNAT forwards P' on the downstream link. 678 3. else (if P has arrived on the downstream link) 680 1. P'.[IP header].SourceIPAddress <- IPus 682 2. P'.[IP header].DestinationIPAddress <- GQ.NLI.IA 684 3. P'.MRI <- GQ.MRI 686 4. P'.NLI.IA <- IPus 688 5. The GaNAT forwards P' on the upstream link. 690 Note that the GaNAT can determine the location in a packet 691 where a GIST header is expected. If, for example, the packet 692 is a UDP packet, then the GIST header should follow 693 immediately after the UDP header. If the packet is a TCP 694 packet, then the GaNAT can determine the location where the 695 GIST header should start by counting the number of NSLP 696 payload bits that followed the end of the previous GIST 697 header. The start of the next GIST header is expected at the 698 position where the previous GIST message, including NSLP 699 payload, ends. The GaNAT can tell where this message ends 700 from the LENGTH field inside the previous GIST header. It 701 should be noted here that, in order to correctly count the 702 bits, the GaNAT may have to keep track of TCP sequence 703 numbers, and thereby be aware of the correct ordering of 704 packets. However, the GaNAT only has to keep buffers that 705 are as long as the LENGTH field inside the previous GIST 706 header (and possibly up to one MTU size more than that). 708 Also note that some TCP packets P may not be expected to 709 contain any GIST header (this happens when the NSLP payload 710 from a previous packet stretches over several packets). For 711 those packets, the GaNAT only applies the transformation in 712 the IP header. Finally, note that a GIST header may start a 713 packet but finish in another. If such a packet is received, 714 the GaNAT MUST buffer that packet, until the packet is 715 received where the GIST header completes. It can then apply 716 the required processing and forward both packets. 718 4. Otherwise, if P matches a (data) NAT binding, the GaNAT applies 719 normal NAT processing and forwards the packet on the 720 corresponding link. 722 5. Otherwise, P is subjected to normal NAT processing. That is, P 723 is either silently discarded or it causes the installation of a 724 (data) NAT binding. 726 Brief discussion of the algorithm: The fact that the GaNAT replaces 727 the NSLP peers' NLI.IA with its own IP address (in both directions), 728 causes the GIST peers to send subsequent signalling messages to the 729 GaNAT, in the belief that they talk to their adjacent NSLP peer. The 730 GaNAT transparently forwards the signalling traffic and appropriately 731 translates the fields in the GIST header, in a way that is consistent 732 with the translation it applies to the data traffic. 734 Note that, according to this mechanism, the size of outgoing GIST 735 messages is always the same as the size of corresponding incoming 736 GIST messages. Also note that the MRI that the NR sees indicates as 737 destination address the IP address of the DR (as expected), but as 738 source address it sees indicates the IPds of the GaNAT that is 739 closest to the NR. 741 5.2. NR-side NSLP-unaware GaNATs 743 The case of NR-side GaNATs is more subtle, since, in this setting, 744 the DS does not learn the IP address of the DR (which is assumed to 745 be on the same side of the GaNATs as the NR) and the NI does not 746 learn the address of the NR. In this setting we assume that each NR- 747 side GaNAT that is in between two GIST peers, a priori knows a 748 routable IP address of the next downstream GaNAT. The last GaNAT of 749 this chain is assumed to know the IP address of the DR. In order to 750 clarify this assumption, see, for example, Figure 2. In this figure, 751 GaNAT A is assumed to know the IP address of GaNAT B, GaNAT B is 752 assumed to know the IP address of GaNAT C, and GaNAT C is assumed to 753 know the IP address of the DR. A given GaNAT that knows such an 754 address, in effect anticipates to receive a signalling message from 755 the upstream direction that refers to a data flow that terminates in 756 a downstream node. In other words, such a GaNAT may typically have 757 already a NAT binding in place for the data traffic. We call the IP 758 address of the next downstream GaNAT (or, if the GaNAT is the last in 759 the chain, the address of the DR) the "pending" IP address and denote 760 it by IPNext. The GaNAT may also have a destination port associated 761 with IPNext. If IPNext is derived from an existing data traffic NAT 762 binding, then this port is typically the destination port after 763 translation from that binding. This port, if known, is denoted 764 PortNext. How IPNext and PortNext are made known to each GaNAT (e.g. 765 how the NAT binding for the data traffic is installed in the GaNAT) 766 is outside the scope of this document. 768 +--+ +------+ +-----+ +-----+ +-----+ +------+ +--+ +--+ 769 +NI+--+ NSLP +---+GaNAT+---+GaNAT+---+GaNAT+---+ NSLP +--+NR+--+DR| 770 +--+ |peer 1| | A | | B | | C | |peer 2| +--+ +--+ 771 +------+ +-----+ +-----+ +-----+ +------+ 773 Figure 2: Network with NR-side GaNATs (the public Internet is assumed 774 to be between NI and NSLP peer 1) 776 For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT 777 executes the following algorithm. 779 1. If P has a RAO followed by the GIST header with the NSLP ID 780 indicates an unsupported NSLP, and if it is identified as a GIST 781 QUERY, the GaNAT does the following. 783 1. We denote P by GQ. The GaNAT looks at the stack proposal in 784 GQ. If it indicates that cryptographic protection is 785 required, the algorithm that is executed is the one described 786 in section Section 6 below. 788 2. The GaNAT remembers GQ along with the link on which it 789 arrived. We call this link the "upstream" link. 791 3. The GaNAT determines whether or not this GIST QUERY is 792 anticipated, i.e. if a pending IPNext (and possibly PortNext) 793 exists that matches this GIST QUERY. A pending IPNext is 794 said to "match" a GIST QUERY, if [this condition is an open 795 issue!] If no pending IPNext is matching, P is discarded (it 796 is a question whether or not an error message should be 797 sent). Otherwise, additional checks may be performed (e.g. 798 something like a DSInfo object may have to be checked against 799 the GQ). If these checks fail, P is discarded. Otherwise, 800 the GaNAT performs the following. 802 4. It searches its table of existing NAT bindings against 803 entries that match the GQ.MRI. A matching entry means that 804 the data flow, to which the signalling refers, already 805 exists. 807 + If a matching entry is found, the GaNAT looks at which 808 link the packets of the data flow are forwarded; we call 809 this link the "downstream" link. Further, the GaNAT 810 checks how the IP and transport layer headers of the data 811 flow are translated according to this NAT binding. Note 812 that the [IP header].DestinationIPAddress and [Transport 813 layer header].DestinationPort of this NAT binding should 814 be equal to IPNext and PortNext respectively. If they are 815 not, this should be handled as an auditive error 816 condition. 818 + If no matching entry is found, the GaNAT determines, based 819 on its routing table, the link on which packets that match 820 GQ.MRI (excluding GQ.MRI.SourceIPAddress and where 821 GQ.MRI.DestinationIPAddress is replaced with IPNext) would 822 be forwarded. We call this link the "downstream" link. 824 5. The GaNAT acquires an IP address for itself on the downstream 825 link. (This address could be dynamic or static.) Depending 826 on its type, the GaNAT may also acquire a UDP source port 827 number for the version of the GIST QUERY that will be 828 forwarded to the downstream direction. We denote the 829 acquired IP address and source port number by IPds SPSTds 830 respectively. The GaNAT then constructs a new GIST QUERY 831 packet GQ', as follows. 833 1. GQ' <- GQ 835 2. GQ'.MRI.DestinationIPAddress <- IPNext. 837 3. GQ'.MRI.DestinationPort <- PortNext. 839 4. GQ'.NLI.IA <- IPds. 841 5. GQ'.[IP header].SourceIPAddress <- IPds. 843 6. GQ'.[IP header].DestinationIPAddress <- IPNext. 845 7. GQ'.[UDP header].SourcePort <- SPSTds. 847 8. GQ'.S <- true 849 6. It remembers GQ, GQ', the fact that they are associated, and 850 the associated upstream and downstream links (interfaces). 852 7. It forwards GQ' on the downstream link. 854 The remaining steps of the algorithm are analogous to the 855 corresponding steps of the algorithm executed by NSLP-unaware, NI- 856 side GaNATs, which was described in Section 5.1. 858 5.3. NSLP-aware GaNATs 860 The difference of NSLP-aware GaNATs and NSLP-unaware GaNATs is that 861 the former perform NSLP processing in addition to the processing of 862 the NSLP-unaware GaNATs. Another way to see this is by observing 863 that NSLP-aware GaNATs should provide an "MRI translation service" 864 (MRITS) in addition to normal GIST and NSLP processing. The MRITS 865 operates at the GIST layer. The motivation behind this is to hide 866 from the NSLP that signalling messages traverse an addressing 867 boundary. In other words, the purpose of the MRITS is to make the 868 NSLP believe that it is operating in a single IP addressing space. 869 When and how the MRITS is invoked for a particular packet depends on 870 (i) the direction of an incoming message (i.e. downstream or 871 upstream) and (ii) the location of the GaNAT (i.e. NI-side or NR- 872 side). It should also be noted that certain NSLP layer tasks must be 873 carried out in consistency with the placement of the MRITS. This is 874 to prevent events triggered by the NSLP to cause installation of 875 inconsistent state. In order to clarify this, consider the scenario 876 of the QoS NSLP running in a GaNAT that operates according to the 877 mechanisms described in this section. Since the GaNAT only presents 878 a single addressing space to the NSLP (say, the internal addressing 879 space), the packet classifier of the GaNAT's QoS provisioning 880 subsystem should classify data packets based on internal addresses 881 only (i.e. it should first translate packets that carry external 882 addresses and then classify them). Whether the MRITS presents 883 internal-only or external-only addresses to the NSLP is not 884 significant, as long as NSLP layer operations are carried out 885 consistently. In the remainder of this section we present the case 886 where internal addresses are presented to the NSLP. 888 The MRITS is obviously invoked only on GIST packets that carry an 889 NSLP identifier that corresponds to an NSLP that the GaNAT 890 implements. For non-GIST packets, normal NAT behaviour applies. 891 Although the MRITS is part of GIST processing, in order to clarify 892 the exposition, we view it as a somewhat separate processing step 893 (i.e. like a subroutine) that is executed in addition to GIST, as 894 this is specified in [1]. For NI-side, NSLP-aware GaNATs, it holds 895 that 897 o for a GIST/NSLP packet that is to be forwarded on the downstream 898 link of an NI-side GaNAT, the MRITS is invoked after the packet 899 has been processed by the NSLP and before it is given to GIST, and 901 o for a GIST/NSLP packet that is received on the downstream link, 902 the MRITS is invoked after GIST processing and before the packet 903 is given to the NSLP. 905 The converse holds for NR-side NSLP-aware GaNATs. In particular, 907 o for a GIST/NSLP packet that is to be forwarded on the upstream 908 link of an NI-side GaNAT, the MRITS is invoked after the packet 909 has been processed by the NSLP and before it is given to GIST, and 911 o for a GIST/NSLP packet that is received on the upstream link, the 912 MRITS is invoked after GIST processing and before NSLP processing. 914 Figure 3 illustrates this idea. 916 +----------------+ +----------------+ 917 | +------+ | | +------+ | 918 | | NSLP | | | | NSLP | | 919 | +-+---++ | | +-+--+-+ | 920 | | | | | | | | 921 | | +-+---+ | | +----++ | | 922 | | |MRITS| | | |MRITS| | | 923 | | +---+-+ | | ++----+ | | 924 | | | | | | | | 925 | +-+-----+-+ | | ++------+-+ | 926 | | GIST | | | | GIST | | 927 u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s 928 -----+----+ +-----+----- -----+---+ +-----+----- 929 link +----------------+ link link +----------------+ link 930 NI-side NR-side 931 NSLP-aware NSLP-aware 932 GaNAT GaNAT 934 Figure 3: Operation of the MRI Translation Service 936 The reason for this construction is to give the NSLP the impression 937 that it works only with flows that originate and terminate in the 938 internal address space. We now describe the operation of the MRITS 939 and GIST in NSLP-aware GaNATs. An NI-side NSLP-aware GaNAT operates 940 according to the following rules. 942 1. When the NSLP asks for a message to be sent towards the 943 downstream GIST peer, the MRITS does the following (IPds and 944 SPDTds are obtained similarly to the case of an NSLP-unaware 945 GaNAT). 947 1. MRI.SourceIPAddress <- IPds 949 2. MRI.SourcePort <- SPDTds 951 2. Additionally, GIST performs the following on the resulting packet 952 before it is forwarded on the downstream link (SPSTds is obtained 953 similarly to the case of an NSLP-unaware GaNAT). 955 1. [IP header].SourceIPAddress <- IPds 956 2. [UDP/TCP header].SourcePort <- SPSTds 958 3. NLI.IA <- IPds 960 4. S <- true 962 3. If a message is received on the downstream link, the MRITS does 963 the following before the NSLP is invoked. 965 1. MRI.SourceIPAddress <- IPflow 967 2. MRI.SourcePort <- SPDTus, where IPflow is the IP address of 968 the DS (as seen by the GaNAT) and SPDTus is the destination 969 port number used in the original MRI. 971 4. If, after NSLP processing, a message is to be forwarded on the 972 upstream link, GIST performs the following processing (note that 973 no MRITS processing takes place in this case). 975 1. [IP header].SourceIPAddress <- IPus 977 2. [IP header].DestinationIPAddress <- IPpeer 979 3. NLI.IA <- IPus 981 4. S <- true, where IPus is the GaNATs IP address for the 982 upstream link, IPpeer is the IP address of the NI (or the 983 next GaNAT in the upstream direction), and IPflow is the IP 984 address of the DS (as seen by the GaNAT). The GaNAT is 985 assumed to determine the correct IPus and IPpeer from 986 previous communications and in cooperation with GIST. 987 [Issue: how exactly should IPus, IPpeer and IPflow be 988 resolved; i.e. what exactly should the GaNAT remember?] 990 An NR-side NSLP-aware GaNAT operates according to the following 991 rules. 993 1. If the packet is received on the upstream link, the MRITS does 994 the following, before the NSLP is notified. 996 1. P.MRI.SourceIPAddress <- IPds 998 2. P.MRI.DestinationIPAddress <- IPNext, where IPds is the 999 GaNAT's IP address for the downstream link and IPNext is the 1000 address of the DR. IPNext is obtained in a way similar to 1001 the case of an NSLP-unaware GaNAT. 1003 2. If, after NSLP processing, a message is to be forwarded on the 1004 downstream link, GIST performs the following processing (note 1005 that no MRITS processing takes place in this case). 1007 1. [IP header].SourceIPAddress <- IPds 1009 2. [IP header].DestinationIPAddress <- IPNext 1011 3. NLI.IA <- IPds 1013 4. S <- true, where IPds is the GaNATs IP address for the 1014 downstream link, IPNext is the IP address of the DR (or the 1015 next GaNAT in the downstream direction). The GaNAT is 1016 assumed to determine the correct IPNext in a way similar to 1017 the case of an NSLP-unaware GaNAT. 1019 3. When the NSLP asks for a message to be sent towards the upstream 1020 peer, the MRITS does the following. 1022 1. MRI.SourceIPAddress <- IPflow 1024 2. MRI.Destination_IP_Address <- IPus 1026 4. Additionally, GIST performs the following on the resulting packet 1027 before it is forwarded on the downstream link. 1029 1. [IP header].SourceIPAddress <- IPus 1031 2. [IP header].DestinationIPAddress <- IPpeer 1033 3. NLI.IA <- IPus 1035 4. S <- true, where IPus is the GaNATs IP address for the 1036 upstream link, IPpeer is the IP address of the NI (or the 1037 next GaNAT in the upstream direction), and IPflow is the IP 1038 address of the DS. The GaNAT is assumed to determine the 1039 correct IPus and IPpeer fields from previous communications 1040 and in cooperation with GIST. [question: how exactly should 1041 IPus and IPpeer be resolved; i.e. what exactly should the 1042 GaNAT remember]? 1044 5.4. Combination of NSLP-aware and NSLP-unaware GaNATs 1046 In the absence of an adversary, a combination of NSLP-aware and NSLP- 1047 unaware GaNATs should work without further specification. However, 1048 in the presence of an adversary, additional security issues may arise 1049 from the combination. These issues may introduce opportunities for 1050 attack that do not exist in setting where the on-path GaNATs are 1051 either all NSLP-aware or all NSLP-unaware. 1053 6. Non-transparent NAT traversal for GIST 1055 This section discusses the "non-transparent" operation for GaNAT 1056 traversal at the GIST layer, i.e. the first approach listed in 1057 Section 3. For this approach the behaviour of both the GaNAT and the 1058 GIST peers is defined. As with the transparent approach, the case of 1059 the in-between GaNAT(s) being located at the NI-side is different 1060 from that of NR-side GaNATs. Note that the mechanisms in this 1061 section apply only to NSLP-unware GaNATs. 1063 The GaNAT informs the NSLP peers about its presence during the GIST 1064 discovery process. This information enables the NSLP peers to map 1065 the translated data flow to the signalling messages, and to 1066 consistently translate the MRI, so that the NSLP only "sees" the 1067 correct MRI. Cryptographic protection of signalling messages can be 1068 supported with this approach because the GaNAT only modifies the GIST 1069 QUERY and RESPONSE messages, which are never cryptographically 1070 protected in their entirety. 1072 In this approach, the GaNAT embeds a "NAT Traversal Object" (NTO) 1073 payload type into the GIST QUERY. The NTO encodes the aforementioned 1074 information and is an optional payload in the GIST header of a GIST 1075 QUERY. It is added, and processed, by the GaNAT(s) through which the 1076 QUERY traverses. The information in the NTO enables the two NSLP 1077 peers to locally translate the MRI in the same way as if it were 1078 consistently and transparently translated by the in-between GaNAT(s). 1079 Note that there may be more than one GaNAT between the two NSLP 1080 peers. The format of the NTO follows the format of the object in the 1081 GIST common header. In particular, the NTO is preceded by a TLV 1082 common header, as defined in [1]. The A and B flags are both set to 1083 0 in this header, indicating that support for the NTO is mandatory. 1084 The type value is TBD. The NTO is defined as in section A.3.8 of 1085 [1]. 1087 6.1. NI-side NSLP-unaware GaNATs 1089 For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT 1090 executes an algorithm that is equivalent to the following. 1092 1. If P has a RAO followed by the GIST header with an NSLP ID that 1093 is not supported, and if it is identified as a GIST QUERY, the 1094 GaNAT does the following. 1096 1. We denote P by GQ. The GaNAT looks at the stack proposal in 1097 GQ. If it does not include any proposal with cryptographic 1098 protection, the GaNAT MAY choose to follow the approach 1099 described in Section 5.1 above. 1101 2. The GaNAT remembers GQ along with the link on which it 1102 arrived. We call this link the "upstream" link. 1104 3. The GaNAT searches its table of existing NAT bindings against 1105 entries that match the GQ.MRI. A matching entry means that 1106 the data flow, to which the signalling refers, already 1107 exists. 1109 + If a matching entry is found, the GaNAT looks at which 1110 link the packets of the data flow are forwarded; we call 1111 this link the "downstream" link. Further, the GaNAT 1112 checks how the headers of the data flow (IP addresses and 1113 port numbers) are translated according to this NAT 1114 binding. We denote the source IP address of translated 1115 data packets by IPds, and their [Transport layer 1116 header].SourcePort by SPDTds. 1118 + If no matching entry is found, the GaNAT determines, based 1119 on its routing table, the link on which packets that match 1120 GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be 1121 forwarded. We call this link the "downstream" link. 1122 Then, the GaNAT acquires an IP address and source port for 1123 itself on the downstream link, denoted by IPds and SPDTds 1124 respectively. This address and port could be dynamic or 1125 static, and will be used (among other things) for the 1126 installation of a NAT binding for the data traffic in the 1127 future. 1129 4. The GaNAT aquires a source port number for the version of the 1130 GIST QUERY that will be forwarded over the downstream link. 1131 We denote this port by SPSTds. (There is no requirement that 1132 SPSTds must be different from GQ.[UDP Header].SourcePort.) 1134 5. It creates a new GIST QUERY packet GQ', as follows. 1136 1. GQ' <- GQ 1138 2. GQ'.MRI.SourceIPAddress <- IPds 1140 3. GQ'.MRI.SourcePortNumber <- SPDTds 1142 4. GQ'.NLI.IA.<- IPds. 1144 5. GQ'.[IP header].SourceIPAddress <- IPds. 1146 6. GQ'.[UDP header].SourcePort <- SPSTds. 1148 7. GQ'.S <- true. 1150 8. It checks whether or not an NTO was included in GQ. 1152 - If none was included, it creates a new NTO as follows 1153 and adds it to GQ'. Note that the MRI field of the 1154 NTO is taken from GQ. 1156 o NTO.[NAT Count] <- 1. 1158 o NTO.MRI <- GQ.MRI. 1160 o NTO.[List of translated objects] <- [type of NLI] 1162 o NTO.opaque information replaced by NAT 1 <- 1163 GQ.NLI.IA, GQ.[UDP header].SourcePort, LinkID, 1164 where LinkID represents the upstream link. 1166 - If one was included, it replaces certain fields and 1167 appends new fields into the NTO, as follows, and adds 1168 the resulting object to GQ'. Note that the MRI field 1169 of the NTO is not modified. 1171 o NTO.[NAT Count] <- i, where i is the current [NAT 1172 count] value increased by one. 1174 o NTO.[List of translated objects] <- [type of NLI] 1176 o NTO.opaque information replaced by NAT i <- 1177 GQ.NLI.IA, GQ.[UDP header].SourcePort, LinkID, 1178 where LinkID represents the upstream link. 1180 9. It remembers GQ, GQ', the fact that they are associated, 1181 and the associated upstream and downstream links. 1183 10. It forwards GQ' on the downstream link. 1185 2. Otherwise, if P carries an [IP header].DestinationIPAddress that 1186 belongs to the GaNAT, and if it is identified as a GIST RESPONSE 1187 with an NSLP ID that is not supported, the GaNAT does the 1188 following (P is denoted by GR). 1190 1. If P does not contain an NTO, the GaNAT discards it without 1191 further processing. Otherwise, it searches for a matching 1192 GQ' in its buffer. A GQ' is said to be matching if it 1193 carries the same cookie value. If none is found, GR is 1194 discarded. Otherwise, the GaNAT should also make sure that 1195 the session ID in GR is the same as in GQ', that the NSLP IDs 1196 match, and that GR arrived on the downstream link. If these 1197 consistency checks fail, GR should be discarded. Otherwise, 1198 the GaNAT constructs a new GIST RESPONSE GR', as follows 1199 (note that no changes are made to the MRI). 1201 1. GR' <- GR 1203 2. The GaNAT selects the information that it encoded in the 1204 [opaque information replaced by NAT i] field of the 1205 embedded NTO, denoted by IPAddressToSend, 1206 PortAddressToSend and LinkID, where i is the current 1207 value of [NAT Count] as indicated in the NTO. 1209 3. GR'.[IP header].DestinationIPAddress <- IPAddressToSend. 1211 4. GR'.[UDP header].DestinationPort=PortAddressToSend. 1213 5. GR'.NTO.[NAT Count] <- reduce by one. 1215 6. GR'.S <- true. 1217 2. The GaNAT inspects the Stack-Configuration-Data object in GR 1218 and the corresponding GQ' in order to check whether or not 1219 the upstream NSLP peer can select one of multiple transport 1220 layer protocol/destination port number combinations for the 1221 establishment of a messaging association. If multiple 1222 choices exist, the GaNAT invalidates as many transport layer 1223 protocol/port number combination proposals from GR' as 1224 necessary, until the upstream NSLP peer can only initiate the 1225 establishment of a messaging association with the downstream 1226 NSLP peer using a single transport layer protocol/destination 1227 port number combination. This invalidation is done by 1228 setting the D-flag in those MA-Protocol-Options fields that 1229 carry the port number proposals that are to be invalidated. 1230 Note that, by setting the D-flag in a particular MA-Protocol- 1231 Option field, the GaNAT may also invalidate the associated 1232 transport layer and security protocol (e.g. TCP/TLS) 1233 proposal. The actions of the GaNAT MUST NOT result in the 1234 strongest, in terms of security, proposal to be invalidated. 1235 In the end, the NAT will expect the upstream NSLP peer to use 1236 a particular combination of transport layer protocol and 1237 destination port (and possibly other details that are 1238 associated with the valid proposal) for the establishment of 1239 the messaging association. We call this combination the 1240 "stack proposal expected by the NAT" and denote it by ST. 1241 The GaNAT remembers this ST, its association with GQ, GQ', 1242 GR, GR', and the upstream and downstream links. By doing so, 1243 the GaNAT is said to "install" ST. 1245 3. It forwards GR' on the link identified by LinkID. 1247 4. The GaNAT now installs a NAT binding for the signalling 1248 traffic that is exchanged over a messaging association which 1249 says that "a packet K that arrives on the upstream link and 1250 for which it holds that 1252 + K.[IP header].DestinationIPAddress=GR.NLI.IA,, 1254 + K.[IP header].Protocol=ST.Protocol, and 1256 + K.[Transport layer 1257 header].DestinationPort=ST.DestinationPort 1259 should be forwarded on the downstream link, with [IP 1260 header].SourceIPAddress = IPds and [UDP/TCP 1261 header].DestinationPort=SIGPort, where SIGPort is a port that 1262 the GaNAT allocates for use as a source port for signalling 1263 traffic. 1265 5. The GaNAT now installs a NAT binding for the UDP-encapsulated 1266 signalling traffic which says that "a packet M that arrives 1267 on the upstream link and for which it holds that 1269 + M.[IP header].DestinationIPAddress=GR.NLI.IA, 1271 + M.[IP header].Protocol=UDP, and 1273 + M.[UDP header].DestinationPort=GIST well-known port 1275 should be forwarded on the downstream link, with [IP 1276 header].SourceIPAddress = IPds. Note that this is a special 1277 type of NAT binding, in that the source port in M may vary 1278 from one incoming message to another. This is why each 1279 packet M may be mapped by the GaNAT to a different source 1280 port. Translation in the upstream direction must be applied 1281 consistently, and timeouts must also be selected 1282 appropriately. That is, the overall binding must be timed 1283 out together with the GIST state that is associated with this 1284 session. However, each incoming packet M that matches this 1285 binding causes the installation of a "sub"-binding (in the 1286 sense that a new port mapping may occur) that will typically 1287 time out faster. 1289 6. If no NAT binding for the data traffic was found in step 1290 1.3.2, the GaNAT now installs a NAT binding (for the 1291 unidirectional data traffic) which says that "a packet L that 1292 arrives on the upstream link and for which it holds that 1293 + L.[IP 1294 header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, 1296 + L.[IP header].Protocol=GQ.MRI.Protocol, and 1298 + L.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers 1300 should be forwarded on the downstream link, with [IP 1301 header].SourceIPAddress = IPds and [UDP/TCP 1302 header].SourcePort=SPDTds. 1304 Issues: there is a question of whether this NAT binding 1305 should also enable data traffic in the opposite direction to 1306 traverse the NAT; in order to be able to demultiplex upstream 1307 traffic that carries data that belongs to different flows, 1308 the GaNAT should keep the necessary per-flow state. From a 1309 signalling point of view, however, upstream data traffic that 1310 corresponds (on the application level) to the downstream flow 1311 to which this GIST session refers, is a separate flow for 1312 which, dependent on the application, there may or there may 1313 not exist a signalling session. If such a signalling session 1314 exists, then the GaNAT acts as an NR-side GaNAT for this 1315 session. Thus, during the processing of this signalling care 1316 has to be taken not to establish a NAT binding for a flow for 1317 which a NAT binding already exists. Finally, security issues 1318 arise when traffic, for which no signalling exists, is 1319 allowed to traverse a GaNAT. 1321 3. Otherwise, if P matches an existing NAT binding, normal NAT 1322 processing is applied. 1324 4. Otherwise, P is subjected to normal NAT processing. That is, P 1325 is either silently discarded or it causes the installation of a 1326 (data) NAT binding. 1328 6.2. NR-side NSLP-unaware GaNATs 1330 As is the case with NR-side NSLP-unaware GaNATs that follow the 1331 "transparent" approach, an NR-side NSLP-unaware GaNAT that follows 1332 the "non-transparent" approach must know a "pending" IP address and 1333 optionally destination port number, as described in Section 5.2. 1334 This IP address and destination port number are denoted by IPNext and 1335 PortNext respectively. How they are made known to the GaNAT is 1336 outside the scope of this document. Note, however, that a typical 1337 scenario would be that the GaNAT has an existing NAT binding in place 1338 from where this information can be derived. 1340 For every incoming IP packet P, an NSLP-unaware, NR-side GaNAT 1341 executes the following algorithm. 1343 1. If P carries an [IP header].DestinationIPAddress that belongs to 1344 the GaNAT, if it has a RAO followed by the GIST header with an 1345 unsupported NSLPID, and if it is identified as a GIST QUERY, the 1346 GaNAT does the following. 1348 1. We denote P by GQ. The GaNAT looks at the stack proposal in 1349 GQ. If it does not include any proposal with cryptographic 1350 protection, the GaNAT MAY choose to follow the "transparent" 1351 approach as described in Section 5.2 above. 1353 2. If GQ.[IP header].DestinationIPAddress, denoted by IPus in 1354 the sequel, is not bound to the link on which GQ arrived, the 1355 GaNAT silently discards the packet. Otherwise, it remembers 1356 GQ along with the link on which it arrived. We call this 1357 link the "upstream" link. 1359 3. The GaNAT determines whether or not this GIST QUERY is 1360 anticipated, i.e. if a pending IPNext and PortNext exists. 1361 One way of determining whether or not a pending IPNext and 1362 PortNext exists is checking whether or not a NAT binding for 1363 the data traffic, as this is defined by the MRI in the GIST 1364 QUERY, exists in the NAT binding cache. If one exists, then 1365 IPNext and PortNext is the address and destination port 1366 number on which this traffic is forwarded. If no pending 1367 IPNext is found, then GQ is discarded (it is a question 1368 whether or not an error message should be sent). Otherwise, 1369 additional checks may be performed (e.g. a DSInfo object may 1370 have to be checked against the GQ). If these checks fail, GQ 1371 is discarded. Otherwise, the GaNAT performs the following. 1373 4. It searches its table of existing NAT bindings against 1374 entries that match GQ.MRI. A matching entry means that the 1375 data flow, to which the signalling refers, already exists. 1377 + If a matching entry is found, the GaNAT looks at which 1378 link the packets of the data flow are forwarded; we call 1379 this link the "downstream" link. Further, the GaNAT 1380 checks how the headers of the data flow (IP addresses, 1381 port numbers) are translated according to this NAT 1382 binding. Note that the [IP header].DestinationIPAddress 1383 and DestinationPort in this NAT binding should be equal to 1384 IPNext and PortNext respectively. If they are not, this 1385 should be handled as an auditive error condition. (This 1386 check is done as a consistency check.) 1388 + If no matching entry is found, the GaNAT determines, based 1389 on its routing table, the link on which packets that match 1390 GQ.MRI (where GQ.MRI.DestinationIPAddress is replaced with 1391 IPNext) would be forwarded. We call this link the 1392 "downstream" link. 1394 5. It creates a new GIST QUERY packet GQ', as follows. 1396 1. GQ' <- GQ 1398 2. GQ'.MRI.DestinationIPAddress <- IPnext 1400 3. GQ'.MRI.DestinationPortNumber <- PortNext 1402 4. GQ'.[IP header].DestinationIPAddress <- IPnext 1404 5. GQ'.[UDP header].DestinationPort <- GIST well-known port 1405 (TBD) 1407 6. It checks whether or not an NTO was included in GQ. 1409 - If none was included, it creates a new NTO as follows 1410 and adds it to GQ'. Note that the MRI field of the 1411 NTO is taken from GQ. 1413 o NTO.[NAT Count] <- 1. 1415 o NTO.MRI <- GQ.MRI. 1417 o NTO.opaque information for NAT 1 <- LinkID of 1418 upstream link. 1420 - If one was included, it replaces certain fields and 1421 appends new fields into the NTO, as follows, and adds 1422 the resulting object to GQ'. Note that the MRI field 1423 of the NTO is not modified. 1425 o NTO.[NAT Count] <- i, where i is the current [NAT 1426 count] value increased by one. 1428 o NTO.opaque information replaced by NAT i <- LinkID 1429 of upstream link. 1431 7. It remembers GQ, GQ', the fact that they are associated, 1432 and the associated upstream and downstream links. 1434 8. It forwards GQ' on the downstream link. 1436 2. Otherwise, if P is identified as a GIST RESPONSE packet with an 1437 NSLP ID that is not supported, the GaNAT does the following (P is 1438 denoted by GR). 1440 1. It searches for a matching GQ' in its buffer. A GQ' is said 1441 to be matching if it carries the same cookie value. If none 1442 is found, GR is discarded. Otherwise, the GaNAT should also 1443 make sure that the session ID in GR is the same as in GQ', 1444 that the NSLP IDs match, and that GR arrived on the 1445 downstream link. If these consistency checks fail, GR should 1446 be discarded. Otherwise, the GaNAT constructs a new GIST 1447 RESPONSE GR', as follows. 1449 2. If P does not contain an NTO, the GaNAT discards it without 1450 further processing. Otherwise, the GaNAT constructs a new 1451 GIST RESPONSE GR', as follows (note that no changes are made 1452 to the MRI). 1454 1. GR' <- GR. 1456 2. The GaNAT selects the information that it encoded in the 1457 [opaque information replaced by NAT i] field of the 1458 embedded NTO, denoted by LinkID, where i is the current 1459 value of [NAT Count] as indicated in the NTO. 1461 3. GR'.NLI.IA <- IPus 1463 4. GR'.NTO.[List of translated objects by NAT i] <- [type of 1464 NLI], where i is the current value of [NAT Count] as 1465 indicated in the NTO. 1467 5. GR'.NTO.[NAT Count] <- reduce by one. 1469 6. GR'.[IP header].SourceIPAddress <- IPus (this is the IP 1470 address that is bound to the link identified by LinkID 1471 and must be equal to GQ.[IP header].DestinationIPAddress, 1472 where GQ is the GIST QUERY associated with GQ'). 1474 7. GR'.[UDP header].DestinationPort <- GQ.[UDP 1475 header].SourcePort, where GQ is the GIST QUERY associated 1476 with GQ'. 1478 8. GR'.S <- true. 1480 3. The GaNAT inspects the Stack-Configuration-Data object in GR 1481 and the corresponding GQ' in order to check whether or not 1482 the upstream NSLP peer can select one of multiple transport 1483 layer protocol/destination port number combinations for the 1484 establishment of a messaging association. If multiple 1485 choices exist, the GaNAT invalidates as many transport layer 1486 protocol/port number combination proposals from GR' as 1487 necessary, until the upstream NSLP peer can only initiate the 1488 establishment of a messaging association with the downstream 1489 NSLP peer using a single transport layer protocol/destination 1490 port number combination. This invalidation is done by 1491 setting the D-flag in those MA-Protocol-Options fields that 1492 carry the port number proposals that are to be invalidated. 1493 Note that, by setting the D-flag in a particular MA-Protocol- 1494 Option field, the GaNAT may also invalidate the associated 1495 transport layer and security protocol (e.g. TCP/TLS) 1496 proposal. The actions of the GaNAT MUST NOT result in the 1497 strongest, in terms of security, proposal to be invalidated. 1498 In the end, the NAT will expect the upstream NSLP peer to use 1499 a particular combination of transport layer protocol and 1500 destination port (and possibly other details that are 1501 associated with the valid proposal) for the establishment of 1502 the messaging association. We call this combination the 1503 "stack proposal expected by the NAT" and denote it by ST. 1504 The GaNAT remembers this ST, its association with GQ, GQ', 1505 GR, GR', and the upstream and downstream links. By doing so, 1506 the GaNAT is said to "install" ST. If ST.DestinationPort is 1507 already used by the GaNAT as a destination port in order to 1508 demultiplex an existing flow, the GaNAT reserves a 1509 destination port SIGPORT and modifies the valid port proposal 1510 in GR' such that SIGPORT will be used by the upstream GIST 1511 peer. Otherwise it sets SIGPORT=ST.DestinationPort. 1513 4. It forwards GR' on the link identified by LinkID (i.e. the 1514 upstream link). 1516 5. The GaNAT now installs a NAT binding for the signalling 1517 traffic that is exchanged over a messaging association which 1518 says that "a packet K that arrives on the upstream link and 1519 for which it holds that 1521 + K.[IP header].DestinationIPAddress=IPus (which is equal to 1522 GQ.MRI.DestinationIPAddress and GQ.[IP 1523 header].DestinationIPAddress), 1525 + K.[IP header].Protocol=ST.Protocol, and 1527 + K.[Transport layer header].DestinationPort=SIGPORT 1529 should be forwarded on the downstream link, with [IP 1530 header].DestinationIPAddress = GR.NLI.IA and [Transport layer 1531 header].DestinationPort=ST.DestinationPort. 1533 6. The GaNAT now installs a NAT binding for the UDP-encapsulated 1534 signalling traffic which says that "a packet M that arrives 1535 on the upstream link and for which it holds that 1537 + M.[IP header].DestinationIPAddress=IPus, 1539 + M.[IP header].Protocol=UDP, and 1541 + M.[UDP header].DestinationPort=GIST well-known port 1543 should be forwarded on the downstream link, with [IP 1544 header].SourceIPAddress = GR.NLI.IA". Note that this is a 1545 special type of NAT binding, in that the source port in M may 1546 vary from one incoming message to another. This is why each 1547 packet M may be mapped by the GaNAT to a different source 1548 port. Translation in the upstream direction must be applied 1549 consistently, and timeouts must also be selected 1550 appropriately. That is, the overall binding must be timed 1551 out together with the GIST state that is associated with this 1552 session. However, each incoming packet M that matches this 1553 binding causes the installation of a "sub"-binding (in the 1554 sense that a new port mapping may occur) that will typically 1555 time out faster. 1557 7. If no NAT binding for the data traffic was found in step 1558 1.3.2, the GaNAT now installs a NAT binding (for the 1559 unidirectional data traffic) which says that "a packet L that 1560 arrives on the upstream link and for which it holds that 1562 + L.[IP header].DestinationIPAddress=IPus (which is equal to 1563 GQ.MRI.DestinationIPAddress and GQ.[IP 1564 header].DestinationIPAddress), 1566 + L.[IP header].Protocol=GQ.MRI.Protocol, and 1568 + L.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers 1570 should be forwarded on the downstream link, with [IP 1571 header].DestinationIPAddress = IPNext and [Transport layer 1572 header].DestinationPort=PortNext. 1574 Note: If the GaNAT also allows data traffic to traverse in 1575 the other direction (i.e. in the upstream direction), then 1576 the IP packets of this data traffic MUST have 1577 SourceIPAddress=IPus, SourcePort=GQ.MRI.DestinationPort, 1578 DestinationPort=GQ.MRI.SourcePort, and must be forwarded on 1579 the upstream link. (This applies anyway for GaNATs with only 1580 two links and where each link is bound to a single IP 1581 address. However, for other types of GaNAT care has to be 1582 taken that this restriction is enforced.) 1584 Issues: there is a question of whether this NAT binding 1585 should also enable data traffic in the opposite direction to 1586 traverse the NAT; in order to be able to demultiplex upstream 1587 traffic that carries data that belongs to different flows, 1588 the GaNAT should keep the necessary per-flow state. From a 1589 signalling point of view, however, upstream data traffic that 1590 corresponds (on the application level) to the downstream flow 1591 to which this GIST session refers, is a separate flow for 1592 which, dependent on the application, there may or there may 1593 not exist a signalling session. If such a signalling session 1594 exists, then the GaNAT acts as an NR-side GaNAT for this 1595 session. Thus, during the processing of this signalling care 1596 has to be taken not to establish a NAT binding for a flow for 1597 which a NAT binding already exists. Finally, security issues 1598 arise when traffic, for which no signalling exists, is 1599 allowed to traverse a GaNAT. 1601 3. Otherwise, if P matches an existing NAT binding, normal NAT 1602 processing is applied. 1604 4. Otherwise, P is subjected to normal NAT processing. That is, P 1605 is either silently discarded or it causes the installation of a 1606 (data) NAT binding. 1608 The remaining steps of the algorithm are analogous to the algorithm 1609 of NSLP-unaware, NR-side GaNATs, which was described in the previous 1610 section. 1612 6.3. GIST peer processing 1614 In the presence of GaNATs on the signalling path between two NSLP 1615 peers, and if the GaNATs follow the "non-transparent" approach (which 1616 they have to follow in the context of cryptographically protected 1617 signalling), the consistent translation of the GIST header fields 1618 must be carried out by the NSLP peers. The GIST processing that 1619 performs this task, is described next. Note that this processing is 1620 in addition to the processing described in [1]. Also note that the 1621 processing described in this section applies only to non-NAT nodes. 1623 A GIST peer that receives a GIST QUERY that carries an NSLP ID for a 1624 supported NSLP and an NTO, constructs a GIST RESPONSE according to 1625 [1]. This response is sent to the public address of the last in- 1626 between GaNAT. This address appeared as NLI.NI in the GIST QUERY 1627 (and also as the source address in the IP header). 1629 If local policy allows the installation of state without the 1630 reception of a GIST CONFIRM message, then the responder stores the 1631 NTO carried with the QUERY together with the routing state 1632 information about the querying GIST peer. In particular, the MRI 1633 field of the NTO must be saved in order for the peer to be able to 1634 map subsequently received signalling messages to this signalling 1635 session. 1637 Note that it is not sufficient for the NSLP to exclusively rely on 1638 the NTO.MRI for this purpose. In order to see this, consider two 1639 private addressing domains, A and B, each with a GaNAT at its border, 1640 and a node N in the public internet. In domain A, node N1 has a 1641 communication session with N, and in domain B, node N2 also has a 1642 communication session with N. Suppose that the (private) IP addresses 1643 of N1 and N2 are equal (e.g. 192.168.0.3), and that they both 1644 communicate with N using the same source and destination ports. If 1645 they both have an NSIS signalling session for this data traffic, the 1646 NTO.MRI field in the GIST QUERY of their respective signalling 1647 sessions are identical. If these signalling sessions meet at an NSLP 1648 node that is located "after" the GaNATs, then this NSLP node sees the 1649 same MRI in signalling messages that are received over a messaging 1650 association. In this case, the node must use other information in 1651 the signalling messages (e.g. session ID, source IP address) in order 1652 to map subsequently received signalling messages to existing 1653 sessions. 1655 If local policy demands that no session-specific state is installed 1656 before the reception of a GIST CONFIRM message, then the responder 1657 must encode the information in NTO.MRI and NLI.IA from the GIST QUERY 1658 (and possibly other values such as NSLP ID and an identifier of the 1659 link on which the GIST QUERY arrived) in the responder cookie. Since 1660 this cookie is echoed in the GIST CONFIRM message, the responder can 1661 then delay the installation of the relevant state until it receives 1662 the GIST CONFIRM. The construction of the responder cookie is 1663 implementation-specific, in the sense that it does not raise 1664 interoperability issues. Nevertheless, the cookie must be generated 1665 in a way that meets the requirements listed in section 8.5 of [1], 1666 and in a way that does not introduce additional attacks against the 1667 system. 1669 Two responder cookie construction mechanisms are described in the 1670 sequel. These methods are in addition to those described in section 1671 8.5 of [1], and meet the requirements listed in that section. 1672 Additionally, they enable the responder to authenticate the contents 1673 of the cookie, i.e. to ensure that the cookie was not tampered with 1674 while in transit. This feature is not provided by the cookie 1675 construction mechanisms described in [1]. 1677 Responder cookie generation mechanism 1: Responder cookie = (gennum 1678 || cookie-left || cookie-right), where || denotes concatenation, 1679 cookie-left is computed as ENC (Q-Node NLI, MRI, NSLPID, reception 1680 interface, [timestamp]), and cookie-right is computed as MAC (cookie- 1681 left). ENC denotes a semantically secure symmetric encryption 1682 scheme, and MAC denotes an unforgeable message authentication code 1683 scheme. The responder must use a key with ENC that has been selected 1684 independently from the one used with MAC. Whenever these keys are 1685 refreshed, they MUST be refreshed together. Gennum is the generation 1686 number of the ENC and MAC keys. The timestamp is an optional field. 1687 Policy dictates whether or not it is included in the construction of 1688 the cookie. For example, responders that have a fast enough key 1689 rollover may omit the timestamp. Example algorithms for ENC and MAC 1690 are AES-128 in CBC mode [3], and HMAC-SHA1 [4]. 1692 Responder cookie generation mechanism 2: Responder cookie = (Gennum 1693 || AUTHENC (Q-Node NLI, MRI, NSLPID, reception interface, 1694 [timestamp])) AUTHENC denotes a symmetric authenticated encryption 1695 scheme. Gennum is the generation number of the key used with 1696 AUTHENC. The timestamp is an optional element for the same reason as 1697 above. Example AUTHENC algorithms include the one specified in 1698 RFC3610. 1700 The version of the MRI that the NSLP peers pass to the NSLP is the 1701 one in the header of the GIST QUERY (not the one in the NTO, if one 1702 is present). Whether or not this is a translated MRI depends on the 1703 location of the peer with respect to the in-between GaNAT(s). Note 1704 that the same MRI is used by the responder in signalling messages 1705 that are sent towards the downstream direction. 1707 7. Security Considerations 1709 The mechanisms proposed in this document give rise to a number of 1710 threats that must be considered. In the following, some of these 1711 threats is mentioned. 1713 7.1. Service Denial Attacks 1715 As described above, NSLP-unaware GaNATs create some state whenever 1716 they receive a GIST QUERY message. This state is necessary in order 1717 for the GaNAT to be able to map a GIST RESPONSE that arrives from the 1718 downstream direction to the corresponding GIST QUERY and thereby to 1719 perform the required translation. 1721 The threat here is an attacker flooding the GaNAT with maliciously 1722 constructed GIST QUERIES with the aim of exhausting the GaNAT's 1723 memory. The attacker might use a variety of methods to construct 1724 such GIST QUERIES, including the following. 1726 1. Use as [IP header].SourceIPAddress the address of some other node 1727 or an unallocated IP address. This method is also known as IP 1728 spoofing. 1730 2. Use an invalid NSLPID, in order to make sure that all on-path 1731 GaNAT(s) will behave like NSLP-unaware GaNATs. 1733 3. For each packet, use a different value for the cookie field. 1735 4. For each packet, use a different value for the session ID field. 1737 5. Combinations of the above. 1739 How vulnerable a GaNAT is to the above service denial attack depends 1740 on a variety of factors, including the following. 1742 o The amount of state allocated at the receipt of a GIST QUERY. 1743 This amount may vary depending on whether or not the data flow to 1744 which the signalling refers, already exists (i.e. whether or not 1745 the GaNAT already maintains a NAT binding for it). 1747 o The mechanism that the GaNAT uses to map RESPONSEs to QUERIEs. 1749 o Whether or not the GaNAT acquires dynamic IP addresses and ports 1750 for the downstream link. 1752 In order to decrease the exposure of a GaNAT to service denial 1753 attacks, the following recommendations are made. 1755 o The GaNAT should perform ingress filtering. This limits the 1756 amount of locations from which an attacker can perform IP spoofing 1757 without being detected. 1759 o The GaNAT should allocate the minimum amount of state required at 1760 the reception of a GIST QUERY. 1762 o All state allocated by the GaNAT should timeout according to a 1763 local policy. If the GaNAT detects heavy loads (which may 1764 indicate a service denial attack in progress), the GaNAT should 1765 timeout the state allocated as a result of a received GIST QUERY 1766 quicker, proportionally to the experienced load. 1768 o The installation of a NAT binding for the data traffic (if such a 1769 binding does not exist prior to signalling) should be postponed 1770 until the correct GIST RESPONSE traverses the NAT. 1772 The service denial threats mentioned in this section do not apply to 1773 an NSLP-aware GaNAT, as such a GaNAT is required, in accordance with 1774 its local policy, to verify the validity of the cookie(s) before 1775 allocating any state, including the state required by the mechanisms 1776 in this document. 1778 7.2. Network Intrusions 1780 Although the primary goal of a NAT is to perform address translation 1781 between two addressing spaces, NATs are sometimes also used to 1782 provide a security service similar to the security service provided 1783 by firewalls. That is, a NAT can be configured so that it does not 1784 forward packets from the external into the internal network, unless 1785 it determines that the packets belong to a communication session that 1786 was originally initiated from an internal node and are, as such, 1787 solicited. 1789 If an NSLP-unaware GaNAT performs the above security-relevant 1790 function in addition to address translation, then the presence of 1791 GIST signalling and, in particular the mechanisms described in this 1792 document, might allow an adversary to cause the installation of NAT 1793 bindings in the GaNAT using these mechansisms. These NAT bindings 1794 would then enable the adversary to inject unsolicited traffic into 1795 the internal network, a capability that it might not have in the 1796 absence of the mechanisms described in this document. 1798 The administrator of an NSLP-unaware GaNAT should therefore make 1799 security-conscious decisions regarding the operation of the GaNAT. 1800 An NSLP-aware GaNAT, on the other hand, follows an NSLP policy which 1801 indicates the required security mechanisms. This policy should 1802 account for the fact that this NSLP-aware node performs also NAT and 1803 the associated packet filtering. 1805 8. IAB Considerations 1807 None. 1809 9. Acknowledgements 1811 The authors would like to thank Cedric Aoun, Christian Dickmann, 1812 Robert Hancock, and Martin Stiemerling for their insightful comments. 1813 Furthermore, we would like to mention that this document builds on 1814 top of a previous document regarding migration scenarios. 1816 10. Normative References 1818 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1819 Signalling Transport", draft-ietf-nsis-ntlp-09 (work in 1820 progress), February 2006. 1822 [2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS 1823 Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 1824 (work in progress), February 2006. 1826 [3] "Advanced Encryption Standard (AES)", FIPS PUB 197, 1827 November 2001. 1829 [4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1830 for Message Authentication", RFC 2104, February 1997. 1832 Authors' Addresses 1834 Andreas Pashalidis 1835 Siemens 1836 Otto-Hahn-Ring 6 1837 Munich, Bavaria 81739 1838 Germany 1840 Email: Andreas.Pashalidis@siemens.com 1842 Hannes Tschofenig 1843 Siemens 1844 Otto-Hahn-Ring 6 1845 Munich, Bavaria 81739 1846 Germany 1848 Email: Hannes.Tschofenig@siemens.com 1850 Intellectual Property Statement 1852 The IETF takes no position regarding the validity or scope of any 1853 Intellectual Property Rights or other rights that might be claimed to 1854 pertain to the implementation or use of the technology described in 1855 this document or the extent to which any license under such rights 1856 might or might not be available; nor does it represent that it has 1857 made any independent effort to identify any such rights. Information 1858 on the procedures with respect to rights in RFC documents can be 1859 found in BCP 78 and BCP 79. 1861 Copies of IPR disclosures made to the IETF Secretariat and any 1862 assurances of licenses to be made available, or the result of an 1863 attempt made to obtain a general license or permission for the use of 1864 such proprietary rights by implementers or users of this 1865 specification can be obtained from the IETF on-line IPR repository at 1866 http://www.ietf.org/ipr. 1868 The IETF invites any interested party to bring to its attention any 1869 copyrights, patents or patent applications, or other proprietary 1870 rights that may cover technology that may be required to implement 1871 this standard. Please address the information to the IETF at 1872 ietf-ipr@ietf.org. 1874 Disclaimer of Validity 1876 This document and the information contained herein are provided on an 1877 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1878 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1879 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1880 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1881 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1882 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1884 Copyright Statement 1886 Copyright (C) The Internet Society (2006). This document is subject 1887 to the rights, licenses and restrictions contained in BCP 78, and 1888 except as set forth therein, the authors retain all their rights. 1890 Acknowledgment 1892 Funding for the RFC Editor function is currently provided by the 1893 Internet Society.