idnits 2.17.00 (12 Aug 2021) /tmp/idnits63720/draft-pashalidis-nsis-gimps-nattraversal-00.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 1562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1552. ** 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 : ---------------------------------------------------------------------------- == There are 22 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 442: '... implementation SHOULD discard at thi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2005) is 6158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'UDP' on line 988 == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '2') Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS A. Pashalidis 3 Internet-Draft H. Tschofenig 4 Expires: January 12, 2006 Siemens 5 July 11, 2005 7 NAT Traversal for GIMPS 8 draft-pashalidis-nsis-gimps-nattraversal-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 12, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document contains a number of mechanisms that may be used in 42 order to enable General Internet Messaging Protocol for Signaling 43 (GIMPS) messages to traverse different types of Network Address 44 Translators that may be located along the path between two adjecent 45 NSLP hosts. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 5. Traversal of GaNATs in the absence TLS or IPsec . . . . . . . 9 54 5.1 NSLP-unaware GaNATs . . . . . . . . . . . . . . . . . . . 9 55 5.1.1 NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . 9 56 5.1.2 NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . 14 57 5.2 NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 17 58 5.3 Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 20 59 6. GaNATs in the presence of TLS or IPSec . . . . . . . . . . . . 22 60 6.1 NSLP-unaware GaNATs . . . . . . . . . . . . . . . . . . . 22 61 6.1.1 NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . 22 62 6.1.2 NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . 26 63 6.1.3 Additional GIMPS peer processing . . . . . . . . . . . 28 64 6.2 NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 30 65 7. NSIS-unaware NATs . . . . . . . . . . . . . . . . . . . . . . 31 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 67 8.1 Service Denial Attacks . . . . . . . . . . . . . . . . . . 34 68 8.2 Network Intrusions . . . . . . . . . . . . . . . . . . . . 35 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 70 10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 38 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 72 12. Normative References . . . . . . . . . . . . . . . . . . . . 39 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 74 Intellectual Property and Copyright Statements . . . . . . . . 40 76 1. Introduction 78 Network Address Translators (NATs) modify certain fields in the IP 79 header of the IP packets that traverse them. In the context of 80 signalling as defined by the NSIS group, this behaviour, if not 81 properly addressed, may lead to the installation of inconsistent and 82 meaningless state at network nodes with respect to the actual traffic 83 that traverses these nodes. 85 This document proposes a collection of algorithms that have to be 86 implemented in order to enable GIMPS signalling, and the data flows 87 to which this signalling refers, to traverse NATs in a way that 88 preserves the consistency of state that is installed in the network, 89 and in a manner transparent to signalling applications. The document 90 is organised as follows. The next section introduces the terminology 91 that is used throughout this document. Section 3 provides a detailed 92 discussion of the problems that are addressed by this document. 93 Section 4 list the assumptions on which the proposed mechanisms are 94 based. Section 5 presents the proposed mechanisms for the case where 95 no TLS or IPsec protection is required for the signalling traffic 96 between two NSLP peers, and Section 6 presents the proposed 97 mechanisms where such protection is required. 99 2. Terminology 101 The terminology, abbreviations and notational conventions that are 102 used throughout the document are as follows. 104 o DR: Data Responder, as defined in [1] 106 o DS: Data Sender, as defined in [1] 108 o GaNAT: GIMPS-aware NAT - A GaNAT may implement a number 109 of NSLPs, but does not implement the NATFW NSLP. 111 o GIMPS: General Internet Messaging Protocol for Signalling 112 [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, as defined in [1] 122 o NSIS-aware: Implements GIMPS and zero or more NSLPs. 124 o NSIS-unaware: GIMPS-unaware, does not implement any NSLP. 126 o NSLP: NSIS Signalling Layer Protocol, as defined in [1] 128 o downstream: as defined in [1] 130 o upstream: as defined in [1] 132 o MRI: Message Routing Information, as defined in [1] 134 o NLI.IA: Interface Address field of the Network Layer 135 Information header field, as defined in [1] 137 o <- : Assignment operator. The quantity to the right of 138 the operator is assigned to the variable to its left. 140 o A.B: Element B of structure A. Example: [IP 141 header].SourceIPAddress denotes the source IP address of an IP 142 header. 144 o [data item]: This notation indicates that "data item" is a 145 single identifier of a data structure. (Square brackets do not 146 denote optional arguments in this document.) 148 3. Problem Statement 150 According to [1], all GIMPS messages carry IP addresses in order to 151 define the data flow to which the signalling refers. Moreover, 152 certain GIMPS messages also carry the IP address of the sending peer, 153 in order to enable the receiving peer to address subsequent traffic 154 to the sender. Packets that cross an addressing boundary, say from 155 addressing space S1 to S2, have the IP addresses in the IP header 156 translated from space S1 to S2 by the NAT; if GIMPS payloads are not 157 translated in a consistent manner, the MRI in a GIMPS packet that 158 crosses the boundary, e.g. from address space S1 to S2, refers to a 159 flow that does not exist in S2. In fact, the flow is invalid in S2 160 because at least one of the involved IP addresses belongs to S1. 161 Moreover, the IP address of the sending peer may also be invalid in 162 the addressing space of the receiving peer. The purpose of this 163 document is to describe a way for GIMPS messages to be translated in 164 a way consistent with the translation that NATs apply to the IP 165 headers of both signalling and data traffic. 167 A NAT may either be NSIS-unaware or NSIS-aware. The case of NSIS- 168 unaware NATs is discussed in Section 7. If the NAT is NSIS-aware, it 169 is typically also able to support at least one NSLP. Note that there 170 exists an NSLP, namely the NATFW NSLP [2], that specifically 171 addresses NAT traversal for data flows. Inevitably, the NATFW NSLP 172 also provides the necessary mechanisms for the related signalling to 173 traverse the NATs involved. Therefore, we can further divide NSIS- 174 aware NATs into two categories, namely GIMPS-and-NATFW-aware NATs and 175 GIMPS-aware-and-NATFW-unaware NATs. In the sequel, we call the 176 latter simply GIMPS-aware NATs (GaNATs). A GIMPS-and-NATFW-aware NAT 177 performs NAT traversal according to the NATFW NSLP; the case of NAT 178 traversal in the presence of such NATs is therefore beyond the scope 179 of this document. 181 As is natural, a NATFW-aware NAT only translates the relevant fields 182 for the NATFW signalling traffic in a way consistent with the 183 relevant data flow. Consequently, GIMPS signalling in the presence 184 of NATFW-unaware NATs and for NSLPs other than the NATFW NSLP remains 185 an open problem. This document precisely addresses this problem, by 186 proposing mechanisms that operate at the GIMPS layer. 188 In general, a given data flow between a data sender (DS) and a data 189 receiver (DR) may have to traverse a number of NATs, some of which 190 may be GIMPS-and-NATFW-aware, some may be GIMPS-aware, and some may 191 be NSIS-unaware. Additionally, NSLP signalling for such a data flow 192 may be required to traverse through a subset of those NATs. Whether 193 or not the routing inftrastructure and state of the network causes 194 the signalling for such a data flow to traverse the same NATs as the 195 flow depends, among other things, on the signalling application. 197 While signalling of a QoS NSLP, for example, might not traverse any 198 of the NATs that are traversed by the data flow, the signalling of 199 the NATFW NSLP traverses at least those NATs that implement the NATFW 200 NSLP (otherwise the signalling path would no longer be coupled to the 201 data path, as this coupling is defined by the GIMPS QUERY/RESPONSE 202 discovery mechanism). It is desirable for every possible combination 203 of NATs, either on the data or the signalling path, to be functional 204 and secure. 206 Due to the GIMPS QUERY/RESPONSE discovery mechanism (according to 207 which QUERY messages are simply forwarded if the current node does 208 not support the required NSLP), two GIMPS nodes identify themselves 209 as NSLP peers only if they both implement the same NSLP, say NSLP X. 210 This means that, if one or more X-unaware NATs are between them, then 211 the two X peers are not able to discover each other at all. This is 212 because, even in the unlikely event that the bindings necessary for 213 the GIMPS traffic to traverse the in-between NAT(s) exist, the NLI.IA 214 Object included in the RESPONSE message sent by the downstream 215 X-aware peer will be invalid (i.e. the IP address will be 216 unreachable) in the address space of the upstream X peer. In order 217 to overcome this limitation, either the two X peers need to cope with 218 the in-between NAT(s), or, if the NAT(s) are GaNATs, they (the 219 GaNATs) need to apply additional processing in order to transparently 220 create and maintain the required consistency. Additionally, if 221 X-aware NATs are on the data path (where X is any NSLP except NATFW), 222 then these NATs should process X traffic in a way the preserves 223 consistency after address translation. This processing deviates from 224 the processing of X-aware non-NAT nodes. In the following sections 225 we propose certain processing rules that aim to overcome the 226 limitation of two adjacent X peers not being able to execute X in the 227 presence of in-between NAT(s). We do not consider the case where 228 X=NATFW and all NAT(s) on the path are NATFW-aware. This case is 229 handled by the NATFW NSLP. 231 Note that we have to deal with a number of different situations, 232 depending on whether X is supported by the GaNATs. Thus, we have the 233 following three subcases. 235 o all GaNAT(s) are X-unaware 237 o all GaNAT(s) are X-aware (and X is not the NATFW NSLP) 239 o a combination of X-aware and X-unaware GaNATs are between to X 240 peers. 242 In the following sections, we discuss the three cases separately. 244 4. Assumptions 246 The discussion in this document is based on the following 247 assumptions. Note that X denotes a fixed NSLP, other than the NATFW 248 NSLP. 250 1. No IP addresses and port numbers are carried in the payloads of 251 X. 253 2. The path taken by the signalling traffic between those X peers 254 that have GaNATs in between is such that the responses to packets 255 that a GaNAT sends on given interface arrive on the same 256 interface (if such responses are sent at all). 258 3. The path taken by signalling traffic remains fixed between the 259 two X peers, as far as the in-between GaNATs are concerned. That 260 is, we assume that signalling traffic traverses the same GaNAT(s) 261 until at least one of the following conditions is met. 263 * The NSIS state that is installed at the two X peers expires. 265 * The NSIS state that is installed at the two X peers is 266 refreshed using a GIMPS QUERY. 268 * A new GIMPS QUERY/RESPONSE exchange takes place due to other 269 reasons, e.g. a detected route change. 271 Note that this assumption is not necessarily met by "normal" data 272 path coupled signalling. This is because, under "normal" data 273 path coupled signalling, the signalling traffic is "coupled" to 274 the data traffic at nodes that implement X. Thus, under "normal" 275 path coupled signalling, it is not an error condition (e.g. a 276 "route change"), for example, if the set of on-path (non-X) GIMPS 277 nodes changes, as long as adjacent X peers remain the same. 279 4. The data flow traverses the same set of GaNATs as the signalling 280 traffic. By assumption 3, this set of GaNATs is fixed until the 281 next GIMPS QUERY/RESPONSE procedure is executed. 283 +-----+ 284 +----+GaNAT|-----+ 285 | | A | | 286 | +-----+ | 287 +------+ +------+ +--+---+ +------+ 288 +--+ |X NSLP| | IP | | IP | |X NSLP| +--+ 289 |DS+-+peer +--+router| |router+--+peer 2+-+DR| 290 +--+ +------+ +---+--+ +--+---+ +------+ +--+ 291 | +-----+ | 292 | |GaNAT| | 293 +----+ B +-----+ 294 +-----+ 296 Figure 1: Network with more than one NAT at an addressing boundary 298 Figure 1 illustrates the importance of assumptions (3) and (4). With 299 regard to that figure, suppose that a (D-mode) signalling session has 300 been setup between the two adjacent X NSLP peers 1 and 2 and that 301 both signalling and data traffic follows the path X NSLP peer 1 -> IP 302 router -> GaNAT A -> IP router -> X NSLP peer 2. Suppose now that, 303 after some time, X peer 1 decides to set up a C-mode connection with 304 peer 2. Suppose moreover that the left IP router decides to forward 305 the C-mode signalling traffic on the link towards GaNAT B. Thus, 306 signalling traffic now follows the alternative path X NSLP peer 1 -> 307 IP router -> GaNAT B -> IP router -> X NSLP peer 2. Note that this 308 change in forwarding between the two adjacent X NSLP peers does not 309 trigger a "route change" at the GIMPS layer because (a) it does not 310 destroy the adjacency of peer 1 and 2 and (b) it does not destroy the 311 coupling of the path taken by signalling traffic to that taken by 312 data traffic (at X-aware nodes). Nevertheless, assumptions (3) and 313 (4) mandate that this situation does not occur. However, even if 314 such a situation occurs, the proposals in this document still work. 316 If assumption (1) does not hold, X has to provide additional 317 mechanisms for the traversal of (Ga)NATs. These mechanisms must be 318 compatible with the mechanisms described in this document. 319 Assumptions (2), (3) and (4) hold if, at an addressing boundary, only 320 one NAT exists. Due to security and management reasons, this is 321 likely to be the case in many settings. 323 5. Traversal of GaNATs in the absence TLS or IPsec 325 This section describes the operation of GIMPS-aware NATs when no 326 cryptographic protection of signalling data is requested by two NSLP 327 peers. The situation when such protection is required is discussed 328 in Section 6. 330 Recall that by GaNAT we mean a NAT that implements GIMPS but does not 331 implement the NATFW NSLP. In this section we discuss the possibility 332 of two NSIS peers that implement a given NSLP, denoted as X, to 333 discover each other and subsequently exchange signalling messages in 334 the presence of one or more GaNATs in between. Note that X may be 335 any NSLP including the NATFW NSLP (however, if X=NATFW we do not 336 consider X-aware GaNATs). 338 Note that we have to deal with three subcases, namely (a) the case 339 where all GaNAT(s) are X-unaware, (b) the case where all GaNAT(s) are 340 X-aware (and X is not the NATFW NSLP), and (c) the case where a 341 combination of X-aware and X-unaware GaNATs are between to X peers. 342 We discuss the three cases separately. 344 5.1 NSLP-unaware GaNATs 346 This section describes the algorithm that an X-unaware GaNAT must 347 execute in order to enable the signalling traffic of two X peers to 348 traverse the GaNAT in a transparent (for the two peers) manner. The 349 notation A.B denotes the field B of data structure A. 351 Note that we have to deal with two types of GaNATs, namely those that 352 are located at the NSIS initiator (NI-side), and those that are 353 located at the NSIS responder (NR-side). This distinction arises due 354 to the fact that NI-side and NR-side GaNATs obtain the destination IP 355 address for forwarded packets in different ways. 357 5.1.1 NI-side NSLP-unaware GaNATs 359 For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT 360 executes the following algorithm. 362 1. If P has a RAO followed by the GIMPS header with an NSLP ID that 363 is not supported, it is identified as a GIMPS QUERY. In this 364 case the GaNAT performs the following. 366 1. We denote P as GQ. It looks at the stack proposal ST in GQ. 367 If it indicates that cryptographic protection is required, 368 the algorithm that is executed is the one described in 369 Section 6. 371 2. The GaNAT remembers GQ along with the interface on which it 372 arrived. We call this interface the "upstream link". 374 3. It searches its table of existing NAT bindings against 375 entries that match the GQ.MRI. A matching entry means that 376 the data flow, to which the signalling refers, already 377 exists. 379 1. If a matching entry is found, the GaNAT looks at which 380 link the packets of the data flow are forwarded; we call 381 this link the "downstream" link. Further, the GaNAT 382 checks how the headers of the data flow (IP addresses, 383 port numbers, etc) are translated according to this NAT 384 binding. We denote [IP header].SourceIPAddress used on 385 the downstream link as IPGaNATds, and the source port 386 number used to forward the data traffic as SPNDTGaNATds. 387 The NAT may also use a different source port number when 388 forwarding signalling traffic. This port number is 389 denoted as SPNSTGaNATds. 391 2. If no matching entry is found, the GaNAT determines, 392 based on its routing table, the link on which packets 393 that match GQ.MRI (excluding GQ.MRI.SourceIPAddress) 394 would be forwarded. We call this link the "downstream 395 link". Then, the GaNAT acquires an IP address for itself 396 on the downstream link. (This address could be dynamic 397 or static.) This address will be used to forward both 398 signalling and data traffic on the downstream link. If 399 it also performs port translation, the GaNAT also 400 acquires a source port number for the data traffic on the 401 downstream link. This will be used with the NAT binding, 402 if such a binding will be established for the data 403 traffic at a later stage, and is denoted as SPNDTGaNATds 404 . The signalling traffic packets may also be forwarded 405 using the a different source port number as the incoming 406 packets. We denote the acquired IP address as IPGaNATds 407 and the source port number for the signalling traffic as 408 SPNSTGaNATds. 410 Issues: The reason why the GaNAT may also assign a 411 different source port number to the signalling traffic, 412 is to enable the GaNAT to demultiplex (i.e. forward to 413 the correct internal address) the signalling responses 414 that arrive from downstream. Of course, a GaNAT does not 415 need to actually change the source port of signalling 416 traffic; it can always use SPNSTGaNATds the same port as 417 in the incoming packet. Such a GaNAT may use the GIMPS 418 session id in order to demultiplex the traffic that 419 arrives from the downstream direction. It is unclear 420 which of the two approaches is preferable. 422 4. It creates a new GIMPS QUERY packet GQ', as follows. 424 1. GQ' <- GQ 426 2. GQ'.MRI.SourceIPAddress <- IPGaNATds 428 3. GQ'.MRI.SourcePortNumber <- SPNDTGaNATds 430 4. GQ'.[IP header].SourceIPAddress <- IPGaNATds 432 5. GQ'.[TRANSPORT_LAYER_HEADER].SourcePort <- SPNSTGaNATds 434 6. GQ'.NLI.IA <- IPGaNATds 436 7. GQ'.S <- true 438 5. It remembers GQ and GQ', the fact that they are associated, 439 and the associated upstream and downstream links. (Note: The 440 GaNAT does not have to remember the entire packets; for 441 simplicity of exposition, however, we assume it does. An 442 implementation SHOULD discard at this point all information 443 that is not used later.) 445 6. It forwards GQ' on the downstream link. 447 2. Otherwise, if P carries a [IP header].DestinationIPAddress that 448 belongs to the GaNAT, and if it is identified as a GIMPS response 449 in D-mode with an NSLP ID that is not supported, the GaNAT does 450 the following (P is denoted as GR). 452 1. It searches for a matching GQ' in its buffer. A GR is said 453 to match a GQ' if they carry the same cookie value. If none 454 is found, GR is discarded. Otherwise, the GaNAT may also 455 perform further consistency checks on a matching GR/GQ' pair, 456 such as checking that they contain the same session IDs, 457 MRIs, NSLP IDs. If consistency checks succeed, the GaNAT 458 constructs a new GIMPS response GR', as follows. 460 1. GR' <- GR 462 2. GR'.MRI <- GQ.MRI, where GQ is the packet associated with 463 GQ'(as remembered previously), and GQ' is the packet that 464 matches the received GR. 466 3. GR'.[IP header].SourceIPAddress <- IPGaNATus, where 467 IPGaNATus = GQ.[IP header].DestinationIPAddress. 469 4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA 471 5. GP'.S <- true. 473 6. It inspects the stack proposals in GR' and the 474 corresponding GQ' to see if the upstream X peer has a 475 choice of more than one possible stack. If such choice 476 exists, the GaNAT removes as many stack proposals from 477 GR' as necessary, until only one stack can be chosen by 478 the upstream peer for the messaging association. We 479 denote this stack as ST. The GaNAT remembers this ST and 480 its association with GQ, GQ', GR, GR'. We say that, in 481 this case, the GaNAT "installs" the ST. 483 2. It forwards GR' on the upstream link. 485 3. If no NAT binding for the data traffic was found in step 486 1.3.2, the GaNAT now installs a NAT binding (for the 487 unidirectional data traffic) which says that "a packet K that 488 arrives on the upstream link and for which it holds that 490 + K.[IP 491 header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, 493 + K.[IP header].Protocol=GQ.MRI.Protocol, and 495 + K.[TCP/UDP header].SourcePort=GQ.MRI.SourcePort 497 should be forwarded on the downstream link, with [IP 498 header].SourceIPAddress = IPGaNATds. 500 Issues: there is a question of whether this NAT binding 501 should also enable data traffic in the opposite direction to 502 traverse the NAT; in order to be able to demultiplex upstream 503 traffic that carries data that belongs to different flows, 504 the GaNAT should keep the necessary per-flow state. From a 505 signalling point of view, however, upstream data traffic that 506 corresponds (on the application level) to the downstream flow 507 to which this GIMPS session refers, is a separate flow for 508 which, dependent on the application, there may or there may 509 not exist a signalling session. If such a signalling session 510 exists, then the GaNAT acts as an NR-side GaNAT for this 511 session. Thus, during the processing of this signalling care 512 has to be taken not to establish a NAT binding for a flow for 513 which a NAT binding already exists. Finally, security issues 514 arise when traffic, for which no signalling exists, is 515 allowed to traverse a GaNAT. 517 Another issue is about refreshing the NAT binding. A NAT 518 binding that was established as a result of GIMPS signalling 519 should remain in place as long as the associated GIMPS state 520 in the GaNAT remains valid. If GIMPS signalling refers to a 521 NAT binding that already exists, then the timeout of the NAT 522 binding should occur according to the NAT policy, in a manner 523 independing from GIMPS processing. (If signalling persists 524 after the deletion of a NAT binding, then the NAT binding may 525 be re-installed and then timeout together with GIMPS state). 527 3. Otherwise, if P.[IP header].DestinationIPAddress belongs to the 528 GaNAT, and if P is a GIMPS packet (either in D-mode or C-mode), 529 the GaNAT does the following. If P does not match an existing 530 installed ST, P is silently discarded. (A packet P is said to 531 "match" an installed ST, if it carries the transport protocol and 532 port numbers indicated by ST.) Otherwise, if P has not arrived 533 on either the downstream or upstream link of some ST, it is 534 silently discarded. Otherwise, P has arrived either on the 535 upstream or the downstream of some ST. The GaNAT constructs an 536 outgoing packet P' as follows (the variables used below refer to 537 those stored together with the ST in question). 539 1. P' <- P 541 2. If P has arrived on the upstream link, then 543 1. P'.[IP header].SourceIPAddress <- IPGaNATds 545 2. P'.MRI <- GQ'.MRI 547 3. P'.NLI.IA <- IPGaNATus 549 4. The GaNAT forwards P' on the downstream link. 551 3. else (if P has arrived on the downstream link) 553 1. P'.[IP header].SourceIPAddress <- IPGaNATus 555 2. P'.MRI <- GQ.MRI 557 3. P'.NLI.IA <- IPGaNATus 559 4. The GaNAT forwards P' on the upstream link. 561 Note: the above step will fail if ST indicates security. 562 That is, if traffic is encrypted, then the GaNAT cannot 563 construct P', and if traffic is integrity-protected, 564 performing this step will cause an error at the receiving X 565 peer. However, recall that, in this section, we only discuss 566 the scenario where such cryptographic protection is not 567 required. 569 4. Otherwise, if P matches a (data) NAT binding, the GaNAT applies 570 normal NAT processing and forwards the packet on the 571 corresponding link. 573 5. Otherwise, P is silently discarded. 575 Brief discussion of the algorithm: The fact that the GaNAT replaces 576 the X peer's NLI.IA with its own IP address (in both directions), 577 causes the peers to send subsequent signalling messages to the GaNAT, 578 in the belief that they talk to the their adjacent X peer. The GaNAT 579 transparently forwards the signalling traffic and appropriately 580 translates the fields in the GIMPS header, by making use of the state 581 it creates bindings. 583 Due to the presence of the GaNATs, no data traffic can be sent from 584 DS to DR until all necessary bindings are in place. The MRI that the 585 NR sees includes as destination address the IP address of the DR (as 586 expected), but as source address the IPGaNATds of the GaNAT that is 587 closest to the NR. 589 5.1.2 NR-side NSLP-unaware GaNATs 591 The case of NR-side GaNATs is more subtle, since, in this setting, 592 the DS does not learn the IP address of the DR (which is assumed to 593 be on the same side of the GaNATs as the NR) and the NI does not 594 learn the address of the NR. In this setting we assume that each NR- 595 side GaNAT that is in between two X peers, a priori knows the IP 596 address of the downstream GaNAT. The last GaNAT of this chain is 597 assumed to know the IP address of the DR. In order to clarify this 598 assumption, see, for example, Figure 2. In this figure, GaNAT A is 599 assumed to know the IP address of GaNAT B, GaNAT B is assumed to know 600 the IP address of GaNAT C, and GaNAT C is assumed to know the IP 601 address of the DR. A given GaNAT that knows such an address, in 602 effect anticipates to receive a signalling message from the upstream 603 direction that refers to a data flow that terminates in a downstream 604 node. In other words, such a GaNAT may typically have already a NAT 605 binding in place for the data traffic. We call the IP address of the 606 next downstream GaNAT (or, if the GaNAT is the last in the chain, the 607 DR) the "pending" IP address. In the following description it is 608 denoted by IPNext. How IPNext is made known to each GaNAT (e.g. how 609 the NAT binding for the data traffic is installed in the GaNAT) is 610 outside the scope of this document. 612 +--+ +------+ +-----+ +-----+ +-----+ +------+ +--+ +--+ 613 +NI+--+X NSLP+---+GaNAT+---+GaNAT+---+GaNAT+---+X NSLP+--+NR+--+DR| 614 +--+ |peer 1| | A | | B | | C | |peer 2| +--+ +--+ 615 +------+ +-----+ +-----+ +-----+ +------+ 617 Figure 2: Network with NR-side GaNATs (the public Internet is assumed 618 to be between NI and X NSLP peer 1) 620 For every arriving IP packet P, an X-unaware, NR-side GaNAT executes 621 the following algorithm. 623 1. If P has a RAO followed by the GIMPS header with NSLP ID = X, it 624 is identified as a GIMPS QUERY. In this case the GaNAT does the 625 following. 627 1. We denote P as GQ. The GaNAT looks at the stack proposal ST 628 in GQ. If it indicates that cryptographic protection is 629 required, the algorithm that is executed is the one described 630 in section Section 6 below. 632 2. The GaNAT remembers GQ along with the link on which it 633 arrived. We call this link the "upstream" link. 635 3. The GaNAT determines whether or not this GIMPS QUERY is 636 anticipated, i.e. if a pending IPNext exists. If no IPNext 637 is pending, P is discarded (it is a question whether or not 638 an error message should be sent). Otherwise, additional 639 checks may be performed (e.g. a DSInfo object may have to be 640 checked against the GQ). If these checks fail, P is 641 discarded. Otherwise, the GaNAT performs the following. 643 4. It searches its table of existing NAT bindings against 644 entries that match the GQ.MRI. A matching entry means that 645 the data flow, to which the signalling refers, already 646 exists. 648 + If a matching entry is found, the GaNAT looks at which 649 link the packets of the data flow are forwarded; we call 650 this link the "downstream" link. Further, the GaNAT 651 checks how the headers of the data flow (IP addresses, 652 port numbers, etc) are translated according to this NAT 653 binding. We denote [IP header].SourceIPAddress used on 654 the downstream link as IPGaNATds, and the source port 655 number as SPNDTGaNATds. Note that the [IP 656 header].DestinationIPAddress of this NAT binding should be 657 equal to IPNext. If it is not, this should be handled as 658 an auditive error condition. The GaNAT may also assign a 659 new source port number to signalling traffic, which is 660 denoted as SPNSTGaNATds. 662 + If no matching entry is found, the GaNAT determines, based 663 on its routing table, the link on which packets that match 664 GQ.MRI (excluding GQ.MRI.SourceIPAddress and where 665 GQ.MRI.DestinationIPAddress is replaced with IPNext) would 666 be forwarded. We call this link the "downstream" link. 667 Then, the GaNAT acquires an IP address for itself on the 668 downstream link. (This address could be dynamic or 669 static.) Depending on its type, the GaNAT may also 670 acquire source port numbers for the translation of data 671 traffic. We denote the acquired IP address as IPGaNATds 672 and the source port numbers for data and signalling 673 traffic as SPNDTGaNATds and SPNSTGaNATds respectively. 675 5. It creates a new GIMPS QUERY packet GQ', as follows. 677 1. GQ' <- GQ 679 2. GQ'.MRI.SourceIPAddress <- IPGaNATds 681 3. GQ'.MRI.DestinationIPAddress <- IPNext. 683 4. GQ'.MRI.SourcePort <- SPNDTGaNATds. 685 5. GQ'.[IP header].SourceIPAddress <- IPGaNATds 687 6. GQ'.[TRANSPORT_LAYER_HEADER].SourcePort <- SPNSTGaNATds 689 7. GQ'.[IP header].Destination_IP_Address <- IPNext 691 8. GQ'.NLI.IA <- IPGaNATds. 693 9. GQ'.S <- true 695 6. It remembers GQ, GQ' the fact that they are associated, and 696 the associated upstream and downstream links (interfaces). 698 7. It forwards GQ' on the downstream link. 700 Steps 2,3, 4 and 5 of the algorithm are analogous to the 701 corresponding steps of the algorithm executed by X-unaware, NI-side 702 GaNATs, which was described in Section 5.1.1 704 5.2 NSLP-aware GaNATs 706 Recall that X may be any NSLP except NATFW. The difference of 707 X-aware GaNATs and X-unaware GaNATs is that the former perform X 708 processing in addition to the processing of the X-unaware GaNATs. 709 Another way to see this is by observing that X-aware GaNATs should 710 provide an "MRI translation service" (MRITS) in addition to normal 711 GIMPS and X processing. The motivation behind the MRITS is for GIMPS 712 to hide from the NSLP that signalling messages traverse an addressing 713 boundary. In other words, the purpose of the MRITS it to make X 714 believe that it is operating in a single IP addressing space. When 715 and how the MRITS is invoked for a particular packet depends on (i) 716 the direction of the packet (i.e. downstream or upstream) and (ii) 717 the location of the GaNAT (i.e. NI-side or NR-side). It should also 718 be noted that certain NSLP layer tasks must be carried out in 719 consistency with the placement of the MRITS. This is to prevent 720 events triggered by X to cause installation of inconsistent state. 721 In order to clarify this, consider the scenario of the QoS NSLP 722 running in a GaNAT that operates according to the mechanisms 723 described in this section. Since the GaNAT only presents a single 724 addressing space to the NSLP (say, the internal addressing space), 725 the packet classifier of the GaNAT's QoS provisioning subsystem 726 should classify packets based on internal addresses only (i.e. it 727 should first translate packets that carry external addresses and then 728 classify them). Whether the MRITS presents internal-only or 729 external-only addresses to the NSLP is not significant, as long as 730 NSLP layer operations are carried out consistently. In the remainder 731 of this section we present the case where internal addresses are 732 presented to the NSLP. 734 The MRITS is obviously invoked only on GIMPS packets that carry NSLP 735 identifier = X. (For other GIMPS packets the GaNAT may adopt the role 736 of an X-unaware GaNAT. Also, for non-GIMPS packets, normal NAT 737 behaviour applies - whatever "normal" may mean.) Although the MRITS 738 is part of GIMPS processing, in order to clarify our discussion, we 739 view it as a somewhat separate processing step (i.e. like a 740 subroutine). For NI-side, X-aware GaNATs, it holds that 742 o if a GIMPS/X packet is to be forwarded on the downstream link of 743 an NI-side GaNAT, the MRITS is invoked after the packet has been 744 processed by X and before it is given to GIMPS, and 746 o if a GIMPS/X packet is received on the downstream link, then the 747 MRITS is invoked after GIMPS processing and before the packet is 748 given to X. 750 The converse holds for NR-side X-aware GaNATs. In particular, 751 o if a GIMPS/X packet is to be forwarded on the upstream link of an 752 NI-side GaNAT, the PTS is invoked after the packet has been 753 processed by X and before it is given to GIMPS, and 755 o if a GIMPS/X packet is received on the upstream link, then the PTS 756 is invoked after GIMPS processing and before X processing. 758 Figure 3 illustrates this idea. 760 +----------------+ +----------------+ 761 | +------+ | | +------+ | 762 | |NSLP X| | | |NSLP X| | 763 | +-+---++ | | +-+--+-+ | 764 | | | | | | | | 765 | | +-+---+ | | +----++ | | 766 | | |MRITS| | | |MRITS| | | 767 | | +---+-+ | | ++----+ | | 768 | | | | | | | | 769 | +-+-----+-+ | | ++------+-+ | 770 | | GIMPS | | | | GIMPS | | 771 u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s 772 -----+----+ +-----+----- -----+---+ +-----+----- 773 link +----------------+ link link +----------------+ link 774 NI-side NR-side 775 X-aware X-aware 776 GaNAT GaNAT 778 Figure 3: Operation of the MRI Translation Service 780 The reason for this construction is to give X the impression that it 781 works only with flows that originate and terminate in the internal 782 address space. We now describe the operation of the MRITS and GIMPS 783 in X-aware GaNATs. An NI-side X-aware GaNAT operates according to 784 the following rules. 786 1. When X asks for a message to be sent towards the downstream X 787 peer, the MRITS does the following (IPGaNATds and SPNDTGaNATds 788 are obtained similarly to the case of an NSLP-unaware GaNAT). 790 1. MRI.SourceIPAddress <- IPGaNATds 792 2. MRI.SourcePort <- SPNDTGaNATds 794 2. Additionally, GIMPS performs the following on the resulting 795 packet before it is forwarded on the downstream link 796 (SPNSTGaNATds is obtained similarly to the case of an NSLP- 797 unaware GaNAT). 799 1. [IP header].SourceIPAddress <- IPGaNATds 801 2. [UDP/TCP header].SourcePort <- SPNSTGaNATds 803 3. NLI.IA < IPGaNATds 805 4. S <- true 807 3. If a message is received on the downstream link, the MRITS does 808 the following before X is invoked. 810 1. MRI.SourceIPAddress <- IPflow 812 2. MRI.SourcePort <- SPNDTGaNATus, where IPflow is the IP 813 address of the DS (as seen by the GaNAT) and SPNDTGaNATus is 814 the destination port number used in the original MRI. 816 4. If, after X processing, a message is to be forwarded on the 817 upstream link, GIMPS performs the following processing (note that 818 no MRITS processing takes place in this case). 820 1. [IP header].SourceIPAddress <- IPGaNATus 822 2. [IP header].DestinationIPAddress <- IPpeer 824 3. NLI.IA <- IPGaNATus 826 4. S <- true, where IPGaNATus is the GaNATs IP address for the 827 upstream link, IPpeer is the IPaddress of the NI (or the next 828 GaNAT in the upstream direction), and IPflow is the IP 829 address of the DS (as seen by the GaNAT). The GaNAT is 830 assumed to determine the correct IPGaNATus and IPpeer from 831 previous communications and in cooperation with GIMPS. 832 [Issue: how exactly should IPGaNATus, IPpeer and IPflow be 833 resolved; i.e. what exactly should the GaNAT remember?] 835 An NR-side X-aware GaNAT operates according to the following rules. 837 1. If the packet is received on the upstream link, the MRITS does 838 the following, before X is notified. 840 1. P.MRI.SourceIPAddress <- IPGaNATds 842 2. P.MRI.DestinationIPAddress <- IPNext, where IPGaNATds is the 843 GaNAT's IP address for the downstream link and IPNext is the 844 address of the DR. IPNext is obtained in a way similar to 845 the case of an NSLP-unaware GaNAT. 847 2. If, after X processing, a message is to be forwarded on the 848 downstream link, GIMPS performs the following processing (note 849 that no MRITS processing takes place in this case). 851 1. [IP header].SourceIPAddress <- IPGaNATds 853 2. [IP header].DestinationIPAddress <- IPNext 855 3. NLI.IA <- IPGaNATds 857 4. S <- true, where IPGaNATds is the GaNATs IP address for the 858 downstream link, IPNext is the IP address of the DR (or the 859 next GaNAT in the downstream direction). The GaNAT is 860 assumed to determine the correct IPNext in a way similar to 861 the case of an NSLP-unaware GaNAT. 863 3. When X asks for a message to be sent towards the upstream X peer, 864 the MRITS does the following. 866 1. MRI.SourceIPAddress <- IPflow 868 2. MRI.Destination_IP_Address <- IPGaNATus 870 4. Additionally, GIMPS performs the following on the resulting 871 packet before it is forwarded on the downstream link. 873 1. [IP header].SourceIPAddress <- IPGaNATus 875 2. [IP header].DestinationIPAddress <- IPpeer 877 3. NLI.IA <- IPGaNATus 879 4. S <- true, where IPGaNATus is the GaNATs IP address for the 880 upstream link, IPpeer is the IP_address of the NI (or the 881 next GaNAT in the upstream direction), and IPflow is the IP 882 address of the DS. The GaNAT is assumed to determine the 883 correct IPGaNATus and IPpeer fields from previous 884 communications and in cooperation with GIMPS. [question: how 885 exactly should IPGaNATus and IPpeer be resolved; i.e. what 886 exactly should the GaNAT remember]? 888 5.3 Combination of NSLP-aware and NSLP-unaware GaNATs 890 In the absence of an adversary, a combination of NSLP-aware and NSLP- 891 unaware GaNATs should work without further specification. However, 892 in the presence of an adversary, additional security issues may arise 893 from the combination. These issues may introduce opportunities for 894 attack that do not exist in setting where the on-path GaNATs are 895 either all X-aware or all X-unaware. 897 6. GaNATs in the presence of TLS or IPSec 899 This section discusses GaNAT traversal for GIMPS in the case where 900 two peers that run a particular NSLP, say NSLP X, require 901 cryptographic protection of the signalling traffic they exchange. As 902 with the case where no cryptographic protection of signalling traffic 903 is required, the case of the in-between GaNAT(s) being X-unaware is 904 different from the case of them being X-aware. 906 6.1 NSLP-unaware GaNATs 908 If the two X peers require a C-mode protocol stack that indicates 909 cryptographic protection, then, after the stack has been agreed by 910 both peers and the underlying cryptographic protection is applied to 911 messages, the GaNAT will be unable to translate the GIMPS header 912 fields, in a way similar to the way described in Section 5.1.1. An 913 approach to cope with this, is to inform the X peers about the 914 presence of the NAT during discovery. This information will enable 915 the X peers, rather than the GaNAT(s) to perform the translation of 916 the fields involved, after the necessary cryptographic operations 917 have been completed. In this scenario, the burden imposed on the 918 GaNAT is considerably less, as the only type of GIMPS messages that 919 it needs to process in a special way, are the GIMPS QUERY and GIMPS 920 RESPONSE messages. 922 In order to support the scenario of X-unaware GaNATs, a new GIMPS 923 payload type has to be defined that encodes the aforementioned 924 information. We call this payload type the "NAT Traversal Object" 925 (NTO). The NTO is an optional payload in the GIMPS header of a GIMPS 926 QUERY, and is added, and processed, by the GaNAT(s) through which the 927 QUERY traverses. The information in the NTO must enable the two X 928 peers to locally translate the MRI in the same way as it would have 929 been translated by the in-between GaNAT(s) if no cryptographic 930 protection was applied to the signalling traffic. Note that there 931 may be more than one GaNAT between the two X peers. We now describe 932 the algorithm that an X-unaware GaNAT must execute in order to enable 933 the two X peers to reach this goal. 935 The two types of GaNATs, namely those at the NSIS initiator (NI) 936 side, and those at the NSIS responder (NR) side, follow different 937 algorithms. 939 6.1.1 NI-side NSLP-unaware GaNATs 941 For every arriving IP packet P, an X-unaware, NI-side GaNAT executes 942 the following algorithm. 944 1. If P has a RAO followed by the GIMPS header with an NSLP ID that 945 is not supported, it is identified as a GIMPS QUERY. In this 946 case the GaNAT does the following. 948 1. We denote P as GQ. The GaNAT looks at the stack proposal ST 949 in GQ. If it does not indicate that cryptographic protection 950 is required, the algorithm that is executed is the one 951 described in Section 5.1.1 above. 953 2. The GaNAT remembers GQ along with the link on which it 954 arrived. We call this link the "upstream" link. 956 3. The GaNAT searches its table of existing NAT bindings against 957 entries that match the GQ.MRI. A matching entry means that 958 the data flow, to which the signalling refers, already 959 exists. 961 + If a matching entry is found, the GaNAT looks at which 962 link the packets of the data flow are forwarded; we call 963 this link the "downstream" link. Further, the GaNAT 964 checks how the headers of the data flow (IP addresses, 965 source port number, etc) are translated according to this 966 NAT binding. 968 + If no matching entry is found, the GaNAT determines, based 969 on its routing table, the link on which packets that match 970 GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be 971 forwarded. We call this link the "downstream" link. 972 Then, the GaNAT acquires an IP address for itself on the 973 downstream link. (This address could be dynamic or 974 static.) 976 4. We denote [IP header].SourceIPAddress used on the downstream 977 link as IPGaNATds, and the source port number for the data 978 and signalling traffic as SPNDTGaNATds and SPNSTGaNATds 979 respectively. 981 5. It creates a new GIMPS QUERY packet GQ', as follows (note 982 that the new packet contains the same MRI as GQ). 984 1. GQ' <- GQ 986 2. GQ'.[IP header].SourceIPAddress <- IPGaNATds. 988 3. GQ'.[UDP].SourcePort <- SPNSTGaNATds. 990 4. GQ'.S <- true 991 5. It checks whether or not a NTO is included in the GQ. 993 - If none is included, it adds a new one to GQ' such 994 that GQ'.NTO=[ IPGaNATds || SPNDTGaNATds] 996 - If one is included, it replaces it as GQ'.NTO=[ 997 IPGaNATds || SPNDTGaNATds] 999 6. It remembers GQ, GQ' the fact that they are associated, 1000 and the associated upstream and downstream links. 1002 7. It forwards GQ' on the downstream link. 1004 2. Otherwise, if P carries a [IP header].DestinationIPAddress that 1005 belongs to the GaNAT, and if it is identified as a GIMPS response 1006 in D-mode with an NSLP ID that is not supported, the GaNAT does 1007 the following (P is denoted as GR). 1009 1. It searches for a matching GQ' in its buffer. A GQ' is said 1010 to be matching if it carries the same cookie value. If none 1011 is found, GR is discarded. Otherwise, the GaNAT should also 1012 make sure that the session ID in GR is the same as in GQ' and 1013 that the NSLP IDs match. If these consistency checks fail, 1014 GR should be discarded. Otherwise, the GaNAT constructs a 1015 new GIMPS response GR', as follows (note that no changes are 1016 made to the MRI). 1018 1. GR' <- GR 1020 2. GR'.[IP header].SourceIPAddress <- IPGaNATus, where 1021 IPGaNATus = GQ.[IP header].DestinationIPAddress. 1023 3. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA 1025 4. GP'.S <- true. 1027 5. It checks whether or not a NTO is included in the GQ. 1029 - If none is included, it adds a new one to GQ' such 1030 that GQ'.NTO=[ IPGaNATus || PNGaNATus] 1032 - If one is included, it replaces it such that GQ'.NTO=[ 1033 IPGaNATus || PNGaNATus] 1035 6. It remembers GQ, GQ' the fact that they are associated, 1036 and the associated upstream and downstream links. 1038 7. It forwards GQ' on the downstream link. 1040 2. It forwards GR' on the upstream link. 1042 3. If no NAT binding for the data traffic was found in step 1043 1.3.2, the GaNAT now installs a NAT binding (for the 1044 unidirectional data traffic) which says that "a packet K that 1045 arrives on the upstream link and for which it holds that 1047 + K.[IP 1048 header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, 1050 + K.[IP header].Protocol=GQ.MRI.Protocol, and 1052 + K.[TCP/UDP header].PortNumbers=GQ.MRI.PortNumbers 1054 should be forwarded on the upstream link, with [IP 1055 header].SourceIPAddress = IPGaNATus. 1057 Issues: there is a question of whether this NAT binding 1058 should also enable data traffic in the opposite direction to 1059 traverse the NAT; in order to be able to demultiplex upstream 1060 traffic that carries data that belongs to different flows, 1061 the GaNAT should keep the necessary per-flow state. From a 1062 signalling point of view, however, upstream data traffic that 1063 corresponds (on the application level) to the downstream flow 1064 to which this GIMPS session refers, is a separate flow for 1065 which, dependent on the application, there may or there may 1066 not exist a signalling session. If such a signalling session 1067 exists, then the GaNAT acts as an NR-side GaNAT for this 1068 session. Thus, during the processing of this signalling care 1069 has to be taken not to establish a NAT binding for a flow for 1070 which a NAT binding already exists. Finally, security issues 1071 arise when traffic, for which no signalling exists, is 1072 allowed to traverse a GaNAT. 1074 3. Otherwise, if P carries a [IP header].DestinationIPAddress that 1075 belongs to the GaNAT, and if it is identified as a GIMPS CONFIRM 1076 in D-mode with an NSLP ID that is not supported, the GaNAT does 1077 the following (P is denoted as GC). 1079 1. It creates a new GIMPS CONFIRM packet GC', as follows (note 1080 that the variables below refer to the variables that were 1081 used in the translation of the GIMPS QUERY that corresponds 1082 to GC. 1084 1. GC' <- GC 1085 2. GC'.[IP header].SourceIPAddress <- IPGaNATds. 1087 3. GC'.NLI.IA <- IPGaNATds 1089 4. GC'.S <- true 1091 5. It checks whether or not a NTO is included in the GC. 1093 - If none is included, it adds a new one to GC' such 1094 that GC'.NTO=[ IPGaNATds || SPNDTGaNATds] 1096 - If one is included, it replaces it as GC'.NTO=[ 1097 IPGaNATds || SPNDTGaNATds] 1099 6. It forwards GC' on the downstream link. 1101 4. Otherwise, if P matches an existing NAT binding, normal NAT 1102 processing is applied. 1104 5. Otherwise, P is silently discarded. 1106 6.1.2 NR-side NSLP-unaware GaNATs 1108 As is the case with NR-side NSLP-unaware GaNATs without security, an 1109 NR-side NSLP-unaware GaNAT must know a "pending" IP address, as 1110 described in Section 5.1.2. This IP address is denoted as IPNext. 1112 For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT 1113 executes the following algorithm. 1115 1. If P has a RAO followed by the GIMPS header with an unsupported 1116 NSLPID, it is identified as a GIMPS QUERY. In this case the 1117 GaNAT does the following. 1119 1. We denote P as GQ. The GaNAT looks at the stack proposal ST 1120 in GQ. If it indicates that no cryptographic protection is 1121 required, the algorithm that is executed is the one described 1122 in Section 5.1.2 above. 1124 2. The GaNAT remembers GQ along with the link on which it 1125 arrived. We call this link the "upstream" link. 1127 3. The GaNAT determines whether or not this GIMPS QUERY is 1128 anticipated, i.e. if a pending IPNext exists. If no IPNext 1129 is pending, GQ is discarded (it is a question whether or not 1130 an error message should be sent). Otherwise, additional 1131 checks may be performed (e.g. a DSInfo object may have to be 1132 checked against the GQ). If these checks fail, GQ is 1133 discarded. Otherwise, the GaNAT performs the following. 1135 4. It searches its table of existing NAT bindings against 1136 entries that match the GQ.MRI. A matching entry means that 1137 the data flow, to which the signalling refers, already 1138 exists. 1140 + If a matching entry is found, the GaNAT looks at which 1141 link the packets of the data flow are forwarded; we call 1142 this link the "downstream" link. Further, the GaNAT 1143 checks how the headers of the data flow (IP addresses, 1144 port numbers, etc) are translated according to this NAT 1145 binding. We denote [IP header].SourceIPAddress used on 1146 the downstream link as IPGaNATds, and the port numbers as 1147 PNGaNATds. Note that the [IP header].DestinationIPAddress 1148 of this NAT binding should be equal to IPNext. If it is 1149 not, this should be handled as an auditive error 1150 condition. (This check is done as a consistency check.) 1152 + If no matching entry is found, the GaNAT determines, based 1153 on its routing table, the link on which packets that match 1154 GQ.MRI (excluding GQ.MRI.SourceIPAddress and where 1155 GQ.MRI.DestinationIPAddress is replaced with IPNext) would 1156 be forwarded. We call this link the "downstream" link. 1157 Then, the GaNAT acquires an IP address for itself on the 1158 downstream link. (This address could be dynamic or 1159 static.) Depending on its type, the GaNAT may also 1160 acquire (UDP) port numbers for the translation of GQ. We 1161 denote the acquired IP address as IPGaNATds and the 1162 associated port numbers as PNGaNATds. 1164 5. It creates a new GIMPS QUERY packet GQ', as follows (note 1165 that the new packet contains the same MRI as GQ). 1167 1. GQ' <- GQ 1169 2. GQ'.[IP header].SourceIPAddress <- IPGaNATds. 1171 3. GQ'.S <- true 1173 4. It checks whether or not a NTO is included in the GQ. 1175 - If none is included, it adds a new one to GQ' such 1176 that GQ'.NTO=[ IPGaNATds || SPNDTGaNATds] 1178 - If one is included, it replaces it as GQ'.NTO=[ 1179 IPGaNATds || SPNDTGaNATds] 1181 5. It remembers GQ, GQ' the fact that they are associated, 1182 and the associated upstream and downstream links. 1184 6. It forwards GQ' on the downstream link. 1186 The remaining steps of the algorithm are analogous to the algorithm 1187 of NSLP-unaware, NI-side GaNATs, which was described in the previous 1188 section. 1190 6.1.3 Additional GIMPS peer processing 1192 In the presence of GaNATs on the signalling path between two NSLP 1193 peers, and if cryptographic protection of the signalling traffic 1194 between these two peers is required, the translation of the GIMPS 1195 header fields that need to be translated for consistency, must be 1196 carried out by the X peers. The GIMPS processing that performs this 1197 task, is described next. Note that this processing is in addition to 1198 the processing described in [1] and that we assume that the in- 1199 between GaNATs adopt the behaviour described in the two preceding 1200 sections. 1202 A GIMPS peer that receives a GIMPS packet that carries (a) an NSLPID 1203 for a supported NSLP, and (b) an NTO in its header, executes the 1204 following algorithm, before the processing described in [1] takes 1205 place. 1207 1. If the packet is a GIMPS QUERY or CONFIRM in D-mode, denoted G, 1208 the peer constructs a new packet, denoted G', as follows. 1210 1. G' <- G 1212 2. G'.MRI.Source_IP_Address <- G.NTO.IPGaNATds 1214 3. G'.MRI.SourcePort <- G.NTO.SPNDTGaNATds 1216 4. G'.NLI.IA <- G.NTO.IPGaNATds 1218 5. G'.NTO is removed. 1220 and forwards G' to GIMPS for further processing. If G is a GIMPS 1221 QUERY and local policy demands the installation of state without 1222 the reception of a GIMPS CONFIRM message, then the peer must 1223 store the NTO carried by G together with the routing state 1224 information about the sending GIMPS peer. If G is a GIMPS 1225 CONFIRM and local policy demands the installation of state only 1226 after reception of a valid CONFIRM, then the peer stores, after 1227 validating the cookie in the CONFIRM, the NTO carried by G 1228 together with the routing state information about the sending 1229 GIMPS peer. 1231 2. Otherwise, if the packet is a GIMPS RESPONSE in D-mode, denoted 1232 GR, the peer constructs a new packet, denoted GR', as follows. 1234 1. GR' <- G 1236 2. GR'.MRI.Source_IP_Address <- GR.NTO.IPGaNATus 1238 3. GR'.MRI.SourcePort <- GR.NTO.PNGaNATus 1240 4. GR'.NLI.IA <- GR.NTO.IPGaNATus 1242 5. GR'.NTO is removed. 1244 and forwards GR' to GIMPS for further processing. If the cookie 1245 in GR' is verified sucessfully, the peer stores the NTO carried 1246 by GR together with the routing state information about the 1247 sending GIMPS peer. 1249 A peer that receives a GIMPS packet P (in this case, the packet will 1250 be a cryptographically protected GIMPS packet) the peer does the 1251 following substitutions after the cryptographic processing is 1252 (successfully) completed and before the processing described in [1] 1253 takes place. 1255 1. P.MRI.SourceIPAddress <- P.NTO.IPGaNATds 1257 2. P.MRI.SourcePort <- P.NTO.SPNDTGaNATds 1259 3. P.NLI.IA <- P.NTO.IPGaNATds 1261 4. P.NTO is removed. 1263 A peer that intends to send a GIMPS packet (in this case, 1264 cryptographic protection will be required for the packet), the peer 1265 does the following after the processing described in [1] and before 1266 the packet is passed to the process that applies the cryptographic 1267 protection. Note that the NTO refers to the NTO that is stored 1268 together with the routing state information of the peer that is to 1269 receive the packet. 1271 1. P.MRI.Source_IP_Address <- NTO.IPGaNATds 1273 2. P.MRI.SourcePort <- NTO.PNGaNATds 1275 3. P.NLI.IA <- NTO.IPGaNATds 1277 6.2 NSLP-aware GaNATs 1279 The cryptographic protection applies to of signalling messages 1280 terminates at NSLP-aware GaNATs. The processing performed by such 1281 GaNATs is therefore identical to the processing described in 1282 Section 5.2, with the exception that the GaNATs additionally perform 1283 cryptographic operations. In this case, there is no requirement for 1284 the NSLP to perform any translation for the purposes of NAT 1285 traversal. 1287 7. NSIS-unaware NATs 1289 The following may serve as indications for the existence of an NSIS- 1290 unaware NAT between two GIMPS peers. These indications can only be 1291 detected by the receiver of a GIMPS message. The first occasion 1292 these indications may be detected is with the reception of a GIMPS 1293 QUERY, typically by the downstream peer. (Note that != denotes 1294 inequality). 1296 o The MRI.SourceIPAddress does not belong to the addressing space of 1297 the receiving peer. 1299 o The MRI.DestinationIPAddress does not belong to the addressing 1300 space of the receiving peer. 1302 o The IP address in the NLI.IA object does not belong to the 1303 addressing space of the receiving peer. 1305 o The D flag of a received GIMPS packet denotes downstream direction 1306 and the S flag is not set and [IP header].SourceIPAddress != 1307 MRI.SourceIPAddress. 1309 o The D flag of a received GIMPS packet denotes upstream direction 1310 and the S flag is not set and [IP header].SourceIPAddress != 1311 MRI.DestinationIPAddress. 1313 o This is a GIMPS QUERY and [IP header].DestinationIPAddress != 1314 MRI.DestinationIPAddress. 1316 Note that these are only indications. In the presence of an 1317 adversary, a GIMPS peer may be tricked into believing that an NSIS- 1318 unaware NAT exists between itself and one of its neighbouring peers, 1319 while in reality this may not be the case. 1321 When a downstream GIMPS peer detects such an indication, it may 1322 notify the upstream peer about the error. It may include additional 1323 information that enables the upstream peer to construct a GIMPS 1324 packet in such a way that, after it traverses the NSIS-unaware NAT, 1325 the IP addresses in the MRI field and the NLI.IA object are 1326 consistent with those in the IP header (which match the addressing 1327 space of the receiving peer). However, this requires the 1328 specification of new data structures and formats, processing rules, 1329 and requires the peers to maintain additional state. 1331 Unfortunately, this approach is likely to fail in many circumstances. 1332 In order to see this, consider the behaviour of an NSIS-unaware NAT 1333 when it receives an IP packet. The packet either 1334 1. matches an existing NAT binding in which case its IP header is 1335 translated and the packet it is forwarded on another link, or 1337 2. matches an existing policy rule which causes a new binding to be 1338 established and then (1) happens, or 1340 3. is discarded because neither (1) nor (2) applies. 1342 With NSIS-unaware NATs it is a matter of local policy (i.e. the rules 1343 that exist in case (2) above) whether or not traffic will be allowed 1344 to traverse the NAT. This obviously applies to both signalling and 1345 data traffic, as an NSIS-unaware NAT is unable to distinguish the two 1346 types of traffic. It may be the case that GIMPS node A is unable to 1347 contact GIMPS node B which is "behind" a NAT, even if communication 1348 in from B to A may be possible because such communication would match 1349 a policy rule; typically, in a scenarios where A is towards the NI 1350 and B is towards the NR, the NAT would have this behaviour. 1352 Another approach to deal with NSIS-unaware NATs is similar to the NAT 1353 traversal approach taken by IKEv2, i.e. by encapsulating GIMPS 1354 messages into UDP datagrams, rather than directly into IP datagrams. 1355 This technique requires the inclusion of additional fields into a 1356 GIMPS QUERY, as follows. The sender adds (a hash of) its own IP 1357 address and the IP address of what it believes to be the DR into the 1358 GIMPS payload. The receiver of this GIMPS messages compares these 1359 addresses to the [IP header].SourceIPAddress and the [IP 1360 header].DestinationIPAddress respectively. If at least one of them 1361 is unequal, the receiver deduces that a NAT is between sender and 1362 receiver. After the detection of a NAT, the remainder of the 1363 communication is encapsulated into UDP datagrams that are addressed 1364 to a specified port. 1366 Unfortunately, the IKEv2 NAT traversal mechanism cannot be used "as 1367 is" for NAT traversal in GIMPS. This is because of a number of 1368 reasons, including the following. 1370 o The NAT may use an IP address for the forwarding of data traffic 1371 that is different from the IP address it uses to forward GIMPS 1372 traffic. Since the NAT is NSIS-unaware it cannot update the MRI 1373 in the GIMPS messages such that it matches the translation applies 1374 to the data traffic. Moreover, neither the GIMPS sending, nor the 1375 GIMPS receiving peer can perform this update; the sending peer 1376 cannot predict the translation that the NAT will apply, and the 1377 receiving peer does not have enough information to associate data 1378 flows to signalling messages. 1380 o It is unclear whether or not the IKEv2 NAT traversal mechanism 1381 supports cascades of NATs. 1383 o It seems to be inappropriate to use UDP encapsulation for certain 1384 C-mode scenarios. For example, using UDP encapsulation for TCP 1385 C-mode would result in GIMPS to appear in TCP over UDP over IP. 1387 8. Security Considerations 1389 The mechanisms proposed in this document give rise to a number of 1390 threats that must be considered. In the following, a subset of these 1391 threats is mentioned. 1393 8.1 Service Denial Attacks 1395 As described in Section 5.1 and Section 6.1, NSLP-unaware GaNATs 1396 create some state whenever they receive a GIMPS QUERY message. This 1397 state is necessary in order for the GaNAT to be able to map a GIMPS 1398 RESPONSE that arrives from the downstream direction to the 1399 corresponding GIMPS QUERY and thereby to perform the required 1400 translation. 1402 The threat here is an attacker flooding the GaNAT with maliciously 1403 constructed GIMPS QUERIES with the aim of exhausting the GaNAT's 1404 memory. The attacker might use a variety of methods to construct 1405 such GIMPS QUERIES, including the following. 1407 1. Use as [IP header].SourceIPAddress the address of some other node 1408 or an unallocated IP address. This method is also known as IP 1409 spoofing. 1411 2. Use an invalid NSLPID, in order to make sure that all on-path 1412 GaNAT(s) will behave like NSLP-unaware GaNATs. 1414 3. For each packet, use a different value for the cookie field. 1416 4. For each packet, use a different value for the session ID field. 1418 5. Combinations of the above. 1420 How vulnerable a GaNAT is to the above service denial attack depends 1421 on a variaty of factors, including the following. 1423 o The amount of state allocated at the receipt of a GIMPS QUERY. 1424 This amount may vary depending on whether or not the data flow to 1425 which the signalling refers, already exists (i.e. whether or not 1426 the GaNAT already maintains a NAT binding for it). 1428 o The mechanism that the GaNAT uses to map RESPONSEs to QUERIEs. 1430 o Whether or not the GaNAT acriques dynamic IP addresses and ports 1431 for the downstream link. 1433 In order to decrease the exposure of a GaNAT to service denial 1434 attacks, the following recommendations are made. 1436 o The GaNAT should perform ingress filtering. This limits the 1437 amount of locations from which an attacker can perform IP spoofing 1438 without being detected. 1440 o The GaNAT should allocate the minimum amount of state required at 1441 the reception of a GIMPS QUERY. 1443 o All state allocated by the GaNAT should timeout according to a 1444 local policy. If the GaNAT detects heavy loads (which may 1445 indicate a service denial attack in progress), the GaNAT should 1446 timeout the state allocated as a result of a received GIMPS QUERY 1447 quicker, proportionally to the experienced load. 1449 o The installation of a NAT binding for the data traffic (if such a 1450 binding does not exist prior to signalling) should be postponed 1451 until the correct GIMPS REPONSE traverses the NAT. 1453 The service denial threats mentioned in this section do not apply to 1454 an NSLP-aware GaNAT, as such a GaNAT is required, in accordance with 1455 its local policy, to verify the validity of the cookie(s) before 1456 allocating any state, including the state required by the mechanisms 1457 in this document. 1459 8.2 Network Intrusions 1461 Although the primary goal of a NAT is to perform address translation 1462 between two addressing spaces, NATs are sometimes also used to 1463 provide a security service similar to the security service provided 1464 by firewalls. That is, a NAT can be configured so that it does not 1465 forward packets from the external into the internal network, unless 1466 it determines that the packets belong to a communication session that 1467 was originally initiated from an internal node and are, as such, 1468 solicited. 1470 If an NSLP-unaware GaNAT performs the above security-relevant 1471 function in addition to address translation, then the presence of 1472 GIMPS signalling and, in particular the mechanisms described in this 1473 document, might allow an adversary cause the installation of NAT 1474 bindings in the GaNAT using these mechansisms. These NAT bindings 1475 would then enable the adversary to inject unsolicited traffic into 1476 the internal network, a capability that it may not have in the 1477 absence of the mechanisms described in this document. 1479 The administrator of an NSLP-unaware GaNAT should therefore make 1480 security-concious decisions regarding the operation of the GaNAT. An 1481 NSLP-aware GaNAT, on the other hand, follows an NSLP policy which 1482 indicates the required security mechanisms. This policy should 1483 account for the fact that this NSLP-aware node performs also NAT and 1484 the associated packet filtering. 1486 9. Acknowledgments 1488 The authors would like to thank Robert Hancock, Cedric Aoun and 1489 Martin Stiemerling for their feedback. Furthermore, we would like to 1490 mention that this document builds on top of a previous document 1491 regarding migration scenarios. 1493 10. IAB Considerations 1495 [Editor's Note: A future version of this document will provide 1496 information regarding IAB considerations. 1498 11. IANA Considerations 1500 This document does not require actions by the IANA. 1502 12. Normative References 1504 [1] Schulzrinne, H. and R. Handcock, "GIMPS: General Internet 1505 Messaging Protocol for Signalling", draft-ietf-nsis-ntlp-06 1506 (work in progress), May 2005. 1508 [2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS 1509 Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 1510 (work in progress), May 2005. 1512 Authors' Addresses 1514 Andreas Pashalidis 1515 Siemens 1516 Otto-Hahn-Ring 6 1517 Munich, Bavaria 81739 1518 Germany 1520 Email: Andreas.Pashalidis@siemens.com 1522 Hannes Tschofenig 1523 Siemens 1524 Otto-Hahn-Ring 6 1525 Munich, Bavaria 81739 1526 Germany 1528 Email: Hannes.Tschofenig@siemens.com 1530 Intellectual Property Statement 1532 The IETF takes no position regarding the validity or scope of any 1533 Intellectual Property Rights or other rights that might be claimed to 1534 pertain to the implementation or use of the technology described in 1535 this document or the extent to which any license under such rights 1536 might or might not be available; nor does it represent that it has 1537 made any independent effort to identify any such rights. Information 1538 on the procedures with respect to rights in RFC documents can be 1539 found in BCP 78 and BCP 79. 1541 Copies of IPR disclosures made to the IETF Secretariat and any 1542 assurances of licenses to be made available, or the result of an 1543 attempt made to obtain a general license or permission for the use of 1544 such proprietary rights by implementers or users of this 1545 specification can be obtained from the IETF on-line IPR repository at 1546 http://www.ietf.org/ipr. 1548 The IETF invites any interested party to bring to its attention any 1549 copyrights, patents or patent applications, or other proprietary 1550 rights that may cover technology that may be required to implement 1551 this standard. Please address the information to the IETF at 1552 ietf-ipr@ietf.org. 1554 Disclaimer of Validity 1556 This document and the information contained herein are provided on an 1557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1559 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1560 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1561 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1564 Copyright Statement 1566 Copyright (C) The Internet Society (2005). This document is subject 1567 to the rights, licenses and restrictions contained in BCP 78, and 1568 except as set forth therein, the authors retain all their rights. 1570 Acknowledgment 1572 Funding for the RFC Editor function is currently provided by the 1573 Internet Society.