idnits 2.17.1 draft-ietf-opsec-framework-05.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, updated by RFC 4748 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 997. 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 abstract seems to contain references ([RFC3871]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 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 (March 20, 2007) is 6240 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-opsec-efforts-05 == Outdated reference: A later version (-09) exists of draft-ietf-opsec-filter-caps-05 == Outdated reference: A later version (-04) exists of draft-ietf-opsec-logging-caps-02 == Outdated reference: A later version (-03) exists of draft-ietf-opsec-routing-capabilities-01 -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC Working Group G. Jones 3 Internet-Draft 4 Intended status: Informational R. Callon 5 Expires: September 21, 2007 Juniper Networks 6 M. Kaeo 7 Double Shot Security 8 March 20, 2007 10 Framework for Operational Security Capabilities for IP Network 11 Infrastructure 12 draft-ietf-opsec-framework-05 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 September 21, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document outlines work done and documents produced by the 46 Operational Security Capabilities (OPSEC) Working Group. The goal of 47 the working group is to codify knowledge gained through operational 48 experience about feature sets that are needed to securely deploy and 49 operate managed network elements providing transit services at the 50 data link and IP layers. 52 The intent is to provide clear, concise documentation of capabilities 53 necessary for operating networks securely, to assist network 54 operators in communicating their requirements to vendors, and to 55 provide vendors with input that is useful for building more secure 56 devices. The working group produced a list of capabilities 57 appropriate for large Internet Service Provider (ISP) and Enterprise 58 Networks. This work is intended to refine [RFC3871]. 60 This document also provides guidance for the creation of profile 61 documents which are lists of security features needed in specific 62 operating environments. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.3.1. Threats Addressed, Threats Not Addressed . . . . . . . 5 71 1.3.2. Active, Passive and Combined Attacks . . . . . . . . . 6 72 1.3.3. Categories of Threats . . . . . . . . . . . . . . . . 6 73 1.3.4. Threat Sources . . . . . . . . . . . . . . . . . . . . 7 74 1.4. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1.4.1. Passive attacks . . . . . . . . . . . . . . . . . . . 7 76 1.4.2. Eavesdropping/Sniffing . . . . . . . . . . . . . . . . 7 77 1.4.3. Off-line Cryptographic Attacks . . . . . . . . . . . . 8 78 1.4.4. Active Attacks . . . . . . . . . . . . . . . . . . . . 8 79 1.4.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . 8 80 1.4.6. Message Insertion . . . . . . . . . . . . . . . . . . 8 81 1.4.7. Message Modification . . . . . . . . . . . . . . . . . 9 82 1.4.8. Message Deletion . . . . . . . . . . . . . . . . . . . 9 83 1.4.9. Man-In-The-Middle . . . . . . . . . . . . . . . . . . 9 84 1.4.10. Invalid Message . . . . . . . . . . . . . . . . . . . 9 85 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1.6. Intended Audience . . . . . . . . . . . . . . . . . . . . 10 87 1.7. Format and Definition of Capabilities . . . . . . . . . . 11 88 1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 89 1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 12 90 1.10. Definitions . . . . . . . . . . . . . . . . . . . . . . . 12 91 2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 2.1. Framework Document . . . . . . . . . . . . . . . . . . . . 17 93 2.2. Operator Practices Survey . . . . . . . . . . . . . . . . 17 94 2.3. Standards Survey . . . . . . . . . . . . . . . . . . . . . 17 95 2.4. Capabilities Documents . . . . . . . . . . . . . . . . . . 17 96 2.5. Profile Documents . . . . . . . . . . . . . . . . . . . . 18 97 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 100 6. Non-Normative References . . . . . . . . . . . . . . . . . . . 22 101 Appendix A. Sample Capability Description . . . . . . . . . . . . 24 102 A.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 24 103 A.1.1. Ability to Filter Traffic on All Interfaces TO the 104 Device . . . . . . . . . . . . . . . . . . . . . . . . 24 105 Appendix B. Guide to writing profiles . . . . . . . . . . . . . . 25 106 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 25 107 B.2. Guidance . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 B.3. Sample Profile . . . . . . . . . . . . . . . . . . . . . . 26 109 B.3.1. Required Capabilities for Edge Routers . . . . . . . . 26 110 B.3.2. Recommended Capabilities for Edge Routers . . . . . . 26 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 112 Intellectual Property and Copyright Statements . . . . . . . . . . 29 114 1. Introduction 116 1.1. Goals 118 The goal of the Operational Security Working Group is to codify 119 knowledge gained through operational experience about feature sets 120 that are needed to securely deploy and operate managed network 121 elements providing transit services at the data link and IP layers. 123 It is anticipated that the codification of this knowledge will be an 124 aid to vendors in producing more securable network elements, and an 125 aid to operators in increasing security by deploying and configuring 126 more secure network elements. 128 This framework document provides an overview of the work done by the 129 working group, and describes the documents produced in this effort. 131 1.2. Motivation 133 Network operators need the appropriate feature sets and tools on 134 their infrastructure devices to ensure that they can effectively 135 deploy and manage their networks securely while maintaining the 136 ability to provide reliable service to their customers. Vendors need 137 guidelines on which security features and functionality are critical 138 for operators to be able to reach that goal. 140 1.3. Threat Model 142 1.3.1. Threats Addressed, Threats Not Addressed 144 This section describes the general classes of threats that this work 145 intends to address. Specific threats and attacks are discussed in 146 the documents which are referred to in this framework. Each of those 147 documents enumerate the capabilities which are required to mitigate 148 the risk of these specific threats. 150 The intent is to address real-world threats to and attacks on network 151 infrastructure devices which have severely impacted network 152 operations or have immediate potential to do so. The intent is NOT 153 to build a complete theoretical threat model or list every possible 154 attack. 156 The threats are limited to those that affect the management of 157 network infrastructure and its ability to transit traffic. Threats 158 to the confidentiality and integrity of transit traffic are not 159 addressed. 161 1.3.2. Active, Passive and Combined Attacks 163 [RFC3552] describes a general Internet threat model which readers of 164 this document should be familiar with. It defines a threat model to 165 describes the capabilities that an attacker is assumed to be able to 166 deploy against a resource. [RFC3552] classifies attacks into two 167 main categories: passive attacks and active attacks. Passive attacks 168 are ones where an attacker simply reads information off the network 169 and obtains confidential and/or private information which can be used 170 to compromise network systems. Active attacks are ones where the 171 attacker writes data to the network and can include replay attacks, 172 message insertion, message deletion, message modification and man-in- 173 the-middle attacks. Often, these passive and active attacks are 174 combined. For example, routing information is diverted via a man-in- 175 the-middle attack to force confidential information to transit a 176 network path on which the attacker is able to perform eavesdropping. 178 1.3.3. Categories of Threats 180 The following sections provide a model that can be used to further 181 categorize attacks on infrastructure devices and/or the operating 182 behavior of these devices, and also gives some examples of attacks 183 which fall into each classification. 185 It is common to categorize threats based on the effects or damage 186 caused by associated attacks. For example, threats generally fall 187 under one of the three categories as defined in [RFC2196]: 189 o Unauthorized access to resources and/or information 191 o Unintended and/or unauthorized disclosure of information 193 o Denial of service 195 There are a number of attacks, any one of which, if exploited, can 196 lead to any of the above mentioned threats. As one example, if an 197 intruder has taken control of a router (for example by guessing the 198 password) then he could potentially obtain unauthorized access to 199 resources, could gain unauthorized disclosure of information, and 200 could also deny service to legitimate users. This method of 201 categorizing threats based on the result of the threat therefore 202 results in categories which are orthogonal to the cause of the 203 effect, and thus orthogonal to the device capabilities which are 204 needed. 206 Categorization of attacks based on the capabilities required to mount 207 the attack will allow the analysis and description of the attacks to 208 be more closely aligned with the product capabilities required to 209 defeat or mitigate the attack. 211 1.3.4. Threat Sources 213 The sources of threats in an operational network take many forms. 214 Some sources can be intentional, such as a malicious intruder 215 actively gaining access to an unauthorized resource or causing a 216 denial of service attack. Other sources can be unintentional but 217 still render the network unusable, such as software bugs or 218 configuration mistakes. Many of the unintentional threat sources can 219 be difficult to recognize or prevent. However wherever possible, 220 capabilities and functionality is defined which minimizes the extent 221 of the damage done under these circumstances. 223 Threats can originate from outside or inside and can be due to 224 vulnerabilities in a device or weaknesses in operational processes. 225 Inside threats pertain to an authorized participant in the operation 226 of the network performing unauthorized actions. Outside threats 227 pertain to any unauthorized network devices or person causing havoc 228 with normal network operations. 230 On Path network devices are able to read, modify, or remove any 231 datagram transmitted along a given path. Off-path hosts can transmit 232 arbitrary datagrams that appear to come from any hosts but cannot 233 necessarily receive datagrams intended for other hosts. 235 1.4. Attacks 237 This section specifies attack categories based on the capabilities 238 required to mount the attack and provides more granular detail of 239 many of the identifiable and recognized threats to which network 240 infrastructure devices are susceptible. 242 1.4.1. Passive attacks 244 Passive attacks are ones where an attacker simply reads information 245 off the network and obtains confidential and/or private information 246 which can be used to compromise network systems. 248 1.4.2. Eavesdropping/Sniffing 250 The most common form of passive attack is eavesdropping, where the 251 attacker is able to read the data which is being transmitted from the 252 sender to the receiver. In any operational network, the entire data 253 path and every device involved in the data path must be considered 254 for this type of attack. Any information which could be used to 255 potentially gain unauthorized access to a device or is private must 256 be protected. This includes passwords, configuration files and log 257 files. It is common to think only of protecting the data path and to 258 make sure that data is not diverted along a different path which may 259 be easier to eavesdrop on, such as a wireless network. In many 260 instances it would be wise to consider cryptographically protecting 261 data confidentiality wherever sensitive information is involved. 263 1.4.3. Off-line Cryptographic Attacks 265 These attacks typically capture some data which has been 266 cryptographically protected and then use varying means to try and 267 recover the original data. Poor password protection protocols can 268 easily be reverse engineered and poorly chosen passwords can also be 269 easily deciphered. As described in [RFC3552], a number of popular 270 password-based challenge response protocols are vulnerable to a 271 dictionary attack. The attacker captures a challenge-response pair 272 and then proceeds to try entries from a list of common words (such as 273 a dictionary file) until he finds a password that produces the right 274 response. 276 1.4.4. Active Attacks 278 Active attacks are ones where the attacker writes data to the 279 network. Generally, any part of a data packet can be forged. When 280 the source IP address is forged, the attack is generally referred to 281 as a spoofing attack. These attacks can be mitigated by filtering 282 traffic based on IP addresses to only allow legitimate traffic to/ 283 from a network. 285 Not all active attacks require forged addresses and most systems are 286 susceptible to a number of common attack patterns which are described 287 in the next sections. Note that any type of active attack can be 288 used for Denial of Service if the traffic is sent at such a rate that 289 it exceeds a networks link capacity or exhausts device resources. 291 1.4.5. Replay Attacks 293 A replay attack is a combination of a passive and an active attack. 294 In this type of attack, the attacker records some number of messages 295 off of the wire and then plays them back to the original recipient. 296 Note that the attacker does not need to be able to understand the 297 messages. He merely needs to capture and re-transmit them. 299 1.4.6. Message Insertion 301 In a message insertion attack, the attacker forges one or more 302 messages and injects them into the network. Often these messages 303 will have a forged source address in order to disguise the identity 304 of the attacker. 306 Message insertion attacks can be used to exploit known 307 vulnerabilities in protocol software. Routers and switches implement 308 protocols which in some cases make use of software which is well 309 known and widely deployed. Malicious attackers therefore may be 310 familiar with the protocol software and be able to exploit known 311 vulnerabilities. 313 1.4.7. Message Modification 315 In a message modification attack, the attacker removes a message from 316 the wire, modifies it, and then resends it. The contents of the 317 message may be modified and/or the intended recipient. For example, 318 a hacker might try to modify a DNS response, in order to redirect a 319 client to the wrong server. 321 1.4.8. Message Deletion 323 In a message deletion attack, the attacker simply removes a message 324 from the wire. 326 1.4.9. Man-In-The-Middle 328 A Man-In-The-Middle attack combines the above techniques in a special 329 form: The attacker subverts the communication stream in order to pose 330 as the sender to receiver and the receiver to the sender. This 331 differs fundamentally from the above forms of attack because it 332 attacks the identity of the communicating parties, rather than the 333 data stream itself. Consequently, many techniques which provide 334 integrity of the communications stream are insufficient to protect 335 against man-in-the-middle attacks. 337 Man-in-the-middle attacks are possible whenever peer entity 338 authentication is not used. For example, it is trivial to mount man- 339 in-the-middle attacks on local networks via ARP spoofing where the 340 attacker forges an ARP with the victim's IP address and his own MAC 341 address to gain access to a network. The attacker can then do 342 further damage by sending forged messages. Imagine if the victims IP 343 address was that of a TFTP server. The attacker could potentially 344 download invalid system images or configuration files to a network 345 device and subsequently compromise that network device. 347 1.4.10. Invalid Message 349 An invalid message attack refers to situations which can be either 350 deliberately invoked or are due to some non-malicious software or 351 configuration error. This attack can be realized if vendors do not 352 conform to standards and send inappropriate control packets which can 353 cause routing loops or neighboring routers to go down. Also, a 354 malicious individual may launch DoS attacks which flood a device's 355 control plane with enough messages that the device becomes inoperable 356 due to resource starvation. 358 1.5. Scope 360 The working group produced a lists of capabilities appropriate for: 362 o Internet Service Provider (ISP) Networks 364 o Enterprise Networks 366 The following are explicitly out of scope: 368 o general purpose hosts that do not transit traffic including 369 infrastructure hosts such as name/time/log/AAA servers, etc., 371 o unmanaged devices, 373 o customer managed devices (e.g. firewalls, Intrusion Detection 374 System, dedicated VPN devices, etc.), 376 o SOHO (Small Office, Home Office) devices (e.g. personal firewalls, 377 Wireless Access Points, Cable Modems, etc.), 379 o confidentiality of customer data, 381 o integrity of customer data, 383 o physical security. 385 These limitations have been made to keep the amount of work and size 386 of documents manageable. While the capabilities listed here may 387 apply to systems outside the scope, no capabilities have been added 388 to account for their unique needs. 390 While the examples given are written with IPv4 in mind, most of the 391 capabilities are general enough to apply to IPv6. 393 1.6. Intended Audience 395 There are two intended audiences: the network operator who selects, 396 purchases, and operates IP network equipment, and the vendors who 397 create these devices. 399 1.7. Format and Definition of Capabilities 401 Separate documents were created for specific categories of 402 capabilities. Each individual capability has the following elements: 404 Capability (what) 406 The capability describes a policy to be supported by the device. 407 Capabilities are described in terms of "The device is able to...". 408 Capability descriptions do not use [RFC2119] keywords, e.g. they 409 are not phrased as "The device MUST...". 411 Capabilities should not refer to specific technologies. It is 412 expected that desired capability will change little over time. 414 Supported Practices (why) 416 The Supported Practice section cites practices described in 417 [RFC4778] that are supported by this capability. The need to 418 support the cited practices provides the justification for the 419 feature. 421 In a few cases, practices not listed in [RFC4778] may be listed at 422 the end of the capability document and cited as justification for 423 a capability. This may be necessary if a practice becomes common 424 after [RFC4778] is finished or if there is widespread consensus 425 that the practice would improve security but it is not, for 426 whatever reason, in widespread deployment. 428 Current Implementations (how) 430 The Current Implementation section is intended to give examples of 431 implementations of the capability, citing technology and standards 432 current at the time of writing. Examples of configuration and 433 usage may also be given. 435 Considerations 437 The Considerations section lists operational and resource 438 constraints, limitations of current implementations, tradeoffs, 439 etc. 441 1.8. Applicability 443 These capabilities are intended to give guidance on how best to 444 protect communications infrastructure. Service Providers, Network 445 Operators, and Equipment Suppliers are encouraged to study these 446 capabilities, and prioritize the extent and manner in which they may 447 implement and/or deploy equipment supporting these capabilities. 449 Decisions of whether or not to support a specific capabilities are 450 intended to be left with the responsible organization (e.g., Service 451 Provider, Network Operator, or Equipment Supplier). Due to the 452 continuously evolving nature of security threats to networks, and due 453 to significant variations in the specific security threats and 454 requirements in different network environments, it is not appropriate 455 to mandate implementation of these capabilities through legislation 456 or regulation, nor would any mandate be consistent with their intent. 458 1.9. Intended Use 460 It is anticipated that the capabilities in these documents will be 461 used for the following purposes: 463 o as a checklist when evaluating networked products, 465 o to create profiles of different subsets of the capabilities which 466 describe the needs of different devices, organizations, and 467 operating environments, 469 o to assist operators in clearly communicating their security 470 requirements, 472 o as high level guidance for the creation of detailed test plans. 474 o as guidance for vendors to make appropriate decisions for 475 engineering feature roadmaps. 477 1.10. Definitions 479 NOTE: The following definitions are take from RFC3871. Unless 480 otherwise stated, the working group documents use these terms as 481 defined below. 483 Bogon. 485 A "Bogon" (plural: "bogons") is a packet with an IP source address 486 in an address block not yet allocated by IANA or the Regional 487 Internet Registries (ARIN, RIPE, APNIC...) as well as all 488 addresses reserved for private or special use by RFCs. See 489 [RFC3330] and [RFC1918]. 491 CLI. 493 Several capabilities refer to a Command Line Interface (CLI). 494 While this refers at present to a classic text oriented command 495 interface, it is not intended to preclude other mechanisms which 496 may provide all the capabilities that reference "CLI". 498 Conformance. 500 Adherence to proposed standards. 502 Console. 504 Several capabilities refer to a "Console". The model for this is 505 the classic RS232 serial port which has, for the past 30 or more 506 years, provided a simple, stable, reliable, well-understood and 507 nearly ubiquitous management interface to network devices. Again, 508 these capabilities are intended primarily to codify the benefits 509 provided by that venerable interface, not to preclude other 510 mechanisms that provide the same capabilities. 512 Filter. 514 In this document, a "filter" is defined as a group of one or more 515 rules where each rule specifies one or more match criteria. 517 In-Band management. 519 "In-Band management" is defined as any management done over the 520 same channels and interfaces used for user/customer data. 521 Examples would include using SSH for management via customer or 522 Internet facing network interfaces. 524 High Resolution Time. 526 "High resolution time" is defined in this document as "time having 527 a resolution greater than one second" (e.g. milliseconds). 529 IP. 531 Unless otherwise indicated, "IP" refers to IPv4. 533 Management. 535 This document uses a broad definition of the term "management". 536 In this document, "management" refers to any authorized 537 interaction with the device intended to change its operational 538 state or configuration. Data/Forwarding plane functions (e.g. the 539 transit of customer traffic) are not considered management. 540 Control plane functions such as routing, signaling and link 541 management protocols and management plane functions such as remote 542 access, configuration and authentication are considered to be 543 management. 545 Martian. 547 Per [RFC1208] "Martian: Humorous term applied to packets that turn 548 up unexpectedly on the wrong network because of bogus routing 549 entries. Also used as a name for a packet which has an altogether 550 bogus (non-registered or ill-formed) Internet address." For the 551 purposes of this document Martians are defined as "packets having 552 a source address that, by application of the current forwarding 553 tables, would not have its return traffic routed back to the 554 sender." "Spoofed packets" are a common source of martians. 556 Note that in some cases, the traffic may be asymmetric, and a 557 simple forwarding table check might produce false positives. See 558 [RFC3704] 560 Out-of-Band (OoB) management. 562 "Out-of-Band management" is defined as any management done over 563 channels and interfaces that are separate from those used for 564 user/customer data. Examples would include a serial console 565 interface or a network interface connected to a dedicated 566 management network that is not used to carry customer traffic. 568 Open Review. 570 "Open review" refers to processes designed to generate public 571 discussion and review of technical solutions such as data 572 communications protocols and cryptographic algorithms with the 573 goals of improving and building confidence in the final solutions. 575 For the purposes of this document "open review" is defined by 576 [RFC2026]. All standards track documents are considered to have 577 been through an open review process. 579 It should be noted that organizations may have local requirements 580 that define what they view as acceptable "open review". For 581 example, they may be required to adhere to certain national or 582 international standards. Such modifications of the definition of 583 the term "open review", while important, are considered local 584 issues that should be discussed between the organization and the 585 vendor. 587 It should also be noted that section 7 of [RFC2026] permits 588 standards track documents to incorporate other "external standards 589 and specifications". 591 PBR. 593 Policy Based Routing. 595 Resource Starvation. 597 A condition where resources necessary for communication and proper 598 functioning of a network element are unavailable. Such resources 599 might include Bandwidth of a link, memory of a routing device, or 600 CPU time on a routing processor. 602 Secure Channel. 604 A "secure channel" is a mechanism that ensures end-to-end 605 integrity and confidentiality of communications. Examples include 606 TLS [RFC4346] and IPsec [RFC4301]. Connecting a terminal to a 607 console port using physically secure, shielded cable would provide 608 confidentiality but possibly not integrity. 610 Service. 612 A number of capabilities refer to "services". For the purposes of 613 this document a "service" is defined as "any process or protocol 614 running in the control or management planes to which non-transit 615 packets may be delivered". Examples might include an SSH server, 616 a BGP process or an NTP server. It would also include the 617 transport, network and link layer protocols since, for example, a 618 TCP packet addressed to a port on which no service is listening 619 will be "delivered" to the IP stack, and possibly result in an 620 ICMP message being sent back. 622 Session. 624 An instance of protocol establishment, e.g. telnet, BGP, OSPF, 625 etc. 627 Single-Homed Network. 629 A "single-homed network" is defined as one for which 631 * There is only one upstream connection 633 * Routing is symmetric. 635 See [RFC3704] for a discussion of related issues and mechanisms 636 for multi-homed networks. 638 Spoofed Packet. 640 A "spoofed packet" is defined as a packet that has a source 641 address that does not correspond to any address assigned to the 642 system which sent the packet. Spoofed packets are often "bogons" 643 or "martians". 645 Secure Network 647 For the purposes of these documents, a secure network is one in 648 which: 650 * The network keeps passing legitimate customer traffic 651 (availability). 653 * Traffic goes where it is supposed to go, and only where it is 654 supposed to go (availability, confidentiality). 656 * The network elements remain manageable (availability). 658 * Only authorized users can manage network elements 659 (authorization). 661 * There is a record of all security related events 662 (accountability). 664 * The network operator has the necessary tools to detect and 665 respond to illegitimate traffic. 667 2. Documents 669 The following describes the documents produced by the OPSEC working 670 group. Each document covers an area important to secure operation of 671 large network infrastructure. 673 2.1. Framework Document 675 This document. 677 2.2. Operator Practices Survey 679 [RFC4778]. 681 This document provides a survey of current operator practices in the 682 area of securing networks. It lists current practices that are cited 683 as justification for capabilities. It defines a general threat model 684 and classes of attacks. 686 2.3. Standards Survey 688 [I-D.ietf-opsec-efforts]. 690 This document provides an overview of other efforts in developing 691 standards, guidelines, best practices, or other information intended 692 to facilitate improvement in network security. Any effort which is 693 known, such as the ANSI T1.276, the NRIC V "Best Practices", ITU-T 694 M.3016 and X.805, the T1S1 effort on securing signaling will be 695 included. The intent is to provide a clear understanding of which 696 efforts are complementary and/or contradictory such that any efforts 697 of future cross-certification of standards may be facilitated. 699 2.4. Capabilities Documents 701 [I-D.ietf-opsec-filter-caps], 702 [I-D.ietf-opsec-logging-caps], 703 [I-D.ietf-opsec-routing-capabilities]. 705 Capability documents list capabilities needed to support security 706 practices. Each capability document lists capabilities of one 707 logical group of functions (e.g. logging, filtering, etc.). They 708 define a threat model, list individual capabilities, cite practices 709 supported in the Operator Practices Survey and in few cases may 710 define additional practices. 712 2.5. Profile Documents 714 Profile documents are intended to list capabilities appropriate to 715 different operating environments such as large Network Service 716 Provider (NSP) core or edge devices or enterprise networks. 718 Appendix B provides guidance to organizations in creating their own 719 profiles. 721 3. Security Considerations 723 Security is the entire focus of this document. 725 4. IANA Considerations 727 This document has no actions for IANA. 729 5. Acknowledgments 731 The authors gratefully acknowledge the contributions of: 733 o Pat Cain who agitated for inclusion of the profile guide. 735 6. Non-Normative References 737 [I-D.ietf-opsec-efforts] 738 Lonvick, C. and D. Spak, "Security Best Practices Efforts 739 and Documents", draft-ietf-opsec-efforts-05 (work in 740 progress), December 2006. 742 [I-D.ietf-opsec-filter-caps] 743 Morrow, C., "Filtering and Rate Limiting Capabilities for 744 IP Network Infrastructure", 745 draft-ietf-opsec-filter-caps-05 (work in progress), 746 March 2007. 748 [I-D.ietf-opsec-logging-caps] 749 Cain, P. and G. Jones, "Logging Capabilities for IP 750 Network Infrastructure", draft-ietf-opsec-logging-caps-02 751 (work in progress), March 2007. 753 [I-D.ietf-opsec-routing-capabilities] 754 Zhao, Y., "Routing Control Plane Security Capabilities", 755 draft-ietf-opsec-routing-capabilities-01 (work in 756 progress), February 2007. 758 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 759 RFC 1208, March 1991. 761 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 762 E. Lear, "Address Allocation for Private Internets", 763 BCP 5, RFC 1918, February 1996. 765 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 766 3", BCP 9, RFC 2026, October 1996. 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, 772 September 1997. 774 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 775 September 2002. 777 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 778 Text on Security Considerations", BCP 72, RFC 3552, 779 July 2003. 781 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 782 Networks", BCP 84, RFC 3704, March 2004. 784 [RFC3871] Jones, G., "Operational Security Requirements for Large 785 Internet Service Provider (ISP) IP Network 786 Infrastructure", RFC 3871, September 2004. 788 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 789 Internet Protocol", RFC 4301, December 2005. 791 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 792 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 794 [RFC4778] Kaeo, M., "Operational Security Current Practices in 795 Internet Service Provider Environments", RFC 4778, 796 January 2007. 798 Appendix A. Sample Capability Description 800 This appendix provides a sample capability description. Note the 801 lack of the use of "MUST", etc in the description of the capability. 802 Also note that in the supported practices section it refers both to 803 the current practices document [RFC4778] and to sections of the same 804 document (xxx.1, xxx.2) that describe practices that were not covered 805 in the current practices document. 807 A.1. Filtering TO the Device 809 A.1.1. Ability to Filter Traffic on All Interfaces TO the Device 811 Capability. 813 The device provides a means to filter IP packets on any interface 814 implementing IP that are non-transit packets. 816 Supported Practices. 818 * Profile Current Traffic (Section xxx.1) 820 * Block Malicious Packets (Section xxx.2 ) 822 * Limit Sources of Management ([RFC4778], Section 2.8.2) 824 Current Implementations. 826 Many devices currently implement access control lists or filters 827 that allow filtering based on protocol and/or source/destination 828 address and or source/destination port and allow these filters to 829 be applied to interfaces. 831 Considerations. 833 None. 835 Appendix B. Guide to writing profiles 837 B.1. Introduction 839 This section provides guidelines for creating security capability 840 profiles. A profile is a list of features that are required to 841 operate a device in a a secure manner in a specific environment. 843 The determination of which capabilities are requirements is a local 844 decision driven by policy and operational need. In addition, the 845 needed capabilities are likely to change over time as operational 846 requirements and security threats change. Profile writes are 847 encouraged to share their output with the broader Internet community 848 to learn from others experiences. 850 It is likely that there are or will be other sources of capabilities 851 that could be cited in developing a profile. For example, 852 [I-D.ietf-opsec-efforts] could be used to identify industry-specific 853 standards or regulations that a specific network would need to 854 support. 856 B.2. Guidance 858 Profiles should: 860 o Be uniquely named 862 o Contain a brief description of the profile 864 o Describe the context/environment to which they apply 866 o Reference capabilities defined in appropriate documents. It is 867 assumed that referenced capabilities contain the elements outlined 868 in Section 1.7 and Appendix A, i.e. that there is no need for a 869 detailed description of the capability, justification, etc. in the 870 profile. If referencing documents that do not contain such 871 information, it might have to be included in the profile. 873 o Be broken down into functional sections (logging, filtering...) 875 o Indicate level of need for each capability ("required", 876 "recommended"...) in the defined context (NOT in the [RFC2119] 877 sense). 879 B.3. Sample Profile 881 The following is an incomplete sample of a profile for edge routers: 883 B.3.1. Required Capabilities for Edge Routers 885 Name: Edge Router Profile 887 Description: This profile defines the capabilities necessary for a 888 network edge device 890 Context: Large NSP/ISP network providing transit services. 892 The following are requirements for edge routers: 894 B.3.1.1. Packet Filtering Profile 896 o Select by Protocol, [I-D.ietf-opsec-filter-caps] Section 3.5 898 o Select by Addresses, [I-D.ietf-opsec-filter-caps] Section 3.6 900 o Select by Protocol Header Fields, [I-D.ietf-opsec-filter-caps] 901 Section 3.7 902 . 903 . 904 . 906 B.3.1.2. Logging 908 o Logs Sent To Remote Servers, [I-D.ietf-opsec-logging-caps] Section 909 2.2 911 o Ability to Select Reliable Delivery, [I-D.ietf-opsec-logging-caps] 912 Section 2.3 914 o Ability to Remotely Log Securely, [I-D.ietf-opsec-logging-caps] 915 Section 2.4 917 o Ability to Log Locally, [I-D.ietf-opsec-logging-caps] Section 2.5 918 . 919 . 920 . 922 B.3.2. Recommended Capabilities for Edge Routers 924 The following are desired capabilities for edge routers: 926 B.3.2.1. Packet Filtering Profile 928 o Minimal Performance Degradation, [I-D.ietf-opsec-filter-caps] 929 Section 6 930 . 931 . 932 . 934 Authors' Addresses 936 George M. Jones 938 Phone: +1 703 488 9740 939 Email: gmj3871@pobox.com 941 Ross Callon 942 Juniper Networks 943 10 Technology Park Drive 944 Westford, MA 01886 945 U.S.A. 947 Phone: +1 978 692 6724 948 Email: rcallon@juniper.net 950 Merike Kaeo 951 Double Shot Security 952 3518 Fremont Avenue North #363 953 Seattle, WA 98103 954 U.S.A. 956 Phone: +1 310 866 0165 957 Email: merike@doubleshotsecurity.com 959 Full Copyright Statement 961 Copyright (C) The IETF Trust (2007). 963 This document is subject to the rights, licenses and restrictions 964 contained in BCP 78, and except as set forth therein, the authors 965 retain all their rights. 967 This document and the information contained herein are provided on an 968 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 969 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 970 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 971 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 972 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 973 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 975 Intellectual Property 977 The IETF takes no position regarding the validity or scope of any 978 Intellectual Property Rights or other rights that might be claimed to 979 pertain to the implementation or use of the technology described in 980 this document or the extent to which any license under such rights 981 might or might not be available; nor does it represent that it has 982 made any independent effort to identify any such rights. Information 983 on the procedures with respect to rights in RFC documents can be 984 found in BCP 78 and BCP 79. 986 Copies of IPR disclosures made to the IETF Secretariat and any 987 assurances of licenses to be made available, or the result of an 988 attempt made to obtain a general license or permission for the use of 989 such proprietary rights by implementers or users of this 990 specification can be obtained from the IETF on-line IPR repository at 991 http://www.ietf.org/ipr. 993 The IETF invites any interested party to bring to its attention any 994 copyrights, patents or patent applications, or other proprietary 995 rights that may cover technology that may be required to implement 996 this standard. Please address the information to the IETF at 997 ietf-ipr@ietf.org. 999 Acknowledgment 1001 Funding for the RFC Editor function is provided by the IETF 1002 Administrative Support Activity (IASA).