idnits 2.17.1 draft-savola-ipv6-rh-ha-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IPV6], [MIPV6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 143 has weird spacing: '... deny proto...' -- 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 (October 2001) is 8222 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) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 == Outdated reference: A later version (-01) exists of draft-arkko-mipv6-bu-security-00 -- Possible downref: Normative reference to a draft: ref. 'BUSEC' == Outdated reference: A later version (-04) exists of draft-ietf-ipngwg-scoping-arch-02 -- Possible downref: Normative reference to a draft: ref. 'ADDRSCOPE' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: April 2002 5 October 2001 7 Security of IPv6 Routing Header and Home Address Options 9 draft-savola-ipv6-rh-ha-security-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 All IPv6 nodes must be able to process Routing Header [IPV6] and Home 35 Address [MIPV6] Options. With these, packet filter access lists can 36 be tricked (among other things) as the destination and source 37 addresses, respectively, are being rewritten as the packet traverses 38 the network. Some of the security considerations of these features 39 are analyzed, and a few possible solutions presented. 41 It will be shown that with the current architecture, the network- 42 based security does not seem to scale to the requirements of Mobile 43 IPv6; it seems possible that unless security is taken seriously when 44 implementing the nodes, the new Mobile IPv6 requirements might not be 45 allowed to be used at all in some circumstances. 47 Table of Contents 49 1. Introduction ............................................... 2 50 2. Routing Header ............................................. 3 51 2.1. The Traffic Filtering Problem .......................... 3 52 2.2. The Denial of Service Reflector Problem ................ 4 53 2.3. Some Requirements for Routing Header Use ............... 5 54 2.4. Solutions .............................................. 6 55 2.4.1. Node-based Approach ................................ 6 56 2.4.2. Network-based Approach ............................. 6 57 2.4.3. New Routing Header Type ............................ 7 58 3. Home Address Option ........................................ 8 59 3.1. The Source Address Spoofing Problem .................... 8 60 3.2. The Double Spoofing Problem ............................ 9 61 3.3. Some Requirements for Home Address Option Use .......... 11 62 3.4. Solutions .............................................. 11 63 3.4.1. Node-based Approach ................................ 11 64 3.4.2. Network-based Approach ............................. 11 65 4. Conclusions ................................................ 12 66 5. Security Considerations .................................... 12 67 6. Acknowledgements ........................................... 13 68 7. References ................................................. 13 69 Author's Address ............................................... 13 71 1. Introduction 73 All IPv6 nodes must be able to process Routing Header [IPV6] and Home 74 Address [MIPV6] Options. With these, packet filter access lists can 75 be tricked (among other things) as the destination and source 76 addresses, respectively, are being rewritten as the packet traverses 77 the network. 79 Some of the security considerations of these features are analyzed, 80 and a few possible solutions presented. 82 For both Routing Header and Home Address options, basically two 83 approaches to enhance security are put forward. It will be shown 84 that with the current architecture, the network-based security will 85 not seem to scale to the requirements of Mobile IPv6; it seems 86 possible that unless security is taken seriously when implementing 87 the nodes, the new Mobile IPv6 requirements might not be allowed to 88 be used at all in some circumstances. 90 In many cases, ingress filtering [INGRESS] is being performed. 91 Unfortunately, it is not being done everywhere; the existance of it 92 cannot be relied on. Routing Header and especially Home Address 93 options are especially harmful if ingress filtering is not being 94 performed, but to some extent, they can still be used quite 95 effectively if ingress filtering is in place. 97 A lot of discussion here is based on the fact that in the real world, 98 packet filtering is a practical requirement for safe operation; 99 almost everyone uses it. Therefore, it is important that it can be 100 performed in a predictable fashion. 102 The security of Binding Updates is another very crucial issue but 103 that is already discussed in other proposals, including [BUSEC]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Routing Header 111 All IPv6 nodes must be able to process Routing Headers. It is 112 implied, even though not clearly stated, that all nodes (including 113 hosts) must also have that processing enabled. 115 Here, "Routing Header" is used as a synonym for "Type 0 Routing 116 Header" unless explicitly stated otherwise as it is the only type 117 defined at the moment. 119 There several problems with Routing Headers: 121 - Getting around access controls if done with destination address 122 - The behaviour is difficult to disable if one wants to support 123 Mobile IPv6 124 - Can be used in reflected Denial of Service attacks 126 These are discussed at more length below. 128 2.1. The Traffic Filtering Problem 130 Because destination address is replaced at every Routing Header 131 processing point, it's impossible to perform traffic filtering based 132 on destination addresses. An example: 134 host1 --- rtr1 - Internet - fwrtr2 -+- webserver 135 | 136 +- host2 138 Assume that fwrtr2 is performing packet filtering on the internal 139 interface. The rules could be like: 141 [...] 142 allow proto tcp from any to webserver port 80 143 deny proto tcp from any to any 144 [...] 146 Here, malicious host1 would write packets as follows: 148 src=host1 149 dst=webserver 150 rtheader=host2, segments left=1 151 payload proto=tcp, dport=80 153 It would pass the packet filter checks fine, and be processed at 154 webserver. When being forwarded directly from there to host2, the 155 packet would look like: 157 src=host1 158 dst=host2 159 rtheader=webserver, segments left=0 160 payload proto=tcp, dport=80 162 If the packet had been sent directly to host2 without Routing Header, 163 it would have been denied in the packet filter access lists. 165 Even though webserver is configured as a Host, it will forward 166 packets with Routing Header. This breaks the principle of least 167 surprise, and as any node can be used as a traffic reflector, the 168 network is very difficult to secure. 170 The same naturally applies to Routers too, but they usually don't 171 have many publically available services, so they aren't optimal for 172 this kind of "access list avoidance via a reflector" attack. 174 2.2. The Denial of Service Reflector Problem 176 This attack only makes sense if source addresses can be spoofed. 177 Some issues about this are also covered under "Home Address Option" 178 sections. One can avoid being used in this reflecting attack by 179 performing proper ingress filtering at the "reflector" site. 181 Assume the scenario: 183 attacker1 --- rtr1 - Internet - rtr2 --- reflector2 184 | 185 rtr3 186 | 187 victim3 189 Now, assuming that ingress filtering is not done at rtr1 (from the 190 direction of attacker1) and rtr2 (from the direction of reflector2), 191 one could packets that would be sent anonymously to victim3 via 192 reflector2: 194 src=spoofed (attacker1) 195 dst=reflector2 196 rtheader=victim3, segments left=1 198 This way, if victim3 wants to investigate from where the packets are 199 coming from, first the trails would lead to reflector2. 201 One should note that even if rtr2 would be performing ingress 202 filtering, rtr2 itself, if the filtering is not carefully 203 implemented, is also susceptible to this. 205 It should be noted that one can never be safe from this, but if one 206 would be able to easily disable routing header processing (as it 207 should be in Hosts at the very least), the damage might be more 208 limited and controlling easier. 210 2.3. Some Requirements for Routing Header Use 212 One should not limit the flexibility of Routing Header usage too much 213 by too strict constraints. One could assume that it might be used 214 for at least: 216 - Mobile IPv6: packets are sent to the mobile node with the care-of 217 address as destination address and Home Address as the last 218 Routing Header entry. These should be assigned on the same node. 219 This way packets can be transmitted transparently between stable 220 addresses. 222 - Traffic engineering or multihoming: for example, one could want 223 to choose the ISP dynamically by some fine-grained criteria (e.g. 224 TCP destination port number) with an automatic use of Routing 225 Header. With this, the Routing Header processing nodes would 226 often be publicly known routers in a topologically important 227 location. 229 2.4. Solutions 231 2.4.1. Node-based Approach 233 Traffic engineering requirements are not difficult to meet; one just 234 has to assume that most routers do have Routing Header processing 235 enabled. This does not create new significant security 236 considerations, unless site's internal routers were to also do that. 237 It can be assumed that responsible administrators turn off the 238 feature on critical routers; Security Considerations section also 239 discusses this issue. 241 Mobile IPv6 is more difficult, as it requires that all mobile nodes 242 are able to completely process Routing Header. However, with MIPv6, 243 the maximum segments left value used is 1 when it reaches the 244 destination network. Taking this into consideration, we would be 245 able to deduce additional new rules for processing Routing Headers: 247 If a node would have to process the Routing Header (that is, 248 destination address equals the node and segments left > 0), it SHOULD 249 check whether segments left equals 1, and if both the current 250 destination address and to-be-swapped destination address in the 251 Routing Header are both assigned to the same interface of the node 252 and are both of the same zone [ADDRSCOPE], the Routing Header is here 253 referred to as "Interface-local Routing Header". 255 On Routers, further processing of Routing Headers SHOULD be 256 configurable and SHOULD be enabled by default. 258 On Hosts, further processing of Routing Headers MAY be configurable 259 and MUST be disabled by default. 261 Regardless of the general Routing Header processing setting, all 262 nodes SHOULD still process "Interface-local" Routing Headers. 263 Disabling this exception MAY also be configurable. 265 2.4.2. Network-based Approach 267 If the packet filters supported parsing Routing Header and performing 268 checks for it, one could argue that there might not be need to change 269 the processing in nodes. 271 The problem is that intermediate nodes, for example packet filters, 272 cannot distinguish mobile nodes from stationary nodes. The 273 distinguishing would only be possible if the node was located in such 274 a way (usually a single point of failure) that every Binding Update 275 would go through the intermediate node and it would keep state of 276 mobile nodes in the internal network. It might also be possible to 277 keep record of the state via some AAA mechanism. 279 If one assumes keeping state reliably cannot be done, one could 280 perform filtering in general case if and only if either is known: 282 - there are no mobile nodes in the internal network, either foreign 283 or local. 284 - the only mobile nodes in the internal network are foreign, only 285 roaming in the internal network. 287 The first scenario is trivial, but in the long run, probably too 288 restrictive. 290 In the second scenario one would have to require that the packets 291 with Routing Header must always "bounce out" of the internal network. 293 One should note that if this "bouncing out" is allowed, anyone can 294 use any node in the internal network as a traffic reflector if 295 ingress filtering isn't being used. 297 On the other hand, if one assumes the state of Mobile Bindings could 298 be kept, one could derive rules on packets from outside to inside, 299 for example: 301 - Packets with Routing Header going to mobile node care-of 302 Addresses are allowed if and only if they are "Interface-local". 303 - If packet with Routing Header bounces inside the internal 304 network, deny it by default (local policy issue). 305 - If packet with Routing Header bounces out of the internal 306 network, deny it by default (mostly testing scenarios) 307 - If packet with Routing Header bounces out of the internal 308 network, so that the final destination and source addresses are 309 equal, allow it by default (e.g. advanced traceroute, a special 310 case from above) 312 2.4.3. New Routing Header Type 314 A more radical approach might be to define a new Routing Header type. 315 This type would be syntactically identical to Type 0 Routing Header, 316 except it would have the requirement of "Interface-local" property, 317 as discussed above in 2.3.1, for the last-to-be-swapped addresses. 319 The "Interface-local" property would be a MUST to be observed at the 320 receiving side; otherwise the packet would be discarded (or 321 alternatively, delivered to the second-last address; the exact 322 behaviour is TBD). 324 This way, nodes communicating with mobile nodes would use this new 325 Routing Header type, which could be easily identifiable by 326 intermediate nodes (and passed through without too big worries about 327 security), and the processing of Type 0 Routing Header could remain 328 intact. Of course, it would still be allowed to send "Interface- 329 local" Routing Headers as Type 0, but practically the probability of 330 it getting through might be smaller. 332 A new Routing Header type would be of great help for both Node and 333 Network-based approaches. 335 An apparent problem of new Routing Header type is that all 336 participating nodes should be able to recognize and process it. 337 However, as MIPv6 is still work in progress, this might not be such a 338 big obstacle after all. 340 3. Home Address Option 342 Home Address option of Mobile IPv6 must be processed in every node 343 whether mobile or not. The source address of a packet is replaced 344 with the address in the Home Address option. The packets don't need 345 to be authenticated in any way. 347 The problem with Home Address is that it allows trivial 348 unidirectional spoofing (good for simple exploits, DoS attacks); 349 destinatation network's internal addresses can also be spoofed (which 350 could normally be prevented in destinatin network's border router by 351 ingress filtering). 353 One could argue that there will always exist operators that do not 354 perform ingress filtering, and as the packets are not in general 355 authenticated, the source address of an unauthenticated packet should 356 not be trusted anyway. 358 It is true that source address alone is not enough for 359 authentication, but it still should be enough for some rudimentary 360 form of identification. 362 3.1. The Source Address Spoofing Problem 364 Sites and operators perform ingress filtering to keep nodes from 365 spoofing their source address. With Home Address option, anyone can 366 work around these checks. An example: 368 host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2 370 Assume packets are originated from host1 with real IPv6 address 371 3ffe:ffff:0::1/64. Now fwrtr1 could perform ingress filtering from 372 the direction of host1 as follows: 374 [...] 375 allow ip from 3ffe:ffff:0:0::/64 to any 376 deny ip from any to any 377 [...] 379 And even if fwrtr1 fails to do that, rtrISP would probably perform 380 ingress filtering as well, with 3ffe:ffff:0::/48. 382 Now, malicious host1 would write packets as follows: 384 src=host1 (or some spoofed address from 3ffe:ffff::/64) 385 dst=host2 386 home address=3ffe:fff0::1 (or whatever) 388 The packet would have been dropped if 3ffe:fff0::1 had been put in 389 the source address itself. Now, however, the packet passes through 390 to host2, which MUST replace src=host1 with src=3ffe:fff0::1 based on 391 the Home Address option. 393 One could argue, that as the original source address is still in the 394 header (whether spoofed or not), it is not usable for spoofing. 395 Assuming the address could not be used, this would be only true to a 396 certain extent. Consider some foreign dial-up service portscanning 397 your network and/or looking for vulnerabilities. The account is 398 possibly stolen, or the local authorities do not care even if the IP 399 address was recorded in conjunction of a scan. However, with Home 400 Address option, you might be able to check whether the scanning with 401 some other IP addresses, e.g. a privileged address from the 402 destination network, would yield more interesting results. 404 3.2. The Double Spoofing Problem 406 This is an extension of a reflector attack with Routing Header from 407 section 2.2. The main purpose is to perform a denial of service, or 408 similar, attack, with an additional goal of blaming someone (or two 409 someones) else for it. 411 "Double Spoofing" is also possible if ingress filtering is only being 412 done very far in the upstream. Combined with Routing Header, this 413 could be used to throw blame on others. Assume scenario: 415 attacker1 --- rtr1 - rtrA -+- fwrtrBigISP 416 reflector3 --- rtr3 - rtrC -' | 417 Internet 418 | 419 fwrtr2 420 | 421 victim2 423 Now malicious attacker1 could write: 425 src=reflector3 426 dst=reflector3 427 rtheader=victim2, segments left=1 428 home address=thepresident.whitehouse.com 430 Even though victim2 noticed something strange was going on, 431 everything would point at reflector3, even the incoming packet trail 432 (note: there would still be a Routing Header with reflector3 in it, 433 so one might be able to notice something was not right); reflector3 434 would be too far away from attacker1 to pose a "threat" to attacker1. 436 Instead of reflector3, one could of course also use some unsuspecting 437 router on the other side of the globe. 439 Now, let's see what the packets would actually look like at victim2's 440 access logs. Casully checked, it would be like: 442 destination=victim2 443 source=thepresident.whitehouse.com 445 A more detailed analysis (a packet dump from the wire with a tool 446 that is able to parse home address) would indicate: 448 destination=victim2 449 source=reflector3 (or some spoofed address) 450 home address=thepresident.whitehouse.com 452 And complete data would be: 454 destination=victim2 455 source=reflector3 (or some spoofed address) 456 routing header=reflector3 457 home address=thepresident.whitehouse.com 459 As noted, a casual observer would probably blame 460 "thepresident.whitehouse.com" immediately. As of this writing, there 461 are no IPv6 packet filters or system-level loggers that would also 462 log the original source address; thus causing a very high probabily 463 for these false trails to go unnoticed. 465 3.3. Some Requirements for Home Address Option Use 467 Home Address option only makes sense when it's used by mobile nodes. 468 The intent is to make the use of care-of addresses transparent, and 469 it apparently should only be used when there exists, or is being 470 formed, a binding between the communicating two nodes. 472 3.4. Solutions 474 3.4.1. Node-based Approach 476 The most important thing is that Home Address option can be trusted 477 to do the right thing in the end node (so that there would be no need 478 to limit it in the network): Home Address must not be allowed to be 479 used by completely untrusted and unauthenticated users. 481 How this is achieved is beside the point; one way to get to this 482 would be to revise the processing rules as follows: 484 Home Address option MUST NOT be processed unless either of the two 485 applies: 487 - the packet, including Home Address option, is authenticated, and 488 the authentication is verified to be correct. 490 - there exists a binding between the source address and Home 491 Address in the destination node, and the binding was created 492 securely. 494 One should note that the latter might require some additional changes 495 in Mobile IPv6, as it is required that all Binding Updates MUST also 496 include a Home Address option, thus creating a chicken-and-egg 497 problem. One should use authentication for these, though. 499 3.4.2. Network-based Approach 501 The discussion of Network-based Approach under Routing Header applies 502 to Home Address as well; without state, and assuming there are mobile 503 nodes in the network, it's impossible to create generic rules on 504 which would be an allowed Home Address and which not. 506 As the address to be compared against is the source address, not 507 destination, without keeping state filtering could be performed if 508 and only if: 510 - local mobile nodes never roam outside of the internal network 511 performing filtering. 513 4. Conclusions 515 It's very difficult to securely control, above all Mobile IPv6 516 -related, use of Home Address and Routing Header in the network. 517 Even if the packet filters would support rule-based matching of Home 518 Address and Routing Header fields, it would be practically impossible 519 to create any kind of general rules on what should be allowed and 520 what not. 522 Therefore, improving the node-based security should definitely be 523 taken into consideration. Additional, local policies can also be be 524 made in very advanced packet filters, but the existence of this 525 technology must not be relied on. 527 To summarize, the author believes the following should be done: 529 - Routing Header processing be disabled on all hosts except for 530 Interface-local Routing Headers, or a new Routing Header type 531 taken to use for MIPv6 purposes, and 533 - Home Address option processing in the correspondent nodes revised 534 in such a way that HA option will only be processed if it is 535 provably secure or the binding that will use it was created 536 securely. 538 5. Security Considerations 540 This draft discusses security considerations; only some of the 541 presented issues (mostly acknowledged problems) are presented here. 543 It was suggested that Routers should by default process Routing 544 Header packets. It is assumed that site internal routers should have 545 this feature disabled (or controlled) by the administration. If this 546 is not done, the routers could be used to reflect packets and 547 possibly avoid access controls as outlined in section 2.1. 549 One should note that note that "Interface-local" property of Routing 550 Headers is important to be, indeed interface-specific, not node- 551 specific. Consider a node with two interfaces, one public, and one 552 completely private. Even if a private service would be bound to the 553 private interface only, one should not be able to use this private 554 service from anywhere in the Internet. 556 Even the interface-locality is not bulletproof, as some addresses 557 assigned to the interface may be more private and public than others; 558 at least this way the potential harm can be minimized. 560 The same zone requirement is also important (how this is observed is 561 implementation dependent; the check doesn't need to be explicit in 562 Routing Header processing) so one cannot reach e.g. link- or site- 563 local addresses through Internet. 565 More fine-grained control of the two addresses could be obtained via 566 access lists if they support Routing Header processing. 568 6. Acknowledgements 570 Discussions with Francis Dupont led to the writing of this draft. 571 Valuable comments were received from Alexandru Petrescu. 573 7. References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [INGRESS] Ferguson, P., Senie, D., "Network Ingress Filtering", 579 BCP 38, RFC 2827, May 2000. 581 [IPV6] Deering, S., Hinden, R., "Internet Protocol, Version 6 582 (IPv6) Specification", RFC 2460, December 1998. 584 [MIPV6] Johnson, D., Perkins, C., "Mobility Support in IPv6", 585 draft-ietf-mobileip-ipv6-14.txt (work in progress). 587 [BUSEC] Arkko, J., "Issues in Protecting MIPv6 Binding Updates", 588 draft-arkko-mipv6-bu-security-00.txt (work in progress). 590 [ADDRSCOPE] Deering, S., et al. "IPv6 Scoped Address Architecture", 591 draft-ietf-ipngwg-scoping-arch-02.txt (work in progress). 593 Author's Address 595 Pekka Savola 596 CSC/FUNET 597 Espoo, Finland 598 EMail: psavola@funet.fi