idnits 2.17.1 draft-ietf-opsec-framework-01.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 851. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 841. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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 a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2005) is 6764 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) ** Downref: Normative reference to an Informational RFC: RFC 1208 ** Downref: Normative reference to an Informational RFC: RFC 2196 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Downref: Normative reference to an Informational RFC: RFC 3871 Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: April 20, 2006 R. Callon 5 Juniper Networks 6 M. Kaeo 7 Double Shot Security 8 October 17, 2005 10 Framework for Operational Security Capabilities for IP Network 11 Infrastructure 12 draft-ietf-opsec-framework-01 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 April 20, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . 9 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 2.6. Deliberations Document . . . . . . . . . . . . . . . . . . 18 93 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 4. Normative References . . . . . . . . . . . . . . . . . . . . . 19 95 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 97 Intellectual Property and Copyright Statements . . . . . . . . . . 22 99 1. Introduction 101 1.1. Goals 103 The goal of the Operational Security Working Group is to codify 104 knowledge gained through operational experience about feature sets 105 that are needed to securely deploy and operate managed network 106 elements providing transit services at the data link and IP layers. 108 It is anticipated that the codification of this knowledge will be an 109 aid to vendors in producing more securable network elements, and an 110 aid to operators in increasing security by deploying and configuring 111 more secure network elements. 113 This framework document provides an overview of the work to be done 114 by the working group, and describes the documents to be produced in 115 this effort. 117 1.2. Motivation 119 Network operators need the appropriate feature sets and tools on 120 their infrastructure devices to ensure that they can effectively 121 deploy and manage their networks securely while maintaining the 122 ability to provide reliable service to their customers. Vendors need 123 guidelines on which security features and functionality are critical 124 for operators to be able to reach that goal. 126 1.3. Threat Model 128 1.3.1. Threats Addressed, Threats Not Addressed 130 This section describes the general classes of threats that this work 131 intends to address. Specific threats and attacks will be discussed 132 in the documents which are referred to in this framework. Each of 133 those documents will enumerate the capabilities which are required to 134 mitigate the risk of these specific threats. 136 The intent is to address real-world threats to and attacks on network 137 infrastructure devices which have severely impacted network 138 operations or have immediate potential to do so. The intent is NOT 139 to build a complete theoretical threat model or list every possible 140 attack. 142 The threats will be limited to those that affect the management of 143 network infrastructure and its ability to transit traffic. Threats 144 to the confidentiality and integrity of transit traffic will not be 145 addressed. 147 1.3.2. Active, Passive and Combined Attacks 149 [RFC3552] describes a general Internet threat model which readers of 150 this document should be familiar with. It defines a threat model to 151 describes the capabilities that an attacker is assumed to be able to 152 deploy against a resource. [RFC3552] classifies attacks into two 153 main categories: passive attacks and active attacks. Passive attacks 154 are ones where an attacker simply reads information off the network 155 and obtains confidential and/or private information which can be used 156 to compromise network systems. Active attacks are ones where the 157 attacker writes data to the network and can include replay attacks, 158 message insertion, message deletion, message modification and man-in- 159 the-middle attacks. Often, these passive and active attacks are 160 combined. For example, routing information is diverted via a man-in- 161 the-middle attack to force confidential information to transit a 162 network path on which the attacker is able to perform eavesdropping. 164 1.3.3. Categories of Threats 166 The following sections provide a model that can be used to further 167 categorize attacks on infrastructure devices and/or the operating 168 behavior of these devices, and also gives some examples of attacks 169 which fall into each classification. 171 It is common to categorize threats based on the effects or damage 172 caused by associated attacks. For example, threats generally fall 173 under one of the three categories as defined in [RFC2196]: 175 o Unauthorized access to resources and/or information 177 o Unintended and/or unauthorized disclosure of information 179 o Denial of service 181 There are a number of attacks, any one of which, if exploited, can 182 lead to any of the above mentioned threats. As one example, if an 183 intruder has taken control of a router (for example by guessing the 184 password) then he could potentially obtain unauthorized access to 185 resources, could gain unauthorized disclosure of information, and 186 could also deny service to legitimate users. This method of 187 categorizing threats based on the result of the threat therefore 188 results in categories which are orthogonal to the cause of the 189 effect, and thus orthogonal to the device capabilities which are 190 needed. 192 Categorization of attacks based on the capabilities required to mount 193 the attack will allow the analysis and description of the attacks to 194 be more closely aligned with the product capabilities required to 195 defeat or mitigate the attack. 197 1.3.4. Threat Sources 199 The sources of threats in an operational network take many forms. 200 Some sources can be intentional, such as a malicious intruder 201 actively gaining access to an unauthorized resource or causing a 202 denial of service attack. Other sources can be unintentional but 203 still render the network unusable, such as software bugs or 204 configuration mistakes. Many of the unintentional threat sources can 205 be difficult to recognize or prevent. However wherever possible, 206 capabilities and functionality will be defined which minimize the 207 extent of the damage done under these circumstances. 209 Threats can originate from outside or inside and can be due to 210 vulnerabilities in a device or weaknesses in operational processes. 211 Inside threats pertain to an authorized participant in the operation 212 of the network performing unauthorized actions. Outside threats 213 pertain to any unauthorized network devices or person causing havoc 214 with normal network operations. 216 On Path network devices are able to read, modify, or remove any 217 datagram transmitted along a given path. Off-path hosts can transmit 218 arbitrary datagrams that appear to come from any hosts but cannot 219 necessarily receive datagrams intended for other hosts. 221 1.4. Attacks 223 This section specifies attack categories based on the capabilities 224 required to mount the attack and provides more granular detail of 225 many of the identifiable and recognized threats to which network 226 infrastructure devices are susceptible. 228 1.4.1. Passive attacks 230 Passive attacks are ones where an attacker simply reads information 231 off the network and obtains confidential and/or private information 232 which can be used to compromise network systems. 234 1.4.2. Eavesdropping/Sniffing 236 The most common form of passive attack is eavesdropping, where the 237 attacker is able to read the data which is being transmitted from the 238 sender to the receiver. In any operational network, the entire data 239 path and every device involved in the data path must be considered 240 for this type of attack. Any information which could be used to 241 potentially gain unauthorized access to a device or is private must 242 be protected. This includes passwords, configuration files and log 243 files. It is common to think only of protecting the data path and to 244 make sure that data is not diverted along a different path which may 245 be easier to eavesdrop on, such as a wireless network. In many 246 instances it would be wise to consider cryptographically protecting 247 data confidentiality wherever sensitive information is involved. 249 1.4.3. Off-line Cryptographic Attacks 251 These attacks typically capture some data which has been 252 cryptographically protected and then use varying means to try and 253 recover the original data. Poor password protection protocols can 254 easily be reverse engineered and poorly chosen passwords can also be 255 easily deciphered. As described in [RFC3552], a number of popular 256 password-based challenge response protocols are vulnerable to a 257 dictionary attack. The attacker captures a challenge-response pair 258 and then proceeds to try entries from a list of common words (such as 259 a dictionary file) until he finds a password that produces the right 260 response. 262 1.4.4. Active Attacks 264 Active attacks are ones where the attacker writes data to the 265 network. Generally, any part of a data packet can be forged. When 266 the source IP address is forged, the attack is generally referred to 267 as a spoofing attack. These attacks can be mitigated by filtering 268 traffic based on IP addresses to only allow legitimate traffic to/ 269 from a network. 271 Not all active attacks require forged addresses and most systems are 272 susceptible to a number of common attack patterns which are described 273 in the next sections. Note that any type of active attack can be 274 used for Denial of Service if the traffic is sent at such a rate that 275 it exceeds a networks link capacity or exhausts device resources. 277 1.4.5. Replay Attacks 279 A replay attack is a combination of a passive and an active attack. 280 In this type of attack, the attacker records some number of messages 281 off of the wire and then plays them back to the original recipient. 282 Note that the attacker does not need to be able to understand the 283 messages. He merely needs to capture and re-transmit them. 285 1.4.6. Message Insertion 287 In a message insertion attack, the attacker forges one or more 288 messages and injects them into the network. Often these messages 289 will have a forged source address in order to disguise the identity 290 of the attacker. 292 Message insertion attacks can be used to exploit known 293 vulnerabilities in protocol software. Routers and switches implement 294 protocols which in some cases make use of software which is well 295 known and widely deployed. Malicious attackers therefore may be 296 familiar with the protocol software and be able to exploit known 297 vulnerabilities. 299 1.4.7. Message Modification 301 In a message modification attack, the attacker removes a message from 302 the wire, modifies it, and then resends it. The contents of the 303 message may be modified and/or the intended recipient. [need example 304 specific to network operations where this would be harmful] 306 1.4.8. Message Deletion 308 In a message deletion attack, the attacker simply removes a message 309 from the wire. [need example specific to network operations where 310 this is harmful] 312 1.4.9. Man-In-The-Middle 314 A Man-In-The-Middle attack combines the above techniques in a special 315 form: The attacker subverts the communication stream in order to pose 316 as the sender to receiver and the receiver to the sender. This 317 differs fundamentally from the above forms of attack because it 318 attacks the identity of the communicating parties, rather than the 319 data stream itself. Consequently, many techniques which provide 320 integrity of the communications stream are insufficient to protect 321 against man-in-the-middle attacks. 323 Man-in-the-middle attacks are possible whenever peer entity 324 authentication is not used. For example, it is trivial to mount man- 325 in-the-middle attacks on local networks via ARP spoofing where the 326 attacker forges an ARP with the victim's IP address and his own MAC 327 address to gain access to a network. The attacker can then do 328 further damage by sending forged messages. Imagine if the victim^Os 329 IP address was that of a TFTP server. The attacker could potentially 330 download invalid system images or configuration files to a network 331 device and subsequently compromise that network device. 333 1.4.10. Invalid Message 335 An invalid message attack refers to situations which can be either 336 deliberately invoked or are due to some non-malicious software or 337 configuration error. This attack can be realized if vendors do not 338 conform to standards and send inappropriate control packets which can 339 cause routing loops or neighboring routers to go down. Also, a 340 malicious individual may launch DoS attacks which flood a device's 341 control plane with enough messages that the device becomes inoperable 342 due to resource starvation. 344 [Ed. - Need to review existing capabilities. Do the threats and 345 attack types listed above cover them all ? Are there capabilities 346 that imply threats and attack classes not listed above] 348 1.5. Scope 350 The working group will produce a list of capabilities appropriate 351 for: 353 o Internet Service Provider (ISP) Networks 355 o Enterprise Networks 357 The following are explicitly out of scope: 359 o general purpose hosts that do not transit traffic including 360 infrastructure hosts such as name/time/log/AAA servers, etc., 362 o unmanaged devices, 364 o customer managed devices (e.g. firewalls, Intrusion Detection 365 System, dedicated VPN devices, etc.), 367 o SOHO (Small Office, Home Office) devices (e.g. personal firewalls, 368 Wireless Access Points, Cable Modems, etc.), 370 o confidentiality of customer data, 372 o integrity of customer data, 374 o physical security. 376 These limitations have been made to keep the amount of work and size 377 of documents manageable. While the capabilities listed here may 378 apply to systems outside the scope, no capabilities have been added 379 to account for their unique needs. 381 While the examples given are written with IPv4 in mind, most of the 382 capabilities are general enough to apply to IPv6. 384 1.6. Intended Audience 386 There are two intended audiences: the network operator who selects, 387 purchases, and operates IP network equipment, and the vendors who 388 create these devices. 390 1.7. Format and Definition of Capabilities 392 A separate document will be created for specific categories of 393 capabilities. Each individual capability will have the following 394 elements: 396 Capability (what) 398 The capability describes a policy to be supported by the device. 400 Capabilities should not refer to specific technologies. It is 401 expected that desired capability will change little over time. 403 Supported Practices (why) 405 The Supported Practice section cites practices described in CITE- 406 OPERATOR-SURVEY-RFC that are supported by this capability. The 407 need to support the cited practices provides the justification for 408 the feature. 410 In a few cases, practices not listed in CITE-OPERATOR-SURVEY-RFC 411 may be listed at the end of the capability document and cited as 412 justification for a capability. This may be necessary if a 413 practice becomes common after CITE-OPERATOR-SURVEY-RFC is finished 414 or if there is widespread consensus that the practice would 415 improve security but it is not, for whatever reason, in widespread 416 deployment. 418 Current Implementations (how) 420 The Current Implementation section is intended to give examples of 421 implementations of the capability, citing technology and standards 422 current at the time of writing. Examples of configuration and 423 usage may also be given. 425 Considerations 427 The Considerations section lists operational and resource 428 constraints, limitations of current implementations, tradeoffs, 429 etc. 431 1.8. Applicability 433 These capabilities are intended to give guidance on how best to 434 protect communications infrastructure. Service Providers, Network 435 Operators, and Equipment Suppliers are encouraged to study these 436 capabilities, and prioritize the extent and manner in which they may 437 implement and/or deploy equipment supporting these capabilities. 439 Decisions of whether or not to support a specific capabilities are 440 intended to be left with the responsible organization (e.g., Service 441 Provider, Network Operator, or Equipment Supplier). Due to the 442 continuously evolving nature of security threats to networks, and due 443 to significant variations in the specific security threats and 444 requirements in different network environments, it is not appropriate 445 to mandate implementation of these capabilities through legislation 446 or regulation, nor would any mandate be consistent with their intent. 448 1.9. Intended Use 450 It is anticipated that the capabilities in these documents will be 451 used for the following purposes: 453 o as a checklist when evaluating networked products, 455 o to create profiles of different subsets of the capabilities which 456 describe the needs of different devices, organizations, and 457 operating environments, 459 o to assist operators in clearly communicating their security 460 requirements, 462 o as high level guidance for the creation of detailed test plans. 464 o as guidance for vendors to make appropriate decisions for 465 engineering feature roadmaps. 467 1.10. Definitions 468 RFC 2119 Keywords 470 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 471 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 472 in this document are to be interpreted as described in [RFC2119]. 474 NOTE: The following definitions are take from RFC3871. Unless 475 otherwise stated, the working group documents will use these terms as 476 defined below. 478 Bogon. 480 A "Bogon" (plural: "bogons") is a packet with an IP source address 481 in an address block not yet allocated by IANA or the Regional 482 Internet Registries (ARIN, RIPE, APNIC...) as well as all 483 addresses reserved for private or special use by RFCs. See 484 [RFC3330] and [RFC1918]. 486 CLI. 488 Several capabilities refer to a Command Line Interface (CLI). 489 While this refers at present to a classic text oriented command 490 interface, it is not intended to preclude other mechanisms which 491 may provide all the capabilities that reference "CLI". 493 Conformance. 495 Adherence to proposed standards. 497 Console. 499 Several capabilities refer to a "Console". The model for this is 500 the classic RS232 serial port which has, for the past 30 or more 501 years, provided a simple, stable, reliable, well-understood and 502 nearly ubiquitous management interface to network devices. Again, 503 these capabilities are intended primarily to codify the benefits 504 provided by that venerable interface, not to preclude other 505 mechanisms that provide the same capabilities. 507 Filter. 509 In this document, a "filter" is defined as a group of one or more 510 rules where each rule specifies one or more match criteria. 512 In-Band management. 514 "In-Band management" is defined as any management done over the 515 same channels and interfaces used for user/customer data. 516 Examples would include using SSH for management via customer or 517 Internet facing network interfaces. 519 High Resolution Time. 521 "High resolution time" is defined in this document as "time having 522 a resolution greater than one second" (e.g. milliseconds). 524 IP. 526 Unless otherwise indicated, "IP" refers to IPv4. 528 Management. 530 This document uses a broad definition of the term "management". 531 In this document, "management" refers to any authorized 532 interaction with the device intended to change its operational 533 state or configuration. Data/Forwarding plane functions (e.g. the 534 transit of customer traffic) are not considered management. 535 Control plane functions such as routing, signaling and link 536 management protocols and management plane functions such as remote 537 access, configuration and authentication are considered to be 538 management. 540 Martian. 542 Per [RFC1208] "Martian: Humorous term applied to packets that turn 543 up unexpectedly on the wrong network because of bogus routing 544 entries. Also used as a name for a packet which has an altogether 545 bogus (non-registered or ill-formed) Internet address." For the 546 purposes of this document Martians are defined as "packets having 547 a source address that, by application of the current forwarding 548 tables, would not have its return traffic routed back to the 549 sender." "Spoofed packets" are a common source of martians. 551 Note that in some cases, the traffic may be asymmetric, and a 552 simple forwarding table check might produce false positives. See 553 [RFC3704] 555 Out-of-Band (OoB) management. 557 "Out-of-Band management" is defined as any management done over 558 channels and interfaces that are separate from those used for 559 user/customer data. Examples would include a serial console 560 interface or a network interface connected to a dedicated 561 management network that is not used to carry customer traffic. 563 Open Review. 565 "Open review" refers to processes designed to generate public 566 discussion and review of technical solutions such as data 567 communications protocols and cryptographic algorithms with the 568 goals of improving and building confidence in the final solutions. 570 For the purposes of this document "open review" is defined by 571 [RFC2026]. All standards track documents are considered to have 572 been through an open review process. 574 It should be noted that organizations may have local requirements 575 that define what they view as acceptable "open review". For 576 example, they may be required to adhere to certain national or 577 international standards. Such modifications of the definition of 578 the term "open review", while important, are considered local 579 issues that should be discussed between the organization and the 580 vendor. 582 It should also be noted that section 7 of [RFC2026] permits 583 standards track documents to incorporate other "external standards 584 and specifications". 586 PBR. 588 Policy Based Routing. 590 Resource Starvation. 592 A condition where resources necessary for communication and proper 593 functioning of a network element are unavailable. Such resources 594 might include Bandwidth of a link, memory of a routing device, or 595 CPU time on a routing processor. 597 Secure Channel. 599 A "secure channel" is a mechanism that ensures end-to-end 600 integrity and confidentiality of communications. Examples include 601 TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a 602 console port using physically secure, shielded cable would provide 603 confidentiality but possibly not integrity. 605 Service. 607 A number of capabilities refer to "services". For the purposes of 608 this document a "service" is defined as "any process or protocol 609 running in the control or management planes to which non-transit 610 packets may be delivered". Examples might include an SSH server, 611 a BGP process or an NTP server. It would also include the 612 transport, network and link layer protocols since, for example, a 613 TCP packet addressed to a port on which no service is listening 614 will be "delivered" to the IP stack, and possibly result in an 615 ICMP message being sent back. 617 Session. 619 An instance of protocol establishment, e.g. telnet, BGP, OSPF, 620 etc. 622 Single-Homed Network. 624 A "single-homed network" is defined as one for which 626 * There is only one upstream connection 628 * Routing is symmetric. 630 See [RFC3704] for a discussion of related issues and mechanisms 631 for multi-homed networks. 633 Spoofed Packet. 635 A "spoofed packet" is defined as a packet that has a source 636 address that does not correspond to any address assigned to the 637 system which sent the packet. Spoofed packets are often "bogons" 638 or "martians". 640 Secure Network 642 For the purposes of these documents, a secure network is one in 643 which: 645 * The network keeps passing legitimate customer traffic 646 (availability). 648 * Traffic goes where it is supposed to go, and only where it is 649 supposed to go (availability, confidentiality). 651 * The network elements remain manageable (availability). 653 * Only authorized users can manage network elements 654 (authorization). 656 * There is a record of all security related events 657 (accountability). 659 * The network operator has the necessary tools to detect and 660 respond to illegitimate traffic. 662 2. Documents 664 The following describes the types of documents to be produced by the 665 OPSEC working group. Each document is intended to cover an area 666 important to secure operation of large network infrastructure. See 667 the working group charter for a complete list of individual 668 documents. 670 2.1. Framework Document 672 Overview 674 This document. 676 2.2. Operator Practices Survey 678 Overview 680 This document is intended to provide a survey of current operator 681 practices in the area of securing networks. It lists current 682 practices that will be cited as justification for capabilities. 683 It defines a general threat model and classes of attacks. 685 2.3. Standards Survey 687 Overview 689 This document provides an overview of other efforts in developing 690 standards, guidelines, best practices, or other information 691 intended to facilitate improvement in network security. Any 692 effort which is known, such as the ANSI T1.276, the NRIC V "Best 693 Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing 694 signalling will be included. The intent is to provide a clear 695 understanding of which efforts are complementary and/or 696 contradictory such that any efforts of future cross-certification 697 of standards may be facilitated. 699 2.4. Capabilities Documents 701 Overview 703 Capability documents list capabilities needed to support security 704 practices. Each capability document lists capabilities of one 705 logical group of functions (e.g. logging, filtering, etc.). They 706 define a threat model, list individual capabilities, cite 707 practices supported in the Operator Practices Survey and in few 708 cases may define additional practices. 710 2.5. Profile Documents 712 Overview 714 Profile documents list capabilities appropriate to different 715 operating environments such as large Network Service Provider 716 (NSP) core or edge devices or enterprise networks. These profiles 717 MAY provide a good starting point for organizations to generate 718 their own list of requirements. 720 2.6. Deliberations Document 722 Overview 724 The deliberations document is intended to capture discussion, list 725 reasons for choices made, and give reasons for the inclusion and 726 exclusion of certain capabilities form the documents. This is 727 intended to provide insight to future work. 729 3. Security Considerations 731 Security is the entire focus of this document. 733 4. Normative References 735 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 736 RFC 1208, March 1991. 738 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 739 E. Lear, "Address Allocation for Private Internets", 740 BCP 5, RFC 1918, February 1996. 742 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 743 3", BCP 9, RFC 2026, October 1996. 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, 749 September 1997. 751 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 752 RFC 2246, January 1999. 754 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 755 Internet Protocol", RFC 2401, November 1998. 757 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 758 September 2002. 760 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 761 Text on Security Considerations", BCP 72, RFC 3552, 762 July 2003. 764 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 765 Networks", BCP 84, RFC 3704, March 2004. 767 [RFC3871] Jones, G., "Operational Security Requirements for Large 768 Internet Service Provider (ISP) IP Network 769 Infrastructure", RFC 3871, September 2004. 771 Appendix A. Acknowledgments 773 The authors gratefully acknowledge the contributions of: 775 o Acknowledgments to be determined. 777 o The MITRE Corporation for supporting development of this document. 778 NOTE: The author's affiliation with The MITRE Corporation is 779 provided for identification purposes only, and is not intended to 780 convey or imply MITRE's concurrence with, or support for, the 781 positions, opinions or viewpoints expressed by the author. 783 o This listing is intended to acknowledge contributions, not to 784 imply that the individual or organizations approve the content of 785 this document. 787 o Apologies to those who commented on/contributed to the document 788 and were not listed. 790 Authors' Addresses 792 George M. Jones 793 The MITRE Corporation 794 7515 Colshire Drive, M/S WEST 795 McLean, Virginia 22102-7508 796 U.S.A. 798 Phone: +1 703 488 9740 799 Email: gmjones@mitre.org 801 Ross Callon 802 Juniper Networks 803 10 Technology Park Drive 804 Westford, MA 01886 805 U.S.A. 807 Phone: +1 978 692 6724 808 Email: rcallon@juniper.net 810 Merike Kaeo 811 Double Shot Security 812 520 Washington Blvd. #363 813 Marina Del Rey, CA 90292 814 U.S.A. 816 Phone: +1 310 866 0165 817 Email: kaeo@merike.com 819 Intellectual Property Statement 821 The IETF takes no position regarding the validity or scope of any 822 Intellectual Property Rights or other rights that might be claimed to 823 pertain to the implementation or use of the technology described in 824 this document or the extent to which any license under such rights 825 might or might not be available; nor does it represent that it has 826 made any independent effort to identify any such rights. Information 827 on the procedures with respect to rights in RFC documents can be 828 found in BCP 78 and BCP 79. 830 Copies of IPR disclosures made to the IETF Secretariat and any 831 assurances of licenses to be made available, or the result of an 832 attempt made to obtain a general license or permission for the use of 833 such proprietary rights by implementers or users of this 834 specification can be obtained from the IETF on-line IPR repository at 835 http://www.ietf.org/ipr. 837 The IETF invites any interested party to bring to its attention any 838 copyrights, patents or patent applications, or other proprietary 839 rights that may cover technology that may be required to implement 840 this standard. Please address the information to the IETF at 841 ietf-ipr@ietf.org. 843 Disclaimer of Validity 845 This document and the information contained herein are provided on an 846 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 847 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 848 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 849 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 850 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 851 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 853 Copyright Statement 855 Copyright (C) The Internet Society (2005). This document is subject 856 to the rights, licenses and restrictions contained in BCP 78, and 857 except as set forth therein, the authors retain all their rights. 859 Acknowledgment 861 Funding for the RFC Editor function is currently provided by the 862 Internet Society.