idnits 2.17.1 draft-savola-v6ops-firewalling-02.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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 623: '... nodes MUST discard certain kinds of...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 504 has weird spacing: '...wall is extre...' == Line 601 has weird spacing: '...tion is detec...' -- 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 2003) is 7496 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) == Missing Reference: 'IP' is mentioned on line 437, but not defined == Unused Reference: 'ICMPV6' is defined on line 643, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'ADDRARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-flow-label-07 == Outdated reference: A later version (-04) exists of draft-ietf-send-psreq-03 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 2 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 2004 5 October 2003 7 Firewalling Considerations for IPv6 9 draft-savola-v6ops-firewalling-02.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 There are quite a few potential problems regarding firewalling or 35 packet filtering in IPv6 environment. These include slight ambiguity 36 in the IPv6 specification, problems parsing packets beyond unknown 37 Extension Headers and Destination Options, and introduction of end- 38 to-end encrypted traffic and peer-to-peer applications. There may 39 also be need to extend packet matching to include some Extension 40 Header or Destination Option fields. A number of often-raised, but 41 not necessary relevant, issues are also summarized. This memo 42 discusses these issues to raise awareness and proposes some tentative 43 solutions or workarounds. 45 Table of Contents 47 1. Introduction ............................................... 2 48 1.1. Terminology ............................................ 3 49 2. Ambiguous Text in the IPv6 Specification ................... 4 50 2.1. The Problem ............................................ 4 51 2.2. Possible Solutions ..................................... 5 52 3. Parsing Extension Header Chains ............................ 6 53 3.1. The Problem ............................................ 6 54 3.2. Possible Solutions ..................................... 6 55 4. Parsing Unknown Destination Options and Security Policy .... 7 56 4.1. The Problem ............................................ 7 57 4.2. Possible Solutions ..................................... 7 58 5. Firewalls and End-to-End IPsec-encrypted ESP-traffic ....... 8 59 5.1. The Problem ............................................ 8 60 5.2. Possible Solutions ..................................... 8 61 6. Firewalls and Interactions with Peer-to-Peer Applications .. 9 62 6.1. The Problem ............................................ 9 63 6.2. Possible Solutions ..................................... 9 64 7. Other Issues Associated with IPv6 Firewalls ................ 10 65 7.1. IPv4 ARP vs IPv6 Neighbor Discovery .................... 10 66 7.2. Filtering Specific Neighbor Discovery Messages ......... 10 67 7.3. Firewall Policies and Multiple Addresses per Node ...... 11 68 7.4. Firewall Transparency in the Network ................... 11 69 8. Security Considerations .................................... 12 70 9. Acknowledgements ........................................... 12 71 10. References ................................................ 12 72 10.1. Normative References .................................. 12 73 10.2. Informative References ................................ 12 74 Author's Address ............................................... 13 75 A. Possible Desirable Header Field Matching Extensions ........ 13 76 B. Amplification DoS Attack Using IPv6 Multicast .............. 14 77 Intellectual Property Statement ................................ 15 78 Full Copyright Statement ....................................... 15 80 1. Introduction 82 There are quite a few potential problems regarding firewalling or 83 packet filtering in IPv6 environment. These include slight ambiguity 84 in the IPv6 specification, problems parsing packets beyond unknown 85 Extension Headers and Destination Options, and introduction of end- 86 to-end encrypted traffic and peer-to-peer applications. There may 87 also be need to extend packet matching to include some Extension 88 Header or Destination Option fields. A number of often-raised, but 89 not necessary relevant, issues are also summarized. 91 This memo discusses these issues to raise awareness and proposes some 92 tentative solutions or workarounds. This document is not meant as a 93 guide on how to set up IPv6 firewall policies (for example), but 94 rather as a list of problematic issues to be considered by firewall 95 developers, subject matter experts and those partipating in the IPv6 96 standardization effort. 98 On-link attacks using Neighbor Discovery are similar to ones 99 available through IPv4 ARP, and not typically applicable to 100 firewalls, and are therefore out of scope. A good summary of the 101 issues is available [SENDREQ]. However, one should note that IPv4 102 ARP traffic is done using link-layer protocols, and is not generally 103 seen (or blocked, even with a "deny all" policy) by firewalls; with 104 IPv6, all such traffic is part of ICMPv6 Neighbor Discovery protocol 105 suite, and thus more visible at the IP layer. 107 Implementation or policy-specific issues are mainly out of scope but 108 partially touched on in section 7 about "non-problems"; these include 109 e.g. issues of node-specific state creation (could be problematic if 110 networks were brute-force scanned) and applicability of existing 111 policies (e.g. blocking ICMPv6 would have very bad effects, 112 particularly if certain link-local messages receive no special 113 consideration). 115 In section 2, slightly ambiguous text in the IPv6 specification is 116 discussed. In section 3, a syntactical problem with parsing unknown 117 Extension Headers is pointed out. In section 4, a similar problem 118 with Destination Options is discussed in the context of security 119 policy. In section 5, implications of end-to-end encrypted traffic 120 are considerated. In section 6, similar implications of peer-to-peer 121 applications are mentioned. In section 7, a number of often-raised, 122 but not necessary relevant, issues are summarized. In appendix A, 123 some possibly useful packet matching extensions for IPv6 are brought 124 up. 126 A possible generic denial-of-service attack using multicast and 127 including amplification has also been noticed; as it is not firewall- 128 specific, it is described (for the lack of a better place) with in 129 Appendix B. 131 1.1. Terminology 133 In this document, the term "firewall" is used to mean any kind of 134 packet filter; no special features (like statefullness or 135 application-specific packet inspection) is assumed. 137 When considering firewalls, one should note that there are several 138 ways to place and implement a firewall; in principle: 140 1. network firewall 142 2. network, user-controlled firewall 144 3. end-node, admin-controlled firewall 146 4. end-node firewall 148 Note that the second seems very rare, and the third is not really 149 common yet. The reason why the entity which controls the firewall is 150 explicitly mentioned is because it has significant implications on 151 trust relations and which kind of solutions to the problems are 152 possible. 154 The first is configured solely by an administrator, and placed in the 155 network to block or pass the traffic of multiple nodes or network in 156 an aggregated fashion. 158 The second is also configured by an administrator and placed in the 159 network, but the user may be able to affect some policy decisions 160 made in the firewall e.g. by some signalling protocol; ie. the policy 161 of the firewall can, to some extent, be influenced by the end-nodes. 163 The third, also sometimes called a distributed firewall, is a 164 firewall placed in the end-nodes, but controlled in some co-ordinated 165 fashion by an administrator [DISFW]. 167 The last is the typical end-node firewall, policy set by the end- 168 user, or sometimes even the applications run on the end-node. 170 2. Ambiguous Text in the IPv6 Specification 172 2.1. The Problem 174 The [IPV6] specification forbids skipping over any of the headers 175 before processing them or processing them at all before reaching the 176 destination (section 4): 178 "With one exception, Extension Headers are not examined or processed 179 by any node along a packet's delivery path, until the packet reaches 180 the node (or each of the set of nodes, in the case of multicast) 181 identified in the Destination Address field of the IPv6 header. 182 There, normal demultiplexing on the Next Header field of the IPv6 183 header invokes the module to process the first Extension Header, or 184 the upper-layer header if no Extension Header is present. The 185 contents and semantics of each Extension Header determine whether or 186 not to proceed to the next header. Therefore, Extension Headers must 187 be processed strictly in the order they appear in the packet; a 188 receiver must not, for example, scan through a packet looking for a 189 particular kind of Extension Header and process that header prior to 190 processing all preceding ones." 192 And: 194 "If, as a result of processing a header, a node is required to 195 proceed to the next header but the Next Header value in the current 196 header is unrecognized by the node, it should discard the packet and 197 send an ICMP Parameter Problem message to the source of the packet, 198 with an ICMP Code value of 1 ("unrecognized Next Header type 199 encountered") and the ICMP Pointer field containing the offset of the 200 unrecognized value within the original packet. The same action 201 should be taken if a node encounters a Next Header value of zero in 202 any header other than an IPv6 header." 204 Similar applies to the specified Destination Options processing 205 behaviour: if the Option Type has been specified so that the packet 206 should not be processed further in the case of unrecognized options 207 (ie. the highest-order two bits are not "00"), should the firewall 208 also discard the packet and/or send ICMP Parameter Problem message 209 back to the source? 211 Are these also to be done by intermediate nodes (which, by some 212 definition, should not be processing Extension Headers or Destination 213 Options Header with Hop-by-Hop options as an exception); this seems 214 unlikely. 216 This wording clearly does not take into the account that there might 217 be middleboxes, or non-final destinations, that could be processing 218 the packet. 220 2.2. Possible Solutions 222 The correct behaviour must be made clear; the wording should be 223 clarified. Clarifications might be needed at least on: 225 1. whether intermediate nodes should be taken into account in the 226 text describing the header processing 228 2. intermediate nodes' behaviour when detecting unrecognized 229 headers 231 It seems to be obvious that the firewalls will always inspect the 232 headers, and in whichever order they want; see the next sections for 233 descriptions of the specific problems. 235 3. Parsing Extension Header Chains 237 3.1. The Problem 239 IPv4 [RFC1122] [RFC1812] silently ignores options it does not 240 recognize; options have a specific, pre-defined format. IPv6 241 Extension Headers are structured differently: the header format can 242 change, and generally it is not possible to parse the header, or 243 proceed to the following Extension Headers unless the processing of 244 the previous header has been implemented. 246 The above is problematic as it is often the case that a packet filter 247 will want to examine the terminal headers, e.g. TCP or UDP. That is 248 not possible if there is a problem processing any one of the 249 preceding headers. 251 Skipping over unknown headers and letting the packet through might be 252 dangerous, if the unknown header would significantly change how the 253 packet would be interpreted by the end-node. 255 One should note that all the currently defined Extension Headers, 256 except Fragmentation, are encoded in the Type, Length, Value (TLV) 257 -notation. 259 3.2. Possible Solutions 261 In the generic case, even ignoring the IPv6 specification, unknown 262 headers cannot be skipped over except by making some very wild 263 guesses of the content. Thus the solutions (or work-arounds) are: 265 1. always keep the packet filter up-to-date, so that it can parse 266 all types of Extension Headers, 268 2. never introduce new Extension Headers, except possibly in a 269 very controlled manner; use Destination Options instead, or 271 3. standardize the format (for at least the first N bytes 272 including at least the length and the next header value) of 273 possibly later specified new Extension Headers (for example, 274 that all the new ones must be in TLV format), so that skipping 275 over headers could be possible. 277 The first is not a workable solution in a generic case at least if 278 it's expected that new Extension Headers should be introducable: the 279 lifetime of firewall devices and software seems to be much longer 280 than one would expect. For example, it is good to consider the case 281 of buggy firewalls and ECN support [ECN]: even though software fixes 282 may have been available for a long time, upgrades have not taken 283 place, hindering the deployment of new technology. It seems that 284 keeping up with Extension Headers is not possible: software firewalls 285 and their patch cycle are a problem big enough already, without 286 considering hardware firewalls which could need new hardware 287 implementations as well. 289 The second seems quite a bleak work-around, but as currently 290 specified, there is little choice; most (if not all) new features can 291 probably be implemented using Destination Options. However, it's 292 still good to document and understand this deployment and 293 specification deadlock. 295 The third might be doable but it would require some standardization 296 effort. 298 4. Parsing Unknown Destination Options and Security Policy 300 4.1. The Problem 302 Similar to the above, Destination Options may also include unknown 303 options. However, the options are encoded in the TLV-format. So, 304 skipping over unknown options is technically possible. 306 However, especially in a very controlled environments, where a 307 firewall may implement a strict security policy, it may be desirable 308 to reject any packets whose options the firewall does not recognize 309 (which may cause the end-nodes to do something that has not been 310 anticipated in the security policy controlled by the firewall). 312 Skipping over unknown destination options and letting the packet 313 through might be dangerous, if the unknown option would significantly 314 change how the packet would be interpreted by the end-node. 316 4.2. Possible Solutions 318 No protocol action seems to be necessary provided that the 319 implementation would not, in this case, send ICMPv6 messages or 320 discard packets upon receiving an unknown header. 322 However, it may be desirable for firewall implementations to have a 323 feature controlling the handling behaviour of unrecognized 324 Destination Options. 326 5. Firewalls and End-to-End IPsec-encrypted ESP-traffic 328 5.1. The Problem 330 With the promise of the restoration of end-to-end transparency, and 331 if at least some of the challenges for implementing Public Key 332 Infrastructures are worked around, it may be possible that the amount 333 of end-to-end encrypted traffic will increase enermously. The 334 traffic is likely to be encrypted using IPsec. 336 In this case, on-the-path observers (such as a firewall) do not have 337 the possibility to examine the usually critical headers (such as 338 TCP/UDP). This may result in an administrative decision to disable 339 IPsec-encrypted traffic by filtering it out completely, as the end- 340 nodes' adherence to the security policies cannot be verified. 342 5.2. Possible Solutions 344 It would be desirable, if the users wish to do so, be able to have 345 the firewall or some node the firewall is configured to trust as an 346 intermediary in IPsec Security Parameter Index (SPI) 347 negotiation/configuration, as that is the only visible way to 348 demultiplex encrypted content between two the source and destination. 349 However, even though this may mitigate the risks somewhat, but it 350 appears that SPI's could be reused (without the intermediary) in such 351 a way that entirely different kind of traffic could be sent. There 352 is no fix for this, by the definition of end-to-end encryption. 354 A related approach could be have an intermediate firewall or security 355 gateway act as some kind of IPsec proxy, either by formally specified 356 means or by performing a "man-in-the-middle" -type "attack" on all 357 the IPsec traffic. Whether this would work or be useful is not 358 clear. A similar proposal is to require the private key storage in 359 the security gateway; however, such an architecture would be a very 360 attracting target and if compromised, would severely compromise the 361 value of IPsec encryption. 363 One could try to encode some interesting values, e.g. protocol 364 numbers and ports, in the Flow Label field; one problem here is the 365 relatively limited length of 20 bits. But this would have to be done 366 in the source node, which is not usually (at least completely) 367 trusted in this context. Also, according to [FLOWLAB], nodes must 368 not assume any properties in the Flow Label values. 370 An approach which has been proposed in the past in many forms has 371 been to specify an IPsec-like ESP-protocol which would allow 372 revealing only some portions of the packets, for example transport- 373 layer headers [ESVP]. To some extent, this would be helpful, but not 374 necessarily enough; for example, application-specific checking might 375 require access to the whole packet, especially if a different 376 solution to the problem noted in the next section is not found. 378 A possible approach would be to try to shift the focus, at least 379 partially, to end-node firewalls; if end-nodes are not particularly 380 trusted, an end-node, admin-controlled firewall might be provide a 381 reasonable tradeoff between security policy and cryptography. 383 There appears to be no network-based solution for this, which is 384 indeed a feature of end-to-end cryptography. 386 6. Firewalls and Interactions with Peer-to-Peer Applications 388 6.1. The Problem 390 As above, the restoration of end-to-end transparency provides a 391 possibility for a more wide-spread use of peer-to-peer applications. 392 Such applications are often a bit problematic from the firewall 393 perspective: it is often the practise to allow outbound (from the 394 protected site) traffic while allowing in only the related traffic 395 (and naturally some other administratively permitted traffic). Being 396 able to run (some) peer-to-peer applications easily in a controlled 397 environment would be valuable. 399 6.2. Possible Solutions 401 One workaround would be to try to standardize some default port 402 ranges (in an application-specific manner) for such applications as 403 these, for example in the above 32768 range. In this way, a site 404 could enable/disable (default) port ranges for (some) peer-to-peer 405 applications at will. A major disadvantage here would be that this 406 could violate the trust model: some applications could intentionally 407 try to use some other's port range to gain entry through the firewall 408 even if the default range for that specific application was blocked. 409 This would imply a requirement for at least some form of trust. 411 Another, but possibly quite a complex solution would be to implement 412 some form of peer-to-peer "pinholing" [MIDCOM]. This hasn't yet been 413 standardized even for IPv4 (though the concept is quite protocol- 414 independent). A problem with model is that generally there is no 415 trust relation between the firewall and the host (or an application 416 at the host): how would it help if a host (or misbehaving application 417 at the host) would be able to request opening a hole in the firewall? 418 So, there certainly seem to be very significant tradeoffs and threat 419 models to consider here. 421 A possible approach, as above, would be to try to shift, at least 422 partially, the focus to end-node firewalls; if end-nodes are not 423 particularly trusted, an end-node, admin-controlled firewall might be 424 provide a reasonable tradeoff between security policy and 425 cryptography. 427 7. Other Issues Associated with IPv6 Firewalls 429 This section tries to summarize some issues which have been brough up 430 in conjunction with IPv6 firewalling, but which are not seen as 431 problems as such. 433 7.1. IPv4 ARP vs IPv6 Neighbor Discovery 435 A number of people have been confused about the fact that IPv4 ARP 436 runs at the link-layer, while IPv6 Neighbor Discovery is part of 437 ICMPv6. When an IPv4 "deny all [IP] traffic" -rule blocks 438 "everything except ARP", the same IPv6 rule would also deny the 439 similar functions provided by Neighbor Discovery. 441 This just seems to be an issue people have to be educated on. 443 7.2. Filtering Specific Neighbor Discovery Messages 445 A typically similar set of people who have been confused of the role 446 of Neighbor Discovery (see above) also seem to be confused on what a 447 firewall should do with certain Neighbor Discovery packets. 449 It has been argued that a firewall should be able to filter out 450 specific proxy-ND behaviour, unauthorized ND Redirects, wrong Router 451 Advertisements, verify that packets coming from a node advertising to 452 be reachable at some link-layer address to really come from that 453 link-layer address, etc. 455 However, there are a number of strong arguments why this should not 456 be done in a firewall. First, all of these messages are strictly on- 457 link -- they are not routed. Thus, firewalling such messages would 458 only be of questionable use in end-node firewalls (to protect against 459 on-link abuse). On the other hand, as [SENDREQ] points out, the 460 physical link is actually rather difficult to secure: in addition to 461 enabling IP-level protections, one also has to secure link-layer 462 -level security. Such very fine-grained, ND-specific features would 463 seem to be clearly belong to the (Secure) Neighbor Discovery (or its 464 implementation) itself - not the firewalls. 466 7.3. Firewall Policies and Multiple Addresses per Node 468 Often, firewall policies try to specify "a node" or "a port in a 469 node". This naturally gets more complicated if the nodes have 470 multiple addresses: typically at least a link-local address and a 471 global address. 473 This is not problematic in itself, as the use of link-local addresses 474 is restricted on the link (and could even be considered out of scope 475 for most firewalls) and because one should not use link-local 476 addresses except for specific purpose protocols. Multiple global 477 addresses (e.g. from multihoming) can be worked out by 478 implementation-specific methods, e.g., by making it easier to 479 identify a node by the Interface ID part of the address when 480 desirable, and creating the rules for all the prefixes by one pseudo- 481 rule. However, the policies must be tuned manually if different 482 security properties have been assigned to different prefixes. 484 All in all, it seems desirable to make setting policies easier also 485 with multiple addresses, but this doesn't seem to be a problem as 486 such. 488 7.4. Firewall Transparency in the Network 490 Many want to deploy firewalls which do not participate in the network 491 at all, e.g. by not sending ICMPv6 unreachable packets for denied 492 targets, but rather silently discarding any traffic they do not 493 allow. In this kind of scenario, it may be desirable to even deploy 494 the firewall to function as a bridge, not as a router. 496 Some others want to deploy firewalls to be visible: either so that 497 the address of the firewall can be seen from the messages it sends, 498 or so that the firewall tries to be "transparent", i.e., forge the 499 replies as if they were coming from the destination nodes the 500 connecting node were trying to reach (e.g., by setting the source 501 address of an ICMPv6 message to be that of the destination address, 502 or by forging TCP RST, etc.). 504 There are trade-offs both ways. A visible firewall is extremely 505 useful when the firewall is used to set "friendly" restrictions (e.g. 506 internally to in an Enterprise), because there will be no TCP 507 timeouts (and similar delays) when accidentally trying something that 508 is not allowed: an immediate ICMPv6 message or a TCP RST allows an 509 immediate abort. The first may be useful in very hostile scenarios, 510 where sending ICMPv6 (or other) messages might just exacerbate the 511 issue (e.g. in the form of ICMPv6 reflection or ICMPv6 storms); 512 however, note that ICMPv6 specification specifies rate-limiting for 513 this specific purpose. 515 In any case, the firewall transparency considerations do not seem to 516 be specific to IPv6 and are not problems as such. 518 8. Security Considerations 520 This draft discusses security considerations related to IPv6 521 firewalling. When discussing potential solutions for problems, the 522 weaknesses are also pointed out. 524 In general, the firewall often does not, and cannot, trust the 525 node(s) it protects. These may even belong to different 526 administrative entit(y/ies). In that case, making compromises will 527 usually open some holes in the firewall. 529 9. Acknowledgements 531 Brian Carpenter suggested an IPv6 firewall could support P2P 532 pinholing. Soo Guan Eng provided commentary. Andras Kis-Szabo and 533 Changming Liu provided a number of comments and useful commentary. 535 10. References 537 10.1. Normative References 539 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing 540 Architecture", RFC3513, April 2003. 542 [IPV6] Deering, S., Hinden, R., "Internet Protocol, Version 6 543 (IPv6) Specification", RFC 2460, December 1998. 545 10.2. Informative References 547 [DISFW] Bellovin, S., "Distributed Firewalls", ;login: in Nov 548 1999, http://www.research.att.com/~smb/papers/distfw.html 550 [ECN] Garzik, J., "ECN-under-Linux Unofficial Vendor Support 551 Page", http://gtf.org/garzik/ecn/, March 2002. 553 [ESVP] Kasera, S. (ed.), "IP Encapsulating Security Variable 554 Payload (ESVP)", work-in-progress, 555 draft-kasera-esvp-00.txt, October 2002. 557 [FLOWLAB] Rajahalme, J., et al., "IPv6 Flow Label Specification", 558 work-in-progress, draft-ietf-ipv6-flow-label-07.txt, 559 April 2002. 561 [ICMPV6] Conta, A., Deering, S., "Internet Control Message 562 Protocol (ICMPv6)", RFC2463, December 1998. 564 [MIDCOM] Srisuresh, P. et al, "Middlebox communication 565 architecture and framework", RFC3303, August 2002. 567 [MIPV6] Johnson, D., et al, "Mobility Support in IPv6", 568 draft-ietf-mobileip-ipv6-24.txt, work-in-progress, 569 July 2003. 571 [RFC1122] Braden, R. (Editor), "Requirements for Internet Hosts 572 -- Communication Layers", RFC1122, October 1989. 574 [RFC1812] Baker, F. (Editor), "Requirements for IP Version 4 575 Routers", RFC1812, June 1995. 577 [RHHAOSEC] Savola, P. "Security of IPv6 Routing Header and 578 Home Address Options", work-in-progress, 579 draft-savola-ipv6-rh-ha-security-03.txt, December 2002. 581 [SENDREQ] Nikander, P., el al., "IPv6 Neighbor Discovery trust 582 models and threats", work-in-progress, 583 draft-ietf-send-psreq-03.txt, April 2003. 585 Author's Address 587 Pekka Savola 588 CSC/FUNET 589 Espoo, Finland 590 EMail: psavola@funet.fi 592 A. Possible Desirable Header Field Matching Extensions 594 As Destination options and Extension Header types are taken into use, 595 it may be desirable for a firewall to support some matching against 596 certain header fields. These include, for example: 598 - whether or not a specific Extension Header or a Destination 599 Option is detected 600 - behaviour when an unknown (or specified) Extension Header or 601 Destination Option is detected 602 - (Routing Header -specific) being able to match segments left 603 (mainly, whether it is zero or not), type and the next-to-be- 604 swapped destination(s) [RHHAOSEC] 605 - (Home Address Option [MIPV6] -specific) being able to match 606 against the home address 607 - (ESP/AH -specific) being able to match against SPI 608 - (Tunneled-traffic specific) being able to match against the 609 embedded IPv4 address in e.g. 6to4, ISATAP, etc. 611 Some of these are much more useful than others; the list is only 612 meant to give ideas about possibly useful (in some scenarios, at 613 least) functionalities. 615 B. Amplification DoS Attack Using IPv6 Multicast 617 It is possible to launch a denial-of-service attack using IPv6, 618 including a form of amplification based on multicast infrastructure. 620 Multicast address must not be used as a source address ([ADDRARCH], 621 section 2.7), but explicit checks to drop those packets or respond to 622 them have not been specified (that is, [ADDRARCH] specifies that 623 nodes MUST discard certain kinds of packets if received, but these 624 are not listed as such). However, such attacks are not considered 625 here. 627 By crafting packets, sent to multicast destinations, which are 628 certain to contain a response to the source address (the victim's 629 address) would seem to be potentially useful for an attacker: 631 src = (unicast-address) 632 dst = (w/ as many receivers as possible) 634 next-header=200 (something undefined) 635 or: 636 next-header=destination-options (or hop-by-hop options) 637 options-header= 639 Now, both of these amount to the same thing: every node which 640 processes the packet and adheres to [IPV6] will generate an ICMPv6 641 parameter problem back to the source. 643 [ICMPV6] does not permit the first approach with an unknown extension 644 header, but additionally permits ICMPv6 message generation with Path 645 MTU Discovery. 647 This is different with IPv4, where no ICMP errors are generated in 648 response to packets sent to multicast addresses [RFC1122]. Clearly, 649 when specifying, allowing the flexibility to define whether a 650 response to multicast packets would be sent was considered a feature, 651 but dangerous features have a tendency to being turned to bad uses. 653 In addition to amplification, this kind of attack would have an 654 effect on multicast-enabled router network as a large amount of 655 multicast forwarding state would be created. 657 Intellectual Property Statement 659 The IETF takes no position regarding the validity or scope of any 660 intellectual property or other rights that might be claimed to 661 pertain to the implementation or use of the technology described in 662 this document or the extent to which any license under such rights 663 might or might not be available; neither does it represent that it 664 has made any effort to identify any such rights. Information on the 665 IETF's procedures with respect to rights in standards-track and 666 standards-related documentation can be found in BCP-11. Copies of 667 claims of rights made available for publication and any assurances of 668 licenses to be made available, or the result of an attempt made to 669 obtain a general license or permission for the use of such 670 proprietary rights by implementors or users of this specification can 671 be obtained from the IETF Secretariat. 673 The IETF invites any interested party to bring to its attention any 674 copyrights, patents or patent applications, or other proprietary 675 rights which may cover technology that may be required to practice 676 this standard. Please address the information to the IETF Executive 677 Director. 679 Full Copyright Statement 681 Copyright (C) The Internet Society (2003). All Rights Reserved. 683 This document and translations of it may be copied and furnished to 684 others, and derivative works that comment on or otherwise explain it 685 or assist in its implementation may be prepared, copied, published 686 and distributed, in whole or in part, without restriction of any 687 kind, provided that the above copyright notice and this paragraph are 688 included on all such copies and derivative works. However, this 689 document itself may not be modified in any way, such as by removing 690 the copyright notice or references to the Internet Society or other 691 Internet organizations, except as needed for the purpose of 692 developing Internet standards in which case the procedures for 693 copyrights defined in the Internet Standards process must be 694 followed, or as required to translate it into languages other than 695 English. 697 The limited permissions granted above are perpetual and will not be 698 revoked by the Internet Society or its successors or assignees. 700 This document and the information contained herein is provided on an 701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 703 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 705 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Acknowledgement 709 Funding for the RFC Editor function is currently provided by the 710 Internet Society.