idnits 2.17.1 draft-ietf-opsec-framework-02.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 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 838. ** 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.) ** There are 102 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 (March 1, 2006) is 6631 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-02 ** Downref: Normative reference to an Informational draft: draft-ietf-opsec-current-practices (ref. 'I-D.ietf-opsec-current-practices') ** 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: 13 errors (**), 0 flaws (~~), 4 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: 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-02 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. Normative References . . . . . . . . . . . . . . . . . . . . . 19 94 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 96 Intellectual Property and Copyright Statements . . . . . . . . . . 22 98 1. Introduction 100 1.1. Goals 102 The goal of the Operational Security Working Group is to codify 103 knowledge gained through operational experience about feature sets 104 that are needed to securely deploy and operate managed network 105 elements providing transit services at the data link and IP layers. 107 It is anticipated that the codification of this knowledge will be an 108 aid to vendors in producing more securable network elements, and an 109 aid to operators in increasing security by deploying and configuring 110 more secure network elements. 112 This framework document provides an overview of the work to be done 113 by the working group, and describes the documents to be produced in 114 this effort. 116 1.2. Motivation 118 Network operators need the appropriate feature sets and tools on 119 their infrastructure devices to ensure that they can effectively 120 deploy and manage their networks securely while maintaining the 121 ability to provide reliable service to their customers. Vendors need 122 guidelines on which security features and functionality are critical 123 for operators to be able to reach that goal. 125 1.3. Threat Model 127 1.3.1. Threats Addressed, Threats Not Addressed 129 This section describes the general classes of threats that this work 130 intends to address. Specific threats and attacks will be discussed 131 in the documents which are referred to in this framework. Each of 132 those documents will enumerate the capabilities which are required to 133 mitigate the risk of these specific threats. 135 The intent is to address real-world threats to and attacks on network 136 infrastructure devices which have severely impacted network 137 operations or have immediate potential to do so. The intent is NOT 138 to build a complete theoretical threat model or list every possible 139 attack. 141 The threats will be limited to those that affect the management of 142 network infrastructure and its ability to transit traffic. Threats 143 to the confidentiality and integrity of transit traffic will not be 144 addressed. 146 1.3.2. Active, Passive and Combined Attacks 148 [RFC3552] describes a general Internet threat model which readers of 149 this document should be familiar with. It defines a threat model to 150 describes the capabilities that an attacker is assumed to be able to 151 deploy against a resource. [RFC3552] classifies attacks into two 152 main categories: passive attacks and active attacks. Passive attacks 153 are ones where an attacker simply reads information off the network 154 and obtains confidential and/or private information which can be used 155 to compromise network systems. Active attacks are ones where the 156 attacker writes data to the network and can include replay attacks, 157 message insertion, message deletion, message modification and man-in- 158 the-middle attacks. Often, these passive and active attacks are 159 combined. For example, routing information is diverted via a man-in- 160 the-middle attack to force confidential information to transit a 161 network path on which the attacker is able to perform eavesdropping. 163 1.3.3. Categories of Threats 165 The following sections provide a model that can be used to further 166 categorize attacks on infrastructure devices and/or the operating 167 behavior of these devices, and also gives some examples of attacks 168 which fall into each classification. 170 It is common to categorize threats based on the effects or damage 171 caused by associated attacks. For example, threats generally fall 172 under one of the three categories as defined in [RFC2196]: 174 o Unauthorized access to resources and/or information 176 o Unintended and/or unauthorized disclosure of information 178 o Denial of service 180 There are a number of attacks, any one of which, if exploited, can 181 lead to any of the above mentioned threats. As one example, if an 182 intruder has taken control of a router (for example by guessing the 183 password) then he could potentially obtain unauthorized access to 184 resources, could gain unauthorized disclosure of information, and 185 could also deny service to legitimate users. This method of 186 categorizing threats based on the result of the threat therefore 187 results in categories which are orthogonal to the cause of the 188 effect, and thus orthogonal to the device capabilities which are 189 needed. 191 Categorization of attacks based on the capabilities required to mount 192 the attack will allow the analysis and description of the attacks to 193 be more closely aligned with the product capabilities required to 194 defeat or mitigate the attack. 196 1.3.4. Threat Sources 198 The sources of threats in an operational network take many forms. 199 Some sources can be intentional, such as a malicious intruder 200 actively gaining access to an unauthorized resource or causing a 201 denial of service attack. Other sources can be unintentional but 202 still render the network unusable, such as software bugs or 203 configuration mistakes. Many of the unintentional threat sources can 204 be difficult to recognize or prevent. However wherever possible, 205 capabilities and functionality will be defined which minimize the 206 extent of the damage done under these circumstances. 208 Threats can originate from outside or inside and can be due to 209 vulnerabilities in a device or weaknesses in operational processes. 210 Inside threats pertain to an authorized participant in the operation 211 of the network performing unauthorized actions. Outside threats 212 pertain to any unauthorized network devices or person causing havoc 213 with normal network operations. 215 On Path network devices are able to read, modify, or remove any 216 datagram transmitted along a given path. Off-path hosts can transmit 217 arbitrary datagrams that appear to come from any hosts but cannot 218 necessarily receive datagrams intended for other hosts. 220 1.4. Attacks 222 This section specifies attack categories based on the capabilities 223 required to mount the attack and provides more granular detail of 224 many of the identifiable and recognized threats to which network 225 infrastructure devices are susceptible. 227 1.4.1. Passive attacks 229 Passive attacks are ones where an attacker simply reads information 230 off the network and obtains confidential and/or private information 231 which can be used to compromise network systems. 233 1.4.2. Eavesdropping/Sniffing 235 The most common form of passive attack is eavesdropping, where the 236 attacker is able to read the data which is being transmitted from the 237 sender to the receiver. In any operational network, the entire data 238 path and every device involved in the data path must be considered 239 for this type of attack. Any information which could be used to 240 potentially gain unauthorized access to a device or is private must 241 be protected. This includes passwords, configuration files and log 242 files. It is common to think only of protecting the data path and to 243 make sure that data is not diverted along a different path which may 244 be easier to eavesdrop on, such as a wireless network. In many 245 instances it would be wise to consider cryptographically protecting 246 data confidentiality wherever sensitive information is involved. 248 1.4.3. Off-line Cryptographic Attacks 250 These attacks typically capture some data which has been 251 cryptographically protected and then use varying means to try and 252 recover the original data. Poor password protection protocols can 253 easily be reverse engineered and poorly chosen passwords can also be 254 easily deciphered. As described in [RFC3552], a number of popular 255 password-based challenge response protocols are vulnerable to a 256 dictionary attack. The attacker captures a challenge-response pair 257 and then proceeds to try entries from a list of common words (such as 258 a dictionary file) until he finds a password that produces the right 259 response. 261 1.4.4. Active Attacks 263 Active attacks are ones where the attacker writes data to the 264 network. Generally, any part of a data packet can be forged. When 265 the source IP address is forged, the attack is generally referred to 266 as a spoofing attack. These attacks can be mitigated by filtering 267 traffic based on IP addresses to only allow legitimate traffic to/ 268 from a network. 270 Not all active attacks require forged addresses and most systems are 271 susceptible to a number of common attack patterns which are described 272 in the next sections. Note that any type of active attack can be 273 used for Denial of Service if the traffic is sent at such a rate that 274 it exceeds a networks link capacity or exhausts device resources. 276 1.4.5. Replay Attacks 278 A replay attack is a combination of a passive and an active attack. 279 In this type of attack, the attacker records some number of messages 280 off of the wire and then plays them back to the original recipient. 281 Note that the attacker does not need to be able to understand the 282 messages. He merely needs to capture and re-transmit them. 284 1.4.6. Message Insertion 286 In a message insertion attack, the attacker forges one or more 287 messages and injects them into the network. Often these messages 288 will have a forged source address in order to disguise the identity 289 of the attacker. 291 Message insertion attacks can be used to exploit known 292 vulnerabilities in protocol software. Routers and switches implement 293 protocols which in some cases make use of software which is well 294 known and widely deployed. Malicious attackers therefore may be 295 familiar with the protocol software and be able to exploit known 296 vulnerabilities. 298 1.4.7. Message Modification 300 In a message modification attack, the attacker removes a message from 301 the wire, modifies it, and then resends it. The contents of the 302 message may be modified and/or the intended recipient. For example, 303 a hacker might try to modify a DNS response, in order to redirect a 304 client to the wrong server. [need example specific to network 305 operations where this would be harmful] 307 1.4.8. Message Deletion 309 In a message deletion attack, the attacker simply removes a message 310 from the wire. [need example specific to network operations where 311 this is harmful] 313 1.4.9. Man-In-The-Middle 315 A Man-In-The-Middle attack combines the above techniques in a special 316 form: The attacker subverts the communication stream in order to pose 317 as the sender to receiver and the receiver to the sender. This 318 differs fundamentally from the above forms of attack because it 319 attacks the identity of the communicating parties, rather than the 320 data stream itself. Consequently, many techniques which provide 321 integrity of the communications stream are insufficient to protect 322 against man-in-the-middle attacks. 324 Man-in-the-middle attacks are possible whenever peer entity 325 authentication is not used. For example, it is trivial to mount man- 326 in-the-middle attacks on local networks via ARP spoofing where the 327 attacker forges an ARP with the victim's IP address and his own MAC 328 address to gain access to a network. The attacker can then do 329 further damage by sending forged messages. Imagine if the victims IP 330 address was that of a TFTP server. The attacker could potentially 331 download invalid system images or configuration files to a network 332 device and subsequently compromise that network device. 334 1.4.10. Invalid Message 336 An invalid message attack refers to situations which can be either 337 deliberately invoked or are due to some non-malicious software or 338 configuration error. This attack can be realized if vendors do not 339 conform to standards and send inappropriate control packets which can 340 cause routing loops or neighboring routers to go down. Also, a 341 malicious individual may launch DoS attacks which flood a device's 342 control plane with enough messages that the device becomes inoperable 343 due to resource starvation. 345 [Ed. - Need to review existing capabilities. Do the threats and 346 attack types listed above cover them all ? Are there capabilities 347 that imply threats and attack classes not listed above] 349 1.5. Scope 351 The working group will produce a list of capabilities appropriate 352 for: 354 o Internet Service Provider (ISP) Networks 356 o Enterprise Networks 358 The following are explicitly out of scope: 360 o general purpose hosts that do not transit traffic including 361 infrastructure hosts such as name/time/log/AAA servers, etc., 363 o unmanaged devices, 365 o customer managed devices (e.g. firewalls, Intrusion Detection 366 System, dedicated VPN devices, etc.), 368 o SOHO (Small Office, Home Office) devices (e.g. personal firewalls, 369 Wireless Access Points, Cable Modems, etc.), 371 o confidentiality of customer data, 373 o integrity of customer data, 375 o physical security. 377 These limitations have been made to keep the amount of work and size 378 of documents manageable. While the capabilities listed here may 379 apply to systems outside the scope, no capabilities have been added 380 to account for their unique needs. 382 While the examples given are written with IPv4 in mind, most of the 383 capabilities are general enough to apply to IPv6. 385 1.6. Intended Audience 387 There are two intended audiences: the network operator who selects, 388 purchases, and operates IP network equipment, and the vendors who 389 create these devices. 391 1.7. Format and Definition of Capabilities 393 A separate document will be created for specific categories of 394 capabilities. Each individual capability will have the following 395 elements: 397 Capability (what) 399 The capability describes a policy to be supported by the device. 401 Capabilities should not refer to specific technologies. It is 402 expected that desired capability will change little over time. 404 Supported Practices (why) 406 The Supported Practice section cites practices described in 407 [I-D.ietf-opsec-current-practices] that are supported by this 408 capability. The need to support the cited practices provides the 409 justification for the feature. 411 In a few cases, practices not listed in [I-D.ietf-opsec-current- 412 practices] may be listed at the end of the capability document and 413 cited as justification for a capability. This may be necessary if 414 a practice becomes common after [I-D.ietf-opsec-current-practices] 415 is finished or if there is widespread consensus that the practice 416 would improve security but it is not, for whatever reason, in 417 widespread deployment. 419 Current Implementations (how) 421 The Current Implementation section is intended to give examples of 422 implementations of the capability, citing technology and standards 423 current at the time of writing. Examples of configuration and 424 usage may also be given. 426 Considerations 428 The Considerations section lists operational and resource 429 constraints, limitations of current implementations, tradeoffs, 430 etc. 432 1.8. Applicability 434 These capabilities are intended to give guidance on how best to 435 protect communications infrastructure. Service Providers, Network 436 Operators, and Equipment Suppliers are encouraged to study these 437 capabilities, and prioritize the extent and manner in which they may 438 implement and/or deploy equipment supporting these capabilities. 440 Decisions of whether or not to support a specific capabilities are 441 intended to be left with the responsible organization (e.g., Service 442 Provider, Network Operator, or Equipment Supplier). Due to the 443 continuously evolving nature of security threats to networks, and due 444 to significant variations in the specific security threats and 445 requirements in different network environments, it is not appropriate 446 to mandate implementation of these capabilities through legislation 447 or regulation, nor would any mandate be consistent with their intent. 449 1.9. Intended Use 451 It is anticipated that the capabilities in these documents will be 452 used for the following purposes: 454 o as a checklist when evaluating networked products, 456 o to create profiles of different subsets of the capabilities which 457 describe the needs of different devices, organizations, and 458 operating environments, 460 o to assist operators in clearly communicating their security 461 requirements, 463 o as high level guidance for the creation of detailed test plans. 465 o as guidance for vendors to make appropriate decisions for 466 engineering feature roadmaps. 468 1.10. Definitions 469 RFC 2119 Keywords 471 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 472 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 473 in this document are to be interpreted as described in [RFC2119]. 475 NOTE: The following definitions are take from RFC3871. Unless 476 otherwise stated, the working group documents will use these terms as 477 defined below. 479 Bogon. 481 A "Bogon" (plural: "bogons") is a packet with an IP source address 482 in an address block not yet allocated by IANA or the Regional 483 Internet Registries (ARIN, RIPE, APNIC...) as well as all 484 addresses reserved for private or special use by RFCs. See 485 [RFC3330] and [RFC1918]. 487 CLI. 489 Several capabilities refer to a Command Line Interface (CLI). 490 While this refers at present to a classic text oriented command 491 interface, it is not intended to preclude other mechanisms which 492 may provide all the capabilities that reference "CLI". 494 Conformance. 496 Adherence to proposed standards. 498 Console. 500 Several capabilities refer to a "Console". The model for this is 501 the classic RS232 serial port which has, for the past 30 or more 502 years, provided a simple, stable, reliable, well-understood and 503 nearly ubiquitous management interface to network devices. Again, 504 these capabilities are intended primarily to codify the benefits 505 provided by that venerable interface, not to preclude other 506 mechanisms that provide the same capabilities. 508 Filter. 510 In this document, a "filter" is defined as a group of one or more 511 rules where each rule specifies one or more match criteria. 513 In-Band management. 515 "In-Band management" is defined as any management done over the 516 same channels and interfaces used for user/customer data. 517 Examples would include using SSH for management via customer or 518 Internet facing network interfaces. 520 High Resolution Time. 522 "High resolution time" is defined in this document as "time having 523 a resolution greater than one second" (e.g. milliseconds). 525 IP. 527 Unless otherwise indicated, "IP" refers to IPv4. 529 Management. 531 This document uses a broad definition of the term "management". 532 In this document, "management" refers to any authorized 533 interaction with the device intended to change its operational 534 state or configuration. Data/Forwarding plane functions (e.g. the 535 transit of customer traffic) are not considered management. 536 Control plane functions such as routing, signaling and link 537 management protocols and management plane functions such as remote 538 access, configuration and authentication are considered to be 539 management. 541 Martian. 543 Per [RFC1208] "Martian: Humorous term applied to packets that turn 544 up unexpectedly on the wrong network because of bogus routing 545 entries. Also used as a name for a packet which has an altogether 546 bogus (non-registered or ill-formed) Internet address." For the 547 purposes of this document Martians are defined as "packets having 548 a source address that, by application of the current forwarding 549 tables, would not have its return traffic routed back to the 550 sender." "Spoofed packets" are a common source of martians. 552 Note that in some cases, the traffic may be asymmetric, and a 553 simple forwarding table check might produce false positives. See 554 [RFC3704] 556 Out-of-Band (OoB) management. 558 "Out-of-Band management" is defined as any management done over 559 channels and interfaces that are separate from those used for 560 user/customer data. Examples would include a serial console 561 interface or a network interface connected to a dedicated 562 management network that is not used to carry customer traffic. 564 Open Review. 566 "Open review" refers to processes designed to generate public 567 discussion and review of technical solutions such as data 568 communications protocols and cryptographic algorithms with the 569 goals of improving and building confidence in the final solutions. 571 For the purposes of this document "open review" is defined by 572 [RFC2026]. All standards track documents are considered to have 573 been through an open review process. 575 It should be noted that organizations may have local requirements 576 that define what they view as acceptable "open review". For 577 example, they may be required to adhere to certain national or 578 international standards. Such modifications of the definition of 579 the term "open review", while important, are considered local 580 issues that should be discussed between the organization and the 581 vendor. 583 It should also be noted that section 7 of [RFC2026] permits 584 standards track documents to incorporate other "external standards 585 and specifications". 587 PBR. 589 Policy Based Routing. 591 Resource Starvation. 593 A condition where resources necessary for communication and proper 594 functioning of a network element are unavailable. Such resources 595 might include Bandwidth of a link, memory of a routing device, or 596 CPU time on a routing processor. 598 Secure Channel. 600 A "secure channel" is a mechanism that ensures end-to-end 601 integrity and confidentiality of communications. Examples include 602 TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a 603 console port using physically secure, shielded cable would provide 604 confidentiality but possibly not integrity. 606 Service. 608 A number of capabilities refer to "services". For the purposes of 609 this document a "service" is defined as "any process or protocol 610 running in the control or management planes to which non-transit 611 packets may be delivered". Examples might include an SSH server, 612 a BGP process or an NTP server. It would also include the 613 transport, network and link layer protocols since, for example, a 614 TCP packet addressed to a port on which no service is listening 615 will be "delivered" to the IP stack, and possibly result in an 616 ICMP message being sent back. 618 Session. 620 An instance of protocol establishment, e.g. telnet, BGP, OSPF, 621 etc. 623 Single-Homed Network. 625 A "single-homed network" is defined as one for which 627 * There is only one upstream connection 629 * Routing is symmetric. 631 See [RFC3704] for a discussion of related issues and mechanisms 632 for multi-homed networks. 634 Spoofed Packet. 636 A "spoofed packet" is defined as a packet that has a source 637 address that does not correspond to any address assigned to the 638 system which sent the packet. Spoofed packets are often "bogons" 639 or "martians". 641 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. Normative References 727 [I-D.ietf-opsec-current-practices] 728 Kaeo, M., "Operational Security Current Practices", 729 draft-ietf-opsec-current-practices-02 (work in progress), 730 October 2005. 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 Acknowledgments to be determined. 774 o The MITRE Corporation for supporting development of this document. 775 NOTE: The author's affiliation with The MITRE Corporation is 776 provided for identification purposes only, and is not intended to 777 convey or imply MITRE's concurrence with, or support for, the 778 positions, opinions or viewpoints expressed by the author. 780 o This listing is intended to acknowledge contributions, not to 781 imply that the individual or organizations approve the content of 782 this document. 784 o Apologies to those who commented on/contributed to the document 785 and were not listed. 787 Authors' Addresses 789 George M. Jones 790 The MITRE Corporation 791 7515 Colshire Drive, M/S WEST 792 McLean, Virginia 22102-7508 793 U.S.A. 795 Phone: +1 703 488 9740 796 Email: gmjones@mitre.org 798 Ross Callon 799 Juniper Networks 800 10 Technology Park Drive 801 Westford, MA 01886 802 U.S.A. 804 Phone: +1 978 692 6724 805 Email: rcallon@juniper.net 807 Merike Kaeo 808 Double Shot Security 809 520 Washington Blvd. #363 810 Marina Del Rey, CA 90292 811 U.S.A. 813 Phone: +1 310 866 0165 814 Email: kaeo@merike.com 816 Intellectual Property Statement 818 The IETF takes no position regarding the validity or scope of any 819 Intellectual Property Rights or other rights that might be claimed to 820 pertain to the implementation or use of the technology described in 821 this document or the extent to which any license under such rights 822 might or might not be available; nor does it represent that it has 823 made any independent effort to identify any such rights. Information 824 on the procedures with respect to rights in RFC documents can be 825 found in BCP 78 and BCP 79. 827 Copies of IPR disclosures made to the IETF Secretariat and any 828 assurances of licenses to be made available, or the result of an 829 attempt made to obtain a general license or permission for the use of 830 such proprietary rights by implementers or users of this 831 specification can be obtained from the IETF on-line IPR repository at 832 http://www.ietf.org/ipr. 834 The IETF invites any interested party to bring to its attention any 835 copyrights, patents or patent applications, or other proprietary 836 rights that may cover technology that may be required to implement 837 this standard. Please address the information to the IETF at 838 ietf-ipr@ietf.org. 840 Disclaimer of Validity 842 This document and the information contained herein are provided on an 843 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 844 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 845 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 846 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 847 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 848 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 850 Copyright Statement 852 Copyright (C) The Internet Society (2006). This document is subject 853 to the rights, licenses and restrictions contained in BCP 78, and 854 except as set forth therein, the authors retain all their rights. 856 Acknowledgment 858 Funding for the RFC Editor function is currently provided by the 859 Internet Society.