idnits 2.17.1 draft-jones-opsec-framework-01.txt: -(336): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 880. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 19) being 74 lines == 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 == Line 224 has weird spacing: '...ces are able ...' == Line 631 has weird spacing: '...in-band manag...' -- 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 21, 2004) is 7125 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) == Unused Reference: 'RFC3013' is defined on line 793, but no explicit reference was found in the text ** 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 3631 ** Downref: Normative reference to an Informational RFC: RFC 3871 Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 OPSEC Working Group G. Jones 2 Internet-Draft The MITRE Corporation 3 Expires: April 21, 2005 R. Callon 4 Juniper Networks 5 M. Kaeo 6 Double Shot Security 7 October 21, 2004 9 Framework for Operational Security Capabilities for IP Network 10 Infrastructure 11 draft-jones-opsec-framework-01 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 21, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document outlines work to be done and documents to be produced 47 by the Operational Security Capabilities (OPSEC) Working Group. The 48 goal of the working group is to codify knowledge gained through 49 operational experience about feature sets that are needed to securely 50 deploy and operate managed network elements providing transit 51 services at the data link and IP layers. The intent is to provide 52 clear, concise documentation of capabilities necessary for operating 53 networks securely, to assist network operators in communicating their 54 requirements to vendors, and to provide vendors with input that is 55 useful for building more secure devices. The working group will 56 produce a list of capabilities appropriate for large Internet Service 57 Provider (ISP) and Enterprise Networks. This work is intended to 58 refine [RFC3871]. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3.1 Threats Addressed, Threats Not Addressed . . . . . . . 4 67 1.3.2 Active, Passive and Combined Attacks . . . . . . . . . 5 68 1.3.3 Categories of Threats . . . . . . . . . . . . . . . . 5 69 1.3.4 Threat Sources . . . . . . . . . . . . . . . . . . . . 6 70 1.4 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1.4.1 Passive attacks . . . . . . . . . . . . . . . . . . . 6 72 1.4.2 Eavesdropping/Sniffing . . . . . . . . . . . . . . . . 6 73 1.4.3 Off-line Cryptographic Attacks . . . . . . . . . . . . 7 74 1.4.4 Active Attacks . . . . . . . . . . . . . . . . . . . . 7 75 1.4.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . 7 76 1.4.6 Message Insertion . . . . . . . . . . . . . . . . . . 7 77 1.4.7 Message Modification . . . . . . . . . . . . . . . . . 8 78 1.4.8 Message Deletion . . . . . . . . . . . . . . . . . . . 8 79 1.4.9 Man-In-The-Middle . . . . . . . . . . . . . . . . . . 8 80 1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1.6 Intended Audience . . . . . . . . . . . . . . . . . . . . 9 82 1.7 Format and Definition of Capabilities . . . . . . . . . . 9 83 1.8 Applicability . . . . . . . . . . . . . . . . . . . . . . 10 84 1.9 Intended Use . . . . . . . . . . . . . . . . . . . . . . . 11 85 1.10 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 86 2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 2.1 Standards Survey (info) . . . . . . . . . . . . . . . . . 15 88 2.2 In-Band management capabilities (BCP) . . . . . . . . . . 15 89 2.3 Out-of-Band management capabilities (BCP) . . . . . . . . 16 90 2.4 Filtering capabilities (BCP) . . . . . . . . . . . . . . . 16 91 2.5 Event Logging Capabilities document (BCP) . . . . . . . . 16 92 2.6 Configuration and Management Interface Capabilities 93 (BCP) . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 2.7 AAA capabilities document (BCP) . . . . . . . . . . . . . 17 95 2.8 Documentation and Assurance capabilities document (BCP) . 17 96 2.9 Miscellaneous capabilities document (BCP) . . . . . . . . 18 97 2.10 Large ISP Operational Security Capabilities Profile 98 (info) . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 2.11 Large Enterprise Operational Security Capabilities 100 Profile (info) . . . . . . . . . . . . . . . . . . . . . . 18 101 2.12 OPSEC Deliberation Summary document (info) . . . . . . . . 18 102 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 103 4. Normative References . . . . . . . . . . . . . . . . . . . . . 19 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 105 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 106 Intellectual Property and Copyright Statements . . . . . . . . 22 108 1. Introduction 110 1.1 Goals 112 The goal of the Operational Security Working Group is to codify 113 knowledge gained through operational experience about feature sets 114 that are needed to securely deploy and operate managed network 115 elements providing transit services at the data link and IP layers. 117 It is anticipated that the codification of this knowledge will be an 118 aid to vendors in producing more securable network elements, and an 119 aid to operators in increasing security by deploying and configuring 120 more secure network elements. 122 This framework document provides an overview of the work to be done 123 by the working group, and describes the documents to be produced in 124 this effort. 126 1.2 Motivation 128 Network operators need the appropriate feature sets and tools on 129 their infrastructure devices to ensure that they can effectively 130 deploy and manage their networks securely while maintaining the 131 ability to provide reliable service to their customers. Vendors need 132 guidelines on which security features and functionality are critical 133 for operators to be able to reach that goal. 135 1.3 Threat Model 137 1.3.1 Threats Addressed, Threats Not Addressed 139 This section describes the general classes of threats that this work 140 intends to address. Specific threats and attacks will be discussed 141 in the documents which are referred to in this framework. Each of 142 those documents will enumerate the capabilities which are required to 143 mitigate the risk of these specific threats. 145 The intent is to address real-world threats to and attacks on network 146 infrastructure devices which have severely impacted network 147 operations or have immediate potential to do so. The intent is NOT 148 to build a complete theoretical threat model or list every possible 149 attack. 151 The threats will be limited to those that affect the management of 152 network infrastructure and its ability to transit traffic. Threats 153 to the confidentiality and integrity of transit traffic will not be 154 addressed. 156 1.3.2 Active, Passive and Combined Attacks 158 [RFC3552] describes a general Internet threat model which readers of 159 this document should be familiar with. It defines a threat model to 160 describes the capabilities that an attacker is assumed to be able to 161 deploy against a resource. [RFC3552] classifies attacks into two 162 main categories: passive attacks and active attacks. Passive attacks 163 are ones where an attacker simply reads information off the network 164 and obtains confidential and/or private information which can be used 165 to compromise network systems. Active attacks are ones where the 166 attacker writes data to the network and can include replay attacks, 167 message insertion, message deletion, message modification and 168 man-in-the-middle attacks. Often, these passive and active attacks 169 are combined. For example, routing information is diverted via a 170 man-in-the-middle attack to force confidential information to transit 171 a network path on which the attacker is able to perform 172 eavesdropping. 174 1.3.3 Categories of Threats 176 The following sections provide a model that can be used to further 177 categorize attacks on infrastructure devices and/or the operating 178 behavior of these devices, and also gives some examples of attacks 179 which fall into each classification. 181 It is common to categorize threats based on the effects or damage 182 caused by associated attacks. For example, threats generally fall 183 under one of the three categories as defined in [RFC2196]: 185 o Unauthorized access to resources and/or information 186 o Unintended and/or unauthorized disclosure of information 187 o Denial of service 189 There are a number of attacks, any one of which, if exploited, can 190 lead to any of the above mentioned threats. As one example, if an 191 intruder has taken control of a router (for example by guessing the 192 password) then he could potentially obtain unauthorized access to 193 resources, could gain unauthorized disclosure of information, and 194 could also deny service to legitimate users. This method of 195 categorizing threats based on the result of the threat therefore 196 results in categories which are orthogonal to the cause of the 197 effect, and thus orthogonal to the device capabilities which are 198 needed. 200 Categorization of attacks based on the capabilities required to mount 201 the attack will allow the analysis and description of the attacks to 202 be more closely aligned with the product capabilities required to 203 defeat or mitigate the attack. 205 1.3.4 Threat Sources 207 The sources of threats in an operational network take many forms. 208 Some sources can be intentional, such as a malicious intruder 209 actively gaining access to an unauthorized resource or causing a 210 denial of service attack. Other sources can be unintentional but 211 still render the network unusable, such as software bugs or 212 configuration mistakes. Many of the unintentional threat sources can 213 be difficult to recognize or prevent. However wherever possible, 214 capabilities and functionality will be defined which minimize the 215 extent of the damage done under these circumstances. 217 Threats can originate from outside or inside and can be due to 218 vulnerabilities in a device or weaknesses in operational processes. 219 Inside threats pertain to an authorized participant in the operation 220 of the network performing unauthorized actions. Outside threats 221 pertain to any unauthorized network devices or person causing havoc 222 with normal network operations. 224 On Path network devices are able to read, modify, or remove any 225 datagram transmitted along a given path. Off-path hosts can transmit 226 arbitrary datagrams that appear to come from any hosts but cannot 227 necessarily receive datagrams intended for other hosts. 229 1.4 Attacks 231 This section specifies attack categories based on the capabilities 232 required to mount the attack and provides more granular detail of 233 many of the identifiable and recognized threats to which network 234 infrastructure devices are susceptible. 236 1.4.1 Passive attacks 238 Passive attacks are ones where an attacker simply reads information 239 off the network and obtains confidential and/or private information 240 which can be used to compromise network systems. 242 1.4.2 Eavesdropping/Sniffing 244 The most common form of passive attack is eavesdropping, where the 245 attacker is able to read the data which is being transmitted from the 246 sender to the receiver. In any operational network, the entire data 247 path and every device involved in the data path must be considered 248 for this type of attack. Any information which could be used to 249 potentially gain unauthorized access to a device or is private must 250 be protected. This includes passwords, configuration files and log 251 files. It is common to think only of protecting the data path and to 252 make sure that data is not diverted along a different path which may 253 be easier to eavesdrop on, such as a wireless network. In many 254 instances it would be wise to consider cryptographically protecting 255 data confidentiality wherever sensitive information is involved. 257 1.4.3 Off-line Cryptographic Attacks 259 These attacks typically capture some data which has been 260 cryptographically protected and then use varying means to try and 261 recover the original data. Poor password protection protocols can 262 easily be reverse engineered and poorly chosen passwords can also be 263 easily deciphered. As described in [RFC3552], a number of popular 264 password-based challenge response protocols are vulnerable to a 265 dictionary attack. The attacker captures a challenge-response pair 266 and then proceeds to try entries from a list of common words (such as 267 a dictionary file) until he finds a password that produces the right 268 response. 270 1.4.4 Active Attacks 272 Active attacks are ones where the attacker writes data to the 273 network. Generally, any part of a data packet can be forged. When 274 the source IP address is forged, the attack is generally referred to 275 as a spoofing attack. These attacks can be mitigated by filtering 276 traffic based on IP addresses to only allow legitimate traffic 277 to/from a network. 279 Not all active attacks require forged addresses and most systems are 280 susceptible to a number of common attack patterns which are described 281 in the next sections. Note that any type of active attack can be 282 used for Denial of Service if the traffic is sent at such a rate that 283 it exceeds a networks link capacity or exhausts device resources. 285 1.4.5 Replay Attacks 287 A replay attack is a combination of a passive and an active attack. 288 In this type of attack, the attacker records some number of messages 289 off of the wire and then plays them back to the original recipient. 290 Note that the attacker does not need to be able to understand the 291 messages. He merely needs to capture and re-transmit them. 293 1.4.6 Message Insertion 295 In a message insertion attack, the attacker forges one or more 296 messages and injects them into the network. Often these messages 297 will have a forged source address in order to disguise the identity 298 of the attacker. 300 Message insertion attacks can be used to exploit known 301 vulnerabilities in protocol software. Routers and switches implement 302 protocols which in some cases make use of software which is well 303 known and widely deployed. Malicious attackers therefore may be 304 familiar with the protocol software and be able to exploit known 305 vulnerabilities. 307 1.4.7 Message Modification 309 In a message modification attack, the attacker removes a message from 310 the wire, modifies it, and then resends it. The contents of the 311 message may be modified and/or the intended recipient. [need example 312 specific to network operations where this would be harmful] 314 1.4.8 Message Deletion 316 In a message deletion attack, the attacker simply removes a message 317 from the wire. [need example specific to network operations where 318 this is harmful] 320 1.4.9 Man-In-The-Middle 322 A Man-In-The-Middle attack combines the above techniques in a special 323 form: The attacker subverts the communication stream in order to pose 324 as the sender to receiver and the receiver to the sender. This 325 differs fundamentally from the above forms of attack because it 326 attacks the identity of the communicating parties, rather than the 327 data stream itself. Consequently, many techniques which provide 328 integrity of the communications stream are insufficient to protect 329 against man-in-the-middle attacks. 331 Man-in-the-middle attacks are possible whenever peer entity 332 authentication is not used. For example, it is trivial to mount 333 man-in-the-middle attacks on local networks via ARP spoofing where 334 the attacker forges an ARP with the victim's IP address and his own 335 MAC address to gain access to a network. The attacker can then do 336 further damage by sending forged messages. Imagine if the victim^�s 337 IP address was that of a tftp server. The attacker could potentially 338 download invalid system images or configuration files to a network 339 device and subsequently compromise that network device. 341 [Ed. - Need to review existing capabilities. Do the threats and 342 attack types listed above cover them all ? Are there capabilities 343 that imply threats and attack classes not listed above] 345 1.5 Scope 347 The working group will produce a list of capabilities appropriate 348 for: 350 o Internet Service Provider (ISP) Networks 351 o Enterprise Networks 353 The following are explicitly out of scope: 355 o general purpose hosts that do not transit traffic including 356 infrastructure hosts such as name/time/log/AAA servers, etc., 357 o unmanaged devices, 358 o customer managed devices (e.g. firewalls, Intrusion Detection 359 System, dedicated VPN devices, etc.), 360 o SOHO (Small Office, Home Office) devices (e.g. personal 361 firewalls, Wireless Access Points, Cable Modems, etc.), 362 o confidentiality of customer data, 363 o integrity of customer data, 364 o physical security. 366 These limitations have been made to keep the amount of work and size 367 of documents manageable. While the capabilities listed here may 368 apply to systems outside the scope, no capabilities have been added 369 to account for their unique needs. 371 While the examples given are written with IPv4 in mind, most of the 372 capabilities are general enough to apply to IPv6. 374 1.6 Intended Audience 376 There are two intended audiences: the network operator who selects, 377 purchases, and operates IP network equipment, and the vendors who 378 create these devices. 380 1.7 Format and Definition of Capabilities 382 A separate document will be created for specific categories of 383 capabilities. Each individual capability will have the following 384 element: 386 Capability (what) 387 The capability describes a policy to be supported by the device. 389 For example, "The device MUST support secure channels that allow 390 in-band access to all management and configuration functions." 392 Capabilities should not refer to specific technologies. It is 393 expected that desired capability will change little over time. 395 Justification (why) 396 The justification tells why and in what context the capability is 397 important. 399 For example, "Secure channels are important because they insure 400 confidentiality, and integrity. This is important in contexts 401 where management is performed in-band over networks with 402 potentially hostile users." 404 The justification is intended to give operators information needed 405 to determine the applicability of a capability their local 406 environment. 408 Examples (how) 409 Examples are intended to give examples of technology and standards 410 current at the time of writing that implement the capability. 411 Examples of configuration and usage may also be given. 413 For example, "SSH provides access to management and configuration 414 functions via secure channels. One way to provide this capability 415 would be to enable SSH for in-band management and to disable all 416 insecure in-band management mechanisms (e.g. telnet, SNMPv1, 417 etc.)" 419 It is expected that the choice of implementations to provide the 420 capability will change over time. See [RFC3631] for a list of 421 some current mechanisms. 423 Warnings (if applicable) 424 The warnings list operational concerns, deviation from standards, 425 caveats, etc. 427 For example, "If SSH is chosen as the mechanism to provide secure 428 channels for remote management and configuration, then there are a 429 number of issues which must be considered including key 430 distribution and known vulnerabilities in various protocol 431 versions." 433 1.8 Applicability 435 These capabilities are intended to give guidance on how best to 436 protect communications infrastructure. Service Providers, Network 437 Operators, and Equipment Suppliers are encouraged to study these 438 capabilities, and prioritize the extent and manner in which they may 439 implement and/or deploy equipment supporting these capabilities. 441 Decisions of whether or not to support a specific capabilities are 442 intended to be left with the responsible organization (e.g., Service 443 Provider, Network Operator, or Equipment Supplier). Due to the 444 continuously evolving nature of security threats to networks, and due 445 to significant variations in the specific security threats and 446 requirements in different network environments, it is not appropriate 447 to mandate implementation of these capabilities through legislation 448 or regulation, nor would any mandate be consistent with their intent. 450 1.9 Intended Use 452 It is anticipated that the capabilities in these documents will be 453 used for the following purposes: 454 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, 458 o to assist operators in clearly communicating their security 459 requirements, 460 o as high level guidance for the creation of detailed test plans. 461 o as guidance for vendors to make appropriate decisions for 462 engineering feature roadmaps. 464 1.10 Definitions 465 RFC 2119 Keywords 466 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 467 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 468 in this document are to be interpreted as described in [RFC2119]. 470 NOTE: The following definitions are take from RFC3871. Unless 471 otherwise stated, the working group documents will use these terms as 472 defined below. 474 Bogon. 475 A "Bogon" (plural: "bogons") is a packet with an IP source address 476 in an address block not yet allocated by IANA or the Regional 477 Internet Registries (ARIN, RIPE, APNIC...) as well as all 478 addresses reserved for private or special use by RFCs. See 479 [RFC3330] and [RFC1918]. 480 CLI. 481 Several capabilities refer to a Command Line Interface (CLI). 482 While this refers at present to a classic text oriented command 483 interface, it is not intended to preclude other mechanisms which 484 may provide all the capabilities that reference "CLI". 485 Console. 486 Several capabilities refer to a "Console". The model for this is 487 the classic RS232 serial port which has, for the past 30 or more 488 years, provided a simple, stable, reliable, well-understood and 489 nearly ubiquitous management interface to network devices. Again, 490 these capabilities are intended primarily to codify the benefits 491 provided by that venerable interface, not to preclude other 492 mechanisms that provide the same capabilities. 493 Filter. 494 In this document, a "filter" is defined as a group of one or more 495 rules where each rule specifies one or more match criteria. 496 In-Band management. 497 "In-Band management" is defined as any management done over the 498 same channels and interfaces used for user/customer data. 499 Examples would include using SSH for management via customer or 500 Internet facing network interfaces. 501 High Resolution Time. 502 "High resolution time" is defined in this document as "time having 503 a resolution greater than one second" (e.g. milliseconds). 504 IP. 505 Unless otherwise indicated, "IP" refers to IPv4. 506 Management. 507 This document uses a broad definition of the term "management". 508 In this document, "management" refers to any authorized 509 interaction with the device intended to change its operational 510 state or configuration. Data/Forwarding plane functions (e.g. 511 the transit of customer traffic) are not considered management. 512 Control plane functions such as routing, signaling and link 513 management protocols and management plane functions such as remote 514 access, configuration and authentication are considered to be 515 management. 516 Martian. 518 Per [RFC1208] "Martian: Humorous term applied to packets that turn 519 up unexpectedly on the wrong network because of bogus routing 520 entries. Also used as a name for a packet which has an altogether 521 bogus (non-registered or ill-formed) Internet address." For the 522 purposes of this document Martians are defined as "packets having 523 a source address that, by application of the current forwarding 524 tables, would not have its return traffic routed back to the 525 sender." "Spoofed packets" are a common source of martians. 526 Note that in some cases, the traffic may be asymmetric, and a 527 simple forwarding table check might produce false positives. See 528 [RFC3704] 529 Out-of-Band (OoB) management. 530 "Out-of-Band management" is defined as any management done over 531 channels and interfaces that are separate from those used for 532 user/customer data. Examples would include a serial console 533 interface or a network interface connected to a dedicated 534 management network that is not used to carry customer traffic. 535 Open Review. 537 "Open review" refers to processes designed to generate public 538 discussion and review of technical solutions such as data 539 communications protocols and cryptographic algorithms with the 540 goals of improving and building confidence in the final solutions. 541 For the purposes of this document "open review" is defined by 542 [RFC2026]. All standards track documents are considered to have 543 been through an open review process. 544 It should be noted that organizations may have local requirements 545 that define what they view as acceptable "open review". For 546 example, they may be required to adhere to certain national or 547 international standards. Such modifications of the definition of 548 the term "open review", while important, are considered local 549 issues that should be discussed between the organization and the 550 vendor. 551 It should also be noted that section 7 of [RFC2026] permits 552 standards track documents to incorporate other "external standards 553 and specifications". 554 Service. 555 A number of capabilities refer to "services". For the purposes of 556 this document a "service" is defined as "any process or protocol 557 running in the control or management planes to which non-transit 558 packets may be delivered". Examples might include an SSH server, 559 a BGP process or an NTP server. It would also include the 560 transport, network and link layer protocols since, for example, a 561 TCP packet addressed to a port on which no service is listening 562 will be "delivered" to the IP stack, and possibly result in an 563 ICMP message being sent back. 564 Secure Channel. 565 A "secure channel" is a mechanism that ensures end-to-end 566 integrity and confidentiality of communications. Examples include 567 TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a 568 console port using physically secure, shielded cable would provide 569 confidentiality but possibly not integrity. 570 Single-Homed Network. 571 A "single-homed network" is defined as one for which 572 * There is only one upstream connection 573 * Routing is symmetric. 574 See [RFC3704] for a discussion of related issues and mechanisms 575 for multi-homed networks. 576 Spoofed Packet. 577 A "spoofed packet" is defined as a packet that has a source 578 address that does not correspond to any address assigned to the 579 system which sent the packet. Spoofed packets are often "bogons" 580 or "martians". 581 Secure Network 582 For the purposes of these documents, a secure network is one in 583 which: 584 * The network keeps passing legitimate customer traffic 585 (availability). 586 * Traffic goes where it is supposed to go, and only where it is 587 supposed to go (availability, confidentiality). 588 * The network elements remain manageable (availability). 589 * Only authorized users can manage network elements 590 (authorization). 591 * There is a record of all security related events 592 (accountability). 593 * The network operator has the necessary tools to detect and 594 respond to illegitimate traffic. 596 2. Documents 598 [Ed. This list of documents is likely to be consolidated/reduced] 600 The following is a list of documents to be produced by OPSEC working 601 group. Each document is intended to cover an area important to 602 secure operation of large network infrastructure. 604 2.1 Standards Survey (info) 605 Overview 606 This document provides an overview of other efforts in developing 607 standards, guidelines, best practices, or other information 608 intended to facilitate improvement in network security. Any 609 effort which is known, such as the ANSI T1.276, the NRIC V "Best 610 Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing 611 signalling will be included. The intent is to provide a clear 612 understanding of which efforts are complementary and/or 613 contradictory such that any efforts of future cross-certification 614 of standards may be facilitated. 615 Security Considerations 616 Many contradictory security requirements from varying standards 617 bodies would seriously impact operator or vendor understanding of 618 which features and functionalities are the most effective to 619 deploy and operate secure networks. This documented survey will 620 help to ensure that there is a consistent set of product 621 requirements to follow. 623 2.2 In-Band management capabilities (BCP) 624 Overview 625 Although there are known security issues with in-band management, 626 there are many situations where in-band management makes sense, is 627 used, and/or is the only option. The features recommended in this 628 document will provide for a more secure means of using any in-band 629 management functionality. 630 Security Considerations 631 Although in-band management has the advantage of lower cost (no 632 extra interfaces or lines), it has significant security 633 disadvantages: 634 * Saturation of customer lines or interfaces can make the device 635 unmanageable unless out-of-band management resources have been 636 reserved 637 * Since public interfaces/channels are used, it is possible for 638 attackers to directly address and reach the device and to 639 attempt management functions. 640 * In-band management traffic on public interfaces may be 641 intercepted, however this would typically require a significant 642 compromise in the routing system. 644 * Public interfaces used for in-band management may become 645 unavailable due to bugs (e.g. buffer overflows being 646 exploited) while out-of-band interfaces (such as a serial 647 console device) remain available 648 The capabilities from this document are meant to provide the means 649 of securing in-band management traffic. 651 2.3 Out-of-Band management capabilities (BCP) 652 Overview 653 This document will describe capabilities related to out of band 654 management of networked devices. 655 Security Considerations 656 Out-of-band management often provides a more secure means of 657 managing networked devices. To ensure that all devices have the 658 appropriate support, this document will list capabilities as to 659 what functionality is needed to effectively use out-of-band 660 management. 662 2.4 Filtering capabilities (BCP) 663 Overview 664 This document will describe capabilities related to stateless 665 filtering for network elements providing transit service at link 666 and transport layers. 667 Security Considerations 668 Filtering is an important security functionality to permit or deny 669 forwarding of traffic, or to specify special treatment of packets, 670 depending on layer 2 or layer 3 header and forwarding information. 671 It provides a basic means of implementing policies, such as 672 policies that specify which traffic is allowed and which is not, 673 and policies which specify special treatment such as setting CoS, 674 rate limiting, or packet copying. It also provides a basic tool 675 for responding to malicious traffic. 677 2.5 Event Logging Capabilities document (BCP) 678 Overview 679 [Ed. The basic questions here are "what gets logged", "how does 680 it get logged", "what are the security issues". There is work in 681 progress (syslog) for the last two that can be cited. The "what 682 gets logged" question needs work] 683 This document will describe the recommended features when logging 684 network device traffic and anomalies. The goal is to make it 685 possible to correlate logging information from varying systems and 686 making sure that logged information is useful and effective. 687 Security Considerations 688 Logging data provides a means for detecting malicious behavior. 689 The logged information can also be used as evidence in legal 690 prosecution cases against illegal network access and device 691 compromises. Ineffective logging practices due to inconsistent 692 functionality in many devices make it hard to get effective data. 693 This document will help provide consistent logging functionality 694 for more effective auditing. It will also point to privacy or 695 legal considerations when logging/monitoring user activity. 697 2.6 Configuration and Management Interface Capabilities (BCP) 698 Overview 699 This document lists the security capabilities necessary for 700 interfaces which allow for configuring and managing the network 701 device. In most cases, this currently involves some sort of 702 command line interface (CLI) and configuration files. It may be 703 possible to provide the capabilities with other mechanisms, for 704 instance SNMP or a script-able HTML interface that provides full 705 access to management and configuration functions. In the future, 706 there may be others (e.g. XML based configuration). 707 Security Considerations 708 The interfaces used to manage and configure network elements need 709 to be effectively secured to avoid a malicious user from being 710 able to logically gain illegal access. In the past, many security 711 vulnerabilities have been discovered, especially with SNMP and 712 HTTP access to devices. These recommendations will help the user 713 and vendor community mitigate any known risks in this area. 715 2.7 AAA capabilities document (BCP) 716 Overview 717 This document will list the capabilities needed for centralized 718 authentication, authorization and accounting functionality. 719 Security Considerations 720 Keeping track of who has access to network devices is critical to 721 any secure infrastructure. Mechanisms to provide authorized 722 access upon successful authentication and also keeping track of 723 what was done can provide important information in case of a 724 device compromise. 726 2.8 Documentation and Assurance capabilities document (BCP) 727 Overview 728 These capabilities will list information which should be 729 documented that will assist operators in evaluating and securely 730 operating a device. 731 Security Considerations 732 Devices many times have default behavior which can cause a severe 733 security vulnerability. Knowing which services are enabled by 734 default or which commands impact other default behavior is 735 essential knowledge that is necessary to effectively mitigate 736 security risks. 738 2.9 Miscellaneous capabilities document (BCP) 739 Overview 740 This document will describe capabilities which do not fit into any 741 of the other documents, and which are brief enough that they don't 742 justify their own document, but which are important enough that 743 they should be documented. 745 2.10 Large ISP Operational Security Capabilities Profile (info) 746 Overview 747 This document will provide a profile specifying which of the 748 capabilities outlined in the set of documents described above are 749 most applicable to large Internet Service Providers offering 750 transit service. 752 2.11 Large Enterprise Operational Security Capabilities Profile (info) 753 Overview 754 This document will provide a profile specifying which of the 755 capabilities outlined in the set of documents described above are 756 most applicable to large Enterprise networks. 758 2.12 OPSEC Deliberation Summary document (info) 759 Overview 760 This document will provide a summary of discussions that have 761 taken place within the OPsec working group. The intent is to 762 document ideas that were "left on the cutting room floor" in order 763 to provide a possible starting point for future work. 765 3. Security Considerations 767 Security is the entire focus of this document. 769 4 Normative References 771 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 772 RFC 1208, March 1991. 774 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 775 E. Lear, "Address Allocation for Private Internets", BCP 776 5, RFC 1918, February 1996. 778 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 779 3", BCP 9, RFC 2026, October 1996. 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, March 1997. 784 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 785 1997. 787 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 788 RFC 2246, January 1999. 790 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 791 Internet Protocol", RFC 2401, November 1998. 793 [RFC3013] Killalea, T., "Recommended Internet Service Provider 794 Security Services and Procedures", BCP 46, RFC 3013, 795 November 2000. 797 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 798 2002. 800 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 801 Text on Security Considerations", BCP 72, RFC 3552, July 802 2003. 804 [RFC3631] Bellovin, S., Schiller, J. and C. Kaufman, "Security 805 Mechanisms for the Internet", RFC 3631, December 2003. 807 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 808 Networks", BCP 84, RFC 3704, March 2004. 810 [RFC3871] Jones, G., "Operational Security Requirements for Large 811 Internet Service Provider (ISP) IP Network 812 Infrastructure", RFC 3871, September 2004. 814 Authors' Addresses 816 George M. Jones 817 The MITRE Corporation 818 7515 Colshire Drive, M/S WEST 819 McLean, Virginia 22102-7508 820 U.S.A. 822 Phone: +1 703 488 9740 823 EMail: gmjones@mitre.org 825 Ross Callon 826 Juniper Networks 827 10 Technology Park Drive 828 Westford, MA 01886 829 U.S.A. 831 Phone: +1 978 692 6724 832 EMail: rcallon@juniper.net 834 Merike Kaeo 835 Double Shot Security 836 520 Washington Blvd. #363 837 Marina Del Rey, CA 90292 838 U.S.A. 840 Phone: +1 310 866 0165 841 EMail: kaeo@merike.com 843 Appendix A. Acknowledgments 845 The authors gratefully acknowledge the contributions of: 846 o Acknowledgments to be determined. 847 o The MITRE Corporation for supporting development of this document. 848 NOTE: The author's affiliation with The MITRE Corporation is 849 provided for identification purposes only, and is not intended to 850 convey or imply MITRE's concurrence with, or support for, the 851 positions, opinions or viewpoints expressed by the editor. 852 o This listing is intended to acknowledge contributions, not to 853 imply that the individual or organizations approve the content of 854 this document. 855 o Apologies to those who commented on/contributed to the document 856 and were not listed. 858 Intellectual Property Statement 860 The IETF takes no position regarding the validity or scope of any 861 Intellectual Property Rights or other rights that might be claimed to 862 pertain to the implementation or use of the technology described in 863 this document or the extent to which any license under such rights 864 might or might not be available; nor does it represent that it has 865 made any independent effort to identify any such rights. Information 866 on the procedures with respect to rights in RFC documents can be 867 found in BCP 78 and BCP 79. 869 Copies of IPR disclosures made to the IETF Secretariat and any 870 assurances of licenses to be made available, or the result of an 871 attempt made to obtain a general license or permission for the use of 872 such proprietary rights by implementers or users of this 873 specification can be obtained from the IETF on-line IPR repository at 874 http://www.ietf.org/ipr. 876 The IETF invites any interested party to bring to its attention any 877 copyrights, patents or patent applications, or other proprietary 878 rights that may cover technology that may be required to implement 879 this standard. Please address the information to the IETF at 880 ietf-ipr@ietf.org. 882 Disclaimer of Validity 884 This document and the information contained herein are provided on an 885 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 886 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 887 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 888 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 889 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 890 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 892 Copyright Statement 894 Copyright (C) The Internet Society (2004). This document is subject 895 to the rights, licenses and restrictions contained in BCP 78, and 896 except as set forth therein, the authors retain all their rights. 898 Acknowledgment 900 Funding for the RFC Editor function is currently provided by the 901 Internet Society.