idnits 2.17.1 draft-gont-opsec-ipv6-firewall-reqs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 21, 2016) is 2929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 630, but not defined == Unused Reference: 'RFC6274' is defined on line 765, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 3511 (Obsoleted by RFC 9411) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Informational M. Ermini 5 Expires: September 22, 2016 ResMed 6 W. Liu 7 Huawei Technologies 8 March 21, 2016 10 Requirements for IPv6 Enterprise Firewalls 11 draft-gont-opsec-ipv6-firewall-reqs-03 13 Abstract 15 While there has been some work in the area of firewalls, concrete 16 requirements for IPv6 firewalls have never been specified in the RFC 17 series. The more limited experience with the IPv6 protocols and the 18 more reduced number of firewalls that support IPv6 has made it rather 19 difficult to infer what are reasonable features to expect in an IPv6 20 firewall. This has typically been a problem for network operators, 21 who typically have to produce a "Request for Proposal" from scratch 22 that describes such features. This document specifies a set of 23 requirements for IPv6 firewalls, in order to establish some common- 24 ground in terms of what features can be expected in them. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 22, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Numbering Conventions . . . . . . . . . . . . . . . . . . 5 66 4. General Security Features . . . . . . . . . . . . . . . . . . 5 67 5. IPv6-Specific Features . . . . . . . . . . . . . . . . . . . 7 68 6. VPN Security Requirements . . . . . . . . . . . . . . . . . . 8 69 7. Denial of Service (DoS) Protection . . . . . . . . . . . . . 9 70 8. Application Layer Firewall . . . . . . . . . . . . . . . . . 11 71 9. Logging, Auditing and Security Operation Centre (SOC) 72 requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. Console and Events Visualization requirements . . . . . . . . 13 74 11. Reporting requirements . . . . . . . . . . . . . . . . . . . 14 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 15.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. DISCLAIMER 85 This initial version of the document is based on a typical IPv6 86 firewall "Request for Proposal" (RFP), and is mostly meant to trigger 87 discussion in the community, and define a direction for the document. 88 Future versions of this document may contain all, more, or a subset 89 of the requirements present in the current version of this document. 90 Additionally, the current version DOES NOT yet properly separate 91 requirements among MUST/REQUIRED, SHOULD/RECOMMENDED, and MAY/ 92 OPTIONAL. 94 Please DO read Section 3 of this document, since it provides 95 important information about the conventions used throughout this 96 document that is mandatory to be able to understand it. 98 Finally, please note this version is meant to provide requirements, 99 rather than implementation guidelines. 101 2. Introduction 103 While the IETF has published a large number of documents discussing 104 IP and IPv6 packet filtering (see e.g. [RFC7126] and some documents 105 on the topic of IP firewalls (see e.g. [RFC2979] and [RFC3511]), 106 concrete requirements for IP firewalls have never been specified in 107 the RFC series. When it comes to IPv4, a number of features have 108 become common over the years, and firewall requirements have somehow 109 become operational wisdom. When it comes to IPv6 [RFC2460], the more 110 limited experience with the protocols, and the reduced variety of 111 IPv6 firewalls has made it rather difficult to specify what are 112 reasonable features to be expected of an IPv6 firewall. This has 113 proven to be a problem for network operators (who have typically had 114 to produce a "Request for Proposal" from scratch), but also for 115 vendors (who lack a well defined set of requirements that can serve 116 as a roadmap for implementation). 118 This situation has not only made the process of purchasing an IPv6 119 firewall harder, but at times has also meant that a number of 120 important/basic features have remained unimplemented by major 121 firewall vendors, or that aforementioned features have not behaved as 122 expected. 124 This document aims to provide a set of requirements for firewall 125 vendors, which are specified as "MUST", "SHOULD", or "MAY". An IPv6 126 firewall product is said to be "fully-compliant" with this 127 specification provided it implements all requirements marked as 128 "MUST" and "SHOULD". An IPv6 firewall product is said to be 129 "conditionally-compliant" with this specification provided it 130 implements all requirements marked as "MUST", but fails to implement 131 one or more of the requirements marked as "SHOULD". 133 3. Conventions 135 3.1. Requirements Language 137 Take careful note: Unlike other IETF documents, the key words "MUST", 138 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 139 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 140 described in [RFC2119]. This document uses these keywords not 141 strictly for the purpose of interoperability, but rather for the 142 purpose of establishing industry-common baseline functionality. 144 In this document, the words that are used to define the significance 145 of each particular requirement are capitalized. These words are: 147 o "MUST" This word, or the words "REQUIRED" and "SHALL" mean that 148 the item is an absolute requirement of the specification. 150 o "SHOULD" This word or the adjective "RECOMMENDED" means that there 151 may exist valid reasons in particular circumstances to ignore this 152 item, but the full implications should be understood and the case 153 carefully weighed before choosing a different course. 155 o "MAY" This word or the adjective "OPTIONAL" means that this item 156 is truly optional. One vendor may choose to include the item 157 because a particular marketplace requires it or because it 158 enhances the product, for example; another vendor may omit the 159 same item. 161 A firewall implementation is a module that supports at least one of 162 the feature types defined in this document. Firewall implementations 163 may support multiple feature types, but conformance is considered 164 individually for each type. 166 A firewall implementation is not compliant with a specific feature 167 type if it fails to satisfy one or more of the MUST requirements of 168 such specific feature type. An implementation that satisfies all the 169 MUST and all the SHOULD requirements of a specific feature is said to 170 be "unconditionally compliant" with such feature type; one that 171 satisfies all the MUST requirements but not all the SHOULD 172 requirements is said to be "conditionally compliant" with such 173 feature type. 175 3.2. Terminology 177 Where possible, this document employs the terminology defined in 178 [RFC2647]. Other additional terms are defined below: 180 session: 181 The term session refers to any protocol instance that involves 182 some sort of stateful exchange. Examples of "sessions" could be 183 TCP connections, UDP query/response pairs, ICMPv6 echo/response 184 pairs, etc. Our definition of session corresponds to the 185 definition of "connection" in Section 3.7 of [RFC2647], but we 186 rather employ "session" to avoid possible confusion. 188 XXX: Should we just get rid of the term "session" and use 189 "connection" throughout this document, with a big reference to the 190 definition in RFC2647? 192 3.3. Numbering Conventions 194 The items for each feature type will follow a monotonically- 195 increasing order -- typically in increments to 10. This is to 196 prevent the insertion of an item in the list of requirements to 197 change the numbering of all the following requirements. Prior to the 198 final publication of this document, each of items of each the feature 199 types will be numbered starting from 1, with increments of 1 (1, 2, 200 3, 4, etc.). 202 NOTE: Those with BASIC language programming experience may find 203 the idea familiar. 205 4. General Security Features 207 REQ GEN-5: 208 The firewall MUST include performance benchmarking documentation. 209 Such documentation MUST include information that reflects firewall 210 performance with respect to IPv6 packet, but also regarding how 211 IPv6 traffic may affect the performance of IPv4 traffic. The 212 aforementioned documentation MUST be, at the very least, 213 conditionally-compliant with both [RFC3511] and [RFC5180] (that 214 is, it MUST support all "MUST" requirements in such documents, and 215 may also support the "SHOULD" requirements in such documents). 217 NOTE: This is for operators to spot be able to identify cases 218 where a devices may under-perform in the presence of IPv6 219 traffic (see e.g. [FW-Benchmark]). XXX: This note may be 220 removed before publication if deemed appropriate. 222 REQ GEN-10: 223 All features of the firewall MUST be able to be individually 224 configured (at least ON or OFF, with other configurable parameters 225 as applicable). A well-documented default initial setting must be 226 provided for each feature. 228 REQ GEN-20: 229 MUST support basic Access Control Lists (ACLs). 231 REQ GEN-30: 232 MUST support stateless packet inspection and filtering at 233 transport layer. 235 REQ GEN-40: 237 MUST support stateful packet inspection and filtering at transport 238 layer. 240 REQ GEN-50: 241 SHOULD support full-proxy for the TCP [RFC0793] connections (the 242 handshake is validated on the firewall before reaching the target 243 system). 245 Some products identify this feature with terms such as "TCP 246 Intercept and Limiting Embryonic Connections". 248 REQ GEN-60: 249 MUST be able to enforce timeouts on protocol sessions based on the 250 upper-layer protocol (e.g. enforce a timeout on the FIN-WAIT state 251 for TCP connections, a timeout for DNS query/respose pair, etc.). 252 In general, it MUST have different timeout parameters and 253 thresholds to be used to prevent idle sessions from exhausting 254 resources on the device and/or the service that is defended. For 255 sessions composed of multiple packets (such as TCP connections), 256 the exchange of valid packets MUST refresh the timers employed for 257 enforcing the aforementioned timeouts. 259 NOTE: This is to avoid the known and buggy behavior where 260 firewalls enforce a maximum lifetime for the protocol session 261 (e.g. TCP connection) regardless of whether there is ongoing 262 exchange of legitimate packets for such session. 264 REQ GEN-70: 265 MUST be able to provide anti-spoofing features (e.g. uRPF ). 267 REQ GEN-80: 268 MUST be able to redirect specific traffic to a proxy server e.g. 269 for HTTP/S protocols. 271 NOTE: "Redirection means that the firewall should be able to 272 divert the traffic to a proxy - i.e., take the traffic, send it 273 to an inspection engine, receive it back and forward it (all 274 this completely transparent to the users). 276 REQ GEN-90: 277 MUST be able to detect and reject invalid source or destination 278 addresses (e.g. local-link addresses that try to traverse the 279 firewall) with a single policy. 281 5. IPv6-Specific Features 283 REQ SPC-10: 284 MUST be able to filter ICMPv6 [RFC4443] traffic at a message type/ 285 code granularity. [RFC4890] MUST be employed for the default 286 filtering configuration. 288 REQ SPC-20: 289 MUST be able to block packets containing any specified extension 290 header type (based on its Next Header value), on a specified 291 number of instances of a specified extension header type, and on a 292 specified overall number of IPv6 extension headers. 294 REQ SPC-30: 295 MUST be able to block IPv6 packets that employ a Routing Header 296 both at the granularity of Extension Header Type (as required in 297 SPC-20) and Routing Header Type. 299 REQ SPC-40: 300 SHOULD be able to drop packets based on IPv6 option types. 302 REQ SPC-50: 303 MUST be able to detect IPv6 tunnels such as SIIT [RFC6145], 6to4 304 [RFC3056], 6in4 [RFC4213], ISATAP [RFC5214] and Teredo [RFC4380] 305 (please see [RFC7123], and MUST be able to selectively block or 306 allow them for specific sources, destinations, routes or 307 interfaces. 309 REQ SPC-60: 310 MUST be able to validate IPv6 Neighbor Discovery [RFC4861] packets 311 (RS, RA, NS, NA, Redirect) according to 312 [I-D.ietf-opsec-ipv6-nd-security]. 314 REQ SPC-70: 315 MUST be able to statefully match ICMPv6 errors to TCP [RFC0793], 316 UDP [RFC0768], and ICMPv6 [RFC4443] communication instances (see 317 [RFC5927]). 319 REQ SPC-80: 320 MUST be able to parse all defined extension headers according to 321 [RFC7045], and SHOULD filter packets containing IPv6 Extension 322 Headers as recommended in [draft-gont-opsec-ipv6-eh-filtering]. 324 REQ SPC-90: 325 MUST be able to find the upper-layer protocol in an IPv6 header 326 chain (see [RFC7112]. 328 REQ SPC-100: 330 SHOULD be able to normalize (rewrite) the following IPv6 header 331 fields on a per-interface basis: 333 * Hop Limit 335 6. VPN Security Requirements 337 REQ VPN-10: 338 MUST implement IPsec-based [RFC4301] VPN technology. 340 REQ VPN-20: 341 MUST implement "hub-and-spoke" Dynamic Multipoint VPN-like 342 technology, allowing creation of dynamic-meshed VPN without having 343 to pre-configure all of possible tunnels. 345 REQ VPN-30: 346 MUST implement SSL/TLS-based [SSL-VPNs] VPN technology. 348 REQ VPN-40: 349 MUST be able to use digital certificates, including CRL and OCSP 350 revocation checking methods, to mutually authenticate VPN peers. 352 REQ VPN-50: 353 MUST be able to disable or enable split-tunnelling feature on VPN 354 as required. 356 REQ VPN-60: 357 MUST support the enrollment of the system in a PKI infrastructure 358 for the regular renewal of certificates. 360 REQ VPN-70: 361 MUST be able to transit IPv4 and IPv6 packets providing full 362 parity for services, and also offer both protocols in dual-stack 363 in the same VPN connection. 365 REQ VPN-80: 366 MUST be able to apply to the tunnelled content that is terminated 367 on the device, the same inspection policies that are possible in 368 the non tunnelled traffic. 370 REQ VPN-90: 371 MUST perform a full validation of the certificates' chains when 372 verifying the validity of the OCSP/CLR responses. Caching of 373 responses SHOULD be configurable by end users, and the default 374 response SHOULD be not to accept a non-valid certificate. The 375 default response MAY be overridden by the administrators, but it 376 MUST be configurable on a per-domain basis (e.g. accept incomplete 377 certificate chains for "intranet_of_internal_corp.example.org", 378 but refuse it for all of the other domains). 380 7. Denial of Service (DoS) Protection 382 REQ DoS-10: 383 MUST be able to protect against implementation-specific attacks, 384 including: 386 * Winnuke [Myst1997] 388 * ping-of-death [Kenney1996] 390 * Smurf [CERT1998a] 392 * LAND Attack [Meltman1997] 394 * Teardrop Attack [CERT1997] [Junos-Teardrop] 396 REQ DoS-20: 397 MUST be able to protect against IPv6 resource exhaustion attacks, 398 including: 400 * fragment flooding attacks 402 * Neighbor Cache Exhaustion attacks, whether launched from a 403 local network (see [I-D.ietf-opsec-ipv6-nd-security] or from 404 remote networks (see [RFC6583] 406 REQ DoS-30: 407 MUST be able to protect against TCP flooding attacks: connection- 408 flooding, FIN-WAIT-1 flooding, etc. (see e.g. [CPNI-TCP]) 410 REQ DoS-40: 411 MUST be able to protect against TCP resource exhaustion attacks: 412 zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP]) 414 REQ DoS-50: 415 MUST be able to detect and drop malformed IPv6 packets (incorrect 416 header/option lengths, etc.). 418 REQ DoS-60: 419 MUST be able to detect and drop malformed TCP packets (incorrect 420 segment/options lengths, etc.). 422 REQ DoS-70: 424 MUST be able to provide bandwidth management (QoS or anti- 425 flooding) policies customizable for specific source and 426 destination networks, or by VLAN or MPLS ID. 428 REQ DoS-80: 429 MUST be able to participate to a blackhole/synkhole routing 430 infrastructure as per [RFC5635]. 432 REQ DoS-85: 433 MUST be able to fetch and use third party "reputational" IP white- 434 and black-lists (e.g. download them via RSS feeds or query via 435 them DNS record) and use them in policy constructs/ACLs. In 436 general, it MUST be able to provide some form of reputational 437 service for IP addresses which must include IPv6 networks. 439 REQ DoS-90: 440 MUST be able to set up a maximum session setup rate, and detect 441 hosts or networks exceeding it. 443 REQ DoS-100: 444 MUST be able to set up a maximum IPv6 source and/or destination 445 session limit, and detect when they are exceeded. 447 REQ DoS-110: 448 For each of the previous detection controls, different 449 configurable reactions SHOULD be possible by IPv6 address and 450 network sources and/or destinations. The minimum actions required 451 are the following: 453 1. allow the traffic ("ignore" or "whitelist") 455 2. allow the traffic but log ("bypass" or "detection only" mode) 457 3. drop the packet (only the offending packet but do not reset 458 the connection) 460 4. drop session (drop the entire connection, but do not send a 461 reset back) 463 5. "greylist" - put it in a list of blocked addresses, but 464 remove it from the list after a configurable amount of time 466 6. send an email/SMS/pager text to the firewall administrator 468 7. send TCP reset to source only 470 8. send TCP reset to destination only 471 9. send TCP reset to both source and destination 473 10. perform a specific, preconfigured change on the firewall 474 policy 476 11. feed a third party source such as a switch/NAC/NAP or RADIUS 477 system, to isolate/quarantine the offending port/MAC address/ 478 user 480 12. quarantine the specific traffic or source (block them for a 481 configurable amount of time, e.g. 5 minutes, and then allow 482 them again; eventually, the quarantine time may get longer if 483 the offense is repeated) 485 8. Application Layer Firewall 487 REQ APP-10: 488 MUST be able to provide web filtering features, such as enforcing 489 access to allowed web content and filtering high risk URLs such as 490 anonymizers and known hostile addresses. 492 REQ APP-20: 493 MUST be able to provide email filtering features, such as 494 mitigating spam, phishing and email harvesting, and enforce email 495 policies. 497 9. Logging, Auditing and Security Operation Centre (SOC) requirements 499 REQ SOC-10: 500 MUST generate log for all the changes performed to the system, 501 including change of group membership for a device, new or removed 502 devices in a group, new or removed administrators. 504 REQ SOC-20: 505 MUST provide the following features: 507 1. Connection logs 509 2. Local log storage 511 3. Network logging 513 4. Real time log viewer 515 5. Attack detected 517 6. Per rule logging 518 7. Automatic log file compression 520 8. Log file rotation 522 REQ SOC-30: 523 MUST be able to generate a log for: 525 1. all the logins, logouts and failed login attempts from 526 firewall administrators 528 2. any modifications or disabling of the firewall rules 530 REQ SOC-40: 531 Any security event detected - malicious traffic, hit of a policy, 532 policy violation, termination of a session and so on - MUST be 533 able to generate a log, and be configurable to do that or not by 534 administrators. 536 REQ SOC-50: 537 There MUST be a mechanism to prevent log flooding from the device 538 against the management system, such as aggregation of like events. 540 REQ SOC-60: 541 The amount of information in the alerts MUST be configurable; it 542 SHOULD possible to have the date/time and type of event and the 543 full payload of the traffic that has triggered the signature/ 544 event. 546 REQ SOC-70: 547 The firewall MUST minimize the number of log entries generated for 548 a single event - e.g. when repeated similar events for a short 549 period of time are detected, they are aggregated and the 550 cumulative number of events is reported. 552 REQ SOC-80: 553 The firewall MUST be able to send logs in multiple ways and 554 formats, for instance UDP syslog, TCP syslog, SMTP, SNMP and so 555 on. It must be possible to configure different ways and formats 556 for different policies and configure some ways and formats as a 557 "backup" in the case that the main way fails. Please describe the 558 different possibilities. 560 REQ SOC-90: 561 The firewall SHOULD alert the firewall administrator when the 562 policy to be enforced does not follow the advice in [RFC4890] -- 563 particularly if the filtering policy would block/drop ICMPv6 564 Packet Too Big error messages. 566 10. Console and Events Visualization requirements 568 REQ CON-10: 569 MUST provide a dashboard view, which must be customizable by end- 570 user and end-users' group (e.g. their Microsoft Active Directory 571 or LDAP group). 573 REQ CON-20: 574 The dashboard must be able to include system health monitoring 575 information, such as the following: 577 1. CPU idle 579 2. Real and Swap memory usage 581 3. Disk usage 583 4. Number of accepted and dropped packets 585 5. Operating status for all supported facilities (HA, QoS, VPN) 587 6. VPN tunnels status 589 7. NIC link state 591 REQ CON-30: 592 MUST have the possibility to select a particular piece of data or 593 individual alert, and visualize the policy that has triggered the 594 event. 596 REQ CON-40: 597 MUST be able to create exception filters that will suppress 598 visualization of a specific alert (e.g. from specific sources, or 599 specific events), without actually affecting the detection and log 600 retention. 602 REQ CON-50: 603 MUST provide a remote access method to obtain all current 604 operational data on demand, in a documented format, covering items 605 such as those listed in REQ CON-20. 607 Note: This is to be able to integrate firewall operations in an 608 existing NMS. 610 11. Reporting requirements 612 REQ REP-10: 613 Built in reports MUST be provided by default, such as protocol 614 distribution, policy and rule matched, top attacks, top sources/ 615 destinations, top targets, top geographical sources, device status 616 including utilizations, and so on. 618 REQ REP-20: 619 SHOULD allow to run reporting over historical and archived logs, 620 automatically restoring and re-archiving them. 622 12. IANA Considerations 624 There are no IANA registries within this document. The RFC-Editor 625 can remove this section before publication of this document as an 626 RFC. 628 13. Security Considerations 630 [TBD] 632 14. Acknowledgements 634 The initial version was based on an (unpublished) document authored 635 by Marco Ermini. 637 The authors would like to thank (in alphabetical order), Mikael 638 Abrahamsson, Cameron Byrne, Brian Carpenter, Tim Chown, Jakub (Jake) 639 Czyz, Marc Heuse, Simon Perreault, Carsten Schmoll, Robert Sleigh, 640 Donald Smith, Qiong Sun, Gunter Van de Velde, and Scott Weeks, for 641 providing valuable comments on earlier versions of this document. 643 15. References 645 15.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 653 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 654 December 1998, . 656 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 657 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 658 December 2005, . 660 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 661 Control Message Protocol (ICMPv6) for the Internet 662 Protocol Version 6 (IPv6) Specification", RFC 4443, 663 DOI 10.17487/RFC4443, March 2006, 664 . 666 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 667 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 668 DOI 10.17487/RFC4861, September 2007, 669 . 671 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 672 DOI 10.17487/RFC0768, August 1980, 673 . 675 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 676 RFC 793, DOI 10.17487/RFC0793, September 1981, 677 . 679 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 680 of IPv6 Extension Headers", RFC 7045, 681 DOI 10.17487/RFC7045, December 2013, 682 . 684 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 685 Oversized IPv6 Header Chains", RFC 7112, 686 DOI 10.17487/RFC7112, January 2014, 687 . 689 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 690 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 691 . 693 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 694 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 695 2001, . 697 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 698 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 699 DOI 10.17487/RFC5214, March 2008, 700 . 702 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 703 Network Address Translations (NATs)", RFC 4380, 704 DOI 10.17487/RFC4380, February 2006, 705 . 707 15.2. Informative References 709 [RFC2647] Newman, D., "Benchmarking Terminology for Firewall 710 Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999, 711 . 713 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 714 for IPv6 Hosts and Routers", RFC 4213, 715 DOI 10.17487/RFC4213, October 2005, 716 . 718 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 719 ICMPv6 Messages in Firewalls", RFC 4890, 720 DOI 10.17487/RFC4890, May 2007, 721 . 723 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 724 Dugatkin, "IPv6 Benchmarking Methodology for Network 725 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 726 2008, . 728 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 729 Filtering with Unicast Reverse Path Forwarding (uRPF)", 730 RFC 5635, DOI 10.17487/RFC5635, August 2009, 731 . 733 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 734 Neighbor Discovery Problems", RFC 6583, 735 DOI 10.17487/RFC6583, March 2012, 736 . 738 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on 739 IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February 740 2014, . 742 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 743 on Filtering of IPv4 Packets Containing IPv4 Options", 744 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 745 . 747 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 748 Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, 749 . 751 [RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, 752 "Benchmarking Methodology for Firewall Performance", 753 RFC 3511, DOI 10.17487/RFC3511, April 2003, 754 . 756 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 757 DOI 10.17487/RFC5927, July 2010, 758 . 760 [I-D.ietf-opsec-ipv6-nd-security] 761 Gont, F., Bonica, R., and W. Will, "Security Assessment of 762 Neighbor Discovery (ND) for IPv6", draft-ietf-opsec-ipv6- 763 nd-security-00 (work in progress), October 2013. 765 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 766 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 767 . 769 [CPNI-TCP] 770 CPNI, , "Security Assessment of the Transmission Control 771 Protocol (TCP)", http://www.gont.com.ar/papers/ 772 tn-03-09-security-assessment-TCP.pdf, 2009. 774 [SSL-VPNs] 775 Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, 776 SAAG Meeting., 2008, 777 . 779 [FW-Benchmark] 780 Zack, E., "Firewall Security Assessment and Benchmarking 781 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 782 Berlin, Germany. June 30, 2013, 783 . 787 [Junos-Teardrop] 788 Juniper, j., "Understanding Teardrop Attacks", Junos OS 789 Security Configuration Guide, 2010, 790 . 794 [draft-gont-opsec-ipv6-eh-filtering] 795 Gont, F., Ermini, M., and W. Liu, "Recommendations on 796 Filtering of IPv6 Packets Containing IPv6 Extension 797 Headers", draft-gont-opsec-ipv6-filtering-00, Work 798 in Progress, April 2014. 800 [Kenney1996] 801 Kenney, M., "The Ping of Death Page", 1996, 802 . 804 [Meltman1997] 805 Meltman, M., "new TCP/IP bug in win95", 1997, 806 . 808 [Myst1997] 809 Myst, M., "Windows 95/NT DoS", 1997, 810 . 812 [CERT1997] 813 CERT, , "CERT Advisory CA-1997-28: IP Denial-of-Service 814 Attacks", 1997, 815 . 817 [CERT1998a] 818 CERT, , "CERT Advisory CA-1998-01: Smurf IP Denial-of- 819 Service Attacks", 1998, 820 . 822 Authors' Addresses 824 Fernando Gont 825 SI6 Networks / UTN-FRH 826 Evaristo Carriego 2644 827 Haedo, Provincia de Buenos Aires 1706 828 Argentina 830 Phone: +54 11 4650 8472 831 Email: fgont@si6networks.com 832 URI: http://www.si6networks.com 834 Marco Ermini 835 ResMed 836 Fraunhoferstrasse 16 837 Munich, Bayern 82152 838 Deutschland 840 Phone: +49 175 4395642 841 Email: marco.ermini@resmed.com 842 URI: http://www.resmed.com 843 Will Liu 844 Huawei Technologies 845 Bantian, Longgang District 846 Shenzhen 518129 847 P.R. China 849 Email: liushucheng@huawei.com