idnits 2.17.1 draft-lewis-infrastructure-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 697), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 49. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2006) is 6403 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'REF' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 630, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'REF' -- Obsolete informational reference (is this intentional?): RFC 3667 (Obsoleted by RFC 3978) -- Obsolete informational reference (is this intentional?): RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Darrel Lewis 3 James Gill 4 Verizon Business. 5 Darrel Lewis 6 Cisco Systems, Inc. 7 Paul Quinn 8 Cisco Systems, Inc. 9 Peter Schoenmaker 10 NTT America 11 October 2006 13 Service Provider Infrastructure Security 14 16 Status of this Memo 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 40 Copyright Notice 42 Copyright (C) The Internet Society (2006) 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on October 28, 2006. 47 Copyright Notice 49 Copyright (C) The Internet Society (2006). All Rights Reserved. 51 Abstract 53 This RFC defines best current practices for implementing Service 54 Provider network infrastructure protection for network elements. 55 This RFC complements and extends RFC 2267 and RFC 3704. RFC 2267 56 provides guidelines for filtering traffic on the ingress to service 57 provider networks. RFC 3704 expands the recommendations described in 58 RFC 2267 to address operational filtering guidelines for single and 59 multi-homed environments. The focus of those RFCs is on filtering 60 ingress packets ingress, regardless of destination, if those packets 61 are have spoofed source address or fall within "reserved" address 62 space. Deployment of RFCs 2267 and 3704 has limited the effects of 63 denial of service attacks by dropping ingress packets with spoofed 64 source addresses, which in turn offers other benefits by ensuring 65 that packets coming into a network originate from validly allocated 66 and consistent sources. 68 This document focuses solely on traffic destined to the network 69 infrastructure itself to protect the network from denial of service 70 and other attacks. This document presents techniques that, together 71 with network edge ingress filtering and RFC 2267 and RFC 3704, create 72 a layered approach for infrastructure protection. 74 This document does not present recommendations for protocol 75 validation (i.e. "sanity checking") nor does it address guidelines 76 for general security configuration. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Overview of Infrastructure Protection Techniques . . . . . . . 5 82 2.1. Edge Infrastructure Access Control Lists. . . . . . . . . . 5 83 2.2. Edge Remarking. . . . . . . . . . . . . . . . . . . . . . . 5 84 2.3. Device and Element Protection . . . . . . . . . . . . . . . 6 85 2.4. Infrastructure Hiding . . . . . . . . . . . . . . . . . . . 6 86 3. Edge Infrastructure Access Control Lists . . . . . . . . . . . 6 87 3.1. Constructing the Access List. . . . . . . . . . . . . . . . 7 88 3.2. Other Traffic . . . . . . . . . . . . . . . . . . . . . . . 7 89 3.3. Edge Infrastructure Conclusion. . . . . . . . . . . . . . . 8 90 4. Edge Rewrite/Remarking . . . . . . . . . . . . . . . . . . . . 8 91 4.1. Edge Rewriting/Remarking Discussion . . . . . . . . . . . . 9 92 5. Device/Element Protection. . . . . . . . . . . . . . . . . . . 9 93 5.1. Service Specific Access Control . . . . . . . . . . . . . . 10 94 5.1.1. Common Services. . . . . . . . . . . . . . . . . . . . . 10 95 5.2. Aggregate Device Access Control . . . . . . . . . . . . . . 10 96 5.2.1. IP Fragments . . . . . . . . . . . . . . . . . . . . . . 11 97 5.2.2. Performance Considerations . . . . . . . . . . . . . . . 11 98 5.2.3. Access Control Implementation Guide. . . . . . . . . . . 11 99 5.3. Device Access Authorization and Accounting. . . . . . . . . 11 100 6. Infrastructure Hiding. . . . . . . . . . . . . . . . . . . . . 12 101 6.1. Use less IP. . . . . . . . . . . . . . . . . . . . . . . . 12 102 6.2. MPLS techniques . . . . . . . . . . . . . . . . . . . . . . 12 103 6.3. IGP configuration . . . . . . . . . . . . . . . . . . . . . 12 104 6.4. Route advertisement control . . . . . . . . . . . . . . . . 13 105 6.4.1. Route Announcement filtering . . . . . . . . . . . . . . 13 106 6.4.2. Address core out of rfc1918 space. . . . . . . . . . . . 13 107 7. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 108 7.1. IPv6 Edge Infrastructure Access Control List. . . . . . . . 14 109 7.2. IPv6 Edge Remarking . . . . . . . . . . . . . . . . . . . . 14 110 7.3. IPv6 Device and Element Protection. . . . . . . . . . . . . 15 111 7.4. IPv6 Infrastructure Hiding. . . . . . . . . . . . . . . . . 15 112 8. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 15 113 8.1. Multicast Group Protection. . . . . . . . . . . . . . . . . 16 114 8.2. Performance Considerations. . . . . . . . . . . . . . . . . 16 115 8.3. IPv6 and Multicast. . . . . . . . . . . . . . . . . . . . . 16 116 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 17 117 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18 118 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 119 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 120 11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19 122 1. Introduction 124 This RFC defines best current practices for implementing Service 125 Provider network infrastructure protection for network elements. 126 RFC 2267 and RFC 3704 focuses on limiting the effects of denial of 127 service attacks by filtering ingress packets with spoofed source 128 addresses, which in turn offers other benefits by ensuring that 129 packets coming into a network originate from validly allocated and 130 consistent sources. RFC 3704 extends the recommendations described 131 in RFC 2267 to address operational filtering guidelines for single 132 and multi-homed environments. In both cases (RFC 2267 and RFC 3704), 133 the focus is on dropping packets on ingress, regardless of 134 destination, if those packets are have spoofed source address or fall 135 within "reserved" address space. This document both refines and 136 extends the filtering best practices outlined in RFC 2267 and RFC 137 3704 and focuses only on traffic destined to the network 138 infrastructure itself to protect the service provider network from 139 denial of service and other attacks. This document presents 140 techniques that, together with network edge ingress filtering and RFC 141 2267 and RFC 3704, create a layered approach for infrastructure 142 protection. 144 Denial of Service (DoS) attacks are common and the network 145 infrastructure itself is a target. Attacks targeting the network 146 infrastructure can take many forms, ranging from bandwidth saturation 147 to crafted packets destined to a router. These attacks might use 148 spoofed source address or they might use the true address of source 149 of the traffic. Regardless of the nature of the attack, the network 150 infrastructure must be protected from both accidental and intentional 151 attacks. 153 The techniques outlined in this document and described in section 2 154 below, provide a layered approach for infrastructure protection: 155 Edge policy (filtering and precedence), per device traffic policy 156 enforcement for packets destined to a device and finally, 157 routing/address advertising best practices to limit core network -- 158 that is P and PE infrastructure -- exposure. 160 This document is aimed at network operators who would like to 161 "harden" their infrastructure and make it more resilient to external 162 attack. These techniques are designed to be used in addition to 163 specific protocol or application security features implemented in 164 network devices. 166 Infrastructure protection is a complex topic, improving protection is 167 always beneficial. 169 2. Overview of Infrastructure Protection Techniques 171 This section provides an overview of the four recommended techniques 172 that may be used to protect network infrastructure. The details of 173 each area along with some deployment consideration are described in 174 detail in subsequent sections. 176 - Edge Infrastructure Access Control List 177 - Edge Remarking 178 - Device and Element Protection 179 - Infrastructure Hiding 181 The above list is not exhaustive; other mechanisms can be used to 182 provide a measure of protection. The techniques discussed in this 183 document have been widely deployment and have proven operational 184 security benefits in large networks. 186 2.1. Edge Infrastructure Access Control Lists 188 Edge infrastructure access control lists are ingress access control 189 lists that filter traffic destined to the network only. They should 190 permit all traffic through the network. Explicit filtering of 191 traffic destined to network devices creates a first level of 192 protection at the network edge: only traffic explicitly permitted 193 into the network can reach a device beyond the PE router with the 194 filter. 196 Although very effective, edge infrastructure access control lists are 197 not perfect and, like any filter lists, must be maintained and 198 updated. Furthermore, while widespread deployment on ingress 199 interface provides the most protection (which in some cases will not 200 be possible), some deployment is better than no deployment. 202 2.2. Edge Remarking 204 We define Edge Remarking as ensuring that ingress IP precedence or 205 DSCP values match expected values within the context of security. 206 This provides another layer of defense particularly for traffic 207 permitted through any of the Edge Infrastructure Access Control 208 Lists. In this RFC we focus only on using Edge Remarking best 209 practices to enforce security policies. 211 2.3. Device and Element Protection 213 Each device infrastructure device should enforce local rules for 214 traffic destined to the device itself. These rules can take the form 215 of filters (permit/deny) or rate limiting rules that allow ingress 216 traffic at specified rates. These should complement any existing 217 Edge Infrastructure Access Control Lists. 219 The deployment of these local device protection rules compliments the 220 edge techniques by protecting the device from traffic that: i) was 221 permitted but violates device policy, ii) could not be filtered at 222 the edge, iii) entered the network on an interface that did not have 223 ingress filtering enabled. 225 2.4. Infrastructure Hiding 227 Hiding the infrastructure of the network provides an elegant 228 mechanism for protecting the network infrastructure. If the 229 destination of an attack is to an infrastructure address that is 230 unreachable, attacks become far more difficult. Infrastructure 231 hiding can be achieved in several ways: 233 - MPLS techniques 234 - IGP configuration 235 - Route advertisement control 237 3. Edge Infrastructure Access Control Lists 239 Edge Infrastructure Access Control Lists (EIACLs) are a specific 240 implementation of the more general Ingress Access List. As opposed 241 to generic ingress filtering which denies data (sometimes referred to 242 as user) plane traffic, edge infrastructure access control lists do 243 not attempt to deny traffic going through the devices, rather this 244 form of access control limits traffic destined to infrastructure 245 equipment while permitting -- if needed, explicitly -- traffic 246 through the network. 248 3.1. Constructing the Access List 250 Edge Infrastructure Access Control Lists permit only required traffic 251 to the network infrastructure, while allowing data plane traffic to 252 flow through unaffected. The basic premise of EIACLs is that only a 253 relatively limited subset of traffic, sourced from outside your AS, 254 needs to be destined for a core router and that by explicitly 255 permitting only that known and understood traffic, the core devices 256 are not subjected to unnecessary traffic that might result in a 257 denial of service attack. 259 Since edge infrastructure access control lists protect only the 260 infrastructure, the development of the list differs somewhat from 261 "traditional" access filter lists: 263 1. Review addressing scheme, and identify address block(s) 264 that represent core devices. 266 2. Determine what traffic must be destined to the core devices 267 from outside the AS. 269 3. Create a filter that allow the required traffic, denies all 270 traffic destined to the core address block and then finally, permits 271 all other traffic to all. 273 As with other ingress filtering techniques, EIACLs are applied on 274 ingress into the network, and clearly comprehensive coverage (i.e. on 275 as many interface as possible) yields the most protection. 277 3.2. Other Traffic 279 In addition to the explicitly permitted traffic, EIACLs can be 280 combined with other common edge filters such as: 282 1. Source spoof prevention (as per RFC 3704) by denying 283 internal AS addresses as external sources. 285 2. Filtering of reserved addresses (e.g. rfc1918 addresses) as 286 traffic should not be sourced from reserved address. 287 3. Other unneeded or unnecessary traffic 289 Filtering this traffic can be part of the list explicitly or 290 implicitly, however, explicit filters often provides log-able 291 information that can be of use during a security event. 293 3.3. Edge Infrastructure Conclusion 295 Edge Infrastructure Access Control Lists provide a very effective 296 first line of defense. To deploy them effectively, core address 297 space must be identifiable and widespread deployment is necessary. 299 4. Edge Rewrite/Remarking 301 RFC 1812 section 5.3 defines the use of IP Preference in IPv4 packets 302 for routing, management and control traffic. In addition it 303 recommends devices use a mechanism for providing preferential 304 forwarding for packets marked as routing, management or control 305 traffic using IP Preference bits 6 or 7 (110 or 111 in binary.) 306 RFC2474 defines DSCP and the compatibility of IP Preference bits when 307 using DSCP. 309 All packets received from the Customer edge (CE,) and the Peer Edge 310 by the Provider Edge (PE,) with IP Preference values of 6 or 7 or 311 DSCP bits of 11xxxx, as specified in RFC2474 Differentiated Services 312 Field Definition, should have the IP Preference bits rewritten. 313 Routing traffic received from the CE and the Peer Edge can safely 314 have the IP Preference bits rewritten, because only a limited number 315 of protocols are transmitted beyond the first PE router. The bits 316 may be rewritten to any value other than IP Preference values 6 or 7, 317 or any DSCP value other than 11xxxx. The new value can be based on 318 the network operators IP Preference or DSCP policy. If no policy 319 exists the bits should be rewritten to 0. 321 Providers may not want to modify traffic that goes through their 322 network in an effort offer a fully transparent service. If the 323 provider relies on alternative means of classifying traffic for 324 prioritized forwarding rewriting the IP Preference bits is not 325 required. Alternatives include encapsulating customer traffic into a 326 second protocol, such as MPLS, GRE, and IP, or using an Access 327 Control List (ACL) to classify legitimate routing, management, and 328 control traffic. When encapsulating traffic into a second protocol, 329 policy must ensure that IP Preference bits 6 and 7 are not 330 transferred to the preference field of encapsulating protocol. In 331 this example the EXP bits or IP Preference/DSCP bits. A longer tuple 332 used for identifying routing, management and control traffic will 333 provide a higher level of security than a shorter one. Other 334 techniques may exist not covered in this document. 336 4.1. Edge Rewriting/Remarking Discussion 338 By default router vendors do not differentiate an interface on a PE 339 router connected to a P router from an interface connected to a CE 340 router. As a result any packet with the proper IP Preference or DSCP 341 bits set may receive the same preferential forwarding behavior as 342 legitimate routing, management, and control traffic. A malicious 343 attack may be able to take advantage of the vulnerability to increase 344 the effectiveness of the attack or to attack the routing, management, 345 and/or control traffic directly. 347 This document is aimed at protecting network infrastructure from 348 traffic to the device rather than traffic through the device. Even 349 though the edge rewrite/remarking deals primarily with traffic 350 through a device it is included because the traffic has a direct 351 impact on traffic to a device. The forwarding prioritization given 352 to routing, management, and control traffic by default leaves devices 353 vulnerable to indirect attacks to the core infrastructure. 355 5. Device/Element Protection 357 Even with the widest possible deployment of the techniques described 358 above in the section Infrastructure Edge Access Control, the 359 individual devices of the network must implement access control 360 mechanisms. This is because in addition to the case of incomplete or 361 imperfect deployment of edge infrastructure control, threats may 362 occur from trusted sources within the perimeter of the network. 364 5.1. Service Specific Access Control 366 Typically these mechanisms are not concerned with protecting the 367 system as a whole, but the service from exploitation. The goal is 368 not overall system availability, but maximizing the security of the 369 particular service. 371 5.1.1. Common Services 373 While each service implemented by network equipment manufacturers 374 differs in its available security features there are some common 375 services and security features for those services that have been 376 widely deployed. 378 The most important first step for the operator is to disable any 379 unneeded/unused services. 381 Second, the operator should utilize the services access control 382 mechanisms to limit the access to the devices service to only 383 required sources. Examples are using virtual terminal access control 384 lists, or SNMP Community access control lists. 386 5.2. Aggregate Device Access Control 388 The device must be protected from denial of service threats, in 389 addition, aggregating the security policy allows for a simplified 390 view of the access policies traffic going to the device. 392 A key requirement of these mechanisms is that it must not impact 393 transit data plane traffic. In addition, these mechanisms should not 394 make the device more vulnerable to malicious traffic than not using 395 them. 397 5.2.1. IP Fragments 399 Traffic destined to a router is not typically fragmented. Fragment 400 keywords or other mechanisms to deny fragments to the device are 401 recommended. 403 5.2.2. Performance Considerations 405 Care should be taken to understand a vendors implementation of this 406 functionality and to make sure that device operation is not impaired 407 during DoS attacks against the device. 409 5.2.3. Access Control Implementation Guide 411 Implementing a complex set of access controls for all traffic going 412 to and from a router is non trivial. The following is a recommended 413 set of steps that has been used successfully by many carriers. 415 -Develop list of required protocols 416 -Develop source address requirements 417 -Determine destination interface on router 418 Does the protocol access a single interface? 419 Does the protocol access many interfaces? 420 Does the protocol access a virtual or physical interfaces? 421 -Deployment should be an iterative process 422 -Start with relatively open lists then tighten as needed 424 5.3. Device Access Authorization and Accounting 426 Operators should use per command authorization and accounting 427 wherever possible. Aside from their utility in mitigating other 428 security threats, they provide an invaluable tool in the post event 429 forensics. 431 6. Infrastructure Hiding 433 Hiding the infrastructure of the network provides an elegant 434 mechanism for protecting the network infrastructure. If the 435 destination of an attack is to an infrastructure address that is 436 unreachable, attacks become far more difficult. Infrastructure 437 hiding can be achieved in several ways: 439 6.1. Use less IP 441 One way to reduce exposure of network infrastructure is to use 442 unnumbered links wherever possible. This is particularly useful for 443 customers in the simple case of a single provider with a default path 444 to the Internet. 446 6.2. MPLS techniques 448 While it may not be feasible to hide the entire infrastructure of 449 large networks from edge to edge using MPLS, it is certainly possible 450 to reduce exposure of critical core infrastructure beyond the first 451 hop by creating an MPLS mesh where TTL is not decremented as packets 452 pass through it. In this manner the number, addresses, and even 453 existence of intermediary devices can be hidden from traffic as it 454 passes through the core. 456 6.3. IGP configuration 458 Using a non-IP control plane for the core routing protocol can 459 substantially reduce the number of IP addresses that 460 [comprise/expose] the core. This simplifies the task of maintaining 461 edge ACLs or route announcement filters. IS-IS is an elegant and 462 mature protocol that may be suitable for this task. 464 6.4. Route advertisement control 466 6.4.1. Route Announcement filtering 468 Inasmuch as it is unavoidable that some network elements must be 469 configured with IP addresses, it may be possible to assign these 470 address out of netblocks for which the routing advertisement can be 471 filtered, thereby limiting possible sources of traffic to core 472 netblocks down to customers for which you provide a default route, or 473 direct peers who would make the effort to create a static route for 474 your core netblock into your AS. 476 Further, it may be possible in those situations where customer point- 477 to-point links must be numbered, to address such links out of another 478 range of addresses for which announcements could be similarly 479 filtered. While this has implications for a customer's ability to 480 remote-monitor their circuit, this can often be overcome with 481 application of an address from the customer's routed space to the CPE 482 loopback. 484 6.4.2. Address core out of rfc1918 space 486 In addition to filtering the visibility of core addresses to the 487 wider Internet, it may be possible to use rfc1918 netblocks for 488 numbering infrastructure when IP addresses are required (eg, 489 loopbacks). This added level of obscurity takes prevention of wide 490 distribution of your infrastructure address space one step further. 491 Many networks filter out packets with rfc1918 address at 492 ingress/egress points as a matter of course. In this circumstance, 493 tools such as traceroute can work through your core, but reverse- 494 resolution of descriptive names should be restricted to queries from 495 internal/support groups. 497 7. IPv6 499 IPv6 Networks contain the same infrastructure security risks as IPv4. 501 All techniques described in this document for IPv4 should be directly 502 applicable to IPv6 networks. Limitations exist where devices do not 503 have feature parity between IPv4 and IPv6. Different techniques 504 maybe required where IPv4 and IPv6 networks deviate in 505 implementation. Multi-vendor networks create greater difficulties 506 when each vendor does not have feature parity with each other. 508 Hardware differences in devices that support both IPv4 and IPv6 must 509 also be taken into consideration. Because IPv6 uses a longer address 510 space the scaling, and performance characteristics of ACLs maybe 511 lower for IPv6 vs IPv4. The fields or number of fields that an ACL 512 can match on may also differ. 514 The fact that all PE devices do not support all the recommended ipv6 515 security features should not preclude the implementation of the 516 recommendations in this document on the devices that do support the 517 security features. 519 With the number of Network Operators deploying IPv6 growing, along 520 with the continued availability of IPv6 Tunnel services, connecting 521 to the IPv6 internet is less difficult. Dual stack IPv6 networks run 522 on 10Gbps and greater backbones with edge speeds equal to IPv4. 523 Neither the edge nor the core limit potential IPv6 attacks. 525 7.1. IPv6 Edge Infrastructure Access Control List 527 The same process should be used for constructing the IPv6 eiacl as 528 the IPv4 eiacl. 530 7.2. IPv6 Edge Remarking 532 IPv6 DSCP bits should be rewritten in the same manner that IPv4 DSCP 533 bits. 535 7.3. IPv6 Device and Element Protection 537 IPv6 device and element protection should be implemented using the 538 same policy as IPv4. 540 7.4. IPv6 Infrastructure Hiding 542 Network operators may deploy IPv4 differently from IPv6 in their 543 network. Providers may use native forwarding for IPv6 while using 544 MPLS for IPv4, other combinations. IPv6 infrastructure hiding should 545 have parity with IPv4 infrastructure hiding even if the technique 546 used is different. 548 Implementation of IPv6 route advertisement control for infrastructure 549 hiding is difficult when using global address space. It is difficult 550 to get non-continuous network blocks from the address registries, and 551 de-aggregation of IPv6 address space is not an acceptable 552 alternative. It is still possible to use private address space as a 553 way of restricting IPv6 advertisements. 555 8. IP Multicast 557 IP Multicast behaves differently from IP unicast therefore must be 558 secured in a different manner. Some of the protocols used with 559 Multicast rely on IP unicast to transport the routing, and control 560 information. Unicast based protocols should be secured using the 561 technique described in much of this document. Because this document 562 is focused on hardening a service providers infrastructure rather 563 than validating routing announcements, much of IP Multicast filtering 564 will be better covered in other documents. 566 In much the same way a host must listen on a certain IP address and 567 port for an IP unicast connection, Multicast must join a group in 568 order to receive any information via Multicast. The major difference 569 is that multicast groups are global and not assigned to a specific 570 customer or end user. Administrative boundaries and scope are 571 created to isolate Multicast groups within one network or desired 572 area. 574 8.1. Multicast Group Protection 576 Certain Multicast groups should never been joined from outside an 577 operators network or administrative boundary. Filters should be 578 placed on the protocols used to communicate with external hosts and 579 networks. IGMP should have a join filter to prevent hosts from 580 joining internal groups. MSDP should be configured with a Source 581 Address (SA) filter to prevent other networks from joining internal 582 groups. 584 EIACLs should include administratively bounded multicast groups, 585 along with any groups used for protocols internal to a providers 586 network. 588 When constructing router Access Control as described in section 589 5.2.4, multicast protocols must be taken into consideration. 591 8.2. Performance Considerations 593 Multicast protocols and implementation have different performance and 594 scaling limitation than IP unicast. Multicast users create state on 595 the router every time the user joins a group. Router resources can 596 be exhausted if the amount of state created exceeds the resources 597 available on the router. Placing limits on the resources used by the 598 Multicast protocols can prevent collateral damage to services other 599 than Multicast on a router. MSDP should have a limit placed on the 600 number of SA announcements received. A fixed limit should be placed 601 on the number of entries the router stores in the IP Multicast 602 routing table. The number of SAP entries should have a limit placed 603 on them. 605 8.3. IPv6 and Multicast 607 IPv6 Multicast policy should be consistent with the IP Multicast 608 policy. 9.0 Security Considerations 610 9. Acknowledgments 611 10. References 613 10.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to 616 Indicate Requirement Levels", BCP 14, RFC 2119, 617 March 1997. 619 [REF] Reference.... 621 10.2. Informative References 623 [RFC3667] Bradner, S., "IETF Rights in Contributions", 624 BCP 78, RFC 3667, February, 2004. 626 [RFC3668] Bradner, S., "Intellectual Property Rights in 627 IETF Technology", BCP 79, RFC 3668, February, 628 2004. 630 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 631 Writing an IANA Considerations Section in RFCs", 632 BCP 26, RFC 2434, October 1998. 634 11. Authors' Addresses 636 James Gill 637 TBD 639 Darrel Lewis 640 Cisco Systems Inc. 641 170 West Tasman Drive 642 San Jose, CA 95134 643 Phone: +1 408 853 3653 644 EMail: darlewis@cisco.com 646 Paul Quinn 647 170 West Tasman Drive 648 San Jose, CA 95134 649 Phone: +1 408 527 3560 650 Email: paulq@cisco.com 652 Peter Schoenmaker 653 NTT America 654 101 Park Ave., FL 41 655 New York, NY 10178 656 +1-212-808-2298 657 pds@ntt.net 659 Intellectual Property Statement 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the procedures with respect to rights in RFC documents can be 668 found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org. 683 Disclaimer of Validity 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 688 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 689 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 690 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Copyright Statement 695 Copyright (C) The Internet Society (2006). This document is subject 696 to the rights, licenses and restrictions contained in BCP 78, and 697 except as set forth therein, the authors retain all their rights. 699 Acknowledgment 701 Funding for the RFC Editor function is currently provided by the 702 Internet Society.