idnits 2.17.00 (12 Aug 2021) /tmp/idnits39354/draft-fessi-nsis-natfw-threats-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 933. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 949), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of lines with control characters 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 209: '... middlebox MUST authenticate and aut...' RFC 2119 keyword, line 211: '... the initiator SHOULD be provided to...' RFC 2119 keyword, line 239: '...T: The middlebox MUST authenticate and...' RFC 2119 keyword, line 242: '... this scenario) MAY be provided to th...' RFC 2119 keyword, line 260: '... According to [1] (Section 3.3) "Policy rules at middleboxes MUST be...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [5], but that reference does not seem to mention RFC 2119 either. -- 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 16, 2004) is 6518 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) == Unused Reference: '7' is defined on line 857, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 863, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 868, but no explicit reference was found in the text == 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. '1') == Outdated reference: draft-ietf-nsis-threats has been published as RFC 4081 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-threats (ref. '2') -- No information found for draft-draft-ietf-nsis-ntlp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-ietf-nsis-requirements - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-02) exists of draft-aoun-nsis-nslp-natfw-migration-01 == Outdated reference: A later version (-01) exists of draft-manyfolks-signaling-protocol-mobility-00 == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS A. Fessi 3 Internet-Draft M. Stiemerling 4 Expires: January 14, 2005 NEC 5 S. Thiruvengadam 6 H. Tschofenig 7 Siemens 8 C. Aoun 9 Nortel Networks 10 July 16, 2004 12 Security Threats for the NATFW NSLP 13 draft-fessi-nsis-natfw-threats-01 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 14, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 Opening a firewall pinhole or creating a NAT binding is a very 49 security sensitive issue. This memo identifies security threats and 50 security requirements that need to be addressed for the NATFW NSLP. 51 Generic security threats to the NSIS protocols have been already 52 discussed in the NSIS Working Group. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Attacks related to authentication and authorization . . . . . 4 61 3.1 Data Sender (DS) behind a firewall . . . . . . . . . . . . 6 62 3.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . . . 7 63 3.3 Data Receiver (DR) behind a firewall . . . . . . . . . . . 7 64 3.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . . . 9 66 4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . 11 67 4.1 Flooding with CREATE messages from outside . . . . . . . . 11 68 4.1.1 Attacks due to NSLP state . . . . . . . . . . . . . . 11 69 4.1.2 Attacks due to authentication complexity . . . . . . . 11 70 4.1.3 Attacks to the endpoints . . . . . . . . . . . . . . . 11 71 4.1.4 Attacks to the NTLP . . . . . . . . . . . . . . . . . 12 72 4.2 Flooding with REA messages from inside . . . . . . . . . . 12 74 5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 12 76 6. Message Modification . . . . . . . . . . . . . . . . . . . . . 13 78 7. Session Modification/Deletion . . . . . . . . . . . . . . . . 14 80 8. Misuse of unreleased sessions . . . . . . . . . . . . . . . . 15 82 9. Data traffic injection . . . . . . . . . . . . . . . . . . . . 17 84 10. Misuse of mobility in NAT handling . . . . . . . . . . . . . 18 86 11. Eavesdropping and traffic analysis . . . . . . . . . . . . . 20 88 12. Security Considerations . . . . . . . . . . . . . . . . . . 21 90 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 94 14.2 Informative References . . . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 97 Intellectual Property and Copyright Statements . . . . . . . . 24 99 1. Introduction 101 This document provides an analysis of the security threats that are 102 specific for the NATFW NSLP. The NATFW NSLP is used to install the 103 required policy rules (firewall pinhole and/or NAT binding) on 104 middleboxes along the path to allow the traversal of a data flow. 106 Opening a pinhole in the firewall or creating a NAT binding is a very 107 security sensitive issue. Thus, we need to examine carefully who is 108 allowed to install these policy rules and what security threats need 109 to be addressed. In this document we will analyze different types of 110 possible attacks to networks running NSIS for middlebox 111 configuration. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [5]. 119 Furthermore, we use the same terminology as in [1], [3] and [4]. 121 3. Attacks related to authentication and authorization 123 As described in [1] the NSIS message which installs policy rules at a 124 middlebox is the CREATE message. The CREATE message travels from the 125 Data Sender (DS) toward the Data Receiver (DR). The packet filter or 126 NAT binding is marked as pending by the middleboxes along the path. 127 If it is confirmed with a success RESPONSE message from the DR the 128 requested policy rules on the middleboxes are installed to allow the 129 traversal of a data flow. 131 +-----+ +-----+ +-----+ 132 | DS | | MB | | DR | 133 +-----+ +-----+ +-----+ 134 | | | 135 | CREATE | CREATE | 136 |-------------------->+-------------------->| 137 | | | 138 | Succeeded/Error | Succeeded/Error | 139 |<--------------------+<--------------------| 140 | | | 141 ==========================================> 142 Direction of data traffic 144 Figure 1: CREATE Mode 146 In this section we will consider some simple scenarios for middlebox 147 configuration: 148 o Data Sender (DS) behind a firewall 149 o Data Sender (DS) behind a NAT 150 o Data Receiver (DR) behind a firewall 151 o Data Receiver (DR) behind a NAT 153 A real scenario could include a combination of one or more cases 154 together, i.e., DS and/or DR is behind a chain of NATs and firewalls. 155 Figure 2 shows such a possible scenario: 157 +-------------------+ +--------------------+ 158 | | | | 159 | Network A | | Network B | 160 | | | | 161 | +-----+ | //-----\\ | +-----+ | 162 | | MB2 |--------+----| INET |----+--------| MB3 | | 163 | +-----+ | \\-----// | +-----+ | 164 | | | | | | 165 | +-----+ | | +-----+ | 166 | | MB1 | | | | MB4 | | 167 | +-----+ | | +-----+ | 168 | | | | | | 169 | +-----+ | | +-----+ | 170 | | DS | | | | DR | | 171 | +-----+ | | +-----+ | 172 | | | | 173 +-------------------+ +--------------------+ 175 MB: Middle box (NAT or Firewall or a combination) 176 DS: Data Sender 177 DR: Data Receiver 179 Figure 2: Several middleboxes per network 181 3.1 Data Sender (DS) behind a firewall 183 +------------------------------+ 184 | | 185 | +-----+ create +-----+ 186 | | DS | --------------> | FW | 187 | +-----+ +-----+ 188 | | 189 +------------------------------+ 191 Figure 3: DS behind a firewall 193 DS sends a CREATE message to request the traversal of a data flow. 195 It is up to network operators to decide how far they can trust users 196 inside their networks. However, there are several reasons why they 197 should not. 199 The following attacks are possible: 200 o DS could open a firewall pinhole with a source address different 201 from its own host. 202 o DS could open firewall pinholes for incoming data flows that are 203 not supposed to enter the network. 205 o DS could request installation of any policy rules and allow all 206 traffic go through. 208 SECURITY REQUIREMENT: As already mentioned in [1] Section (3.2), the 209 middlebox MUST authenticate and authorize the neighboring NAT/FW NSLP 210 node which requests an action. Authentication and authorization of 211 the initiator SHOULD be provided to NATs and Firewalls along the path 212 as motivated with Section 2.2.3 of [1]. 214 3.2 Data Sender (DS) behind a NAT 216 The case 'DS behind a NAT' is analogous to the case 'DS behind a 217 firewall'. 219 It is worth mentioning that authentication based on IP address is not 220 possible if NATs are deployed. Figure 4 illustrates such a scenario: 222 +------------------------------+ 223 | | 224 | +------+ CREATE | 225 | | NI_1 | ------\ +-----+ CREATE +-----+ 226 | +------+ \------> | NAT |-------->| MB | 227 | +-----+ +-----+ 228 | +------+ | 229 | | NI_2 | | 230 | +------+ | 231 +------------------------------+ 233 Figure 4: Several NIs behind a NAT 235 In this case the middlebox MB does not know who is the NSIS Initiator 236 since both NI_1 and NI_2 are behind a NAT. Authentication needs to 237 be provided by other means such as the NSLP or the application layer. 239 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that 240 the neighboring NAT/FW NSLP node is authorized to request an action. 241 Authentication and authorization of the initiator (which is the DR in 242 this scenario) MAY be provided to the middleboxes. 244 3.3 Data Receiver (DR) behind a firewall 246 In this case a CREATE message comes from an entity DS outside the 247 network towards the DR inside the network. 249 +------------------------------+ 250 | | 251 +-----+ CREATE +-----+ CREATE +-----+ | 252 | DS | -------------> | FW | -------------> | DR | | 253 +-----+ <------------- +-----+ <------------- +-----+ | 254 success RESPONSE | success RESPONSE | 255 | | 256 +------------------------------+ 258 Figure 5: DR behind a firewall 260 According to [1] (Section 3.3) "Policy rules at middleboxes MUST be 261 only installed upon receiving a successful response of type success 262 RESPONSE". 264 This means that the middlebox waits until the Data Receiver DR 265 confirms the request of the Data Sender DS with a success RESPONSE 266 message. This is, however, only necessary 267 o if the policy rule creation/deletion/update at a firewall along 268 the path cannot be authorized and 269 o if the middlebox is still forwarding the signaling message towards 270 the end host (without state creation/deletion/modification). 272 This confirmation implies that the data receiver is expecting the 273 data flow. 275 At this point we differentiate 2 cases: 276 1. DR knows the IP address of the DS (for instance because of some 277 previous application layer signaling) and is expecting the data 278 flow. 279 2. DR might be expecting the data flow (for instance because of some 280 previous application layer signaling) but does not know the IP 281 address of the Data Sender DS. 283 For the second case, Figure 6 illustrates a possible attack: an 284 adversary Mallory M could be sniffing the application layer signaling 285 and thus knows the address and port number where DR is expecting the 286 data flow. Thus it could pretend to be DS and send a CREATE message 287 towards DR with the data flow description (M -> DR). Since DR does 288 not know the IP address of DS, it is not able to recognize that the 289 request is coming from the "wrong guy". It will send a success 290 RESPONSE message back and the middlebox will install policy rules 291 that will allow Mallory M to inject its data into the network. 293 Application Layer signaling 294 <------------------------------------> 295 / \ 296 / +-----------------\------------+ 297 / | \ | 298 +-----+ +-----+ +-----+ | 299 | DS | -> | FW | | DR | | 300 +-----+ / +-----+ +-----+ | 301 CREATE / | | 302 +-----+ / +-------------------------------+ 303 | M |---------- 304 +-----+ 306 Figure 6: DR behind a firewall with an adversary 308 Network administrators will probably not rely on a DR to check the IP 309 address of the DS. Thus we have to assume the worst case with an 310 attack such as in Figure 6. Many operators might not allow NSIS 311 signaling message to traverse the firewall in Figure 6 without proper 312 authorization. In this case the threat is not applicable. 314 SECURITY REQUIREMENT: A binding between the application layer and the 315 NSIS signaling SHOULD be provided. 317 3.4 Data Receiver (DR) behind a NAT 319 We will describe briefly the NSIS message flow that takes place to 320 install the necessary rules for the traversal of a data flow from DS 321 towards DR. For detailed description please refer to [1] Section 322 3.3. 324 DR sends a RESERVE-EXTERNAL-ADDRESS (REA) message to get a public 325 reachable address that can be used by potential DSs. The NAT 326 reserves an external address and port number and sends them back to 327 DR. The NAT adds an address mapping entry in its reservation list 328 which links the public and private addresses as follows: 330 (DR_ext <=> DR_int) (*). 332 The NAT sends a RESPONSE message with 'return external address' 333 object back to the DR with the address DR_ext. DR informs DS about 334 the public address that it has recently received, for instance, by 335 means of application layer signaling. 337 Now DS sends the CREATE message towards DR_ext. When the 'create 338 session' message arrives at the NAT, the NAT looks up its reservation 339 list and finds the entry (*). 341 Now the NAT knows the address of DS and stores it as a part of the 342 policy rule to be loaded. It forwards the message towards DR and 343 waits for the confirmation with the success RESPONSE message. 345 At the arrival of the success RESPONSE message from DR, the NAT 346 installs the policy rule to forward the data flow correctly from DS 347 to DR. 349 Possible attack: 351 We assume that the adversary obtains the external address allocated 352 at the NAT (possibly by eavesdropping on the application layer 353 signaling) and triggers the CREATE message before the NAT binding 354 expires. The CREATE message is assumed to travel from DS to DR 355 through NAT. An attacker Mallory M could send a CREATE message to 356 install a NAT binding to forward the data flow from M to DR instead 357 of from DS to DR. This kind of attack is equivalent to the attack 358 described in Section 3.3 above. 360 In order for this attack to work the following pre-requisities need 361 to hold: 362 The adversary needs to be authorized to create a NAT binding at 363 the NAT. 364 The adversary needs to know when a DR creates a NAT binding at the 365 DR. A certain timing is required and some specific information, 366 such as the message routing identifier and session identifier must 367 be known 369 Application Layer signaling 370 <------------------------------------> 371 / \ 372 / +-----------------\------------+ 373 / | REA \ | 374 +-----+ +-----+ <----------- +-----+ | 375 | DS | -> | NAT | -----------> | DR | | 376 +-----+ / +-----+ rtn_ext_addr +-----+ | 377 CREATE / | | 378 +-----+ / +-------------------------------+ 379 | M |---------- 380 +-----+ 382 Figure 7: DR behind a NAT with an adversary 384 SECURITY REQUIREMENT: TBD 386 4. Denial-of-Service Attacks 388 In this section we describe several ways how an adversary could 389 launch a Denial of service (DoS) attack on networks running NSIS for 390 middlebox configuration to exhaust their resources. 392 4.1 Flooding with CREATE messages from outside 394 4.1.1 Attacks due to NSLP state 396 A CREATE message requests the NSLP to store some state information 397 such as Session-ID and flow identifier. 399 The policy rules requested in the CREATE message will be installed at 400 the arrival of a confirmation from the Data Receiver with a success 401 RESPONSE message. The success RESPONSE message includes the session 402 ID. So the NSLP looks up the NSIS session and installs the requested 403 policy rules. 405 An adversary from outside could launch a DoS attack with arbitrary 406 CREATE messages. For each of these messages the middlebox needs to 407 store state information such as the policy rules to be loaded, i.e., 408 the middlebox could run out of memory. This kind of attack is also 409 mentioned in [2] Section 4.8. 411 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 412 'create-session' message before storing state information. 414 4.1.2 Attacks due to authentication complexity 416 This kind of attack is possible if authentication is based on 417 mechanisms that require computing power, for example, digital 418 signatures. 420 For a more detailed treatment of this kind of attack, the reader is 421 encouraged to see [2]. 423 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 424 denial of service attacks based on authentication or key management 425 mechanisms. 427 4.1.3 Attacks to the endpoints 429 The NATFW NSLP requires firewalls to forward NSLP messages, a 430 malicious node may keep sending NSLP messages to a target. This may 431 consume the access network resources of the victim, drain the battery 432 of the victim's terminal and may force the victim to pay for the 433 received although undesired data. 435 This threat may be more particularly be relevant in networks where 436 access link is a limited resource, for instance in cellular networks, 437 and where the terminal capacities are limited. 439 SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able 440 to block unauthorized signaling message, if this threat is a concern. 442 4.1.4 Attacks to the NTLP 444 Flooding a middlebox with CREATE messages affects also the NTLP. 446 The success RESPONSE message needs to take the same route as the 447 previous CREATE message. Thus the NTLP needs to store routing 448 information for each CREATE message. This kind of attack is also 449 described in [2] Section 4.8. 451 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 452 denial of service attacks based on authentication or key management 453 mechanisms. 455 4.2 Flooding with REA messages from inside 457 Although we are more concerned with possible attacks from outside the 458 network, we need also to consider possible attacks from inside the 459 network. 461 An adversary inside the network could send arbitrary 462 RESERVE-EXTERNAL-ADDRESS messages. At a certain point the NAT will 463 run out of port numbers and the access for other users to the outside 464 will be disabled. 466 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 467 creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, the 468 NAT/FW NSLP implementation MUST prevent denial of service attacks 469 involving the allocation of an arbitrary number of NAT bindings or 470 the installation of a large number of packet filters. 472 5. Man-in-the-Middle Attacks 474 Figure 8 illustrates a possible man-in-the-middle attack using the 475 'reserve external address' (REA) message. This message travels from 476 DR towards the public Internet. The message might not be intercepted 477 by any NAT either because there are no NATs or because there are NSIS 478 unaware. 480 Mallory M returns a faked RESPONSE message with an IP address of its 481 choosing. This IP address is meant to be used by the DR as the 482 public external IP address. Malory might insert it own IP address in 483 the response, the IP address of a third party or the address of a 484 black hole. In the first case, the DR thinks that the address of 485 Mallory M is its public address and will inform the DS about it. As 486 a consequence, the DS will send the data traffic to Mallory M. 488 The data traffic from the DS to the DR will re-directed to Mallory M. 489 Mallory M will be able to read, modify or block the data traffic. 490 Eavesdropping and modification is only possible if the data traffic 491 is itself unprotected. 493 +-----+ +-----+ +-----+ +-----+ 494 | DS | | M | | FW | | DR | 495 +-----+ +-----+ +-----+ +-----+ 496 | | | | 497 | | REA | REA | 498 | | <------------------ | <------------ | 499 | | | | 500 | | ret_ext_addr | ret_ext_addr | 501 | | ------------------> | ------------> | 502 | | | | 503 | data traffic | | | 504 |===============>| data traffic | 505 | |===================================> | 507 Figure 8: MITM attack using the RESERVE-EXTERNAL-ADDRESS message 509 Please note that the NSIS aware firewall in Figure 8 might not be 510 present when DR communicates directly with the adversary. 512 SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW 513 NSLP MUST be provided. To ensure that only legitimate nodes along 514 the path act as NSIS entities the initiator MUST authorize the 515 responder. In the example in Figure 8 the firewall FW must perform 516 an authorization with the neighboring entities. 518 6. Message Modification 520 Any on-path subverted node en route to the destination could easily 521 modify, inject or just drop an NSIS message. It could also hijack or 522 disrupt the communication. 524 SECURITY REQUIREMENT: Message integrity, replay protection and data 525 origin authentication between neighboring NAT/FW NSLPs MUST be 526 provided. 528 Message modification by a subverted NSIS node could create arbitrary 529 pinholes or NAT bindigs. For example: 531 o NATs need to modify the source/destination of the data flow in the 532 'create session' message. 533 o Each middlebox along the path may change the requested lifetime in 534 the CREATE message to fit their needs and/or local policy (see 535 also section 3.2.7 of [1] with regard to calculation of refresh 536 interval). 538 SECURITY REQUIREMENT: None. Malicous NSIS NATs and Firewalls will 539 not be addressed. 541 7. Session Modification/Deletion 543 The Session ID is included in signaling messages as a reference to 544 the established state. If an adversary is able to obtain the Session 545 Identifier for example by eavesdropping on signaling messages, it 546 would be able to add the same Session Identifier to a new a signaling 547 message and effect some modifications. 549 Consider the scenario described in Figure 9. Here an adversary 550 pretends to be 'DS in mobility'. The signaling messages start from 551 the DS and go through a series of routers towards the DR. We assume 552 that an off-path adversary is connected to one of the routers along 553 the old path (here Router 3). We also assume that the adversary 554 knows the Session ID of the NSIS session initiated by the DS. 555 Knowing the Session ID, the adversary now sends signalling messages 556 towards the DR. When the signaling message reaches Router3 then 557 existing state information can be modified or even deleted. The 558 adversary can modify or delete the established reservation causing 559 unexpected behavior for the legitimate user. The source of the 560 problem is that the Router 3 (cross-over router) is unable to decide 561 whether the new signaling message was initiated from the owner of the 562 session. In this scenario, the adversary need not even be located in 563 the DS-DR path. This problem and the solution approaches are 564 described in more detail in [6]. 566 Session ID(SID-x) 567 +--------+ +--------+ 568 +-------->--------+ Router +-------->+ DR | 569 Session ID(SID-x)| | 4 | | | 570 +---+----+ +--------+ +--------+ 571 | Router | 572 +------+ 3 +******* 573 | +---+----+ * 574 | * 575 | Session ID(SID-x) * Session ID(SID-x) 576 +---+----+ +---+----+ 577 | Access | | Access | 578 | Router | | Router | 579 | 1 | | 2 | 580 +---+----+ +---+----+ 581 | * 582 | Session ID(SID-x) * Session ID(SID-x) 583 +----+------+ +----+------+ 584 | DS | | Adversary | 585 | | | | 586 +-----------+ +-----------+ 588 Figure 9: State Modification by off-path adversary 590 Summary: Off-path adversary's knowledge of Session-ID could cause 591 session modification/deletion. 593 SECURITY REQUIREMENT: TBD: This is not a NAT/FW NSLP specific problem 594 but a GIMPS problem. The initiator MUST be able to demonstrate 595 ownership of the session it wishes to modify. 597 8. Misuse of unreleased sessions 599 Assume that DS (N1) initiates NSIS session with DR (N2) through a 600 series of middleboxes as in Figure 10. When the DS is sending data 601 to DR, it might happen that the DR disconnects from the network 602 (crashes or moves out of the network in mobility scenarios). In such 603 cases, it is possible that another node N3 (which recently entered 604 the network protected by the same firewall) is assigned the same IP 605 address that was previously allocated to N2. The DS could take 606 advantage of the firewall policies installed already, if the refresh 607 interval time is very high. The DS can flood the node (N3), which 608 will consume the access network resources of the victim forcing it to 609 pay for unwanted traffic as shown in Figure 11. 611 Public Internet 613 +--------------------------+ 614 | | 615 | | 616 +-------+ CREATE +---+-----+ +-------+ | 617 | |-------------->------| |---->---| | | 618 | N1 |--------------<------| FW |----<---| N2 | | 619 | | success RESPONSE | | | | | 620 | |==============>======| |====>===| | | 621 +-------+ Data Traffic +---+-----+ +-------+ | 622 | | 623 | | 624 +--------------------------+ 626 Figure 10: Before mobility 628 Public Internet 630 +--------------------------+ 631 | | 632 | | 633 +-------+ +---+-----+ +-------+ | 634 | | | | | | | 635 | N1 |==============>======| FW |====>===| N3 | | 636 | | Data Traffic | | | | | 637 | | | | | | | 638 +-------+ +---+-----+ +-------+ | 639 | | 640 | | 641 +--------------------------+ 643 Figure 11: After mobility 645 Also, this threat is valid for the other direction as well. The DS 646 which is communicating with the DR may disconnect from the network 647 and this IP address may be assigned to a new node that had recently 648 entered the network. This new node could pretend to be the DS and 649 send data traffic to the DR in conformance with the firewall policies 650 and cause service disruption. 652 SECURITY REQUIREMENT: Data origin authentication is needed to 653 mitigate this threat. However, the described threat is applicable 654 only for the time until the policy rules are deleted due to NSLP soft 655 state. Awareness for this threat is important especially when the 656 refresh interval time is high. It should be noted, that networks 657 supporting mobility should remove any state at middleboxes when a 658 mobile node is diconnecting, thus leaving a clean state. 660 9. Data traffic injection 662 This attack takes place where there exists trust relationship between 663 machines. It is common in corporate networks, where internal 664 machines trust each other and authentication is only based on IP 665 address. Hence by spoofing a connection, an attacker is able to 666 reach the target machines, using the existing firewall rules. 668 The adversary is able to inject its own data traffic in conformance 669 with the firewall policies simultaneously along with the genuine DS. 671 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 672 non-cryptographic packet filters no security requirement needs to be 673 created for the NAT/FW NSLP. Techniques such as ingress filtering 674 (described below) and data origin authentication (such as provided 675 with IPsec based VPNs) can help mitigate this threat. This issue is, 676 however, outside the scope of this document. 678 Ingress Filtering: Consider the scenario shown in Figure 12. In this 679 scenario the DS is behind a router (R1) and a malicious node (M) is 680 behind another router (R2). The DS communicates with the DR through 681 a firewall (FW). The DS initiates NSIS signaling and installs 682 firewall policies at FW. But the malicious node is also able to send 683 data traffic using DS's source address. If R2 implements ingress 684 filtering, these spoofed packets will be blocked. But this ingress 685 filtering may not work in all scenarios. If both the DS and the 686 malicious node are behind the same router, then the ingress filter 687 will not be able to detect the spoofed packets as both the DS and the 688 malicious node are in the same address range. 690 +-----------------------------------+ 691 | +------------------+ | 692 | | | | 693 | | | | 694 | | +-------+ +---+---+ | 695 | | | DS +>--+ R1 +->+ | 696 | | | | | | | | 697 | | +-------+ +---+---+ | | 698 | | | v | 699 | | | | | 700 | +------------------+ | +---+---+ +-------+ 701 | | | | | | 702 | +---+ FW +-->--| DR | 703 | +------------------+ | | | | 704 | | | ****| |*****| | 705 | | | * +---+---+ +-------+ 706 | | +-------+ +---+---+ * | 707 | | | M | | R2 | * | 708 | | | |***| |*** | 709 | | +-------+ +---+---+ | 710 | | | | 711 | | | | 712 | +------------------+ | 713 +-----------------------------------+ 715 ---->---- = genuine data traffic 716 ********* = spoofed data traffic 718 Figure 12: Ingress filtering 720 10. Misuse of mobility in NAT handling 722 Since NSIS allows end hosts to be mobile it is possible that an NSIS 723 node behind a NAT needs to update its NAT binding in case of address 724 change. Whenever a host behind a NAT initiates a data transfer, it 725 is assigned an external IP and port number. In typical mobility 726 scenarios, the DR might also obtain a new address according to the 727 topology and it should convey the NAT binding updates. The NAT is 728 assumed to modify these NAT bindings based on the new IP address 729 conveyed by the endhost. 731 Public Private Address 732 Internet space 734 +----------+ +----------+ 735 +----------| NAT |------------------|End host | 736 | | | | 737 +----------+ +----------+ 738 | 739 | 740 | +----------+ 741 \--------------------|Malicious | 742 |End host | 743 +----------+ 744 data traffic 745 <======================== 747 Figure 13: Misuse of mobility in NAT binding 749 For this description , we assume that a NAT binding state can be 750 changed with the help of NSIS signalling. When the DR is receiving 751 data traffic, if it happens to move to a new location, it sends an 752 NSIS signalling message to modify the NAT binding. It would use the 753 Session-ID and the new flow-id to update the state. The NAT updates 754 the binding and the DR continues to receive the data traffic. 755 Consider the scenario in Figure 13 where an the endhost(DR) and the 756 adversary are behind a NAT. The adversary pretending that it is the 757 end host could generate a spurious signaling message to update the 758 state at the NAT. This could be done for these purposes: 760 1. Connection hijacking by redirecting packets to the attacker as in 761 Figure 14 763 2. Third party flooding by redirecting packets to arbitrary hosts 765 3. Service disruption by redirecting to non-existing hosts 766 +----------+ +----------+ +----------+ 767 | NAT | |End host | |Malicious | 768 | | | | |End host | 769 +----------+ +----------+ +----------+ 770 | | | 771 | | | 772 | Data Traffic | | 773 |--------->----------| | 774 | | | 775 | | Spurious | 776 | | NAT binding update | 777 |---------<----------+--------<------------| 778 | | | 779 | | | 780 | Data Traffic | | 781 |--------->----------+-------->------------| 782 | | | 783 | | | 784 | | | 786 Figure 14: Connection Hijacking 788 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 789 authenticated, authorized, integrity protected and replay protected 790 between neighboring NAT/FW NSLP nodes. 792 11. Eavesdropping and traffic analysis 794 By collecting NSLP messages, an adversary is able to learn policy 795 rules for packet filters and knows which ports are open. It can use 796 this to inject its own data traffic due to the IP spoofing capability 797 as already mentioned in Section 9. 799 An adversary could learn authorization tokens included in CREATE 800 messages and use them to launch reply-attacks or to create a session 801 with its own address as source address. (cut-and-paste attack) 803 As shown in Section 4.3 of [6] a solution of Section 7 might require 804 confidentiality protection of signaling messages 806 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 807 mandate the usage of confidentiality protection since an adversary 808 can also eavesdrop on data traffic. In the context of a particular 809 security solutions (e.g., authorization tokens) it might be necessary 810 to offer confidentiality protection. Confidentiality protection also 811 needs to be offered to the refresh period. 813 12. Security Considerations 815 The entire document highlights security threats that need to be 816 mitigated for the NATFW NSLP. It also addresses security issues 817 related to packet filters. Security requirements have been derived 818 from the relevant threats. 820 13. Acknowledgments 822 This document is the result of discussions with many individuals. 823 The authors would like to thank especially: Marcus Brunner, Miquel 824 Martin, Frank Le, Joao Girao, and Elwyn Davis. 826 14. References 828 14.1 Normative References 830 [1] Stiemerling, M., Tschofenig, H. and M. Martin, "A NAT/Firewall 831 NSIS Signaling Layer Protocol (NSLP)", 832 draft-ietf-nsis-nslp-natfw-03 (work in progress), July 2004, 833 . 835 [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 836 draft-ietf-nsis-threats-05 (work in progress), June 2004, 837 . 839 [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 840 Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-02 841 (work in progress), May 2004, 842 . 844 [4] Brunner, M., "Requirements for Signaling Protocols", 845 draft-ietf-nsis-requirements (work in progress), April 2004, 846 . 848 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 849 Levels", March 1997. 851 14.2 Informative References 853 [6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and 854 X. Fu, "Security Implications of the Session Identifier", June 855 2003, . 857 [7] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 858 Tschofenig, "NAT/Firewall NSLP Migration Considerations", 859 draft-aoun-nsis-nslp-natfw-migration-01 (work in progress), 860 February 2004, 861 . 863 [8] Bless, R., "Mobility and Internet Signaling Protocols", 864 draft-manyfolks-signaling-protocol-mobility-00 (work in 865 progress), January 2004, 866 . 868 [9] Bosch, S., "NSLP for Quality-of-Service signaling", 869 draft-ietf-nsis-qos-nslp-03 (work in progress), May 2004, 870 . 872 Authors' Addresses 874 Ali Fessi 875 Network Laboratories, NEC Europe Ltd. 877 EMail: alifessi@web.de 878 URI: 880 Martin Stiemerling 881 Network Laboratories, NEC Europe Ltd. 882 Kurfuersten-Anlage 36 883 Heidelberg 69115 884 Germany 886 Phone: +49 (0) 6221 905 11 13 887 EMail: stiemerling@ccrle.nec.de 888 URI: 890 Srinath Thiruvengadam 891 Siemens 892 Otto-Hahn-Ring 6 893 Munich, Bayern 81739 894 Germany 896 EMail: srinath@mytum.de 898 Hannes Tschofenig 899 Siemens 900 Otto-Hahn-Ring 6 901 Munich, Bayern 81739 902 Germany 904 EMail: Hannes.Tschofenig@siemens.com 905 Cedric Aoun 906 Nortel Networks 907 France 909 EMail: cedric.aoun@nortelnetworks.com 911 Intellectual Property Statement 913 The IETF takes no position regarding the validity or scope of any 914 Intellectual Property Rights or other rights that might be claimed to 915 pertain to the implementation or use of the technology described in 916 this document or the extent to which any license under such rights 917 might or might not be available; nor does it represent that it has 918 made any independent effort to identify any such rights. Information 919 on the procedures with respect to rights in RFC documents can be 920 found in BCP 78 and BCP 79. 922 Copies of IPR disclosures made to the IETF Secretariat and any 923 assurances of licenses to be made available, or the result of an 924 attempt made to obtain a general license or permission for the use of 925 such proprietary rights by implementers or users of this 926 specification can be obtained from the IETF on-line IPR repository at 927 http://www.ietf.org/ipr. 929 The IETF invites any interested party to bring to its attention any 930 copyrights, patents or patent applications, or other proprietary 931 rights that may cover technology that may be required to implement 932 this standard. Please address the information to the IETF at 933 ietf-ipr@ietf.org. 935 Disclaimer of Validity 937 This document and the information contained herein are provided on an 938 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 939 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 940 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 941 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 942 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 943 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 945 Copyright Statement 947 Copyright (C) The Internet Society (2004). This document is subject 948 to the rights, licenses and restrictions contained in BCP 78, and 949 except as set forth therein, the authors retain all their rights. 951 Acknowledgment 953 Funding for the RFC Editor function is currently provided by the 954 Internet Society.