idnits 2.17.1 draft-savola-ipv6-rh-ha-security-03.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. ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. ** 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 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 174 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 (December 2002) is 7803 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PAXSON' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-16 -- Possible downref: Normative reference to a draft: ref. 'BUSEC' -- Possible downref: Normative reference to a draft: ref. 'ADDRSCOPE' == Outdated reference: A later version (-04) exists of draft-ietf-itrace-01 -- Possible downref: Normative reference to a draft: ref. 'ITRACE' -- Possible downref: Non-RFC (?) normative reference: ref. 'REVITRACE' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: June 2003 5 December 2002 7 Security of IPv6 Routing Header and Home Address Options 9 draft-savola-ipv6-rh-ha-security-03.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. It will be 40 shown that with the current architecture, the network-based security 41 does not seem to scale to the requirements of Mobile IPv6; it seems 42 possible that unless security is taken seriously when implementing 43 the nodes, the new Mobile IPv6 requirements might not be allowed to 44 be used at all in some circumstances. 46 Table of Contents 48 1. Introduction ............................................... 2 49 1.1. Terminology ............................................ 3 50 2. Routing Header ............................................. 4 51 2.1. The Traffic Filtering Problem .......................... 4 52 2.2. The Denial of Service Reflector Problem ................ 5 53 2.3. The ICMP Traceback Avoidance Problem ................... 6 54 2.4. Some Requirements for Routing Header Use ............... 7 55 2.5. Solutions .............................................. 7 56 2.5.1. Node-based Approach ................................ 8 57 2.5.2. Second Node-based Approach ......................... 8 58 2.5.3. Network-based Approach ............................. 9 59 2.5.4. New Routing Header Type ............................ 10 60 3. Home Address Option ........................................ 11 61 3.1. The Source Address Spoofing Problem .................... 11 62 3.2. The Double Spoofing Problem ............................ 13 63 3.3. The Protocol Reflection and Untraceability Problem ..... 14 64 3.4. Some Requirements for Home Address Option Use .......... 15 65 3.5. Solutions .............................................. 15 66 3.5.1. Node-based Approach ................................ 15 67 3.5.2. Network-based Approach ............................. 15 68 4. Conclusions ................................................ 16 69 5. Security Considerations .................................... 16 70 6. Acknowledgements ........................................... 17 71 7. References ................................................. 17 72 Author's Address ............................................... 18 74 1. Introduction 76 All IPv6 nodes must be able to process Routing Header [IPV6] and Home 77 Address [MIPV6] Options. With these, packet filter access lists can 78 be tricked (among other things) as the destination and source 79 addresses, respectively, are being rewritten as the packet traverses 80 the network. 82 Some of the security considerations of these features are analyzed, 83 and a few possible solutions presented. 85 For both Routing Header and Home Address options, basically two 86 approaches to enhance security are put forward. It will be shown 87 that with the current architecture, the network-based security will 88 not seem to scale to the requirements of Mobile IPv6; it seems 89 possible that unless security is taken seriously when implementing 90 the nodes, the new Mobile IPv6 requirements might not be allowed to 91 be used at all in some circumstances. 93 In many cases, ingress and egress filtering [FILTERING] are being 94 performed. Unfortunately, the filtering is not being done 95 everywhere; the existance of it cannot be relied on. Routing Header 96 and especially Home Address options are very harmful if at least 97 ingress filtering is not being performed, but to some extent, they 98 can still be used quite effectively if filtering is in place too. 100 Routing Header and Home Address Option can be used in helping to hide 101 the traces of DoS attacks from certain tracing methods. Here, ICMP 102 Traceback [ITRACE] and Reverse ICMP Traceback [REVITRACE] are used as 103 examples; the issues most probably affect other mechanisms as well. 105 A lot of discussion here is based on the fact that in the real world, 106 packet filtering is a practical requirement for safe operation; 107 almost everyone uses it. Therefore, it is important that it can be 108 performed in a predictable fashion. 110 The security of Binding Updates is another very crucial issue but 111 that is already discussed in other proposals, including [BUSEC]. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 1.1. Terminology 119 Ingress filtering 121 Filtering on source addresses from the direction of a site to 122 the Internet. This is often done to keep the site from using 123 wrong source addresses. 125 Egress filtering 127 Filtering on source addresses from the direction of the Internet 128 to the site. This is often done to keep packets with IP 129 addresses belonging to the site from arriving in the site from 130 the Internet 132 Reflected attacks 134 Attacks that are launched by the attacker, using a third party 135 as a proxy, against the victim. Here, the term is used in a 136 more generic sense than in, for example, [PAXSON]. 138 2. Routing Header 140 All IPv6 nodes must be able to process Routing Headers. It is 141 implied, even though not clearly stated, that all nodes (including 142 hosts) must also have that processing enabled. 144 Here, "Routing Header" is used as a synonym for "Type 0 Routing 145 Header" unless explicitly stated otherwise as it is the only type 146 defined at the moment. 148 There are several problems with Routing Headers: 150 - Getting around access controls if done with destination address 151 - The behaviour is difficult to disable if one wants to support 152 Mobile IPv6 153 - Can be used in reflected Denial of Service attacks 154 - Can be used to make tracing the path of DoS attacks with iTrace 155 [ITRACE] more difficult. 157 These are discussed at more length below. 159 2.1. The Traffic Filtering Problem 161 Because destination address is replaced at every Routing Header 162 processing point, it's impossible to perform traffic filtering based 163 on destination addresses. An example: 165 host1 --- rtr1 - Internet - fwrtr2 -+- webserver 166 | 167 +- host2 169 Assume that fwrtr2 is performing packet filtering on the internal 170 interface. The rules could be like: 172 [...] 173 allow proto tcp from any to webserver port 80 174 deny proto tcp from any to any 175 [...] 177 Here, malicious host1 would write packets as follows: 179 src=host1 180 dst=webserver 181 rtheader=host2, segments left=1 182 payload proto=tcp, dport=80 184 It would pass the packet filter checks fine, and be processed at 185 webserver. When being forwarded directly from there to host2, the 186 packet would look like: 188 src=host1 189 dst=host2 190 rtheader=webserver, segments left=0 191 payload proto=tcp, dport=80 193 If the packet had been sent directly to host2 without Routing Header, 194 it would have been denied in the packet filter access lists. 196 Even though webserver is configured as a Host, it will forward 197 packets with Routing Header. This breaks the principle of least 198 surprise, and as any node can be used as a traffic reflector, the 199 network is very difficult to secure. 201 The same naturally applies to Routers too, but they usually don't 202 have many publically available services, so they aren't optimal for 203 this kind of "access list avoidance via a reflector" attack. 205 2.2. The Denial of Service Reflector Problem 207 This attack only makes sense if source addresses can be spoofed. 208 Some issues about this are also covered under "Home Address Option" 209 sections. One can avoid being used in this reflecting attack by 210 performing proper ingress filtering at the "reflector" site. 212 So, this method can be used to route Denial of Service attacks 213 through intermediary reflectors, to make it more difficult to trace 214 them. 216 Assume the scenario: 218 attacker1 --- rtr1 - Internet - rtr2 --- reflector2 219 | 220 rtr3 221 | 222 victim3 224 Now, assuming that ingress filtering is not done at rtr1 (from the 225 direction of attacker1) and rtr2 (from the direction of reflector2), 226 one could send packets that would be reflected anonymously to victim3 227 via reflector2: 229 src=spoofedX (attacker1) 230 dst=reflector2 231 rtheader=victim3, segments left=1 233 This way, if victim3 wants to investigate from where the packets are 234 coming from, first the source would appear to be spoofedX; it may or 235 may not be obvious to victim3 whether the address is spoofed. Then, 236 investigating Routing Header, the trails would lead to reflector2, 237 where they would disappear. 239 However, it should be noted that reliance on Routing Header trails is 240 very chancy at best. The attacker could very well construct a packet 241 with false routing header entries, like: 243 src=spoofedX (attacker1) 244 dst=reflector2 245 rtheader=someoneA,victim3, segments left=1 247 At reflectror2, the packets are now directed straight to victim3 248 (because segments left is one smaller than it normally should be) and 249 one node (someoneA) would only be inserted for false trails. 250 Segments left could have been 0 at the sender, for all the 251 destination knows. So, in consequence, the packets can be made to 252 look like they went through someoneA but really didn't. 254 One should note that even if rtr2 would be performing ingress 255 filtering, rtr2 itself, if the filtering is not carefully 256 implemented, is also susceptible to this. 258 It should be noted that one can never be safe from this, but if one 259 would be able to easily disable routing header processing (as it 260 should be in Hosts at the very least), the damage might be more 261 limited and controlling easier. 263 2.3. The ICMP Traceback Avoidance Problem 265 ICMP Traceback [ITRACE] specifies a new method where intermediate 266 routers may send ICMP Traceback messages probabilistically along the 267 path of the packets to the destination address. Among others, this 268 can be used to trace the origin of Denial of Service attacks with 269 forged source addresses. 271 If the attacker inserts a Routing Header in the spoofed packets, the 272 only iTrace messages to reach the final destination will be those 273 that came from between the last Routing Header entry and the final 274 destination. To illustrate a simple scenario: 276 attacker1 -- Internet -- rtr2 -- Internet -- victim3 277 (20 hops) (10 hops) 279 Here, iTrace messages from between attacker1 and rtr2 (the really 280 interesting data) would be sent to rtr2, and from between rtr2 and 281 victim3 to victim3. Rtr2 would probably just discard the messages, 282 having no knowledge what to do with them. Victim3 would receive 283 messages only from 10 last hops which would be next to unusable. 285 Naturally, it would be possible to circulate the traffic via many 286 different routers, possibly adding a few in the list for confusion 287 (that is, using smaller segments left than the number of routers, as 288 described above). 290 One could revise the iTrace specification so that it'll send messages 291 to every destination listed in the routing header, but it might be 292 more appropriate just to acknowledge the problem; after all, victim3 293 would know from the packets it receives that rtr2 should know the 294 full path, and contact its adminitration. 296 2.4. Some Requirements for Routing Header Use 298 One should not limit the flexibility of Routing Header usage too much 299 by too strict constraints. One could assume that it might be used 300 for at least: 302 - Mobile IPv6: packets are sent to the mobile node with the care-of 303 address as destination address and Home Address as the last 304 Routing Header entry. These should be assigned on the same node. 305 This way packets can be transmitted transparently between stable 306 addresses. 308 - Traffic engineering or multihoming: for example, one could want 309 to choose the ISP dynamically by some fine-grained criteria (e.g. 310 TCP destination port number) with an automatic use of Routing 311 Header. With this, the Routing Header processing nodes would 312 often be publicly known routers (identifiable by specific 313 configuration or an anycast address, for example) in a 314 topologically important location. 316 2.5. Solutions 318 Two node-based approaches are defined. It is expected that only one 319 would be chosen when it becomes more clear which one is best. 321 2.5.1. Node-based Approach 323 Traffic engineering requirements are not difficult to meet; one just 324 has to assume that most routers do have Routing Header processing 325 enabled. This does not create new significant security 326 considerations, unless site's internal routers were to also process 327 Routing Headers. It can be assumed that responsible administrators 328 turn off the feature on critical routers; Security Considerations 329 section also discusses this issue. 331 Mobile IPv6 is more difficult, as it requires that all mobile nodes 332 are able to completely process Routing Header. However, with MIPv6, 333 the maximum segments left value used is 1 when it reaches the 334 destination network. Taking this into consideration, we would be 335 able to deduce additional new rules for processing Routing Headers 336 (we're assuming here that Home Address would be assigned on the 337 appropriate interface; please also see Security Considerations about 338 this): 340 If a node would have to process the Routing Header (that is, 341 destination address equals the node and segments left > 0), it SHOULD 342 check whether segments left equals 1, and if both the current 343 destination address and to-be-swapped destination address in the 344 Routing Header are both assigned to the same interface of the node 345 and are both of the same zone [ADDRSCOPE], the Routing Header is here 346 referred to as "Interface-local Routing Header". 348 On Routers, further processing of Routing Headers SHOULD be 349 configurable and SHOULD be enabled by default. 351 On Hosts, further processing of Routing Headers MAY be configurable 352 and MUST be disabled by default. 354 Regardless of the general Routing Header processing setting, all 355 nodes SHOULD still process "Interface-local" Routing Headers. 356 Disabling this exception MAY also be configurable. 358 2.5.2. Second Node-based Approach 360 This approach just tackles the current Routing Header use 361 requirements (Mobility), and leaves the rest undefined; as the 362 processing rule change would be rather simple, this might be the best 363 way forward until it becomes clear for what else "Interface-local" 364 Routing Headers would be needed for. The revision would be as 365 follows: 367 On Hosts, Routing Header processing MUST be supported, but the 368 processing MUST NOT be enabled by default. The enabling of the 369 processing SHOULD be configurable. 371 Regardless of the processing setting above, routing headers destined 372 to the host are further processed if the following applies: 374 type == 0 and segments left == 1 and, 375 if the to-be-swapped address in Routing Header is either: 377 1. a Home Address assigned to the node, 379 the Routing Header MUST be processed in full. 381 2. or, an address which has been authorized in some way to be a 382 valid target of routing header processing, 384 the Routing Header MAY be processed in full. 386 2.5.3. Network-based Approach 388 If the packet filters supported parsing Routing Header and performing 389 checks for it, one could argue that there might not be need to change 390 the processing in nodes. 392 The problem is that intermediate nodes, for example packet filters, 393 cannot distinguish mobile nodes from stationary nodes. The 394 distinguishing would only be possible if the node was located in such 395 a way (usually a single point of failure) that every Binding Update 396 would go through the intermediate node and it would keep state of 397 mobile nodes in the internal network. It might also be possible to 398 keep record of the state via some AAA mechanism. 400 If one assumes keeping state reliably cannot be done, one could 401 perform filtering in general case if and only if either is known: 403 - there are no mobile nodes in the internal network, either foreign 404 (Home Agent is not in this network) or local. 405 - the only mobile nodes in the internal network are foreign, only 406 roaming in the internal network. 408 The first scenario is trivial, but in the long run, probably too 409 restrictive. 411 In the second scenario one would have to require that the packets 412 with Routing Header must not have the to-be-swapped address 413 topologically in the internal network ("must bounce out"). 415 One should note that if this "bouncing out" is allowed, anyone can 416 use any node in the internal network as a traffic reflector if 417 ingress filtering isn't being used. 419 On the other hand, if one assumes the state of Mobile Bindings could 420 be kept, one could derive rules on packets from outside to inside, 421 for example: 423 - Packets with Routing Header going to mobile node care-of 424 Addresses are allowed if and only if they are "Interface-local". 425 - If packet with Routing Header bounces inside the internal 426 network, deny it by default (local policy issue). 427 - If packet with Routing Header bounces out of the internal 428 network, deny it by default (mostly testing scenarios) 429 - If packet with Routing Header bounces out of the internal 430 network, so that the final destination and source addresses are 431 equal, allow it by default (e.g. advanced traceroute, a special 432 case from above) 434 2.5.4. New Routing Header Type 436 A more radical approach might be to define a new Routing Header type. 437 This type would be syntactically identical to Type 0 Routing Header, 438 except it would have the requirement of "Interface-local" property, 439 as discussed above in 2.3.1, for the last-to-be-swapped addresses. 441 The "Interface-local" property would be a MUST to be observed at the 442 receiving side; otherwise the packet would be discarded (or 443 alternatively, delivered to the second-last address; the exact 444 behaviour is TBD). 446 This way, nodes communicating with mobile nodes would use this new 447 Routing Header type, which could be easily identifiable by 448 intermediate nodes (and passed through without too big worries about 449 security), and the processing of Type 0 Routing Header could remain 450 intact. Of course, it would still be allowed to send "Interface- 451 local" Routing Headers as Type 0, but practically the probability of 452 it getting through might be smaller. 454 A new Routing Header type would be of great help for both Node and 455 Network-based approaches. 457 An apparent problem of new Routing Header type is that all 458 participating nodes should be able to recognize and process it. 459 However, as MIPv6 is still work in progress, this might not be such a 460 big obstacle after all. One should note, however, that this might 461 effectively hinder combining MIPv6-like Routing Header use with e.g. 462 certain traffic engineering solutions, as the participating 463 participating routers would have to be able to understand the new 464 Routing Header type. 466 3. Home Address Option 468 Home Address option of Mobile IPv6 must be processed in every node 469 whether mobile or not. The source address of a packet is replaced 470 with the address in the Home Address option. The packets don't need 471 to be authenticated in any way. 473 The problem with Home Address is that it allows trivial 474 unidirectional spoofing (good for simple exploits, DoS attacks); 475 destinatation network's internal addresses can also be spoofed (which 476 could normally be prevented in destinatin network's border router by 477 egress filtering). 479 As a general note on both spoofing attacks, one could argue that 480 there will always exist operators that do not perform filtering, and 481 as the packets are not in general authenticated, the source address 482 of an unauthenticated packet should not be trusted anyway. 484 It is true that source address alone is not enough for 485 authentication, but it still should be enough for some rudimentary 486 form of identification. 488 3.1. The Source Address Spoofing Problem 490 Sites and operators perform ingress filtering to keep nodes from 491 spoofing their source address. With Home Address option, anyone can 492 work around these checks. An example: 494 host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2 496 Assume packets are originated from host1 with real IPv6 address 497 3ffe:ffff:0::1/64. Now fwrtr1 could perform ingress filtering from 498 the direction of host1 as follows: 500 [...] 501 allow ip from 3ffe:ffff:0:0::/64 to any 502 deny ip from any to any 503 [...] 505 And even if fwrtr1 fails to do that, rtrISP would probably perform 506 ingress filtering as well, with 3ffe:ffff:0::/48. 508 Now, malicious host1 would write packets as follows: 510 src=host1 (or some spoofed address from 3ffe:ffff::/64) 511 dst=host2 512 home address=3ffe:fff0::1 (or whatever) 514 The packet would have been dropped if 3ffe:fff0::1 had been put in 515 the source address itself. Now, however, the packet passes through 516 to host2, which MUST replace src=host1 with src=3ffe:fff0::1 based on 517 the Home Address option. 519 A more dangerous variation is being able to circumvent egress 520 filtering of the destination site; with topology: 522 host1 --- rtr1 - Internet - fwrtr2 ---host2 523 3ffe:ffff:1::/48 3ffe:ffff:2::/48 525 Assume that fwrtr2 aims to protect the site by filtering all source 526 addresses belonging to the site that come from the direction of the 527 Internet, like: 529 [...] 530 deny ip from 3ffe:ffff:2::/48 to any interface from_internet 531 allow ip from any to 3ffe:ffff:2::/48 interface from_internet 532 [...] 534 Now, the attacking host1 could write packets as follows: 536 src= (or something from 3ffe:ffff:1::/48 if rtr1 is filtering) 537 dst=host2 538 home address=3ffe:ffff:2::2 (some trusted node in site2) 540 One could argue, that as the original source address is still in the 541 header (whether spoofed or not), it is not usable for spoofing. 542 Assuming the address could not be used, this would be only true to a 543 certain extent. Consider a user from some foreign dial-up service 544 looking for vulnerabilities. The account is possibly stolen, or the 545 local authorities do not care even if the IP address was recorded in 546 conjunction of the probing. However, with Home Address option, you 547 might be able to check whether the scanning with some other IP 548 addresses, e.g. a privileged address from the destination network, 549 would yield more interesting results. 551 3.2. The Double Spoofing Problem 553 This is an extension of a reflector attack with Routing Header from 554 section 2.2. The main purpose is to perform a denial of service, or 555 similar, attack, with an additional goal of blaming someone (or two 556 someones) else for it. 558 "Double Spoofing" is also possible if ingress filtering is only being 559 done very far in the upstream. Combined with Routing Header, this 560 could be used to throw blame on others. Assume the scenario: 562 attacker1 --- rtr1 - rtrA -+- fwrtrBigISP 563 reflector3 --- rtr3 - rtrC -' | 564 Internet 565 | 566 fwrtr2 567 | 568 victim2 570 Now malicious attacker1 could write: 572 src=reflector3 573 dst=reflector3 574 rtheader=victim2, segments left=1 575 home address=thepresident.whitehouse.com 577 Even though victim2 noticed something strange was going on, 578 everything would point at reflector3, even the incoming packet trail 579 (note: there would still be a Routing Header with reflector3 in it, 580 so one might be able to notice something was not right); reflector3 581 would be too far away from attacker1 to pose a "threat" to attacker1. 583 Instead of reflector3, one could of course also use some unsuspecting 584 router on the other side of the globe. 586 Now, let's see what the packets would actually look like at victim2's 587 access logs. Casully checked, it would be like: 589 destination=victim2 590 source=thepresident.whitehouse.com 592 A more detailed analysis (a packet dump from the wire with a tool 593 that is able to parse home address) would indicate: 595 destination=victim2 596 source=reflector3 (or some spoofed address) 597 home address=thepresident.whitehouse.com 599 And complete data would be: 601 destination=victim2 602 source=reflector3 (or some spoofed address) 603 routing header=reflector3 604 home address=thepresident.whitehouse.com 606 As noted, a casual observer would probably blame 607 "thepresident.whitehouse.com" immediately. As of this writing, there 608 are no IPv6 packet filters or system-level loggers that would also 609 log the original source address; thus causing a very high probabily 610 for these false trails to go unnoticed. 612 3.3. The Protocol Reflection and Untraceability Problem 614 ICMP Traceback [REVITRACE] suggest modifying iTrace so that it would 615 also be possible to send ICMP Traceback messages to the source of the 616 packets as well. There are certain issues with this, as the source 617 addresses are most probably spoofed, but here only the interaction 618 with Home Address Option is considered. 620 Here, with 'protocol reflector', we mean a more specific case of 621 packet reflection, as introduced in [PAXSON]. (For example, src sends 622 TCP SYN to protocol reflector, and reflector sends SYN+ACK to the 623 victim). Consider: 625 src = attacker (gets by ingress filtering) or some other node 626 dst = protocol reflector 627 home address = victim 629 The attacker could use Home Option to send these Reverse iTrace 630 packets to itself or some node that it believes will not react to 631 them. Now, Reverse iTrace messages would go to the attacker. Home 632 Address Option in protocol reflection is especially harmful, as once 633 reflected, the packet will look like: 635 src = reflector 636 dst = victim 638 And every trace of the message is lost, including Reverse iTrace 639 traceability. However, the path from the attacker to protocol 640 reflector would still be traceable with Forward iTrace; the issues 641 with this are discussed under "The ICMP Traceback Avoidance Problem" 642 section. 644 3.4. Some Requirements for Home Address Option Use 646 Home Address option only makes sense when it's used by mobile nodes. 647 The intent is to make the use of care-of addresses transparent, and 648 it apparently should only be used when there exists, or is being 649 formed, a binding between the communicating two nodes. 651 3.5. Solutions 653 3.5.1. Node-based Approach 655 The most important thing is that Home Address option can be trusted 656 to do the right thing in the end node (so that there would be no need 657 to limit it in the network): Home Address must not be allowed to be 658 used by completely untrusted and unauthenticated users. 660 How this is achieved is beside the point; one way to get to this 661 would be to revise the processing rules as follows: 663 Home Address option MUST NOT be processed unless either of the two 664 applies: 666 - the packet, including Home Address option, is authenticated, and 667 the authentication is verified to be correct. 669 - there exists a binding between the source address and Home 670 Address in the destination node, and the binding (usually, but 671 not necessary, one created with a Binding Update) was created 672 securely. 674 One should note that the latter might require some additional changes 675 in Mobile IPv6, as it is required that all Binding Updates MUST also 676 include a Home Address option, thus creating a chicken-and-egg 677 problem. One should use authentication for these, though. 679 It should be noted that this approach makes the so-called triangle 680 routing between MN, CN and HA impossible. 682 3.5.2. Network-based Approach 684 The discussion of Network-based Approach under Routing Header applies 685 to Home Address as well; without state, and assuming there are mobile 686 nodes in the network, it's impossible to create generic rules on 687 which would be an allowed Home Address and which not. 689 Without keeping state, filtering could be performed only if: 691 - local mobile nodes never roam outside of the internal network 692 performing filtering. 694 4. Conclusions 696 It's very difficult to securely control, above all Mobile IPv6 697 -related, use of Home Address and Routing Header in the network. 698 Even if the packet filters would support rule-based matching of Home 699 Address and Routing Header fields, it would be practically impossible 700 to create any kind of general rules on what should be allowed and 701 what not. 703 Therefore, improving the node-based security should definitely be 704 taken into consideration. Additional, local policies can also be be 705 made in very advanced packet filters, but the existence of this 706 technology must not be relied on. 708 To summarize, the author believes the following should be done: 710 - Routing Header processing be disabled on all hosts except for 711 Interface-local Routing Headers, or a new Routing Header type 712 taken to use for MIPv6 purposes, and 714 - Home Address option processing in the correspondent nodes revised 715 in such a way that HA option will only be processed if it is 716 provably secure or the binding that will use it was created 717 securely. 719 - It should be considered whether the use of Routing Headers or 720 Home Address Option makes traceback mechanisms too non-effective, 721 and whether the mechanisms should be revised. 723 5. Security Considerations 725 This draft discusses security considerations; only some of the 726 presented issues (mostly acknowledged problems) are presented here. 728 The widespread use of Routing Header or Home Address Options may make 729 traceback mechanisms at least partially non-effective. 731 It was suggested that Routers should by default process Routing 732 Header packets. It is assumed that site internal routers should have 733 this feature disabled (or controlled) by the administration. If this 734 is not done, the routers could be used to reflect packets and 735 possibly avoid access controls as outlined in section 2.1. 737 One should note that note that "Interface-local" property of Routing 738 Headers is important to be, indeed interface-specific, not node- 739 specific. Consider a node with two interfaces, one public, and one 740 completely private. Even if a private service would be bound to the 741 private interface only, one should not be able to use this private 742 service from anywhere in the Internet. 744 Even the interface-locality is not bulletproof, as some addresses 745 assigned to the interface may be more private and public than others; 746 at least this way the potential harm can be minimized. 748 It is clear that interface-locality is a must in certain scenarios 749 (e.g. a security gateway, or a secure node), but in a general case, 750 it is debateable whether a significant loss of security would occur 751 if the restriction would be lifted from normal hosts. 753 The same zone requirement is also important (how this is observed is 754 implementation dependent; the check doesn't need to be explicit in 755 Routing Header processing) so one cannot reach e.g. link- or site- 756 local addresses through Internet. 758 More fine-grained control of the two addresses could be obtained via 759 access lists if they support Routing Header processing. 761 6. Acknowledgements 763 Discussions with Francis Dupont led to the writing of this draft. 764 Valuable comments were received from Alexandru Petrescu. Erik 765 Nordmark provided extensive commentary and brought up the interaction 766 with Reverse iTrace. Jarmo Molsa reviewed a later version of the 767 draft. 769 7. References 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, March 1997. 774 [FILTERING] Killalea, T., "Recommended Internet Service Provider 775 Security Services and Procedures", BCP 46, RFC 3013, 776 Nov 2000. 778 [PAXSON] Paxson, V., "An Analysis of Using Reflectors for 779 Distributed Denial-of-Service Attacks", Jun 2001, 780 http://www.aciri.org/vern/papers/reflectors.CCR.01/. 782 [IPV6] Deering, S., Hinden, R., "Internet Protocol, Version 6 783 (IPv6) Specification", RFC 2460, December 1998. 785 [MIPV6] Johnson, D., Perkins, C., "Mobility Support in IPv6", 786 draft-ietf-mobileip-ipv6-16.txt (work in progress). 788 [BUSEC] Arkko, J., "Issues in Protecting MIPv6 Binding Updates", 789 draft-arkko-mipv6-bu-security-01.txt (work in progress). 791 [ADDRSCOPE] Deering, S., et al. "IPv6 Scoped Address Architecture", 792 draft-ietf-ipngwg-scoping-arch-04.txt (work in progress). 794 [ITRACE] Bellovin, S., Leech, M., Taylor, T., "ICMP Traceback 795 Messages", draft-ietf-itrace-01.txt (work in progress). 797 [REVITRACE] Barros, C., "A Proposal for ICMP Traceback Messages", 798 http://www.research.att.com/lists/ietf-itrace/2000/09/ 799 msg00044.html. 801 Author's Address 803 Pekka Savola 804 CSC/FUNET 805 Espoo, Finland 806 EMail: psavola@funet.fi