idnits 2.17.1 draft-ietf-opsec-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 718. ** 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: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (August 31, 2006) is 6419 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2334' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 634, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3667 (Obsoleted by RFC 3978) -- Obsolete informational reference (is this intentional?): RFC 3668 (Obsoleted by RFC 3979) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Opsec Working Group J. Gill 3 Internet-Draft Verizon Business 4 Intended status: Informational D. Lewis 5 Expires: March 4, 2007 P. Quinn 6 Cisco Systems Inc. 7 P. Schoenmaker 8 NTT America 9 August 31, 2006 11 Service Provider Infrastructure Security 12 draft-ietf-opsec-infrastructure-security-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 4, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This RFC describes best current practices for implementing Service 46 Provider network infrastructure protection for network elements. 47 This RFC complements and extends RFC 2267 and RFC 3704. RFC 2267 48 provides guidelines for filtering traffic on the ingress to service 49 provider networks. RFC 3704 expands the recommendations described in 50 RFC 2267 to address operational filtering guidelines for single and 51 multi-homed environments. The focus of those RFCs is on filtering 52 packets on ingress to a network, regardless of destination, if those 53 packets have a spoofed source address, or if the source address fall 54 within "reserved" address space. Deployment of RFCs 2267 and 3704 55 has limited the effects of denial of service attacks by dropping 56 ingress packets with spoofed source addresses, which in turn offers 57 other benefits by ensuring that packets coming into a network 58 originate from validly allocated and consistent sources. This 59 document focuses solely on traffic destined to elements of the the 60 network infrastructure itself. This document presents techniques 61 that, together with network edge ingress filtering and RFC 2267 and 62 RFC 3704, provides a defense in depth approach for infrastructure 63 protection. This document does not present recommendations for 64 protocol validation (i.e. "sanity checking") nor does it address 65 guidelines for general security configuration. 67 Requirements Language 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Overview of Infrastructure Protection Techniques . . . . . . . 5 77 2.1. Edge Remarking . . . . . . . . . . . . . . . . . . . . . . 5 78 2.2. Device and Element Protection . . . . . . . . . . . . . . 5 79 2.3. Infrastructure Hiding . . . . . . . . . . . . . . . . . . 5 80 3. Edge Infrastructure Access Control Lists . . . . . . . . . . . 6 81 3.1. Constructing the Access List . . . . . . . . . . . . . . . 6 82 3.2. Other Traffic . . . . . . . . . . . . . . . . . . . . . . 6 83 3.3. Edge Infrastructure Conclusion . . . . . . . . . . . . . . 7 84 4. Edge Rewrite/Remarking . . . . . . . . . . . . . . . . . . . . 7 85 4.1. Edge Rewrite/Remarking Discussion . . . . . . . . . . . . 7 86 4.2. Edge Rewriting/Remarking Performance Considerations . . . 8 87 5. Device/Element Protection . . . . . . . . . . . . . . . . . . 8 88 5.1. Service Specific Access Control . . . . . . . . . . . . . 8 89 5.1.1. Common Services . . . . . . . . . . . . . . . . . . . 9 90 5.2. Aggregate Device Access Control . . . . . . . . . . . . . 9 91 5.2.1. IP Fragments . . . . . . . . . . . . . . . . . . . . . 9 92 5.2.2. Performance Considerations . . . . . . . . . . . . . . 9 93 5.2.3. Access Control Implementation Guide . . . . . . . . . 9 94 5.3. Device Access Authorization and Accounting . . . . . . . . 10 95 6. Infrastructure Hiding . . . . . . . . . . . . . . . . . . . . 10 96 6.1. Use Less IP . . . . . . . . . . . . . . . . . . . . . . . 10 97 6.2. MPLS Techniques . . . . . . . . . . . . . . . . . . . . . 10 98 6.3. IGP Configuration . . . . . . . . . . . . . . . . . . . . 11 99 6.4. Route Advertisement Control . . . . . . . . . . . . . . . 11 100 6.4.1. Route Announcement Filtering . . . . . . . . . . . . . 11 101 6.4.2. Address Core Out of RFC 1918 Space . . . . . . . . . . 11 102 6.5. Further obfuscation . . . . . . . . . . . . . . . . . . . 12 103 7. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 104 7.1. Use LIPv6 Edge Infrastructure Access Control Lists . . . . 12 105 7.2. IPv6 Edge Remarking . . . . . . . . . . . . . . . . . . . 12 106 7.3. IPv6 Device and Element Protection . . . . . . . . . . . . 13 107 7.4. IPv6 Infrastructure Hiding . . . . . . . . . . . . . . . . 13 108 8. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 13 109 8.1. Multicast Group Protection . . . . . . . . . . . . . . . . 13 110 8.2. Performance Considerations . . . . . . . . . . . . . . . . 14 111 8.3. IPv6 and Multicast . . . . . . . . . . . . . . . . . . . . 14 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 114 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 115 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 117 Intellectual Property and Copyright Statements . . . . . . . . . . 16 119 1. Introduction 121 This RFC describes best current practices for implementing Service 122 Provider network infrastructure protection for network elements. RFC 123 2267 and RFC 3704 focuses on limiting the effects of denial of 124 service attacks by filtering ingress packets with spoofed source 125 addresses. This offers additional benefits by ensuring that packets 126 coming into a network originate from validly allocated and consistent 127 sources. RFC 3704 extends the recommendations described in RFC 2267 128 to address operational filtering guidelines for single and multi- 129 homed environments. In both cases (RFC 2267 and RFC 3704), the focus 130 is on dropping packets on ingress, regardless of destination, if 131 those packets are have a spoofed source address or if the source of 132 the packet falls within "reserved" address space. This document both 133 refines and extends the filtering best practices outlined in RFC 2267 134 and RFC 3704 and focuses only on traffic destined to the network 135 infrastructure itself to protect the service provider network from 136 denial of service and other attacks. This document presents 137 techniques that, together with network edge ingress filtering and RFC 138 2267 and RFC 3704, provides a defense in depth approach for 139 infrastructure protection. Denial of Service (DoS) attacks are 140 common and the network infrastructure itself is a target. 142 Attacks targeting the network infrastructure can take many forms, 143 including bandwidth saturation to crafted packets destined to a 144 router. These attacks might use spoofed source addresses or they 145 might use the true source address of of the traffic. Regardless of 146 the nature of the attack, the network infrastructure must be 147 protected from both accidental floods and intentional attacks. 148 Additionally, this protection will assist in preventing the network 149 elements from being used as reflectors in attacks against others. 151 The techniques outlined in this document and described in section 2 152 below, describe best practices for infrastructure protection: edge 153 policy (filtering and precedence), per device traffic policy 154 enforcement for packets destined to a device and, limiting of address 155 and routing visibility to reduce exposure to limit core network -- 156 that is provider (P) and provider edge (PE) infrastructure -- 157 attacks. This document is targeted at network operators seeking to 158 limit their exposure to risks associated with denial of service 159 targeting the infrastructure. These techniques are designed to be 160 used in addition to specific protocol or application security 161 features implemented in network devices. 163 Infrastructure protection is a complex topic. While the best 164 practices outlines in this document do not provide perfect 165 protection, they can significantly improve the protection of the 166 network infrastructure. 168 2. Overview of Infrastructure Protection Techniques 170 This section provides an overview of recommended techniques that may 171 be used to protect network infrastructure. The details of each area, 172 along with some deployment consideration, are described in detail in 173 subsequent sections. The four technique describes in this document 174 are: - Edge Infrastructure Access Control List - Edge Remarking - 175 Device and Element Protection - Infrastructure Hiding The above list 176 is not exhaustive; other mechanisms can be used to provide additional 177 protection. The techniques discussed in this document have been 178 widely deployment and have proven operational security benefits in 179 large networks. 181 2.1. Edge Remarking 183 Edge Remarking, detailed in section 4, ensures that ingress IP 184 precedence or DSCP values match expected values within the context of 185 security. This provides another layer of defense, particularly for 186 traffic permitted through any of the Edge Infrastructure Access 187 Control Lists. This document focuses only on using Edge Remarking 188 best practices to enforce security policies. 190 2.2. Device and Element Protection 192 Each network infrastructure device should enforce local rules for 193 traffic destined to the device itself. These rules can take the form 194 of filters (permit/deny) or rate limiting rules that allow ingress 195 traffic at specified rates. These should complement any existing 196 Edge Infrastructure Access Control Lists and are described in more 197 detail in section 5. The deployment of these local device protection 198 rules complements the edge techniques by protecting the device from 199 traffic that: i) was permitted but violates device policy, ii) could 200 not be filtered at the edge, iii) entered the network on an interface 201 that did not have ingress filtering enabled. 203 2.3. Infrastructure Hiding 205 Hiding the infrastructure of the network provides an elegant 206 mechanism for protecting the network infrastructure. If the 207 destination of an attack is to an infrastructure address that is 208 unreachable, attacks become far more difficult. Infrastructure 209 hiding can be achieved in several ways: - MPLS techniques - IGP 210 configuration - Route advertisement control Section 6 covers 211 infrastructure hiding techniques. 213 3. Edge Infrastructure Access Control Lists 215 Edge Infrastructure Access Control Lists (EIACLs) are a specific 216 implementation of the more general Ingress Access List. As opposed 217 to generic ingress filtering which denies data (sometimes referred to 218 as user) plane traffic, edge infrastructure access control lists do 219 not attempt to deny transit traffic; rather, this form of access 220 control limits traffic destined to infrastructureequipment while 221 permitting -- if needed, explicitly -- traffic through the network. 223 3.1. Constructing the Access List 225 Edge Infrastructure Access Control Lists permit only required traffic 226 destined to the network infrastructure, while allowing data plane 227 traffic to flow through unfiltered. The basic premise of EIACLs is 228 that only a relatively limited subset of traffic, sourced from 229 outside an AS, needs to be destined towards a core router and that by 230 explicitly permitting only that known and understood traffic, the 231 core devices are not subjected to unnecessary traffic that might 232 result in a denial of service. Since edge infrastructure access 233 control lists protect only the infrastructure, the development of the 234 list differs somewhat from "traditional" access filter lists: 236 1. Review addressing scheme, and identify address block(s) that 237 represent core devices. 239 2. Determine what traffic must be destined to the core devices from 240 outside the AS. 242 3. Create a filter that allow the required traffic, denies all 243 traffic destined to the core address block and then finally, 244 permits all other traffic. 246 As with other ingress filtering techniques, EIACLs are applied on 247 ingress interfaces, as close to the edge as possible. Comprehensive 248 coverage (i.e. on as many interface as possible) yields the most 249 protection. 251 3.2. Other Traffic 253 In addition to the explicitly permitted traffic, EIACLs can be 254 combined with other common edge filters such as: 1. Source spoof 255 prevention (as per RFC 3704) by denying internal AS addresses as 256 external sources. 2. Filtering of reserved addresses (e.g. rfc1918 257 addresses) as traffic should not be sourced from reserved address. 3. 258 Other unneeded or unnecessary traffic Filtering this traffic can be 259 part of the list explicitly or implicitly; explicit filters often 260 provide log-able information that can be of use during a security 261 event. 263 3.3. Edge Infrastructure Conclusion 265 Edge Infrastructure Access Control Lists provide a very effective 266 first line of defense. EIACLs are not perfect and cannot protect the 267 network against every attack. Furthermore, to be manageable, EIACLs 268 must be able to clearly and simply identify infrastructure address 269 space. To be effective, the EIACLs should be deployed as widely as 270 possible at the edge of the network on devices that support the 271 required filtering performance characteristics. 273 4. Edge Rewrite/Remarking 275 RFC 1812 section 5.3 defines the use of IP Preference in IPv4 packets 276 for routing, management and control traffic. In addition, the RFC 277 recommends that devices use a mechanism for providing preferential 278 forwarding for packets marked as routing, management or control 279 traffic using IP Preference bits 6 or 7 (110 or 111 in binary.) 280 RFC2474 defines DSCP and the compatibility of IP Preference bits when 281 using DSCP. All packets received by customer- and peer-facing 282 Provider Edge (PE) router interfaces with IP Preference values of 6 283 or 7 or DSCP bits of 11xxxx, as specified in RFC2474 Differentiated 284 Services Field Definition, should have the IP Preference bits 285 rewritten. Routing traffic received from customer- and peer-facing 286 interfaces can safely have the IP Preference bits rewritten because 287 only a limited number of protocols are transmitted beyond the first 288 PE router. The bits may be rewritten to any value other than IP 289 Preference values 6 or 7, or any DSCP value other than 11xxxx. The 290 new value can be based on the network operators IP Preference or DSCP 291 policy. If no policy exists the bits should be rewritten to 0. 293 In cases where control, management, and routing traffic enters the 294 provider network via the customer- and peer-facing interfaces policy 295 should be employed to ensure proper prioritization of critical 296 traffic. EIACLs maybe be used facilitate the proper classification 297 of traffic. To offer fully transparent service, a provider may not 298 wish to modify the IP precedence on transit traffic through the 299 network. If a provider has alternate means of applying different 300 prioritization to router management and control traffic and transit 301 traffic then rewriting IP precedence bits is not required. 303 4.1. Edge Rewrite/Remarking Discussion 305 By default router vendors do not differentiate an interface on a PE 306 router connected to a P router from an interface connected to a CE 307 router. As a result any packet with the proper IP Preference or DSCP 308 bits set may receive the same preferential forwarding behavior as 309 legitimate routing, management, and control traffic. A malicious 310 attack may be able to take advantage of the vulnerability to increase 311 the effectiveness of the attack or to attack the routing, management, 312 and/or control traffic directly. This document is aimed at 313 protecting network infrastructure from traffic to the device rather 314 than traffic through the device. Even though the edge rewrite/ 315 remarking deals primarily with traffic through a device it is 316 included because the traffic has a direct impact on traffic to a 317 device. The forwarding prioritization given to routing, management, 318 and control traffic by default leaves devices vulnerable to indirect 319 attacks to the infrastructure. By rewriting the IP Precedence at the 320 PE protection is provided for both traffic through the network along 321 with traffic that is to the network that is not blocked by other 322 methods discussed in this document. This document assumes that all 323 customer- and peer-facing interfaces cannot be trusted for inter- 324 domain diff-serv. In cases where a trust relationship exists for 325 inter-domain diff-serv, diff-serv bits 1xxxxxxx do not have to be 326 rewritten. 328 4.2. Edge Rewriting/Remarking Performance Considerations 330 Device resources required must be taken into consideration when 331 rewriting/remarking IP Precedence/DSCP bits. Devices may require 332 additional resources to rewrite/remark packets. 334 5. Device/Element Protection 336 Even with the widest possible deployment of the techniques described 337 above in the section Infrastructure Edge Access Control, the 338 individual devices of the network must implement access control 339 mechanisms. This is required because, in addition to the case of 340 incomplete or imperfect deployment of edge infrastructure control, 341 threats may coem from from trusted sources within the perimeter of 342 the network. 344 5.1. Service Specific Access Control 346 Typically these mechanisms are not directly concerned with protecting 347 the availability of the device as a whole, but the device from 348 exploitation via the service concerned. Analysis of the behavior of 349 widly deployed serivce security features shows that maximizing the 350 security of the particular service, not overall system availability, 351 is the primary goal of the feature. There are many practical 352 examples of vendor specific security mechanisms, the references 353 section provides likes to several of them. These should guide the 354 operator in securing the services that they enable. 356 5.1.1. Common Services 358 While each service implemented by network equipment manufacturers 359 differs in its available security features there are some common 360 services and security features for those services that have been 361 widely deployed. The most important first step for the operator is 362 to disable any unneeded/unused services. This reduces the devices 363 profile. If the device is not listening to a port, it is much more 364 difficult to attack via that port. Second, the operator should 365 utilize the services access control mechanisms to limit the access to 366 the devices service to only required sources. Examples of per serive 367 security are using virtual terminal access control lists, or SNMP 368 Community access control lists. 370 5.2. Aggregate Device Access Control 372 The device must be protected from denial of service threats, in 373 addition, aggregating the security policy -- as opposed to defining 374 it on a per service basis -- allows for a simplified view of the 375 access policies traffic going to the device. A key requirement of 376 these mechanisms is that it must not impact transit data plane 377 traffic. 379 5.2.1. IP Fragments 381 Traffic destined to a router is not typically fragmented. Use of 382 mechanisms to deny fragments to the device are recommended. 384 5.2.2. Performance Considerations 386 Care should be taken to understand a vendors implementation of 387 aggregate device access control and to make sure that device 388 operation is not impaired during DoS attacks against the device. 390 5.2.3. Access Control Implementation Guide 392 Implementing a complex set of access controls for all traffic going 393 to and from a router is non trivial. The following is a recommended 394 set of steps that has been used successfully by many carriers. 396 1. Develop list of required protocols. 398 2. Develop source address requirements: Determine destination 399 interface on router Does the protocol access a single interface? 400 Does the protocol access many interfaces? Does the protocol 401 access a virtual or physical interfaces? 403 3. Prior to implementing with a deny, it is recommended to test the 404 behavior with the action of "log" and observe the results 406 4. Deployment should be an iterative process: Start with relatively 407 open lists then tighten as needed 409 5.3. Device Access Authorization and Accounting 411 Operators should use per command authorization and accounting 412 wherever possible. Aside from their utility in mitigating other 413 security threats, they provide an invaluable tool in the post event 414 forensics. 416 6. Infrastructure Hiding 418 While core equipment is in the transit path it is necessarily 419 reachable and succeptible to attacks that fall beyond the scope of 420 this document. Primarily, transit equipment is always at risk for 421 collateral damage when hosts downstream come under substantial 422 attack. Hiding the infrastructure of the network provides an elegant 423 mechanism for protecting the network infrastructure. If the an 424 attack vector requires that packets are sent to infrastructure 425 address that is unreachable, successful execution of such attacks 426 becomes far more difficult. The following sections present different 427 options for accomplishing infrastructure hiding. 429 6.1. Use Less IP 431 One way to reduce exposure of network infrastructure is to use 432 unnumbered links wherever possible. This is particularly useful for 433 customers in the simple case of a single provider with a default path 434 to the Internet. Not only can such a configuration reduce the 435 exposure of the equipment on both ends of the link to malicious 436 attack, the overall effort required to manage a link can be reduced 437 considerably with a simplified configuration and without the 438 additional overhead and expense of managing the addresses. 440 6.2. MPLS Techniques 442 While it may not be feasible to hide the entire infrastructure of 443 large networks from edge to edge using MPLS, it is certainly possible 444 to reduce exposure of critical core infrastructure beyond the first 445 hop by creating an MPLS mesh where TTL is not decremented as packets 446 pass through it. In this manner the number, addresses, and even 447 existence of intermediary devices can be hidden from traffic as it 448 passes through the core. 450 6.3. IGP Configuration 452 Using a non-IP control plane for the core routing protocol can 453 substantially reduce the number of IP addresses that comprise (and 454 therefore, expose) the core. This simplifies the task of maintaining 455 edge ACLs or route announcement filters. IS-IS is an elegant and 456 mature protocol that may be suitable for this task. 458 6.4. Route Advertisement Control 460 6.4.1. Route Announcement Filtering 462 Inasmuch as it is unavoidable that some network elements must be 463 configured with IP addresses, it may be possible to assign these 464 address out of netblocks for which the routing advertisement can be 465 filtered out, thereby limiting possible sources of traffic to core 466 netblocks down to customers for whom you provide a default route, or 467 direct peers who would make the effort to create a static route for 468 your core netblock into your AS. By assigining address for network 469 infrastructure out of a limited number of address blocks which are 470 well known to internal network administrators, the operator can 471 greatly simplify ACL configuration. This can also minimise the 472 frequency with which ACLs need to be updated based on changes in the 473 network. This can also have performance implications, especially for 474 equipment where the length of ACLs is limited. By keeping ACLs short 475 they may be deployable on a wider range of existing equipment. 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 RFC 1918 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 ingress/ 492 egress points as a matter of course. In this circumstance, tools 493 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 6.5. Further obfuscation 499 The strategy of changing services to run on ports different from the 500 default and well-known ones will not protect you from a determined 501 attacker. It can, however, provide some level of protection from 502 many attack tools, worms, auto-rooters, etc. Should they find access 503 to the infrastructure equipment in some way. Again, this does 504 nothing to restrict access, nor to make network devices more 505 difficult to reach. As with the other methods, a careful 506 consideration of how much effort and management each strategy 507 requires must be weighed against the protection that it provides and 508 the necessity of that protection in light of all measures taken to 509 protect a network. 511 7. IPv6 513 IPv6 Networks contain the same infrastructure security risks as IPv4. 514 All techniques described in this document for IPv4 should be directly 515 applicable to IPv6 networks. Limitations exist where devices do not 516 have feature parity between IPv4 and IPv6. Different techniques 517 maybe required where IPv4 and IPv6 networks deviate in 518 implementation. Multi-vendor networks create greater difficulties 519 when each vendor does not have feature parity with each other. 520 Hardware differences in devices that support both IPv4 and IPv6 must 521 also be taken into consideration. Because IPv6 uses a longer address 522 space the scaling, and performance characteristics of ACLs maybe 523 lower for IPv6 vs IPv4. The fields or number of fields that an ACL 524 can match on may also differ. The fact that all PE devices do not 525 support all the recommended ipv6 security features should not 526 preclude the implementation of the recommendations in this document 527 on the devices that do support the security features. With the 528 number of Network Operators deploying IPv6 growing, along with the 529 continued availability of IPv6 Tunnel services, connecting to the 530 IPv6 internet is less difficult. Dual stack IPv6 networks run on 531 10Gbps and greater backbones with edge speeds equal to IPv4. Neither 532 the edge nor the core limit potential IPv6 attacks. 534 7.1. Use LIPv6 Edge Infrastructure Access Control Lists 536 The same process should be used for constructing the IPv6 eiacl as 537 the IPv4 EIACL. 539 7.2. IPv6 Edge Remarking 541 IPv6 DSCP bits should be rewritten in the same manner that IPv4 DSCP 542 bits. Differences between DSCP rewriting of IPv4 and IPv6 will 543 minimal except in cases where the device capabilities differ between 544 IPv4 and IPv6. 546 7.3. IPv6 Device and Element Protection 548 Device and Element protection should be created using the same 549 methods described in this document for IPv4. The policy may differ 550 for IPv6 from IPv4 in cases where services are exclusively IPv4 or 551 exclusively IPv6. Services not used with IPv6 should be disabled. 553 7.4. IPv6 Infrastructure Hiding 555 Network operators may deploy IPv4 differently from IPv6 in their 556 network. Providers may use native forwarding for IPv6 while using 557 MPLS for IPv4, other combinations. IPv6 infrastructure hiding should 558 have parity with IPv4 infrastructure hiding even if the technique 559 used is different. Implementation of IPv6 route advertisement 560 control for infrastructure hiding is difficult when using global 561 address space. Registeries assign fewer large blocks of IPv6 space 562 compared to IPv4. Providers cannot control the announcement of 563 infrastructure global IPv6 blocks for infrastructure hiding without 564 deaggregating their IPv6 announcements. 566 8. IP Multicast 568 IP Multicast behaves differently from IP unicast therefore must be 569 secured in a different manner. Some of the protocols used with 570 Multicast rely on IP unicast to transport the routing, and control 571 information. Unicast based protocols should be secured using the 572 technique described in much of this document. Because this document 573 is focused on hardening a service providers infrastructure rather 574 than validating routing announcements, much of IP Multicast filtering 575 will be better covered in other documents. In much the same way a 576 host must listen on a certain IP address and port for an IP unicast 577 connection, Multicast must join a group in order to receive any 578 information via Multicast. The major difference is that multicast 579 groups are global and not assigned to a specific customer or end 580 user. Administrative boundaries and scope are created to isolate 581 Multicast groups within one network or desired area. 583 8.1. Multicast Group Protection 585 Certain Multicast groups should never be joined from outside an 586 operators network or administrative boundary. Filters should be 587 placed on the protocols used to communicate with external hosts and 588 networks. IGMP should have a join filter to prevent hosts from 589 joining internal groups. MSDP should be configured with a Source 590 Address (SA) filter to prevent other networks from joining internal 591 groups. EIACLs should include administratively bounded multicast 592 groups, along with any groups used for protocols internal to a 593 providers network. When constructing router Access Control as 594 described in section 5.2.4, multicast protocols must be taken into 595 consideration. 597 8.2. Performance Considerations 599 Multicast protocols and implementation have different performance and 600 scaling limitation than IP unicast. Multicast users create state on 601 the router every time the user joins a group. Router resources can 602 be exhausted if the amount of state created exceeds the resources 603 available on the router. Placing limits on the resources used by the 604 Multicast protocols can prevent collateral damage to services other 605 than Multicast on a router. MSDP should have a limit placed on the 606 number of SA announcements received. A fixed limit should be placed 607 on the number of entries the router stores in the IP Multicast 608 routing table. The number of SAP entries should have a limit placed 609 on them. 611 8.3. IPv6 and Multicast 613 IPv6 Multicast policy should be consistent with the IP Multicast 614 policy. 616 9. Security Considerations 618 This entire document is concerned with security. 620 10. References 622 10.1. Normative References 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, March 1997. 627 10.2. Informative References 629 [RFC2334] "Guidelines for Writing an IANA Considerations Section in 630 RFCs", October 1998. 632 [RFC3667] "IETF Rights in Contributions", February 2004. 634 [RFC3668] "Intellectual Property Rights in IETF Technology", 635 February 2004. 637 Authors' Addresses 639 James Gill 640 Verizon Business 641 22001 Louden County Parkway 642 Ashburn, VA 20147 643 US 645 Phone: +1-703-886-3834 646 Email: james.gill@verizonbusiness.com 647 URI: www.verizonbusiness.com 649 Darrel Lewis 650 Cisco Systems Inc. 651 170 West Tasman Dr. 652 San Jose, CA 95134 653 US 655 Phone: +1-408-853-3653 656 Email: darlewis@cisco.com 657 URI: www.cisco.com 659 Paul Quinn 660 Cisco Systems Inc. 661 170 West Tasman Drive 662 San Jose, CA 95134 663 US 665 Phone: +1-408-527-3560 666 Email: paulq@cisco.com 667 URI: www.cisco.com 669 Peter Schoenmaker 670 NTT America 671 101 Park Ave., FL 41 672 New York, NY 10178 673 US 675 Phone: +1-202-808-2298 676 Fax: 677 Email: pds@ntt.net 678 URI: 680 Full Copyright Statement 682 Copyright (C) The Internet Society (2006). 684 This document is subject to the rights, licenses and restrictions 685 contained in BCP 78, and except as set forth therein, the authors 686 retain all their rights. 688 This document and the information contained herein are provided on an 689 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 690 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 691 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 692 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 693 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 694 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 696 Intellectual Property 698 The IETF takes no position regarding the validity or scope of any 699 Intellectual Property Rights or other rights that might be claimed to 700 pertain to the implementation or use of the technology described in 701 this document or the extent to which any license under such rights 702 might or might not be available; nor does it represent that it has 703 made any independent effort to identify any such rights. Information 704 on the procedures with respect to rights in RFC documents can be 705 found in BCP 78 and BCP 79. 707 Copies of IPR disclosures made to the IETF Secretariat and any 708 assurances of licenses to be made available, or the result of an 709 attempt made to obtain a general license or permission for the use of 710 such proprietary rights by implementers or users of this 711 specification can be obtained from the IETF on-line IPR repository at 712 http://www.ietf.org/ipr. 714 The IETF invites any interested party to bring to its attention any 715 copyrights, patents or patent applications, or other proprietary 716 rights that may cover technology that may be required to implement 717 this standard. Please address the information to the IETF at 718 ietf-ipr@ietf.org. 720 Acknowledgment 722 Funding for the RFC Editor function is provided by the IETF 723 Administrative Support Activity (IASA).