idnits 2.17.1 draft-ietf-opsec-framework-03.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 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 867. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 RFC 3978 Section 5.4 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 1, 2006) is 6629 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) == Outdated reference: A later version (-07) exists of draft-ietf-opsec-current-practices-04 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC Working Group G. Jones 3 Internet-Draft The MITRE Corporation 4 Expires: September 2, 2006 R. Callon 5 Juniper Networks 6 M. Kaeo 7 Double Shot Security 8 March 1, 2006 10 Framework for Operational Security Capabilities for IP Network 11 Infrastructure 12 draft-ietf-opsec-framework-03 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 2, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document outlines work to be done and documents to be produced 46 by the Operational Security Capabilities (OPSEC) Working Group. The 47 goal of the working group is to codify knowledge gained through 48 operational experience about feature sets that are needed to securely 49 deploy and operate managed network elements providing transit 50 services at the data link and IP layers. The intent is to provide 51 clear, concise documentation of capabilities necessary for operating 52 networks securely, to assist network operators in communicating their 53 requirements to vendors, and to provide vendors with input that is 54 useful for building more secure devices. The working group will 55 produce a list of capabilities appropriate for large Internet Service 56 Provider (ISP) and Enterprise Networks. This work is intended to 57 refine [RFC3871]. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3.1. Threats Addressed, Threats Not Addressed . . . . . . . 4 66 1.3.2. Active, Passive and Combined Attacks . . . . . . . . . 5 67 1.3.3. Categories of Threats . . . . . . . . . . . . . . . . 5 68 1.3.4. Threat Sources . . . . . . . . . . . . . . . . . . . . 6 69 1.4. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.4.1. Passive attacks . . . . . . . . . . . . . . . . . . . 6 71 1.4.2. Eavesdropping/Sniffing . . . . . . . . . . . . . . . . 6 72 1.4.3. Off-line Cryptographic Attacks . . . . . . . . . . . . 7 73 1.4.4. Active Attacks . . . . . . . . . . . . . . . . . . . . 7 74 1.4.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . 7 75 1.4.6. Message Insertion . . . . . . . . . . . . . . . . . . 7 76 1.4.7. Message Modification . . . . . . . . . . . . . . . . . 8 77 1.4.8. Message Deletion . . . . . . . . . . . . . . . . . . . 8 78 1.4.9. Man-In-The-Middle . . . . . . . . . . . . . . . . . . 8 79 1.4.10. Invalid Message . . . . . . . . . . . . . . . . . . . 8 80 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 1.6. Intended Audience . . . . . . . . . . . . . . . . . . . . 10 82 1.7. Format and Definition of Capabilities . . . . . . . . . . 10 83 1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 84 1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 11 85 1.10. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 86 2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 2.1. Framework Document . . . . . . . . . . . . . . . . . . . . 17 88 2.2. Operator Practices Survey . . . . . . . . . . . . . . . . 17 89 2.3. Standards Survey . . . . . . . . . . . . . . . . . . . . . 17 90 2.4. Capabilities Documents . . . . . . . . . . . . . . . . . . 17 91 2.5. Profile Documents . . . . . . . . . . . . . . . . . . . . 18 92 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 4. Non-Normative References . . . . . . . . . . . . . . . . . . . 19 94 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 95 Appendix B. Sample Capability Description . . . . . . . . . . . . 21 96 B.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 21 97 B.1.1. Ability to Filter Traffic on All Interfaces TO the 98 Device . . . . . . . . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 100 Intellectual Property and Copyright Statements . . . . . . . . . . 23 102 1. Introduction 104 1.1. Goals 106 The goal of the Operational Security Working Group is to codify 107 knowledge gained through operational experience about feature sets 108 that are needed to securely deploy and operate managed network 109 elements providing transit services at the data link and IP layers. 111 It is anticipated that the codification of this knowledge will be an 112 aid to vendors in producing more securable network elements, and an 113 aid to operators in increasing security by deploying and configuring 114 more secure network elements. 116 This framework document provides an overview of the work to be done 117 by the working group, and describes the documents to be produced in 118 this effort. 120 1.2. Motivation 122 Network operators need the appropriate feature sets and tools on 123 their infrastructure devices to ensure that they can effectively 124 deploy and manage their networks securely while maintaining the 125 ability to provide reliable service to their customers. Vendors need 126 guidelines on which security features and functionality are critical 127 for operators to be able to reach that goal. 129 1.3. Threat Model 131 1.3.1. Threats Addressed, Threats Not Addressed 133 This section describes the general classes of threats that this work 134 intends to address. Specific threats and attacks will be discussed 135 in the documents which are referred to in this framework. Each of 136 those documents will enumerate the capabilities which are required to 137 mitigate the risk of these specific threats. 139 The intent is to address real-world threats to and attacks on network 140 infrastructure devices which have severely impacted network 141 operations or have immediate potential to do so. The intent is NOT 142 to build a complete theoretical threat model or list every possible 143 attack. 145 The threats will be limited to those that affect the management of 146 network infrastructure and its ability to transit traffic. Threats 147 to the confidentiality and integrity of transit traffic will not be 148 addressed. 150 1.3.2. Active, Passive and Combined Attacks 152 [RFC3552] describes a general Internet threat model which readers of 153 this document should be familiar with. It defines a threat model to 154 describes the capabilities that an attacker is assumed to be able to 155 deploy against a resource. [RFC3552] classifies attacks into two 156 main categories: passive attacks and active attacks. Passive attacks 157 are ones where an attacker simply reads information off the network 158 and obtains confidential and/or private information which can be used 159 to compromise network systems. Active attacks are ones where the 160 attacker writes data to the network and can include replay attacks, 161 message insertion, message deletion, message modification and man-in- 162 the-middle attacks. Often, these passive and active attacks are 163 combined. For example, routing information is diverted via a man-in- 164 the-middle attack to force confidential information to transit a 165 network path on which the attacker is able to perform eavesdropping. 167 1.3.3. Categories of Threats 169 The following sections provide a model that can be used to further 170 categorize attacks on infrastructure devices and/or the operating 171 behavior of these devices, and also gives some examples of attacks 172 which fall into each classification. 174 It is common to categorize threats based on the effects or damage 175 caused by associated attacks. For example, threats generally fall 176 under one of the three categories as defined in [RFC2196]: 178 o Unauthorized access to resources and/or information 180 o Unintended and/or unauthorized disclosure of information 182 o Denial of service 184 There are a number of attacks, any one of which, if exploited, can 185 lead to any of the above mentioned threats. As one example, if an 186 intruder has taken control of a router (for example by guessing the 187 password) then he could potentially obtain unauthorized access to 188 resources, could gain unauthorized disclosure of information, and 189 could also deny service to legitimate users. This method of 190 categorizing threats based on the result of the threat therefore 191 results in categories which are orthogonal to the cause of the 192 effect, and thus orthogonal to the device capabilities which are 193 needed. 195 Categorization of attacks based on the capabilities required to mount 196 the attack will allow the analysis and description of the attacks to 197 be more closely aligned with the product capabilities required to 198 defeat or mitigate the attack. 200 1.3.4. Threat Sources 202 The sources of threats in an operational network take many forms. 203 Some sources can be intentional, such as a malicious intruder 204 actively gaining access to an unauthorized resource or causing a 205 denial of service attack. Other sources can be unintentional but 206 still render the network unusable, such as software bugs or 207 configuration mistakes. Many of the unintentional threat sources can 208 be difficult to recognize or prevent. However wherever possible, 209 capabilities and functionality will be defined which minimize the 210 extent of the damage done under these circumstances. 212 Threats can originate from outside or inside and can be due to 213 vulnerabilities in a device or weaknesses in operational processes. 214 Inside threats pertain to an authorized participant in the operation 215 of the network performing unauthorized actions. Outside threats 216 pertain to any unauthorized network devices or person causing havoc 217 with normal network operations. 219 On Path network devices are able to read, modify, or remove any 220 datagram transmitted along a given path. Off-path hosts can transmit 221 arbitrary datagrams that appear to come from any hosts but cannot 222 necessarily receive datagrams intended for other hosts. 224 1.4. Attacks 226 This section specifies attack categories based on the capabilities 227 required to mount the attack and provides more granular detail of 228 many of the identifiable and recognized threats to which network 229 infrastructure devices are susceptible. 231 1.4.1. Passive attacks 233 Passive attacks are ones where an attacker simply reads information 234 off the network and obtains confidential and/or private information 235 which can be used to compromise network systems. 237 1.4.2. Eavesdropping/Sniffing 239 The most common form of passive attack is eavesdropping, where the 240 attacker is able to read the data which is being transmitted from the 241 sender to the receiver. In any operational network, the entire data 242 path and every device involved in the data path must be considered 243 for this type of attack. Any information which could be used to 244 potentially gain unauthorized access to a device or is private must 245 be protected. This includes passwords, configuration files and log 246 files. It is common to think only of protecting the data path and to 247 make sure that data is not diverted along a different path which may 248 be easier to eavesdrop on, such as a wireless network. In many 249 instances it would be wise to consider cryptographically protecting 250 data confidentiality wherever sensitive information is involved. 252 1.4.3. Off-line Cryptographic Attacks 254 These attacks typically capture some data which has been 255 cryptographically protected and then use varying means to try and 256 recover the original data. Poor password protection protocols can 257 easily be reverse engineered and poorly chosen passwords can also be 258 easily deciphered. As described in [RFC3552], a number of popular 259 password-based challenge response protocols are vulnerable to a 260 dictionary attack. The attacker captures a challenge-response pair 261 and then proceeds to try entries from a list of common words (such as 262 a dictionary file) until he finds a password that produces the right 263 response. 265 1.4.4. Active Attacks 267 Active attacks are ones where the attacker writes data to the 268 network. Generally, any part of a data packet can be forged. When 269 the source IP address is forged, the attack is generally referred to 270 as a spoofing attack. These attacks can be mitigated by filtering 271 traffic based on IP addresses to only allow legitimate traffic to/ 272 from a network. 274 Not all active attacks require forged addresses and most systems are 275 susceptible to a number of common attack patterns which are described 276 in the next sections. Note that any type of active attack can be 277 used for Denial of Service if the traffic is sent at such a rate that 278 it exceeds a networks link capacity or exhausts device resources. 280 1.4.5. Replay Attacks 282 A replay attack is a combination of a passive and an active attack. 283 In this type of attack, the attacker records some number of messages 284 off of the wire and then plays them back to the original recipient. 285 Note that the attacker does not need to be able to understand the 286 messages. He merely needs to capture and re-transmit them. 288 1.4.6. Message Insertion 290 In a message insertion attack, the attacker forges one or more 291 messages and injects them into the network. Often these messages 292 will have a forged source address in order to disguise the identity 293 of the attacker. 295 Message insertion attacks can be used to exploit known 296 vulnerabilities in protocol software. Routers and switches implement 297 protocols which in some cases make use of software which is well 298 known and widely deployed. Malicious attackers therefore may be 299 familiar with the protocol software and be able to exploit known 300 vulnerabilities. 302 1.4.7. Message Modification 304 In a message modification attack, the attacker removes a message from 305 the wire, modifies it, and then resends it. The contents of the 306 message may be modified and/or the intended recipient. For example, 307 a hacker might try to modify a DNS response, in order to redirect a 308 client to the wrong server. [need example specific to network 309 operations where this would be harmful] 311 1.4.8. Message Deletion 313 In a message deletion attack, the attacker simply removes a message 314 from the wire. [need example specific to network operations where 315 this is harmful] 317 1.4.9. Man-In-The-Middle 319 A Man-In-The-Middle attack combines the above techniques in a special 320 form: The attacker subverts the communication stream in order to pose 321 as the sender to receiver and the receiver to the sender. This 322 differs fundamentally from the above forms of attack because it 323 attacks the identity of the communicating parties, rather than the 324 data stream itself. Consequently, many techniques which provide 325 integrity of the communications stream are insufficient to protect 326 against man-in-the-middle attacks. 328 Man-in-the-middle attacks are possible whenever peer entity 329 authentication is not used. For example, it is trivial to mount man- 330 in-the-middle attacks on local networks via ARP spoofing where the 331 attacker forges an ARP with the victim's IP address and his own MAC 332 address to gain access to a network. The attacker can then do 333 further damage by sending forged messages. Imagine if the victims IP 334 address was that of a TFTP server. The attacker could potentially 335 download invalid system images or configuration files to a network 336 device and subsequently compromise that network device. 338 1.4.10. Invalid Message 340 An invalid message attack refers to situations which can be either 341 deliberately invoked or are due to some non-malicious software or 342 configuration error. This attack can be realized if vendors do not 343 conform to standards and send inappropriate control packets which can 344 cause routing loops or neighboring routers to go down. Also, a 345 malicious individual may launch DoS attacks which flood a device's 346 control plane with enough messages that the device becomes inoperable 347 due to resource starvation. 349 [Ed. - Need to review existing capabilities. Do the threats and 350 attack types listed above cover them all ? Are there capabilities 351 that imply threats and attack classes not listed above] 353 1.5. Scope 355 The working group will produce a list of capabilities appropriate 356 for: 358 o Internet Service Provider (ISP) Networks 360 o Enterprise Networks 362 The following are explicitly out of scope: 364 o general purpose hosts that do not transit traffic including 365 infrastructure hosts such as name/time/log/AAA servers, etc., 367 o unmanaged devices, 369 o customer managed devices (e.g. firewalls, Intrusion Detection 370 System, dedicated VPN devices, etc.), 372 o SOHO (Small Office, Home Office) devices (e.g. personal firewalls, 373 Wireless Access Points, Cable Modems, etc.), 375 o confidentiality of customer data, 377 o integrity of customer data, 379 o physical security. 381 These limitations have been made to keep the amount of work and size 382 of documents manageable. While the capabilities listed here may 383 apply to systems outside the scope, no capabilities have been added 384 to account for their unique needs. 386 While the examples given are written with IPv4 in mind, most of the 387 capabilities are general enough to apply to IPv6. 389 1.6. Intended Audience 391 There are two intended audiences: the network operator who selects, 392 purchases, and operates IP network equipment, and the vendors who 393 create these devices. 395 1.7. Format and Definition of Capabilities 397 A separate document will be created for specific categories of 398 capabilities. Each individual capability will have the following 399 elements: 401 Capability (what) 403 The capability describes a policy to be supported by the device. 404 Capabilities are described in terms of "The device is able to...". 405 Capability descriptions do not use [RFC2119] keywords, e.g. they 406 are not phrased as "The device MUST...". 408 Capabilities should not refer to specific technologies. It is 409 expected that desired capability will change little over time. 411 Supported Practices (why) 413 The Supported Practice section cites practices described in 414 [I-D.ietf-opsec-current-practices] that are supported by this 415 capability. The need to support the cited practices provides the 416 justification for the feature. 418 In a few cases, practices not listed in [I-D.ietf-opsec-current- 419 practices] may be listed at the end of the capability document and 420 cited as justification for a capability. This may be necessary if 421 a practice becomes common after [I-D.ietf-opsec-current-practices] 422 is finished or if there is widespread consensus that the practice 423 would improve security but it is not, for whatever reason, in 424 widespread deployment. 426 Current Implementations (how) 428 The Current Implementation section is intended to give examples of 429 implementations of the capability, citing technology and standards 430 current at the time of writing. Examples of configuration and 431 usage may also be given. 433 Considerations 435 The Considerations section lists operational and resource 436 constraints, limitations of current implementations, tradeoffs, 437 etc. 439 1.8. Applicability 441 These capabilities are intended to give guidance on how best to 442 protect communications infrastructure. Service Providers, Network 443 Operators, and Equipment Suppliers are encouraged to study these 444 capabilities, and prioritize the extent and manner in which they may 445 implement and/or deploy equipment supporting these capabilities. 447 Decisions of whether or not to support a specific capabilities are 448 intended to be left with the responsible organization (e.g., Service 449 Provider, Network Operator, or Equipment Supplier). Due to the 450 continuously evolving nature of security threats to networks, and due 451 to significant variations in the specific security threats and 452 requirements in different network environments, it is not appropriate 453 to mandate implementation of these capabilities through legislation 454 or regulation, nor would any mandate be consistent with their intent. 456 1.9. Intended Use 458 It is anticipated that the capabilities in these documents will be 459 used for the following purposes: 461 o as a checklist when evaluating networked products, 463 o to create profiles of different subsets of the capabilities which 464 describe the needs of different devices, organizations, and 465 operating environments, 467 o to assist operators in clearly communicating their security 468 requirements, 470 o as high level guidance for the creation of detailed test plans. 472 o as guidance for vendors to make appropriate decisions for 473 engineering feature roadmaps. 475 1.10. Definitions 476 NOTE: The following definitions are take from RFC3871. Unless 477 otherwise stated, the working group documents will use these terms as 478 defined below. 480 Bogon. 482 A "Bogon" (plural: "bogons") is a packet with an IP source address 483 in an address block not yet allocated by IANA or the Regional 484 Internet Registries (ARIN, RIPE, APNIC...) as well as all 485 addresses reserved for private or special use by RFCs. See 486 [RFC3330] and [RFC1918]. 488 CLI. 490 Several capabilities refer to a Command Line Interface (CLI). 491 While this refers at present to a classic text oriented command 492 interface, it is not intended to preclude other mechanisms which 493 may provide all the capabilities that reference "CLI". 495 Conformance. 497 Adherence to proposed standards. 499 Console. 501 Several capabilities refer to a "Console". The model for this is 502 the classic RS232 serial port which has, for the past 30 or more 503 years, provided a simple, stable, reliable, well-understood and 504 nearly ubiquitous management interface to network devices. Again, 505 these capabilities are intended primarily to codify the benefits 506 provided by that venerable interface, not to preclude other 507 mechanisms that provide the same capabilities. 509 Filter. 511 In this document, a "filter" is defined as a group of one or more 512 rules where each rule specifies one or more match criteria. 514 In-Band management. 516 "In-Band management" is defined as any management done over the 517 same channels and interfaces used for user/customer data. 518 Examples would include using SSH for management via customer or 519 Internet facing network interfaces. 521 High Resolution Time. 523 "High resolution time" is defined in this document as "time having 524 a resolution greater than one second" (e.g. milliseconds). 526 IP. 528 Unless otherwise indicated, "IP" refers to IPv4. 530 Management. 532 This document uses a broad definition of the term "management". 533 In this document, "management" refers to any authorized 534 interaction with the device intended to change its operational 535 state or configuration. Data/Forwarding plane functions (e.g. the 536 transit of customer traffic) are not considered management. 537 Control plane functions such as routing, signaling and link 538 management protocols and management plane functions such as remote 539 access, configuration and authentication are considered to be 540 management. 542 Martian. 544 Per [RFC1208] "Martian: Humorous term applied to packets that turn 545 up unexpectedly on the wrong network because of bogus routing 546 entries. Also used as a name for a packet which has an altogether 547 bogus (non-registered or ill-formed) Internet address." For the 548 purposes of this document Martians are defined as "packets having 549 a source address that, by application of the current forwarding 550 tables, would not have its return traffic routed back to the 551 sender." "Spoofed packets" are a common source of martians. 553 Note that in some cases, the traffic may be asymmetric, and a 554 simple forwarding table check might produce false positives. See 555 [RFC3704] 557 Out-of-Band (OoB) management. 559 "Out-of-Band management" is defined as any management done over 560 channels and interfaces that are separate from those used for 561 user/customer data. Examples would include a serial console 562 interface or a network interface connected to a dedicated 563 management network that is not used to carry customer traffic. 565 Open Review. 567 "Open review" refers to processes designed to generate public 568 discussion and review of technical solutions such as data 569 communications protocols and cryptographic algorithms with the 570 goals of improving and building confidence in the final solutions. 572 For the purposes of this document "open review" is defined by 573 [RFC2026]. All standards track documents are considered to have 574 been through an open review process. 576 It should be noted that organizations may have local requirements 577 that define what they view as acceptable "open review". For 578 example, they may be required to adhere to certain national or 579 international standards. Such modifications of the definition of 580 the term "open review", while important, are considered local 581 issues that should be discussed between the organization and the 582 vendor. 584 It should also be noted that section 7 of [RFC2026] permits 585 standards track documents to incorporate other "external standards 586 and specifications". 588 PBR. 590 Policy Based Routing. 592 Resource Starvation. 594 A condition where resources necessary for communication and proper 595 functioning of a network element are unavailable. Such resources 596 might include Bandwidth of a link, memory of a routing device, or 597 CPU time on a routing processor. 599 Secure Channel. 601 A "secure channel" is a mechanism that ensures end-to-end 602 integrity and confidentiality of communications. Examples include 603 TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a 604 console port using physically secure, shielded cable would provide 605 confidentiality but possibly not integrity. 607 Service. 609 A number of capabilities refer to "services". For the purposes of 610 this document a "service" is defined as "any process or protocol 611 running in the control or management planes to which non-transit 612 packets may be delivered". Examples might include an SSH server, 613 a BGP process or an NTP server. It would also include the 614 transport, network and link layer protocols since, for example, a 615 TCP packet addressed to a port on which no service is listening 616 will be "delivered" to the IP stack, and possibly result in an 617 ICMP message being sent back. 619 Session. 621 An instance of protocol establishment, e.g. telnet, BGP, OSPF, 622 etc. 624 Single-Homed Network. 626 A "single-homed network" is defined as one for which 628 * There is only one upstream connection 630 * Routing is symmetric. 632 See [RFC3704] for a discussion of related issues and mechanisms 633 for multi-homed networks. 635 Spoofed Packet. 637 A "spoofed packet" is defined as a packet that has a source 638 address that does not correspond to any address assigned to the 639 system which sent the packet. Spoofed packets are often "bogons" 640 or "martians". 642 Secure Network 643 For the purposes of these documents, a secure network is one in 644 which: 646 * The network keeps passing legitimate customer traffic 647 (availability). 649 * Traffic goes where it is supposed to go, and only where it is 650 supposed to go (availability, confidentiality). 652 * The network elements remain manageable (availability). 654 * Only authorized users can manage network elements 655 (authorization). 657 * There is a record of all security related events 658 (accountability). 660 * The network operator has the necessary tools to detect and 661 respond to illegitimate traffic. 663 2. Documents 665 The following describes the types of documents to be produced by the 666 OPSEC working group. Each document is intended to cover an area 667 important to secure operation of large network infrastructure. See 668 the working group charter for a complete list of individual 669 documents. 671 2.1. Framework Document 673 Overview 675 This document. 677 2.2. Operator Practices Survey 679 Overview 681 This document provides a survey of current operator practices in 682 the area of securing networks. It lists current practices that 683 will be cited as justification for capabilities. It defines a 684 general threat model and classes of attacks. 686 2.3. Standards Survey 688 Overview 690 This document provides an overview of other efforts in developing 691 standards, guidelines, best practices, or other information 692 intended to facilitate improvement in network security. Any 693 effort which is known, such as the ANSI T1.276, the NRIC V "Best 694 Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing 695 signaling will be included. The intent is to provide a clear 696 understanding of which efforts are complementary and/or 697 contradictory such that any efforts of future cross-certification 698 of standards may be facilitated. 700 2.4. Capabilities Documents 702 Overview 704 Capability documents list capabilities needed to support security 705 practices. Each capability document lists capabilities of one 706 logical group of functions (e.g. logging, filtering, etc.). They 707 define a threat model, list individual capabilities, cite 708 practices supported in the Operator Practices Survey and in few 709 cases may define additional practices. 711 2.5. Profile Documents 713 Overview 715 Profile documents list capabilities appropriate to different 716 operating environments such as large Network Service Provider 717 (NSP) core or edge devices or enterprise networks. These profiles 718 MAY provide a good starting point for organizations to generate 719 their own list of requirements. 721 3. Security Considerations 723 Security is the entire focus of this document. 725 4. Non-Normative References 727 [I-D.ietf-opsec-current-practices] 728 Kaeo, M., "Operational Security Current Practices", 729 draft-ietf-opsec-current-practices-04 (work in progress), 730 June 2006. 732 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 733 RFC 1208, March 1991. 735 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 736 E. Lear, "Address Allocation for Private Internets", 737 BCP 5, RFC 1918, February 1996. 739 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 740 3", BCP 9, RFC 2026, October 1996. 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, 746 September 1997. 748 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 749 RFC 2246, January 1999. 751 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 752 Internet Protocol", RFC 2401, November 1998. 754 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 755 September 2002. 757 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 758 Text on Security Considerations", BCP 72, RFC 3552, 759 July 2003. 761 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 762 Networks", BCP 84, RFC 3704, March 2004. 764 [RFC3871] Jones, G., "Operational Security Requirements for Large 765 Internet Service Provider (ISP) IP Network 766 Infrastructure", RFC 3871, September 2004. 768 Appendix A. Acknowledgments 770 The authors gratefully acknowledge the contributions of: 772 o The MITRE Corporation for supporting development of this document. 773 NOTE: The author's affiliation with The MITRE Corporation is 774 provided for identification purposes only, and is not intended to 775 convey or imply MITRE's concurrence with, or support for, the 776 positions, opinions or viewpoints expressed by the author. 778 Appendix B. Sample Capability Description 780 This appendix provides a sample capability description. Note the 781 lack of the use of "MUST", etc in the description of the capability. 782 Also note that in the supported practices section it refers both to 783 the current practices document [I-D.ietf-opsec-current-practices] and 784 to sections of the same document (xxx.1, xxx.2) that describe 785 practices that were not covered in the current practices document. 787 B.1. Filtering TO the Device 789 B.1.1. Ability to Filter Traffic on All Interfaces TO the Device 791 Capability. 793 The device provides a means to filter IP packets on any interface 794 implementing IP that are non-transit packets. 796 Supported Practices. 798 * Profile Current Traffic (Section xxx.1) 800 * Block Malicious Packets (Section xxx.2 ) 802 * Limit Sources of Management ([I-D.ietf-opsec-current- 803 practices], Section 2.8.2) 805 Current Implementations. 807 Many devices currently implement access control lists or filters 808 that allow filtering based on protocol and/or source/destination 809 address and or source/destination port and allow these filters to 810 be applied to interfaces. 812 Considerations. 814 None. 816 Authors' Addresses 818 George M. Jones 819 The MITRE Corporation 820 7515 Colshire Drive, M/S WEST 821 McLean, Virginia 22102-7508 822 U.S.A. 824 Phone: +1 703 488 9740 825 Email: gmjones@mitre.org 827 Ross Callon 828 Juniper Networks 829 10 Technology Park Drive 830 Westford, MA 01886 831 U.S.A. 833 Phone: +1 978 692 6724 834 Email: rcallon@juniper.net 836 Merike Kaeo 837 Double Shot Security 838 3518 Fremont Avenue North #363 839 Seattle, WA 98103 840 U.S.A. 842 Phone: +1 310 866 0165 843 Email: merike@doubleshotsecurity.com 845 Intellectual Property Statement 847 The IETF takes no position regarding the validity or scope of any 848 Intellectual Property Rights or other rights that might be claimed to 849 pertain to the implementation or use of the technology described in 850 this document or the extent to which any license under such rights 851 might or might not be available; nor does it represent that it has 852 made any independent effort to identify any such rights. Information 853 on the procedures with respect to rights in RFC documents can be 854 found in BCP 78 and BCP 79. 856 Copies of IPR disclosures made to the IETF Secretariat and any 857 assurances of licenses to be made available, or the result of an 858 attempt made to obtain a general license or permission for the use of 859 such proprietary rights by implementers or users of this 860 specification can be obtained from the IETF on-line IPR repository at 861 http://www.ietf.org/ipr. 863 The IETF invites any interested party to bring to its attention any 864 copyrights, patents or patent applications, or other proprietary 865 rights that may cover technology that may be required to implement 866 this standard. Please address the information to the IETF at 867 ietf-ipr@ietf.org. 869 Disclaimer of Validity 871 This document and the information contained herein are provided on an 872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 879 Copyright Statement 881 Copyright (C) The Internet Society (2006). This document is subject 882 to the rights, licenses and restrictions contained in BCP 78, and 883 except as set forth therein, the authors retain all their rights. 885 Acknowledgment 887 Funding for the RFC Editor function is currently provided by the 888 Internet Society.