idnits 2.17.00 (12 Aug 2021) /tmp/idnits38288/draft-fessi-nsis-natfw-threats-02.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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 965. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 972. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 978. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 994), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 208: '... middlebox MUST authenticate and aut...' RFC 2119 keyword, line 210: '... the initiator SHOULD be provided to...' RFC 2119 keyword, line 238: '...T: The middlebox MUST authenticate and...' RFC 2119 keyword, line 241: '... this scenario) MAY be provided to th...' RFC 2119 keyword, line 259: '... 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 2004) is 6519 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 900, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 906, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 911, 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' ** Downref: Normative reference to an Informational RFC: RFC 3726 (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: 13 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS A. Fessi 2 Internet-Draft M. Stiemerling 3 Expires: December 30, 2004 NEC 4 S. Thiruvengadam 5 H. Tschofenig 6 Siemens 7 C. Aoun 8 Nortel Networks 9 July 2004 11 Security Threats for the NATFW NSLP 12 draft-fessi-nsis-natfw-threats-02 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 30, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 Opening a firewall pinhole or creating a NAT binding is a very 46 security sensitive issue. This memo identifies security threats and 47 security requirements that need to be addressed for the NATFW NSLP. 48 Generic security threats to the NSIS protocols have been already 49 discussed in the NSIS Working Group. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Attacks related to authentication and authorization . . . . . 4 58 3.1 Data Sender (DS) behind a firewall . . . . . . . . . . . . 6 59 3.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . . . 7 60 3.3 Data Receiver (DR) behind a firewall . . . . . . . . . . . 7 61 3.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . . . 9 62 3.5 NSLP message injection . . . . . . . . . . . . . . . . . . 11 64 4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . 11 65 4.1 Flooding with CREATE messages from outside . . . . . . . . 11 66 4.1.1 Attacks due to NSLP state . . . . . . . . . . . . . . 11 67 4.1.2 Attacks due to authentication complexity . . . . . . . 12 68 4.1.3 Attacks to the endpoints . . . . . . . . . . . . . . . 12 69 4.1.4 Attacks to the NTLP . . . . . . . . . . . . . . . . . 12 70 4.2 Flooding with REA messages from inside . . . . . . . . . . 12 72 5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 13 74 6. Message Modification . . . . . . . . . . . . . . . . . . . . . 14 76 7. Session Modification/Deletion . . . . . . . . . . . . . . . . 15 77 7.1 Misuse of mobility in NAT handling . . . . . . . . . . . . 16 79 8. Misuse of unreleased sessions . . . . . . . . . . . . . . . . 18 81 9. Data traffic injection . . . . . . . . . . . . . . . . . . . . 20 83 10. Eavesdropping and traffic analysis . . . . . . . . . . . . . 21 85 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 22 87 12. Security Considerations . . . . . . . . . . . . . . . . . . 22 89 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 91 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 93 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 96 Intellectual Property and Copyright Statements . . . . . . . . 25 98 1. Introduction 100 This document provides an analysis of the security threats that are 101 specific for the NATFW NSLP. The NATFW NSLP is used to install the 102 required policy rules (firewall pinhole and/or NAT binding) on 103 middleboxes along the path to allow the traversal of a data flow. 105 Opening a pinhole in the firewall or creating a NAT binding is a very 106 security sensitive issue. Thus, we need to examine carefully who is 107 allowed to install these policy rules and what security threats need 108 to be addressed. In this document we will analyze different types of 109 possible attacks to networks running NSIS for middlebox 110 configuration. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [5]. 118 Furthermore, we use the same terminology as in [1], [3] and [4]. 120 3. Attacks related to authentication and authorization 122 As described in [1] the NSIS message which installs policy rules at a 123 middlebox is the CREATE message. The CREATE message travels from the 124 Data Sender (DS) toward the Data Receiver (DR). The packet filter or 125 NAT binding is marked as pending by the middleboxes along the path. 126 If it is confirmed with a success RESPONSE message from the DR the 127 requested policy rules on the middleboxes are installed to allow the 128 traversal of a data flow. 130 +-----+ +-----+ +-----+ 131 | DS | | MB | | DR | 132 +-----+ +-----+ +-----+ 133 | | | 134 | CREATE | CREATE | 135 |-------------------->+-------------------->| 136 | | | 137 | Succeeded/Error | Succeeded/Error | 138 |<--------------------+<--------------------| 139 | | | 140 ==========================================> 141 Direction of data traffic 143 Figure 1: CREATE Mode 145 In this section we will consider some simple scenarios for middlebox 146 configuration: 147 o Data Sender (DS) behind a firewall 148 o Data Sender (DS) behind a NAT 149 o Data Receiver (DR) behind a firewall 150 o Data Receiver (DR) behind a NAT 152 A real scenario could include a combination of one or more cases 153 together, i.e., DS and/or DR is behind a chain of NATs and firewalls. 154 Figure 2 shows such a possible scenario: 156 +-------------------+ +--------------------+ 157 | | | | 158 | Network A | | Network B | 159 | | | | 160 | +-----+ | //-----\\ | +-----+ | 161 | | MB2 |--------+----| INET |----+--------| MB3 | | 162 | +-----+ | \\-----// | +-----+ | 163 | | | | | | 164 | +-----+ | | +-----+ | 165 | | MB1 | | | | MB4 | | 166 | +-----+ | | +-----+ | 167 | | | | | | 168 | +-----+ | | +-----+ | 169 | | DS | | | | DR | | 170 | +-----+ | | +-----+ | 171 | | | | 172 +-------------------+ +--------------------+ 174 MB: Middle box (NAT or Firewall or a combination) 175 DS: Data Sender 176 DR: Data Receiver 178 Figure 2: Several middleboxes per network 180 3.1 Data Sender (DS) behind a firewall 182 +------------------------------+ 183 | | 184 | +-----+ create +-----+ 185 | | DS | --------------> | FW | 186 | +-----+ +-----+ 187 | | 188 +------------------------------+ 190 Figure 3: DS behind a firewall 192 DS sends a CREATE message to request the traversal of a data flow. 194 It is up to network operators to decide how far they can trust users 195 inside their networks. However, there are several reasons why they 196 should not. 198 The following attacks are possible: 199 o DS could open a firewall pinhole with a source address different 200 from its own host. 201 o DS could open firewall pinholes for incoming data flows that are 202 not supposed to enter the network. 204 o DS could request installation of any policy rules and allow all 205 traffic go through. 207 SECURITY REQUIREMENT: As already mentioned in [1] Section (3.2), the 208 middlebox MUST authenticate and authorize the neighboring NAT/FW NSLP 209 node which requests an action. Authentication and authorization of 210 the initiator SHOULD be provided to NATs and Firewalls along the path 211 as motivated with Section 2.2.3 of [1]. 213 3.2 Data Sender (DS) behind a NAT 215 The case 'DS behind a NAT' is analogous to the case 'DS behind a 216 firewall'. 218 It is worth mentioning that authentication based on IP address is not 219 possible if NATs are deployed. Figure 4 illustrates such a scenario: 221 +------------------------------+ 222 | | 223 | +------+ CREATE | 224 | | NI_1 | ------\ +-----+ CREATE +-----+ 225 | +------+ \------> | NAT |-------->| MB | 226 | +-----+ +-----+ 227 | +------+ | 228 | | NI_2 | | 229 | +------+ | 230 +------------------------------+ 232 Figure 4: Several NIs behind a NAT 234 In this case the middlebox MB does not know who is the NSIS Initiator 235 since both NI_1 and NI_2 are behind a NAT. Authentication needs to 236 be provided by other means such as the NSLP or the application layer. 238 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that 239 the neighboring NAT/FW NSLP node is authorized to request an action. 240 Authentication and authorization of the initiator (which is the DR in 241 this scenario) MAY be provided to the middleboxes. 243 3.3 Data Receiver (DR) behind a firewall 245 In this case a CREATE message comes from an entity DS outside the 246 network towards the DR inside the network. 248 +------------------------------+ 249 | | 250 +-----+ CREATE +-----+ CREATE +-----+ | 251 | DS | -------------> | FW | -------------> | DR | | 252 +-----+ <------------- +-----+ <------------- +-----+ | 253 success RESPONSE | success RESPONSE | 254 | | 255 +------------------------------+ 257 Figure 5: DR behind a firewall 259 According to [1] (Section 3.3) "Policy rules at middleboxes MUST be 260 only installed upon receiving a successful response of type success 261 RESPONSE". 263 This means that the middlebox waits until the Data Receiver DR 264 confirms the request of the Data Sender DS with a success RESPONSE 265 message. This is, however, only necessary 266 o if the policy rule creation/deletion/update at a firewall along 267 the path cannot be authorized and 268 o if the middlebox is still forwarding the signaling message towards 269 the end host (without state creation/deletion/modification). 271 This confirmation implies that the data receiver is expecting the 272 data flow. 274 At this point we differentiate 2 cases: 275 1. DR knows the IP address of the DS (for instance because of some 276 previous application layer signaling) and is expecting the data 277 flow. 278 2. DR might be expecting the data flow (for instance because of some 279 previous application layer signaling) but does not know the IP 280 address of the Data Sender DS. 282 For the second case, Figure 6 illustrates a possible attack: an 283 adversary Mallory M could be sniffing the application layer signaling 284 and thus knows the address and port number where DR is expecting the 285 data flow. Thus it could pretend to be DS and send a CREATE message 286 towards DR with the data flow description (M -> DR). Since DR does 287 not know the IP address of DS, it is not able to recognize that the 288 request is coming from the "wrong guy". It will send a success 289 RESPONSE message back and the middlebox will install policy rules 290 that will allow Mallory M to inject its data into the network. 292 Application Layer signaling 293 <------------------------------------> 294 / \ 295 / +-----------------\------------+ 296 / | \ | 297 +-----+ +-----+ +-----+ | 298 | DS | -> | FW | | DR | | 299 +-----+ / +-----+ +-----+ | 300 CREATE / | | 301 +-----+ / +-------------------------------+ 302 | M |---------- 303 +-----+ 305 Figure 6: DR behind a firewall with an adversary 307 Network administrators will probably not rely on a DR to check the IP 308 address of the DS. Thus we have to assume the worst case with an 309 attack such as in Figure 6. Many operators might not allow NSIS 310 signaling message to traverse the firewall in Figure 6 without proper 311 authorization. In this case the threat is not applicable. 313 SECURITY REQUIREMENT: A binding between the application layer and the 314 NSIS signaling SHOULD be provided. 316 3.4 Data Receiver (DR) behind a NAT 318 We will describe briefly the NSIS message flow that takes place to 319 install the necessary rules for the traversal of a data flow from DS 320 towards DR. For detailed description please refer to [1] Section 321 3.3. 323 DR sends a RESERVE-EXTERNAL-ADDRESS (REA) message to get a public 324 reachable address that can be used by potential DSs. The NAT 325 reserves an external address and port number and sends them back to 326 DR. The NAT adds an address mapping entry in its reservation list 327 which links the public and private addresses as follows: 329 (DR_ext <=> DR_int) (*). 331 The NAT sends a RESPONSE message with 'return external address' 332 object back to the DR with the address DR_ext. DR informs DS about 333 the public address that it has recently received, for instance, by 334 means of application layer signaling. 336 Now DS sends the CREATE message towards DR_ext. When the 'create 337 session' message arrives at the NAT, the NAT looks up its reservation 338 list and finds the entry (*). 340 Now the NAT knows the address of DS and stores it as a part of the 341 policy rule to be loaded. It forwards the message towards DR and 342 waits for the confirmation with the success RESPONSE message. 344 At the arrival of the success RESPONSE message from DR, the NAT 345 installs the policy rule to forward the data flow correctly from DS 346 to DR. 348 Possible attack: 350 We assume that the adversary obtains the external address allocated 351 at the NAT (possibly by eavesdropping on the application layer 352 signaling) and triggers the CREATE message before the NAT binding 353 expires. The CREATE message is assumed to travel from DS to DR 354 through NAT. An attacker Mallory M could send a CREATE message to 355 install a NAT binding to forward the data flow from M to DR instead 356 of from DS to DR. This kind of attack is equivalent to the attack 357 described in Section 3.3 above. 359 In order for this attack to work the following pre-requisities need 360 to hold: 361 The adversary needs to be authorized to create a NAT binding at 362 the NAT. 363 The adversary needs to know when a DR creates a NAT binding at the 364 DR. A certain timing is required and some specific information, 365 such as the message routing identifier and session identifier must 366 be known 368 Application Layer signaling 369 <------------------------------------> 370 / \ 371 / +-----------------\------------+ 372 / | REA \ | 373 +-----+ +-----+ <----------- +-----+ | 374 | DS | -> | NAT | -----------> | DR | | 375 +-----+ / +-----+ rtn_ext_addr +-----+ | 376 CREATE / | | 377 +-----+ / +-------------------------------+ 378 | M |---------- 379 +-----+ 381 Figure 7: DR behind a NAT with an adversary 383 SECURITY REQUIREMENT: TBD 385 3.5 NSLP message injection 387 Malicious Hosts, locate either off-path or on-path, could inject 388 arbitrary NATFW NSLP messages into the signaling path, causing 389 several problems. These problems apply when no proper authorization 390 and authentication scheme is available. 392 By injecting a bogus CREATE message with lifetime set to zero, a 393 malicious host could try to teardown NATFW NSLP session state 394 partially or completely on a data path, causing a service 395 interruption. 397 By injecting a bogus responses message, for instance, timeout, a 398 malicious host could try to teardown NATFW NSLP session state as 399 well. This could affect the data path partially or complete, causing 400 a service interruption. 402 Other messages, such as TRIGGER, can be misused by malicious hosts, 403 causing a service interruption. Following versions of this document 404 will investigate the impact of these messages as well. 406 4. Denial-of-Service Attacks 408 In this section we describe several ways how an adversary could 409 launch a Denial of service (DoS) attack on networks running NSIS for 410 middlebox configuration to exhaust their resources. 412 4.1 Flooding with CREATE messages from outside 414 4.1.1 Attacks due to NSLP state 416 A CREATE message requests the NSLP to store some state information 417 such as Session-ID and flow identifier. 419 The policy rules requested in the CREATE message will be installed at 420 the arrival of a confirmation from the Data Receiver with a success 421 RESPONSE message. The success RESPONSE message includes the session 422 ID. So the NSLP looks up the NSIS session and installs the requested 423 policy rules. 425 An adversary from outside could launch a DoS attack with arbitrary 426 CREATE messages. For each of these messages the middlebox needs to 427 store state information such as the policy rules to be loaded, i.e., 428 the middlebox could run out of memory. This kind of attack is also 429 mentioned in [2] Section 4.8. 431 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 432 'create-session' message before storing state information. 434 4.1.2 Attacks due to authentication complexity 436 This kind of attack is possible if authentication is based on 437 mechanisms that require computing power, for example, digital 438 signatures. 440 For a more detailed treatment of this kind of attack, the reader is 441 encouraged to see [2]. 443 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 444 denial of service attacks based on authentication or key management 445 mechanisms. 447 4.1.3 Attacks to the endpoints 449 The NATFW NSLP requires firewalls to forward NSLP messages, a 450 malicious node may keep sending NSLP messages to a target. This may 451 consume the access network resources of the victim, drain the battery 452 of the victim's terminal and may force the victim to pay for the 453 received although undesired data. 455 This threat may be more particularly be relevant in networks where 456 access link is a limited resource, for instance in cellular networks, 457 and where the terminal capacities are limited. 459 SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able 460 to block unauthorized signaling message, if this threat is a concern. 462 4.1.4 Attacks to the NTLP 464 Flooding a middlebox with CREATE messages affects also the NTLP. 466 The success RESPONSE message needs to take the same route as the 467 previous CREATE message. Thus the NTLP needs to store routing 468 information for each CREATE message. This kind of attack is also 469 described in [2] Section 4.8. 471 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 472 denial of service attacks based on authentication or key management 473 mechanisms. 475 4.2 Flooding with REA messages from inside 477 Although we are more concerned with possible attacks from outside the 478 network, we need also to consider possible attacks from inside the 479 network. 481 An adversary inside the network could send arbitrary 482 RESERVE-EXTERNAL-ADDRESS messages. At a certain point the NAT will 483 run out of port numbers and the access for other users to the outside 484 will be disabled. 486 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 487 creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, the 488 NAT/FW NSLP implementation MUST prevent denial of service attacks 489 involving the allocation of an arbitrary number of NAT bindings or 490 the installation of a large number of packet filters. 492 5. Man-in-the-Middle Attacks 494 Figure 8 illustrates a possible man-in-the-middle attack using the 495 'reserve external address' (REA) message. This message travels from 496 DR towards the public Internet. The message might not be intercepted 497 by any NAT either because there are no NATs or because there are NSIS 498 unaware. 500 Mallory M returns a faked RESPONSE message with an IP address of its 501 choosing. This IP address is meant to be used by the DR as the 502 public external IP address. Malory might insert it own IP address in 503 the response, the IP address of a third party or the address of a 504 black hole. In the first case, the DR thinks that the address of 505 Mallory M is its public address and will inform the DS about it. As 506 a consequence, the DS will send the data traffic to Mallory M. 508 The data traffic from the DS to the DR will re-directed to Mallory M. 509 Mallory M will be able to read, modify or block the data traffic. 510 Eavesdropping and modification is only possible if the data traffic 511 is itself unprotected. 513 +-----+ +-----+ +-----+ +-----+ 514 | DS | | M | | FW | | DR | 515 +-----+ +-----+ +-----+ +-----+ 516 | | | | 517 | | REA | REA | 518 | | <------------------ | <------------ | 519 | | | | 520 | | ret_ext_addr | ret_ext_addr | 521 | | ------------------> | ------------> | 522 | | | | 523 | data traffic | | | 524 |===============>| data traffic | 525 | |===================================> | 527 Figure 8: MITM attack using the RESERVE-EXTERNAL-ADDRESS message 529 Please note that the NSIS aware firewall in Figure 8 might not be 530 present when DR communicates directly with the adversary. 532 SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW 533 NSLP MUST be provided. To ensure that only legitimate nodes along 534 the path act as NSIS entities the initiator MUST authorize the 535 responder. In the example in Figure 8 the firewall FW must perform 536 an authorization with the neighboring entities. 538 6. Message Modification 540 Any on-path subverted node en route to the destination could easily 541 modify, inject or just drop an NSIS message. It could also hijack or 542 disrupt the communication. 544 SECURITY REQUIREMENT: Message integrity, replay protection and data 545 origin authentication between neighboring NAT/FW NSLPs MUST be 546 provided. 548 Message modification by a subverted NSIS node could create arbitrary 549 pinholes or NAT bindigs. For example: 551 o NATs need to modify the source/destination of the data flow in the 552 'create session' message. 553 o Each middlebox along the path may change the requested lifetime in 554 the CREATE message to fit their needs and/or local policy (see 555 also section 3.2.7 of [1] with regard to calculation of refresh 556 interval). 558 SECURITY REQUIREMENT: None. Malicous NSIS NATs and Firewalls will 559 not be addressed. 561 7. Session Modification/Deletion 563 The Session ID is included in signaling messages as a reference to 564 the established state. If an adversary is able to obtain the Session 565 Identifier for example by eavesdropping on signaling messages, it 566 would be able to add the same Session Identifier to a new a signaling 567 message and effect some modifications. 569 Consider the scenario described in Figure 9. Here an adversary 570 pretends to be 'DS in mobility'. The signaling messages start from 571 the DS and go through a series of routers towards the DR. We assume 572 that an off-path adversary is connected to one of the routers along 573 the old path (here Router 3). We also assume that the adversary 574 knows the Session ID of the NSIS session initiated by the DS. 575 Knowing the Session ID, the adversary now sends signalling messages 576 towards the DR. When the signaling message reaches Router3 then 577 existing state information can be modified or even deleted. The 578 adversary can modify or delete the established reservation causing 579 unexpected behavior for the legitimate user. The source of the 580 problem is that the Router 3 (cross-over router) is unable to decide 581 whether the new signaling message was initiated from the owner of the 582 session. In this scenario, the adversary need not even be located in 583 the DS-DR path. This problem and the solution approaches are 584 described in more detail in [6]. 586 Session ID(SID-x) 587 +--------+ +--------+ 588 +-------->--------+ Router +-------->+ DR | 589 Session ID(SID-x)| | 4 | | | 590 +---+----+ +--------+ +--------+ 591 | Router | 592 +------+ 3 +******* 593 | +---+----+ * 594 | * 595 | Session ID(SID-x) * Session ID(SID-x) 596 +---+----+ +---+----+ 597 | Access | | Access | 598 | Router | | Router | 599 | 1 | | 2 | 600 +---+----+ +---+----+ 601 | * 602 | Session ID(SID-x) * Session ID(SID-x) 603 +----+------+ +----+------+ 604 | DS | | Adversary | 605 | | | | 606 +-----------+ +-----------+ 608 Figure 9: State Modification by off-path adversary 610 Summary: Off-path adversary's knowledge of Session-ID could cause 611 session modification/deletion. 613 SECURITY REQUIREMENT: TBD: This is not a NAT/FW NSLP specific problem 614 but a GIMPS problem. The initiator MUST be able to demonstrate 615 ownership of the session it wishes to modify. 617 7.1 Misuse of mobility in NAT handling 619 Another kind of session modification is related to mobility 620 scenarios. NSIS allows end hosts to be mobile it is possible that an 621 NSIS node behind a NAT needs to update its NAT binding in case of 622 address change. Whenever a host behind a NAT initiates a data 623 transfer, it is assigned an external IP and port number. In typical 624 mobility scenarios, the DR might also obtain a new address according 625 to the topology and it should convey the NAT binding updates. The 626 NAT is assumed to modify these NAT bindings based on the new IP 627 address conveyed by the endhost. 629 Public Private Address 630 Internet space 632 +----------+ +----------+ 633 +----------| NAT |------------------|End host | 634 | | | | 635 +----------+ +----------+ 636 | 637 | 638 | +----------+ 639 \--------------------|Malicious | 640 |End host | 641 +----------+ 642 data traffic 643 <======================== 645 Figure 10: Misuse of mobility in NAT binding 647 For this description , we assume that a NAT binding state can be 648 changed with the help of NSIS signalling. When the DR is receiving 649 data traffic, if it happens to move to a new location, it sends an 650 NSIS signalling message to modify the NAT binding. It would use the 651 Session-ID and the new flow-id to update the state. The NAT updates 652 the binding and the DR continues to receive the data traffic. 653 Consider the scenario in Figure 10 where an the endhost(DR) and the 654 adversary are behind a NAT. The adversary pretending that it is the 655 end host could generate a spurious signaling message to update the 656 state at the NAT. This could be done for these purposes: 658 1. Connection hijacking by redirecting packets to the attacker as in 659 Figure 11 661 2. Third party flooding by redirecting packets to arbitrary hosts 663 3. Service disruption by redirecting to non-existing hosts 664 +----------+ +----------+ +----------+ 665 | NAT | |End host | |Malicious | 666 | | | | |End host | 667 +----------+ +----------+ +----------+ 668 | | | 669 | | | 670 | Data Traffic | | 671 |--------->----------| | 672 | | | 673 | | Spurious | 674 | | NAT binding update | 675 |---------<----------+--------<------------| 676 | | | 677 | | | 678 | Data Traffic | | 679 |--------->----------+-------->------------| 680 | | | 681 | | | 682 | | | 684 Figure 11: Connection Hijacking 686 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 687 authenticated, authorized, integrity protected and replay protected 688 between neighboring NAT/FW NSLP nodes. 690 8. Misuse of unreleased sessions 692 Assume that DS (N1) initiates NSIS session with DR (N2) through a 693 series of middleboxes as in Figure 12. When the DS is sending data 694 to DR, it might happen that the DR disconnects from the network 695 (crashes or moves out of the network in mobility scenarios). In such 696 cases, it is possible that another node N3 (which recently entered 697 the network protected by the same firewall) is assigned the same IP 698 address that was previously allocated to N2. The DS could take 699 advantage of the firewall policies installed already, if the refresh 700 interval time is very high. The DS can flood the node (N3), which 701 will consume the access network resources of the victim forcing it to 702 pay for unwanted traffic as shown in Figure 13. 704 Public Internet 706 +--------------------------+ 707 | | 708 | | 709 +-------+ CREATE +---+-----+ +-------+ | 710 | |-------------->------| |---->---| | | 711 | N1 |--------------<------| FW |----<---| N2 | | 712 | | success RESPONSE | | | | | 713 | |==============>======| |====>===| | | 714 +-------+ Data Traffic +---+-----+ +-------+ | 715 | | 716 | | 717 +--------------------------+ 719 Figure 12: Before mobility 721 Public Internet 723 +--------------------------+ 724 | | 725 | | 726 +-------+ +---+-----+ +-------+ | 727 | | | | | | | 728 | N1 |==============>======| FW |====>===| N3 | | 729 | | Data Traffic | | | | | 730 | | | | | | | 731 +-------+ +---+-----+ +-------+ | 732 | | 733 | | 734 +--------------------------+ 736 Figure 13: After mobility 738 Also, this threat is valid for the other direction as well. The DS 739 which is communicating with the DR may disconnect from the network 740 and this IP address may be assigned to a new node that had recently 741 entered the network. This new node could pretend to be the DS and 742 send data traffic to the DR in conformance with the firewall policies 743 and cause service disruption. 745 SECURITY REQUIREMENT: Data origin authentication is needed to 746 mitigate this threat. However, the described threat is applicable 747 only for the time until the policy rules are deleted due to NSLP soft 748 state. Awareness for this threat is important especially when the 749 refresh interval time is high. It should be noted, that networks 750 supporting mobility should remove any state at middleboxes when a 751 mobile node is diconnecting, thus leaving a clean state. 753 9. Data traffic injection 755 This attack takes place where there exists trust relationship between 756 machines. It is common in corporate networks, where internal 757 machines trust each other and authentication is only based on IP 758 address. Hence by spoofing a connection, an attacker is able to 759 reach the target machines, using the existing firewall rules. 761 The adversary is able to inject its own data traffic in conformance 762 with the firewall policies simultaneously along with the genuine DS. 764 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 765 non-cryptographic packet filters no security requirement needs to be 766 created for the NAT/FW NSLP. Techniques such as ingress filtering 767 (described below) and data origin authentication (such as provided 768 with IPsec based VPNs) can help mitigate this threat. This issue is, 769 however, outside the scope of this document. 771 Ingress Filtering: Consider the scenario shown in Figure 14. In this 772 scenario the DS is behind a router (R1) and a malicious node (M) is 773 behind another router (R2). The DS communicates with the DR through 774 a firewall (FW). The DS initiates NSIS signaling and installs 775 firewall policies at FW. But the malicious node is also able to send 776 data traffic using DS's source address. If R2 implements ingress 777 filtering, these spoofed packets will be blocked. But this ingress 778 filtering may not work in all scenarios. If both the DS and the 779 malicious node are behind the same router, then the ingress filter 780 will not be able to detect the spoofed packets as both the DS and the 781 malicious node are in the same address range. 783 +-----------------------------------+ 784 | +------------------+ | 785 | | | | 786 | | | | 787 | | +-------+ +---+---+ | 788 | | | DS +>--+ R1 +->+ | 789 | | | | | | | | 790 | | +-------+ +---+---+ | | 791 | | | v | 792 | | | | | 793 | +------------------+ | +---+---+ +-------+ 794 | | | | | | 795 | +---+ FW +-->--| DR | 796 | +------------------+ | | | | 797 | | | ****| |*****| | 798 | | | * +---+---+ +-------+ 799 | | +-------+ +---+---+ * | 800 | | | M | | R2 | * | 801 | | | |***| |*** | 802 | | +-------+ +---+---+ | 803 | | | | 804 | | | | 805 | +------------------+ | 806 +-----------------------------------+ 808 ---->---- = genuine data traffic 809 ********* = spoofed data traffic 811 Figure 14: Ingress filtering 813 10. Eavesdropping and traffic analysis 815 By collecting NSLP messages, an adversary is able to learn policy 816 rules for packet filters and knows which ports are open. It can use 817 this to inject its own data traffic due to the IP spoofing capability 818 as already mentioned in Section 9. 820 An adversary could learn authorization tokens included in CREATE 821 messages and use them to launch reply-attacks or to create a session 822 with its own address as source address. (cut-and-paste attack) 824 As shown in Section 4.3 of [6] a solution of Section 7 might require 825 confidentiality protection of signaling messages 827 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 828 mandate the usage of confidentiality protection since an adversary 829 can also eavesdrop on data traffic. In the context of a particular 830 security solutions (e.g., authorization tokens) it might be necessary 831 to offer confidentiality protection. Confidentiality protection also 832 needs to be offered to the refresh period. 834 11. Conclusions 836 This memo describes security threads that are applicable to the NSIS 837 NATFW NSLP and some related threads inherent to firewalls and NATs. 838 Security requirements are given for the scenarios and some issues to 839 be considered in NTLP design are raised. 841 The most security threads shown here are related to missing 842 authentication or authorization schemes between all NATFW nodes. 843 Given a proper authentication and authorization scheme, many of these 844 threads can be mitigated. The general problem is the missing 845 identity of the nodes to what authorization and authentication could 846 be bound. IP addresses are in general not suitable, since NATs are 847 involved in any place to imagine and in mobility scenarios they are 848 changed frequently. Other attacks, such as message eavesdropping, 849 can be managed easily between adjacent NSIS nodes if the NTLP or NSLP 850 supports encryption. The flooding, or denial of service, of NSIS 851 nodes can be mitigated not only by authorization and authentication 852 schemes, but also by extensions to NATFW NSLP, where NSIS receivers 853 should be able to communicate upstream which type or from which node, 854 via the flow routing information, signaling traffic is allowed to be 855 forwarded to them. 857 12. Security Considerations 859 The entire document highlights security threats that need to be 860 mitigated for the NATFW NSLP. It also addresses security issues 861 related to packet filters. Security requirements have been derived 862 from the relevant threats. 864 13. Acknowledgments 866 This document is the result of discussions with many individuals. 867 The authors would like to thank especially: Marcus Brunner, Miquel 868 Martin, Frank Le, Joao Girao, and Elwyn Davis. 870 14. References 872 14.1 Normative References 874 [1] Stiemerling, M., Tschofenig, H. and M. Martin, "A NAT/Firewall 875 NSIS Signaling Layer Protocol (NSLP)", 876 draft-ietf-nsis-nslp-natfw-03 (work in progress), July 2004, 877 . 879 [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 880 draft-ietf-nsis-threats-05 (work in progress), June 2004, 881 . 883 [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 884 Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-02 885 (work in progress), May 2004, 886 . 888 [4] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 889 April 2004, . 891 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 892 Levels", March 1997. 894 14.2 Informative References 896 [6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and 897 X. Fu, "Security Implications of the Session Identifier", June 898 2003, . 900 [7] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 901 Tschofenig, "NAT/Firewall NSLP Migration Considerations", 902 draft-aoun-nsis-nslp-natfw-migration-01 (work in progress), 903 February 2004, 904 . 906 [8] Bless, R., "Mobility and Internet Signaling Protocols", 907 draft-manyfolks-signaling-protocol-mobility-00 (work in 908 progress), January 2004, 909 . 911 [9] Bosch, S., "NSLP for Quality-of-Service signaling", 912 draft-ietf-nsis-qos-nslp-03 (work in progress), May 2004, 913 . 915 Authors' Addresses 917 Ali Fessi 918 Network Laboratories, NEC Europe Ltd. 920 EMail: alifessi@web.de 921 URI: 923 Martin Stiemerling 924 Network Laboratories, NEC Europe Ltd. 925 Kurfuersten-Anlage 36 926 Heidelberg 69115 927 Germany 929 Phone: +49 (0) 6221 905 11 13 930 EMail: stiemerling@netlab.nec.de 931 URI: 933 Srinath Thiruvengadam 934 Siemens 935 Otto-Hahn-Ring 6 936 Munich, Bayern 81739 937 Germany 939 EMail: srinath@mytum.de 941 Hannes Tschofenig 942 Siemens 943 Otto-Hahn-Ring 6 944 Munich, Bayern 81739 945 Germany 947 EMail: Hannes.Tschofenig@siemens.com 949 Cedric Aoun 950 Nortel Networks 952 France 954 EMail: cedric.aoun@nortelnetworks.com 956 Intellectual Property Statement 958 The IETF takes no position regarding the validity or scope of any 959 Intellectual Property Rights or other rights that might be claimed to 960 pertain to the implementation or use of the technology described in 961 this document or the extent to which any license under such rights 962 might or might not be available; nor does it represent that it has 963 made any independent effort to identify any such rights. Information 964 on the procedures with respect to rights in RFC documents can be 965 found in BCP 78 and BCP 79. 967 Copies of IPR disclosures made to the IETF Secretariat and any 968 assurances of licenses to be made available, or the result of an 969 attempt made to obtain a general license or permission for the use of 970 such proprietary rights by implementers or users of this 971 specification can be obtained from the IETF on-line IPR repository at 972 http://www.ietf.org/ipr. 974 The IETF invites any interested party to bring to its attention any 975 copyrights, patents or patent applications, or other proprietary 976 rights that may cover technology that may be required to implement 977 this standard. Please address the information to the IETF at 978 ietf-ipr@ietf.org. 980 Disclaimer of Validity 982 This document and the information contained herein are provided on an 983 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 984 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 985 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 986 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 987 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 988 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 990 Copyright Statement 992 Copyright (C) The Internet Society (2004). This document is subject 993 to the rights, licenses and restrictions contained in BCP 78, and 994 except as set forth therein, the authors retain all their rights. 996 Acknowledgment 998 Funding for the RFC Editor function is currently provided by the 999 Internet Society.