idnits 2.17.1 draft-jones-opsec-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 86 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 2 instances of lines with control characters in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 525 has weird spacing: '...In-band manag...' == Line 998 has weird spacing: '...ts that suppo...' == Line 1209 has weird spacing: '...ew code from ...' == Line 1615 has weird spacing: '...nfected serve...' == Line 1708 has weird spacing: '...filters that ...' == (3 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (April 21, 2004) is 7309 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 1321 ** Downref: Normative reference to an Informational RFC: RFC 1492 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1704 ** Downref: Normative reference to an Informational RFC: RFC 2196 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3164 (Obsoleted by RFC 5424) ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Downref: Normative reference to an Informational RFC: RFC 3410 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 3562 ** Downref: Normative reference to an Informational RFC: RFC 3579 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Downref: Normative reference to an Informational RFC: RFC 3631 Summary: 22 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 None. G. Jones, Editor 2 Internet-Draft The MITRE Corporation 3 Expires: October 20, 2004 April 21, 2004 5 Operational Security Requirements for Large ISP IP Network 6 Infrastructure 7 draft-jones-opsec-06 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on October 20, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines a list of operational security requirements for 38 the infrastructure of large ISP IP networks (routers and switches). 39 A framework is defined for specifying "profiles", which are 40 collections of requirements applicable to certain network topology 41 contexts (all, core-only, edge-only...). The goal is to provide 42 network operators a clear, concise way of communicating their 43 security requirements to vendors. 45 CAVEAT LECTOR ("let the reader beware"). This document is not 46 normative. It is not a standard. It is not the product of a working 47 group. It is an attempt, by the editor, to collect, order and 48 publish a list of security requirements useful to both vendors and 49 network operators. The use of the RFC 2119 keywords is an attempt, 50 by the editor, to assign the correct requirement levels ("MUST", 51 "SHOULD", "MAY"...). It must be noted that different organizations, 52 operational environments, policies and legal environments will 53 generate different requirement levels. Operators and vendors should 54 carefully consider the individual requirements listed here in their 55 own context. One size does not fit all. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.4 Definition of a Secure Network . . . . . . . . . . . . . . 6 64 1.5 Intended Audience . . . . . . . . . . . . . . . . . . . . 6 65 1.6 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1.7 Intended Use . . . . . . . . . . . . . . . . . . . . . . . 7 67 1.8 Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 68 2. Functional Requirements . . . . . . . . . . . . . . . . . 12 69 2.1 Device Management Requirements . . . . . . . . . . . . . . 12 70 2.1.1 Support Secure Channels For Management . . . . . . . . . . 12 71 2.2 In-Band Management Requirements . . . . . . . . . . . . . 12 72 2.2.1 Use Cryptographic Algorithms Subject To Open Review . . . 13 73 2.2.2 Use Strong Cryptography . . . . . . . . . . . . . . . . . 14 74 2.2.3 Use Protocols Subject To Open Review For Management . . . 15 75 2.2.4 Allow Selection of Cryptographic Parameters . . . . . . . 16 76 2.2.5 Management Functions Should Have Increased Priority . . . 16 77 2.3 Out-of-Band (OoB) Management Requirements . . . . . . . . 17 78 2.3.1 Support a 'Console' Interface . . . . . . . . . . . . . . 18 79 2.3.2 'Console' Communication Profile Must Support Reset . . . . 20 80 2.3.3 'Console' Requires Minimal Functionality of Attached 81 Devices. . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 2.3.4 'Console' Supports Fall-back Authentication . . . . . . . 21 83 2.3.5 Support Separate Management Plane IP Interfaces . . . . . 21 84 2.3.6 No Forwarding Between Management Plane And Other 85 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 22 86 2.4 Configuration and Management Interface Requirements . . . 23 87 2.4.1 'CLI' Provides Access to All Configuration and 88 Management Functions . . . . . . . . . . . . . . . . . . . 23 89 2.4.2 'CLI' Supports Scripting of Configuration . . . . . . . . 24 90 2.4.3 'CLI' Supports Management Over 'Slow' Links . . . . . . . 24 91 2.4.4 'CLI' Supports Idle Session Timeout . . . . . . . . . . . 25 92 2.4.5 Support Software Installation . . . . . . . . . . . . . . 26 93 2.4.6 Support Remote Configuration Backup . . . . . . . . . . . 27 94 2.4.7 Support Remote Configuration Restore . . . . . . . . . . . 28 95 2.4.8 Support Text Configuration Files . . . . . . . . . . . . . 29 96 2.5 IP Stack Requirements . . . . . . . . . . . . . . . . . . 30 97 2.5.1 Ability to Identify All Listening Services . . . . . . . . 30 98 2.5.2 Ability to Disable Any and All Services . . . . . . . . . 31 99 2.5.3 Ability to Control Service Bindings for Listening 100 Services . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 2.5.4 Ability to Control Service Source Addresses . . . . . . . 32 102 2.5.5 Support Automatic Anti-spoofing for Single-Homed 103 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 2.5.6 Support Automatic Discarding Of Bogons and Martians . . . 34 105 2.5.7 Support Counters For Dropped Packets . . . . . . . . . . . 35 106 2.6 Rate Limiting Requirements . . . . . . . . . . . . . . . . 35 107 2.6.1 Support Rate Limiting . . . . . . . . . . . . . . . . . . 35 108 2.6.2 Support Directional Application Of Rate Limiting Per 109 Interface . . . . . . . . . . . . . . . . . . . . . . . . 36 110 2.6.3 Support Rate Limiting Based on State . . . . . . . . . . . 37 111 2.7 Basic Filtering Capabilities . . . . . . . . . . . . . . . 37 112 2.7.1 Ability to Filter Traffic . . . . . . . . . . . . . . . . 37 113 2.7.2 Ability to Filter Traffic TO the Device . . . . . . . . . 38 114 2.7.3 Ability to Filter Traffic THROUGH the Device . . . . . . . 38 115 2.7.4 Ability to Filter Without Significant Performance 116 Degradation . . . . . . . . . . . . . . . . . . . . . . . 39 117 2.7.5 Support Route Filtering . . . . . . . . . . . . . . . . . 40 118 2.7.6 Ability to Specify Filter Actions . . . . . . . . . . . . 40 119 2.7.7 Ability to Log Filter Actions . . . . . . . . . . . . . . 41 120 2.8 Packet Filtering Criteria . . . . . . . . . . . . . . . . 42 121 2.8.1 Ability to Filter on Protocols . . . . . . . . . . . . . . 42 122 2.8.2 Ability to Filter on Addresses . . . . . . . . . . . . . . 42 123 2.8.3 Ability to Filter on Protocol Header Fields . . . . . . . 43 124 2.8.4 Ability to Filter Inbound and Outbound . . . . . . . . . . 44 125 2.9 Packet Filtering Counter Requirements . . . . . . . . . . 44 126 2.9.1 Ability to Accurately Count Filter Hits . . . . . . . . . 44 127 2.9.2 Ability to Display Filter Counters . . . . . . . . . . . . 45 128 2.9.3 Ability to Display Filter Counters per Rule . . . . . . . 45 129 2.9.4 Ability to Display Filter Counters per Filter 130 Application . . . . . . . . . . . . . . . . . . . . . . . 46 131 2.9.5 Ability to Reset Filter Counters . . . . . . . . . . . . . 47 132 2.9.6 Filter Counters Must Be Accurate . . . . . . . . . . . . . 47 133 2.10 Other Packet Filtering Requirements . . . . . . . . . . . 48 134 2.10.1 Ability to Specify Filter Log Granularity . . . . . . . . 48 135 2.11 Event Logging Requirements . . . . . . . . . . . . . . . . 49 136 2.11.1 Logging Facility Uses Protocols Subject To Open Review . . 49 137 2.11.2 Logs Sent To Remote Servers . . . . . . . . . . . . . . . 49 138 2.11.3 Ability to Select Reliable Delivery . . . . . . . . . . . 50 139 2.11.4 Ability to Log Locally . . . . . . . . . . . . . . . . . . 51 140 2.11.5 Ability to Maintain Accurate System Time . . . . . . . . . 51 141 2.11.6 Display Timezone And UTC Offset . . . . . . . . . . . . . 52 142 2.11.7 Default Timezone Should Be UTC . . . . . . . . . . . . . . 53 143 2.11.8 Logs Must Be Timestamped . . . . . . . . . . . . . . . . . 53 144 2.11.9 Logs Contain Untranslated IP Addresses . . . . . . . . . . 54 145 2.11.10 Logs Contain Records Of Security Events . . . . . . . . . 55 146 2.11.11 Logs Do Not Contain Passwords . . . . . . . . . . . . . . 56 147 2.12 Authentication, Authorization, and Accounting (AAA) 148 Requirements . . . . . . . . . . . . . . . . . . . . . . . 56 149 2.12.1 Authenticate All User Access . . . . . . . . . . . . . . . 56 150 2.12.2 Support Authentication of Individual Users . . . . . . . . 57 151 2.12.3 Support Simultaneous Connections . . . . . . . . . . . . . 57 152 2.12.4 Ability to Disable All Local Accounts . . . . . . . . . . 58 153 2.12.5 Support Centralized User Authentication Methods . . . . . 59 154 2.12.6 Support Local User Authentication Method . . . . . . . . . 59 155 2.12.7 Support Configuration of Order of Authentication 156 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 60 157 2.12.8 Ability To Authenticate Without Plaintext Passwords . . . 61 158 2.12.9 No Default Passwords . . . . . . . . . . . . . . . . . . . 61 159 2.12.10 Passwords Must Be Explicitly Configured Prior To Use . . . 62 160 2.12.11 Ability to Define Privilege Levels . . . . . . . . . . . . 62 161 2.12.12 Ability to Assign Privilege Levels to Users . . . . . . . 63 162 2.12.13 Default Privilege Level Must Be 'None' . . . . . . . . . . 64 163 2.12.14 Change in Privilege Levels Requires Re-Authentication . . 64 164 2.12.15 Support Recovery Of Privileged Access . . . . . . . . . . 65 165 2.13 Layer 2 Devices Must Meet Higher Layer Requirements . . . 66 166 2.14 Security Features Must Not Cause Operational Problems . . 67 167 2.15 Security Features Should Have Minimal Performance 168 Impact . . . . . . . . . . . . . . . . . . . . . . . . . . 67 169 3. Documentation Requirements . . . . . . . . . . . . . . . . 69 170 3.1 Identify Services That May Be Listening . . . . . . . . . 69 171 3.2 Document Service Defaults . . . . . . . . . . . . . . . . 69 172 3.3 Document Service Activation Process . . . . . . . . . . . 70 173 3.4 Document Command Line Interface . . . . . . . . . . . . . 70 174 3.5 'Console' Default Communication Profile Documented . . . . 71 175 4. Assurance Requirements . . . . . . . . . . . . . . . . . . 72 176 4.1 Identify Origin of IP Stack . . . . . . . . . . . . . . . 72 177 4.2 Identify Origin of Operating System . . . . . . . . . . . 72 178 5. Security Considerations . . . . . . . . . . . . . . . . . 74 179 Normative References . . . . . . . . . . . . . . . . . . . 75 180 Non-normative References . . . . . . . . . . . . . . . . . 78 181 Author's Address . . . . . . . . . . . . . . . . . . . . . 78 182 A. Requirement Profiles . . . . . . . . . . . . . . . . . . . 79 183 A.1 Minimum Requirements Profile . . . . . . . . . . . . . . . 79 184 A.2 Layer 3 Network Edge Profile . . . . . . . . . . . . . . . 82 185 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 84 186 Intellectual Property and Copyright Statements . . . . . . 85 188 1. Introduction 190 1.1 Goals 192 This document defines a list of operational security requirements for 193 the infrastructure of large IP networks (routers and switches). The 194 goal is to provide network operators a clear, concise way of 195 communicating their security requirements to equipment vendors. 197 1.2 Motivation 199 Network operators need tools to ensure that they are able to manage 200 their networks securely and to insure that they maintain the ability 201 to provide service to their customers. Some of the threats are 202 outlined in section 3.2 of [RFC2196]. This document enumerates 203 features which are required to implement many of the policies and 204 procedures suggested by [RFC2196] in the context of the 205 infrastructure of large IP-based networks. Also see [RFC3013]. 207 1.3 Scope 209 The scope of these requirements is intended to cover the managed 210 infrastructure of large ISP IP networks (e.g. routers and switches). 211 Certain groups (or "profiles", see below) apply only in specific 212 situations (e.g. edge-only). 214 The following are explicitly out of scope: 216 o general purpose hosts that do not transit traffic including 217 infrastructure hosts such as name/time/log/AAA servers, etc., 219 o unmanaged devices, 221 o customer managed devices (e.g. firewalls, Intrusion Detection 222 System, dedicated VPN devices, etc.), 224 o SOHO (Small Office, Home Office) devices (e.g. personal firewalls, 225 Wireless Access Points, Cable Modems, etc.), 227 o confidentiality of customer data, 229 o integrity of customer data, 231 o physical security. 233 This means that while the requirements in the minimum profile (and 234 others) may apply, additional requirements have not be added to 235 account for their unique needs. 237 While the examples given are written with IPv4 in mind, most of the 238 requirements are general enough to apply to IPv6. 240 1.4 Definition of a Secure Network 242 For the purposes of this document, a secure network is one in which: 244 o The network keeps passing legitimate customer traffic 245 (availability). 247 o Traffic goes where it is supposed to go, and only where it is 248 supposed to go (availability, confidentiality). 250 o The network elements remain manageable (availability). 252 o Only authorized users can manage network elements (authorization). 254 o There is a record of all security related events (accountability). 256 o The network operator has the necessary tools to detect and respond 257 to illegitimate traffic. 259 1.5 Intended Audience 261 There are two intended audiences: the network operator who selects, 262 purchases, and operates IP network equipment, and the vendors who 263 create them. 265 1.6 Format 267 The individual requirements are listed in one of the three sections 268 listed below. 270 o Section 2 lists functional requirements. 272 o Section 3 lists documentation requirements. 274 o Section 4 lists assurance requirements. 276 Within these areas, requirements are grouped in major functional 277 areas (e.g., logging, authentication, filtering, etc.) 279 Each requirement has the following subsections: 281 o Requirement (what) 283 o Justification (why) 284 o Examples (how) 286 o Warnings (if applicable) 288 The requirement describes a policy to be supported by the device. The 289 justification tells why and in what context the requirement is 290 important. The examples section is intended to give examples of 291 implementations that may meet the requirement. Examples cite 292 technology and standards current at the time of this writing. See 293 [RFC3631]. It is expected that the choice of implementations to meet 294 the requirements will change over time. The warnings list operational 295 concerns, deviation from standards, caveats, etc. 297 Security requirements will vary across different device types and 298 different organizations, depending on policy and other factors. A 299 desired feature in one environment may be a requirement in another. 300 Classifications must be made according to local need. 302 In order to assist in classification, Appendix A defines several 303 requirement "profiles" for different types of devices. Profiles are 304 concise lists of requirements that apply to certain classes of 305 devices. The profiles in this document should be reviewed to 306 determine if they are appropriate to the local environment. 308 1.7 Intended Use 310 It is anticipated that the requirements in this document will be used 311 for the following purposes: 313 o as a checklist when evaluating networked products, 315 o to create profiles of different subsets of the requirements which 316 describe the needs of different devices, organizations, and 317 operating environments, 319 o to assist operators in clearly communicating their security 320 requirements, 322 o as high level guidance for the creation of detailed test plans. 324 1.8 Definitions 326 RFC 2119 Keywords 328 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 329 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 330 in this document are to be interpreted as described in [RFC2119]. 332 The use of the RFC 2119 keywords is an attempt, by the editor, to 333 assign the correct requirement levels ("MUST", "SHOULD", 334 "MAY"...). It must be noted that different organizations, 335 operational environments, policies and legal environments will 336 generate different requirement levels. Operators and vendors 337 should carefully consider the individual requirements listed here 338 in their own context. One size does not fit all. 340 Bogon. 342 A "Bogon" (plural: "bogons") is a packet with an IP source address 343 in an address block not yet allocated by IANA or the Regional 344 Internet Registries (ARIN, RIPE, APNIC...) as well as all 345 addresses reserved for private or special use by RFCs. See 346 [RFC3330] and [RFC1918]. 348 CLI. 350 Several requirements refer to a Command Line Interface (CLI). 351 While this refers at present to a classic text oriented command 352 interface, it is not intended to preclude other mechanisms which 353 may meet all the requirements that reference "CLI". 355 Console. 357 Several requirements refer to a "Console". The model for this is 358 the classic RS232 serial port which has, for the past 30 or more 359 years, provided a simple, stable, reliable, well-understood and 360 nearly ubiquitous management interface to network devices. Again, 361 these requirements are intended primarily to codify the benefits 362 provided by that venerable interface, not to preclude other 363 mechanisms that meet all the same requirements. 365 Filter. 367 In this document, a "filter" is defined as a group of one or more 368 rules where each rule specifies one or more match criteria as 369 specified in Section 2.8. 371 In-Band management. 373 "In-Band management" is defined as any management done over the 374 same channels and interfaces used for user/customer data. Examples 375 would include using SSH for management via customer or Internet 376 facing network interfaces. 378 High Resolution Time. 380 "High resolution time" is defined in this document as "time having 381 a resolution greater than one second" (e.g. milliseconds). 383 IP. 385 Unless otherwise indicated, "IP" refers to IPv4. 387 Management. 389 This document uses a broad definition of the term "management". 390 In this document, "management" refers to any authorized 391 interaction with the device intended to change its operational 392 state or configuration. Data/Forwarding plane functions (e.g. the 393 transit of customer traffic) are not considered management. 394 Control plane functions such as routing, signaling and link 395 management protocols and management plane functions such as remote 396 access, configuration and authentication are considered to be 397 management. 399 Martian. 401 Per [RFC1208] "Martian: Humorous term applied to packets that turn 402 up unexpectedly on the wrong network because of bogus routing 403 entries. Also used as a name for a packet which has an altogether 404 bogus (non-registered or ill-formed) Internet address." For the 405 purposes of this document Martians are defined as "packets having 406 a source address that, by application of the current forwarding 407 tables, would not have its return traffic routed back to the 408 sender." "Spoofed packets" are a common source of martians. 410 Note that in some cases, the traffic may be asymmetric, and a 411 simple forwarding table check might produce false positives. See 412 [I-D.savola-bcp38-multihoming-update] 414 Out-of-Band (OoB) management. 416 "Out-of-Band management" is defined as any management done over 417 channels and interfaces that are separate from those used for 418 user/customer data. Examples would include a serial console 419 interface or a network interface connected to a dedicated 420 management network that is not used to carry customer traffic. 422 Open Review. 424 "Open review" refers to processes designed to generate public 425 discussion and review of proposed technical solutions such as data 426 communications protocols and cryptographic algorithms with the 427 goals of improving and building confidence in the final solutions. 429 For the purposes of this document "open review" is defined by 430 [RFC2026]. All standards track documents are considered to have 431 been through an open review process. 433 It should be noted that organizations may have local requirements 434 that define what they view as acceptable "open review". For 435 example, they may be required to adhere to certain national or 436 international standards. Such modifications of the definition of 437 the term "open review", while important, are considered local 438 issues that should be discussed between the organization and the 439 vendor. 441 It should also be noted that section 7 of [RFC2026] permits 442 standards track documents to incorporate other "external standards 443 and specifications". 445 Service. 447 A number of requirements refer to "services". For the purposes of 448 this document a "service" is defined as "any process or protocol 449 running in the control or management planes to which non-transit 450 packets may be delivered". Examples might include an SSH server, 451 a BGP process or an NTP server. It would also include the 452 transport, network and link layer protocols since, for example, a 453 TCP packet addressed to a port on which no service is listening 454 will be "delivered" to the IP stack, and possibly result in an 455 ICMP message being sent back. 457 Secure Channel. 459 A "secure channel" is a mechanism that ensures end-to-end 460 integrity and confidentiality of communications. Examples include 461 TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a 462 console port using physically secure, shielded cable would provide 463 confidentiality but possibly not integrity. 465 Single-Homed Network. 467 A "single-homed network" is defined as one for which 469 * There is only one upstream connection 470 * Routing is symmetric. 472 See [I-D.savola-bcp38-multihoming-update] for a discussion of 473 related issues and mechanisms for multihomed networks. 475 Spoofed Packet. 477 A "spoofed packet" is defined as a packet that has a source 478 address that does not correspond to any address assigned to the 479 system which sent the packet. Spoofed packets are often "bogons" 480 or "martians". 482 2. Functional Requirements 484 The requirements in this section are intended to list testable, 485 functional requirements that are needed to operate devices securely. 487 2.1 Device Management Requirements 489 2.1.1 Support Secure Channels For Management 491 Requirement. 493 The device MUST provide mechanisms to ensure end-to-end integrity 494 and confidentiality for all network traffic and protocols used to 495 support management functions. This MUST include at least 496 protocols used for configuration, monitoring, configuration backup 497 and restore, logging, time synchronization, authentication, and 498 routing. 500 Justification. 502 Integrity protection is required to ensure that unauthorized users 503 cannot manage the device or alter log data or the results of 504 management commands. Confidentiality is required so that 505 unauthorized users cannot view sensitive information, such as 506 keys, passwords, or the identity of users. 508 Examples. 510 See [RFC3631] for a current list of mechanisms that can be used to 511 support secure management. 513 Later sections list requirements for supporting in-band management 514 (Section 2.2) and out-of-band management (Section 2.3) as well as 515 trade-offs that must be weighed in considering which is 516 appropriate to a given situation. 518 Warnings. 520 None. 522 2.2 In-Band Management Requirements 524 This section lists security requirements that support secure in-band 525 management. In-band management has the advantage of lower cost (no 526 extra interfaces or lines), but has significant security 527 disadvantages: 529 o Saturation of customer lines or interfaces can make the device 530 unmanageable unless out-of-band management resources have been 531 reserved. 533 o Since public interfaces/channels are used, it is possible for 534 attackers to directly address and reach the device and to attempt 535 management functions. 537 o In-band management traffic on public interfaces may be 538 intercepted, however this would typically require a significant 539 compromise in the routing system. 541 o Public interfaces used for in-band management may become 542 unavailable due to bugs (e.g. buffer overflows being exploited) 543 while out-of-band interfaces (such as a serial console device) 544 remain available. 546 There are many situations where in-band management makes sense, is 547 used, and/or is the only option. The following requirements are meant 548 to provide means of securing in-band management traffic. 550 2.2.1 Use Cryptographic Algorithms Subject To Open Review 552 Requirement. 554 If cryptography is used to provide secure management functions, 555 then there MUST be an option to use algorithms that are subject to 556 "open review" as defined in Section 1.8 to provide these 557 functions. These SHOULD be used by default. The device MAY 558 optionally support algorithms that are not open to review. 560 Justification. 562 Cryptographic algorithms that have not been subjected to 563 widespread, extended public/peer review are more likely to have 564 undiscovered weaknesses or flaws than open standards and publicly 565 reviewed algorithms. Network operators may have need or desire to 566 use non-open cryptographic algorithms. They should be allowed to 567 evaluate the trade-offs and make an informed choice between open 568 and non-open cryptography. See [Schneier] for further discussion. 570 Examples. 572 The following are some algorithms that satisfy the requirement at 573 the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] 574 for applications requiring symmetric encryption; RSA [RFC3447] and 575 Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring 576 key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications 577 requiring message verification. 579 Warnings. 581 This list is not exhaustive. Other strong, well-reviewed 582 algorithms may meet the requirement. The dynamic nature of the 583 field means that what is good enough today may not be in the 584 future. 586 Open review is necessary but not sufficient. The strength of the 587 algorithm and key length must also be considered. For example, 588 56-bit DES meets the open review requirement, but is today 589 considered too weak and is therefore not recommended. 591 2.2.2 Use Strong Cryptography 593 Requirement. 595 If cryptography is used to meet the secure management channel 596 requirements, then the key lengths and algorithms SHOULD be 597 "strong". 599 Justification. 601 Short keys and weak algorithms threaten the confidentiality and 602 integrity of communications. 604 Examples. 606 The following algorithms satisfy the requirement at the time of 607 writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for 608 applications requiring symmetric encryption; RSA [RFC3447] and 609 Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring 610 key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications 611 requiring message verification. 613 Note that for *new protocols* [RFC3631] says the following: 614 "Simple keyed hashes based on MD5 [RFC1321], such as that used in 615 the BGP session security mechanism [RFC2385], are especially to be 616 avoided in new protocols, given the hints of weakness in MD5." 617 While use of such hashes in deployed products and protocols is 618 preferable to a complete lack of integrity and authentication 619 checks, this document concurs with the recommendation that new 620 products and protocols strongly consider alternatives. 622 Warnings. 624 This list is not exhaustive. Other strong, well-reviewed 625 algorithms may meet the requirement. The dynamic nature of the 626 field means that what is good enough today may not be in the 627 future. 629 Strength is relative. Long keys and strong algorithms are 630 intended to increase the work factor required to compromise the 631 security of the data protected. Over time, as processing power 632 increases, the security provided by a given algorithm and key 633 length will degrade. The definition of "Strong" must be 634 constantly reevaluated. 636 There may be legal issues governing the use of cryptography and 637 the strength of cryptography used. 639 This document explicitly does not attempt to make any 640 authoritative statement about what key lengths constitute "strong" 641 cryptography. See [RFC3562] and [I-D.orman-public-key-lengths] 642 for help in determining appropriate key lengths. Also see 643 [Schneier] chapter 7 for a discussion of key lengths. 645 2.2.3 Use Protocols Subject To Open Review For Management 647 Requirement. 649 If cryptography is used to provide secure management channels, 650 then its use MUST be supported in protocols that are subject to 651 "open review" as defined in Section 1.8. These SHOULD be used by 652 default. The device MAY optionally support the use of cryptography 653 in protocols that are not open to review. 655 Justification. 657 Protocols that have not been subjected to widespread, extended 658 public/peer review are more likely to have undiscovered weaknesses 659 or flaws than open standards and publicly reviewed protocols 660 Network operators may have need or desire to use non-open 661 protocols They should be allowed to evaluate the trade-offs and 662 make an informed choice between open and non-open protocols. 664 Examples. 666 See TLS [RFC2246] and IPsec [RFC2401]. 668 Warnings. 670 Note that open review is necessary but may not be sufficient. It 671 is perfectly possible for an openly reviewed protocol to misuse 672 (or not use) cryptography. 674 2.2.4 Allow Selection of Cryptographic Parameters 676 Requirement. 678 The device SHOULD allow the operator to select cryptographic 679 parameters. This SHOULD include key lengths and algorithms. 681 Justification. 683 Cryptography using certain algorithms and key lengths may be 684 considered "strong" at one point in time, but "weak" at another. 685 The constant increase in compute power continually reduces the 686 time needed to break cryptography of a certain strength. 687 Weaknesses may be discovered in algorithms. The ability to 688 select a different algorithm is a useful tool for maintaining 689 security in the face of such discoveries. 691 Examples. 693 56-bit DES was once considered secure. In 1998 it was cracked by 694 custom built machine in under 3 days. The ability to select 695 algorithms and key lengths would give the operator options 696 (different algorithms, longer keys) in the face of such 697 developments. 699 Warnings. 701 None. 703 2.2.5 Management Functions Should Have Increased Priority 705 Requirement. 707 Management functions SHOULD be processed at higher priority than 708 non-management traffic. This SHOULD include ingress, egress, 709 internal transmission, and processing. This SHOULD include at 710 least protocols used for configuration, monitoring, configuration 711 backup, logging, time synchronization, authentication, and 712 routing. 714 Justification. 716 Certain attacks (and normal operation) can cause resource 717 saturation such as link congestion, memory exhaustion or CPU 718 overload. In these cases it is important that management functions 719 be prioritized to ensure that operators have the tools needed to 720 recover from the attack. 722 Examples. 724 Imagine a service provider with 1,000,000 DSL subscribers, most of 725 whom have no firewall protection. Imagine that a large portion of 726 these subscribers machines were infected with a new worm that 727 enabled them to be used in coordinated fashion as part of large 728 denial of service attack that involved flooding. It is entirely 729 possible that without prioritization such an attack would cause 730 link congestion resulting in routing adjacencies being lost. A 731 DoS attack against hosts has just become a DoS attack against the 732 network. 734 Warnings. 736 Prioritization is not a panacea. Routing update packets may not 737 make it across a saturated link. This requirement simply says 738 that the device should prioritize management functions within its 739 scope of control (e.g. ingress, egress, internal transit, 740 processing). To the extent that this is done across an entire 741 network, the overall effect will be to ensure that the network 742 remains manageable. 744 2.3 Out-of-Band (OoB) Management Requirements 746 See Section 2.2 for a discussion of the advantages and disadvantages 747 of In-band vs. Out-of-Band management. 749 These requirements assume two different possible Out-of-Band 750 topologies: 752 o serial line (or equivalent) console connections using a CLI, 754 o network interfaces connected to a separate network dedicated to 755 management. 757 The following assumptions are made about out-of-band management: 759 o The out-of-band management network is secure. 761 o Communications beyond the management interface (e.g. console port, 762 management network interface) is secure. 764 o There is no need for encryption of communication on out-of-band 765 management interfaces, (e.g. on a serial connection between a 766 terminal server and a device's console port). 768 o Security measures are in place to prevent unauthorized physical 769 access. 771 Even if these assumptions hold it would be wise, as an application of 772 defense-in-depth, to apply the in-band requirements (e.g. encryption) 773 to out-of-band interfaces. 775 2.3.1 Support a 'Console' Interface 777 Requirement. 779 The device MUST support complete configuration and management via 780 a 'console' interface that functions independently from the 781 forwarding and IP control planes. 783 Justification. 785 There are times when it is operationally necessary to be able to 786 immediately and easily access a device for management or 787 configuration, even when the network is unavailable, routing and 788 network interfaces are incorrectly configured, the IP stack and/or 789 operating system may not be working (or may be vulnerable to 790 recently discovered exploits that make their use impossible/ 791 inadvisable), or when high bandwidth paths to the device are 792 unavailable. In such situations, a console interface can provide 793 a way to manage and configure the device. 795 Examples. 797 An RS232 (EIA232) interface that provides the capability to load 798 new versions of the system software and to perform configuration 799 via a command line interface. RS232 interfaces are ubiquitous and 800 well understood. 802 A simple embedded device that provides management and 803 configuration access via an Ethernet or USB interface. 805 As of this writing, RS232 is still strongly recommended as it 806 provides the following benefits: 808 * Simplicity. RS232 is far simpler than the alternatives. It is 809 simply a hardware specification. By contrast an Ethernet based 810 solution might require an ethernet interface, an operating 811 system, an IP stack and an HTTP server all to be functioning 812 and properly configured. 814 * Proven. RS232 has more than 30 years of use. 816 * Well-Understood. Operators have a great deal of experience with 817 RS232. 819 * Availability. It works even in the presence of network 820 failure. 822 * Ubiquity. It is very widely deployed in mid to high end network 823 infrastructure. 825 * Low-Cost. The cost of adding a RS232 port to a device is 826 small. 828 * CLI-Friendly. An RS232 interface and a CLI are sufficient in 829 most cases to manage a device. No additional software is 830 required. 832 * Integrated. Operators have many solutions (terminal servers, 833 etc.) currently deployed to support management via RS232. 835 While other interfaces may be supplied, the properties listed 836 above should be considered. Interfaces not having these properties 837 may present challenges in terms of ease of use, integration or 838 adoption. Problems in any of these areas could have negative 839 security impacts, particularly in situations where the console 840 must be used to quickly respond to incidents. 842 Warnings. 844 It is common practice is to connect RS232 ports to terminal 845 servers that permit networked access for convenience. This 846 increases the potential security exposure of mechanisms available 847 only via RS232 ports. For example, a password recovery mechanism 848 that is available only via RS232 might give a remote hacker to 849 completely reconfigure a router. While operational procedures are 850 beyond the scope of this document, it is important to note here 851 that strong attention should be given to policies, procedures, 852 access mechanisms and physical security governing access to 853 console ports. 855 2.3.2 'Console' Communication Profile Must Support Reset 857 Requirement. 859 There MUST be a method defined and published for returning the 860 console communication parameters to their default settings. This 861 method must not require the current settings to be known. 863 Justification. 865 Having to guess at communications settings can waste time. In a 866 crisis situation, the operator may need to get on the console of a 867 device quickly. 869 Examples. 871 One method might be to send a break on a serial line. 873 Warnings. 875 None. 877 2.3.3 'Console' Requires Minimal Functionality of Attached Devices. 879 Requirement. 881 The use of the 'console' interface MUST NOT require proprietary 882 devices, protocol extensions or specific client software. 884 Justification. 886 The purpose of having the console interface is to have a 887 management interface that can be made to work quickly at all 888 times. Requiring complex or nonstandard behavior on the part of 889 attached devices reduces the likelihood that the console will work 890 without hassles. 892 Examples. 894 If the console is supplied via an RS232 interface, then it should 895 function with an attached device that only implements a "dumb" 896 terminal. Support of "advanced" terminal features/types should be 897 optional. 899 Warnings. 901 None. 903 2.3.4 'Console' Supports Fall-back Authentication 905 Requirement. 907 The 'console' SHOULD support an authentication mechanism which 908 does not require functional IP or depend on external services. 909 This authentication mechanism MAY be disabled until a failure of 910 other preferred mechanisms is detected. 912 Justification. 914 It does little good to have a console interface on a device if you 915 cannot get into the device with it when the network is not 916 working. 918 Examples. 920 Some devices which use TACACS or RADIUS for authentication will 921 fall back to a local account if the TACACS or RADIUS server does 922 not reply to an authentication request. 924 Warnings. 926 This requirement represents a trade-off between being able to 927 manage the device (functionality) and security. There are many 928 ways to implement this which would provide reduced security for 929 the device, (e.g. a back door for unauthorized access). Local 930 policy should be consulted to determine if "fail open" or "fail 931 closed" is the correct stance. The implications of "fail closed" 932 (e.g. not being able to manage a device) should be fully 933 considered. 935 If the fall-back mechanism is disabled, it is important that the 936 failure of IP based authentication mechanism be reliably detected 937 and the fall-back mechanism automatically enabled...otherwise the 938 operator may be left with no means to authenticate. 940 2.3.5 Support Separate Management Plane IP Interfaces 942 Requirement. 944 The device MAY provide designated network interface(s) that are 945 used for management plane traffic. 947 Justification. 949 A separate management plane interface allows management traffic to 950 be segregated from other traffic (data/forwarding plane, control 951 plane). This reduces the risk that unauthorized individuals will 952 be able to observe management traffic and/or compromise the 953 device. 955 This requirement applies in situations where a separate OoB 956 management network exists. 958 Examples. 960 Ethernet port dedicated to management and isolated from customer 961 traffic satisfies this requirement. 963 Warnings. 965 The use of this type of interface depends on proper functioning of 966 both the operating system and the IP stack, as well as good, known 967 configuration at least on the portions of the device dedicated to 968 management. 970 2.3.6 No Forwarding Between Management Plane And Other Interfaces 972 Requirement. 974 If the device implements separate network interface(s) for the 975 management plane per Section 2.3.5 then the device MUST NOT 976 forward traffic between the management plane and non-management 977 plane interfaces. 979 Justification. 981 This prevents the flow, intentional or unintentional, of 982 management traffic to/from places that it should not be 983 originating/terminating (e.g. anything beyond the customer-facing 984 interfaces). 986 Examples. 988 Implementing separate forwarding tables for management plane and 989 non-management plane interfaces that do not propagate routes to 990 each other satisfies this requirement. 992 Warnings. 994 None. 996 2.4 Configuration and Management Interface Requirements 998 This section lists requirements that support secure device 999 configuration and management methods. In most cases, this currently 1000 involves some sort of command line interface (CLI) and configuration 1001 files. It may be possible to meet these requirements with other 1002 mechanisms, for instance SNMP or a script-able HTML interface that 1003 provides full access to management and configuration functions. In 1004 the future, there may be others (e.g. XML based configuration). 1006 2.4.1 'CLI' Provides Access to All Configuration and Management 1007 Functions 1009 Requirement. 1011 The Command Line Interface (CLI) or equivalent MUST allow complete 1012 access to all configuration and management functions. The CLI MUST 1013 be supported on the console (see Section 2.3.1) and SHOULD be 1014 supported on all other interfaces used for management. 1016 Justification. 1018 The CLI (or equivalent) is needed to provide the ability to do 1019 reliable, fast, direct, local management and monitoring of a 1020 device. It is particularly useful in situations where it is not 1021 possible to manage and monitor the device in-band via "normal" 1022 means (e.g. SSH or SNMP [RFC3410], [RFC3411]) that depend on 1023 functional networking. Such situations often occur during security 1024 incidents such as bandwidth-based denial of service attacks. 1026 Examples. 1028 Examples of configuration include setting interface addresses, 1029 defining and applying filters, configuring logging and 1030 authentication, etc. Examples of management functions include 1031 displaying dynamic state information such as CPU load, memory 1032 utilization, packet processing statistics, etc. 1034 Warnings. 1036 None. 1038 2.4.2 'CLI' Supports Scripting of Configuration 1040 Requirement. 1042 The CLI or equivalent MUST support external scripting of 1043 configuration functions. This CLI SHOULD support the same command 1044 set and syntax as that in Section 2.4.1. 1046 Justification. 1048 During the handling of security incidents, it is often necessary 1049 to quickly make configuration changes on large numbers of devices. 1050 Doing so manually is error prone and slow. Vendor supplied 1051 management solutions do not always foresee or address the type or 1052 scale of solutions that are required. The ability to script 1053 provides a solution to these problems. 1055 Examples. 1057 Example uses of scripting include: tracking an attack across a 1058 large network, updating authentication parameters, updating 1059 logging parameters, updating filters, configuration fetching/ 1060 auditing, etc. Some languages that are currently used for 1061 scripting include expect, Perl and TCL. 1063 Warnings. 1065 Some properties of the command language that enhance the ability 1066 to script are: simplicity, regularity and consistency. Some 1067 implementations that would make scripting difficult or impossible 1068 include: "text menu" style interfaces (e.g. "curses" on UNIX) or a 1069 hard-coded GUI interfaces (e.g. a native Windows or Macintosh GUI 1070 application) that communicate using a proprietary or undocumented 1071 protocol not based on a CLI. 1073 2.4.3 'CLI' Supports Management Over 'Slow' Links 1075 Requirement. 1077 The device MUST support a command line interface (CLI) or 1078 equivalent mechanism that works over low bandwidth connections. 1080 Justification. 1082 There are situations where high bandwidth for management is not 1083 available, for example when in-band connections are overloaded 1084 during an attack or when low-bandwidth, out-of-band connections 1085 such as modems must be used. It is often under these conditions 1086 that it is most crucial to be able to perform management and 1087 configuration functions. 1089 Examples. 1091 The network is down. The network engineer just disabled routing 1092 by mistake on the sole gateway router in a remote unmanned data 1093 center. The only access to the device is over a modem connected to 1094 a console port. The data center customers are starting to call the 1095 support line. The GUI management interface is redrawing the screen 1096 multiple times...slowly... at 9600bps. 1098 One mechanism that supports operation over slow links is the 1099 ability to apply filters to the output of CLI commands which have 1100 potentially large output. This may be implemented with something 1101 similar to the UNIX pipe facility and "grep" command. 1103 For example, 1105 cat largefile.txt | grep interesting-string 1107 Another is the ability to "page" through large command output, 1108 e.g. the UNIX "more" command: 1110 For example, 1112 cat largefile.txt | more 1114 Warnings. 1116 One consequence of this requirement may be that requiring a GUI 1117 interface for management is unacceptable unless it can be shown to 1118 work acceptably over slow links. 1120 2.4.4 'CLI' Supports Idle Session Timeout 1122 Requirement. 1124 The command line interface (CLI) or equivalent mechanism MUST 1125 support a configurable idle timeout value. 1127 Justification. 1129 Network administrators go to lunch. They leave themselves logged 1130 in with administrative privileges. They forget to use 1131 screen-savers with password protection. They do this while at 1132 conferences and in other public places. This behavior presents 1133 opportunity for unauthorized access. Idle timeouts reduce the 1134 window of exposure. 1136 Examples. 1138 The CLI may provide a configuration command that allows an idle 1139 timeout to be set. If the operator does not enter commands for 1140 that amount of time, the login session will be automatically 1141 terminated. 1143 Warnings. 1145 None. 1147 2.4.5 Support Software Installation 1149 Requirement. 1151 The device MUST provide a means to install new software versions. 1152 It MUST be possible to install new software while the device is 1153 disconnected from all public IP networks. This MUST NOT rely on 1154 previous installation and/or configuration. While new software MAY 1155 be loaded from writable media (disk, flash, etc.), the capability 1156 to load new software MUST depend only on non-writable media (ROM, 1157 etc.). The installation procedures SHOULD support mechanisms to 1158 ensure reliability and integrity of data transfers. 1160 Justification. 1162 * Vulnerabilities are often discovered in the base software 1163 (operating systems, etc.) shipped by vendors. Often mitigation 1164 of the risk presented by these vulnerabilities can only be 1165 accomplished by updates to the vendor supplied software (e.g. 1166 bug fixes, new versions of code, etc.). Without a mechanism to 1167 load new vendor supplied code, it may not be possible to 1168 mitigate the risk posed by these vulnerabilities. 1170 * It is also conceivable that malicious behavior on the part of 1171 hackers or unintentional behaviors on the part of operators 1172 could cause software on devices to be corrupted or erased. In 1173 these situations, it is necessary to have a means to (re)load 1174 software onto the device to restore correct functioning. 1176 * It is important to be able to load new software while 1177 disconnected from all public IP networks because the device may 1178 be vulnerable to old attacks before the update is complete. 1180 * One has to assume that hackers, operators, etc. may erase or 1181 corrupt all writable media (disks, flash, etc.). In such 1182 situations, it is necessary to be able to recover starting with 1183 only non-writable media (e.g. CD-ROM, a true ROM-based 1184 monitor). 1186 * System images may be corrupted in transit (from vendor to 1187 customer, or during the loading process) or in storage (bit 1188 rot, defective media, etc.) Failure to reliably load a new 1189 image, for example after a hacker deletes or corrupts the 1190 installed image, could result in extended loss of availability. 1192 Examples. 1194 The device could support booting into a simple ROM-based monitor 1195 that supported a set of commands sufficient to load new operating 1196 system code and configuration data from other devices. The 1197 operating system and configuration might be loaded from: 1199 RS232. The device could support uploading new code via an RS232 1200 console port. 1202 CD-ROM. The device could support installing new code from a 1203 locally attached CD-ROM drive. 1205 NETWORK. The device could support installing new code via a 1206 network interface, assuming that (a) it is disconnected from 1207 all public networks and (b) the device can boot an OS and IP 1208 stack from some read-only media with sufficient capabilities to 1209 load new code from the network. 1211 FLASH. The device could support booting from flash memory cards. 1213 Simple mechanisms currently in use to protect the integrity of 1214 system images and data transfer include image checksums and simple 1215 serial file transfer protocols such as XMODEM and Kermit. 1217 Warnings. 1219 None. 1221 2.4.6 Support Remote Configuration Backup 1223 Requirement. 1225 The device MUST provide a means to store the system configuration 1226 to a remote server. The stored configuration MUST have sufficient 1227 information to restore the device to its operational state at the 1228 time the configuration is saved. Stored versions of the 1229 configuration MAY be compressed using an algorithm which is 1230 subject to open review, as long as the fact is clearly identified 1231 and the compression can be disabled. Sensitive information such as 1232 passwords that could be used to compromise the security of the 1233 device MAY be excluded from the saved configuration. 1235 Justification. 1237 Archived configurations are essential to enable auditing and 1238 recovery. 1240 Examples. 1242 Possible implementations include SCP, SFTP or FTP over a secure 1243 channel. See Section 2.1.1 for requirements related to secure 1244 communication channels for management protocols and data. 1246 Warnings. 1248 The security of the remote server is assumed, with appropriate 1249 measures being outside the scope of this document. 1251 2.4.7 Support Remote Configuration Restore 1253 Requirement. 1255 The device MUST provide a means to restore a configuration that 1256 was saved as described in Section 2.4.6. The system MUST be 1257 restored to its operational state at the time the configuration 1258 was saved. 1260 Justification. 1262 Restoration of archived configurations allows quick restoration of 1263 service following an outage (security related as well as from 1264 other causes). 1266 Examples. 1268 Configurations may be restored using SCP, SFTP or FTP over a 1269 secure channel. See Section 2.1.1 for requirements related to 1270 secure communication channels for management protocols and data. 1272 Warnings. 1274 The security of the remote server is assumed, with appropriate 1275 measures being outside the scope of this document. 1277 Note that if passwords or other sensitive information are excluded 1278 from the saved copy of the configuration, as allowed by Section 1279 2.4.6, then the restore may not be complete. The operator may 1280 have to set new passwords or supply other information that was not 1281 saved. 1283 2.4.8 Support Text Configuration Files 1285 Requirement. 1287 The device MUST support display, backup and restore of system 1288 configuration in a simple well defined textual format. The 1289 configuration MUST also be viewable as text on the device itself. 1290 It MUST NOT be necessary to use a proprietary program to view the 1291 configuration. 1293 Justification. 1295 Simple, well-defined textual configurations facilitate human 1296 understanding of the operational state of the device, enable 1297 off-line audits, and facilitate automation. Requiring the use of a 1298 proprietary program to access the configuration inhibits these 1299 goals. 1301 Examples. 1303 A 7-bit ASCII configuration file that shows the current settings 1304 of the various configuration options would satisfy the 1305 requirement, as would a Unicode configuration or any other 1306 "textual" representation. A structured binary format intended only 1307 for consumption by programs would not be acceptable. 1309 Warnings. 1311 Offline copies of configurations should be well protected as they 1312 often contain sensitive information such as SNMP community 1313 strings, passwords, network blocks, customer information, etc. 1315 "Well defined" and "textual" are open to interpretation. Clearly 1316 an ASCII configuration file with a regular, documented command 1317 oriented-syntax would meet the definition. These are currently in 1318 wide use. Future options, such as XML based configuration may 1319 meet the requirement. Determining this will require evaluation 1320 against the justifications listed above. 1322 2.5 IP Stack Requirements 1324 2.5.1 Ability to Identify All Listening Services 1326 Requirement. 1328 The vendor MUST: 1330 * Provide a means to display all services that are listening for 1331 network traffic directed at the device from any external 1332 source. 1334 * Display the addresses to which each service is bound. 1336 * Display the addresses assigned to each interface. 1338 * Display any and all port(s) on which the service is listing. 1340 * Include both open standard and vendor proprietary services. 1342 Justification. 1344 This information is necessary to enable a thorough assessment of 1345 the security risks associated with the operation of the device 1346 (e.g., "does this protocol allow complete management of the device 1347 without also requiring authentication, authorization, or 1348 accounting?"). The information also assists in determining what 1349 steps should be taken to mitigate risk (e.g., "should I turn this 1350 service off ?") 1352 Examples. 1354 If the device is listening for SNMP traffic from any source 1355 directed to the IP addresses of any of its local interfaces, then 1356 this requirement could be met by the provision of a command which 1357 displays that fact. 1359 Warnings. 1361 None. 1363 2.5.2 Ability to Disable Any and All Services 1365 Requirement. 1367 The device MUST provide a means to turn off any "services" (see 1368 Section 1.8). 1370 Justification. 1372 The ability to disable services for which there is no operational 1373 need will allow administrators to reduce the overall risk posed to 1374 the device. 1376 Examples. 1378 Processes that listen on TCP and UDP ports would be prime examples 1379 of services that it must be possible to disable. 1381 Warnings. 1383 None. 1385 2.5.3 Ability to Control Service Bindings for Listening Services 1387 Requirement. 1389 The device MUST provide a means for the user to specify the 1390 bindings used for all listening services. It MUST support binding 1391 to any address or net-block associated with any interface local to 1392 the device. This must include addresses bound to physical or 1393 non-physical (e.g. loopback) interfaces. 1395 Justification. 1397 It is a common practice among operators to configure "loopback" 1398 pseudo-interfaces to use as the source and destination of 1399 management traffic. These are preferred to physical interfaces 1400 because they provide a stable, routable address. Services bound 1401 to the addresses of physical interface addresses might become 1402 unreachable if the associated hardware goes down, is removed, etc. 1404 This requirement makes it possible to restrict access to 1405 management services using routing. Management services may be 1406 bound only to the addresses of loopback interfaces. The loopback 1407 interfaces may be addressed out of net-blocks that are only routed 1408 between the managed devices and the authorized management 1409 networks/hosts. This has the effect of making it impossible for 1410 anyone to connect to (or attempt to DoS) management services from 1411 anywhere but the authorized management networks/hosts. 1413 It also greatly reduces the need for complex filters. It reduces 1414 the number of ports listening, and thus the number of potential 1415 avenues of attack. It ensures that only traffic arriving from 1416 legitimate addresses and/or on designated interfaces can access 1417 services on the device. 1419 Examples. 1421 If the device listens for inbound SSH connections, this 1422 requirement means that it should be possible to specify that the 1423 device will only listen to connections destined to specific 1424 addresses (e.g. the address of the loopback interface) or received 1425 on certain interfaces (e.g. an Ethernet interface designated as 1426 the "management" interface). It should be possible in this example 1427 to configure the device such that the SSH is NOT listening to 1428 every address configured on the device. Similar effects may be 1429 achieved with the use of global filters, sometimes called 1430 "receive" or "loopback" ACLs, that filter traffic destined for the 1431 device itself on all interfaces. 1433 Warnings. 1435 None. 1437 2.5.4 Ability to Control Service Source Addresses 1439 Requirement. 1441 The device MUST provide a means that allows the user to specify 1442 the source addresses used for all outbound connections or 1443 transmissions originating from the device. It SHOULD be possible 1444 to specify source addresses independently for each type of 1445 outbound connection or transmission. Source addresses MUST be 1446 limited to addresses that are assigned to interfaces (including 1447 loopbacks) local to the device. 1449 Justification. 1451 This allows remote devices receiving connections or transmissions 1452 to use source filtering as one means of authentication. For 1453 example, if SNMP traps were configured to use a known loopback 1454 address as their source, the SNMP workstation receiving the traps 1455 (or a firewall in front of it) could be configured to receive SNMP 1456 packets only from that address. 1458 Examples. 1460 The operator may allocate a distinct block of addresses from which 1461 all loopbacks are numbered. NTP and syslog can be configured to 1462 use those loopback addresses as source, while SNMP and BGP may be 1463 configured to use specific physical interface addresses. This 1464 would facilitate filtering based on source address as one way of 1465 rejecting unauthorized attempts to connect to peers/servers. 1467 Warnings. 1469 Care should be taken to assure that the addresses chosen are 1470 routable between the sending and receiving devices, (e.g. setting 1471 SSH to use a loopback address of 10.1.1.1 which is not routed 1472 between a router and all intended destinations could cause 1473 problems). 1475 Note that some protocols, such as SCTP [RFC3309], can use more 1476 than one IP address as the endpoint of a single connection. 1478 Also note that [RFC3631] lists address-based authentication as an 1479 "insecurity mechanism". Address based authentication should be 1480 replaced or augmented by other mechanisms wherever possible. 1482 2.5.5 Support Automatic Anti-spoofing for Single-Homed Networks 1484 Requirement. 1486 The device MUST provide a means to designate particular interfaces 1487 as servicing "single-homed networks" (see Section 1.8) and MUST 1488 provide an option to automatically drop "spoofed packets" (Section 1489 1.8) received on such interfaces where application of the current 1490 forwarding table would not route return traffic back through the 1491 same interface. This option MUST work in the presence of dynamic 1492 routing and dynamically assigned addresses. 1494 Justification. 1496 See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of 1497 [RFC1812], and [RFC2827]. 1499 Examples. 1501 This requirement could be satisfied in several ways. It could be 1502 satisfied by the provision of a single command that automatically 1503 generates and applies filters to an interface that implements 1504 anti-spoofing. It could be satisfied by the provision of a 1505 command that causes the return path for packets received to be 1506 checked against the current forwarding tables and dropped if they 1507 would not be forwarded back through the interface on which they 1508 were received. 1510 See [I-D.savola-bcp38-multihoming-update]. 1512 Warnings. 1514 This requirement only holds for single-homed networks. Note that a 1515 simple forwarding table check is not sufficient in the more 1516 complex scenarios of multi-homed or multi-attached networks, i.e., 1517 where the traffic may be asymmetric. In these cases, a more 1518 extensive check such as Feasible Path RPF could be very useful. 1520 2.5.6 Support Automatic Discarding Of Bogons and Martians 1522 Requirement. 1524 The device MUST provide a means to automatically drop all "bogons" 1525 (Section 1.8) and "martians" (Section 1.8). This option MUST work 1526 in the presence of dynamic routing and dynamically assigned 1527 addresses. 1529 Justification. 1531 These sorts of packets have little (no?) legitimate use and are 1532 used primarily to allow individuals and organization to avoid 1533 identification (and thus accountability) and appear to be most 1534 often used for DoS attacks, email abuse, hacking, etc. In 1535 addition, transiting these packets needlessly consumes resources 1536 and may lead to capacity and performance problems for customers. 1538 See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of 1539 [RFC1812], and [RFC2827]. 1541 Examples. 1543 This requirement could be satisfied by the provision of a command 1544 that causes the return path for packets received to be checked 1545 against the current forwarding tables and dropped if no viable 1546 return path exists. This assumes that steps are taken to assure 1547 that no bogon entries are present in the forwarding tables (for 1548 example filtering routing updates per Section 2.7.5 to reject 1549 advertisements of unassigned addresses). 1551 See [I-D.savola-bcp38-multihoming-update]. 1553 Warnings. 1555 This requirement only holds for single-homed networks. Note that a 1556 simple forwarding table check is not sufficient in the more 1557 complex scenarios of multi-homed or multi-attached networks, i.e., 1558 where the traffic may be asymmetric. In these cases, a more 1559 extensive check such as Feasible Path RPF could be very useful. 1561 2.5.7 Support Counters For Dropped Packets 1563 Requirement. 1565 The device MUST provide accurate, per-interface counts of spoofed 1566 packets dropped in accordance with Section 2.5.5 and Section 1567 2.5.6. 1569 Justification. 1571 Counters can help in identifying the source of spoofed traffic. 1573 Examples. 1575 An edge router may have several single-homed customers attached. 1576 When an attack using spoofed packets is detected, a quick check of 1577 counters may be able to identify which customer is attempting to 1578 send spoofed traffic. 1580 Warnings. 1582 None. 1584 2.6 Rate Limiting Requirements 1586 2.6.1 Support Rate Limiting 1588 Requirement. 1590 The device MUST provide the capability to limit the rate at which 1591 it will pass traffic based on protocol, source and destination IP 1592 address or CIDR block, source and destination port, and interface. 1593 Protocols MUST include at least least IP, ICMP, UDP, and TCP and 1594 SHOULD include any protocol. 1596 Justification. 1598 This requirement provides a means of reducing or eliminating the 1599 impact of certain types of attacks. Also, rate limiting has the 1600 advantage that in some cases it can be turned on a priori, thereby 1601 offering some ability to mitigate the effect of future attacks 1602 prior to any explicit operator reaction to the attacks. 1604 Examples. 1606 Assume that a web hosting company provides space in its 1607 data-center to a company that becomes unpopular with a certain 1608 element of network users, who then decide to flood the web server 1609 with inbound ICMP traffic. It would be useful in such a situation 1610 to be able to rate-filter inbound ICMP traffic at the 1611 data-center's border routers. On the other side, assume that a 1612 new worm is released that infects vulnerable database servers such 1613 that they then start spewing traffic on TCP port 1433 aimed at 1614 random destination addresses as fast as the system and network 1615 interface of the infected server is capable. Further assume that 1616 a data center has many vulnerable servers that are infected and 1617 simultaneously sending large amounts of traffic with the result 1618 that all outbound links are saturated. Implementation of this 1619 requirement, would allow the network operator to rate limit 1620 inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0 1621 packets/bytes per second) to respond to the attack and maintain 1622 service levels for other legitimate customers/traffic. 1624 Warnings. 1626 None. 1628 2.6.2 Support Directional Application Of Rate Limiting Per Interface 1630 Requirement. 1632 The device MUST provide support to rate-limit input and/or output 1633 separately on each interface. 1635 Justification. 1637 This level of granular control allows appropriately targeted 1638 controls that minimize the impact on third parties. 1640 Examples. 1642 If an ICMP flood is directed a single customer on an edge router, 1643 it may be appropriate to rate-limit outbound ICMP only on that 1644 customers interface. 1646 Warnings. 1648 None. 1650 2.6.3 Support Rate Limiting Based on State 1652 Requirement. 1654 The device MUST be able to rate limit based on all TCP control 1655 flag bits. The device SHOULD support rate limiting of other 1656 stateful protocols where the normal processing of the protocol 1657 gives the device access to protocol state. 1659 Justification. 1661 This allows appropriate response to certain classes of attack. 1663 Examples. 1665 For example, for TCP sessions, it should be possible to rate limit 1666 based on the SYN, SYN-ACK, RST, or other bit state. 1668 Warnings. 1670 None. 1672 2.7 Basic Filtering Capabilities 1674 2.7.1 Ability to Filter Traffic 1676 Requirement. 1678 The device MUST provide a means to filter IP packets on any 1679 interface implementing IP. 1681 Justification. 1683 Packet filtering is important because it provides a basic means of 1684 implementing policies that specify which traffic is allowed and 1685 which is not. It also provides a basic tool for responding to 1686 malicious traffic. 1688 Examples. 1690 Access control lists that allow filtering based on protocol and/or 1691 source/destination address and or source/destination port would be 1692 one example. 1694 Warnings. 1696 None. 1698 2.7.2 Ability to Filter Traffic TO the Device 1700 Requirement. 1702 It MUST be possible to apply the filtering mechanism to traffic 1703 that is addressed directly to the device via any of its interfaces 1704 - including loopback interfaces. 1706 Justification. 1708 This allows the operator to apply filters that protect the device 1709 itself from attacks and unauthorized access. 1711 Examples. 1713 Examples of this might include filters that permit only BGP from 1714 peers and SNMP and SSH from an authorized management segment and 1715 directed to the device itself, while dropping all other traffic 1716 addressed to the device. 1718 Warnings. 1720 None. 1722 2.7.3 Ability to Filter Traffic THROUGH the Device 1724 Requirement. 1726 It MUST be possible to apply the filtering mechanism to traffic 1727 that is being routed (switched) through the device. 1729 Justification. 1731 This permits implementation of basic policies on devices that 1732 carry transit traffic (routers, switches, etc.). 1734 Examples. 1736 One simple and common way to meet this requirement is to provide 1737 the ability to filter traffic inbound to each interface and/or 1738 outbound from each interface. Ingress filtering as described in 1739 [RFC2827] provides one example of the use of this capability. 1741 Warnings. 1743 None. 1745 2.7.4 Ability to Filter Without Significant Performance Degradation 1747 Requirement. 1749 The device MUST provide a means to filter packets without 1750 significant performance degradation. This specifically applies to 1751 stateless packet filtering operating on layer 3 (IP) and layer 4 1752 (TCP or UDP) headers, as well as normal packet forwarding 1753 information such as incoming and outgoing interfaces. 1755 The device MUST be able to apply stateless packet filters on ALL 1756 interfaces (up to the maximum number possible) simultaneously and 1757 with multiple filters per interface (e.g., inbound and outbound). 1759 Justification. 1761 This enables the implementation of filtering wherever and whenever 1762 needed. To the extent that filtering causes degradation, it may 1763 not be possible to apply filters that implement the appropriate 1764 policies. 1766 Examples. 1768 Another way of stating the requirement is that filter performance 1769 should not be the limiting factor in device throughput. If a 1770 device is capable of forwarding 30Mb/sec without filtering, then 1771 it should be able to forward the same amount with filtering in 1772 place. 1774 Warnings. 1776 The definition of "significant" is subjective. At one end of the 1777 spectrum it might mean "the application of filters may cause the 1778 box to crash". At the other end would be a throughput loss of 1779 less than one percent with tens of thousands of filters applied. 1780 The level of performance degradation that is acceptable will have 1781 to be determined by the operator. 1783 Repeatable test data showing filter performance impact would be 1784 very useful in evaluating conformance with this requirement. 1785 Tests should include such information as packet size, packet rate, 1786 number of interfaces tested (source/destination), types of 1787 interfaces, routing table size, routing protocols in use, 1788 frequency of routing updates, etc. See 1789 [I-D.ietf-bmwg-acc-bench-framework]. 1791 This requirement does not address stateful filtering, filtering 1792 above layer 4 headers or other more advanced types of filtering 1793 that may be important in certain operational environments. 1795 2.7.5 Support Route Filtering 1797 Requirement. 1799 The device MUST provide a means to filter routing updates for all 1800 protocols used to exchange external routing information. 1802 Justification. 1804 See [RFC3013] and section 3.2 of [RFC2196]. 1806 Examples. 1808 Operators may wish to ignore advertisements for routes to 1809 addresses allocated for private internets. See eBGP. 1811 Warnings. 1813 None. 1815 2.7.6 Ability to Specify Filter Actions 1817 Requirement. 1819 The device MUST provide a mechanism to allow the specification of 1820 the action to be taken when a filter rule matches. Actions MUST 1821 include "permit" (allow the traffic), "reject" (drop with 1822 appropriate notification to sender), and "drop" (drop with no 1823 notification to sender). Also see Section 2.7.7 and Section 2.9 1825 Justification. 1827 This capability is essential to the use of filters to enforce 1828 policy. 1830 Examples. 1832 Assume that you have a small DMZ network connected to the 1833 Internet. You want to allow management using SSH coming from your 1834 corporate office. In this case, you might "permit" all traffic to 1835 port 22 in the DMZ from your corporate network, "rejecting" all 1836 others. Port 22 traffic from the corporate network is allowed 1837 through. Port 22 traffic from all other addresses results in an 1838 ICMP message to the sender. For those who are slightly more 1839 paranoid, you might choose to "drop" instead of "reject" traffic 1840 from unauthorized addresses, with the result being that *nothing* 1841 is sent back to the source. 1843 Warnings. 1845 While silently dropping traffic without sending notification may 1846 be the correct action in security terms, consideration should be 1847 given to operational implications. See [RFC3360] for consideration 1848 of potential problems caused by sending inappropriate TCP Resets. 1850 2.7.7 Ability to Log Filter Actions 1852 Requirement. 1854 It MUST be possible to log all filter actions. The logging 1855 capability MUST be able to capture at least the following data: 1857 * permit/deny/drop status, 1859 * source and destination IP address, 1861 * source and destination ports (if applicable to the protocol), 1863 * which network element received the packet (interface, MAC 1864 address or other layer 2 information that identifies the 1865 previous hop source of the packet). 1867 Logging of filter actions is subject to the requirements of 1868 Section 2.11. 1870 Justification. 1872 Logging is essential for auditing, incident response, and 1873 operations. 1875 Examples. 1877 A desktop network may not provide any services that should be 1878 accessible from "outside." In such cases, all inbound connection 1879 attempts should be logged as possible intrusion attempts. 1881 Warnings. 1883 None. 1885 2.8 Packet Filtering Criteria 1887 2.8.1 Ability to Filter on Protocols 1889 Requirement. 1891 The device MUST provide a means to filter traffic based on the 1892 value of the protocol field in the IP header. 1894 Justification. 1896 Being able to filter on protocol is necessary to allow 1897 implementation of policy, secure operations and for support of 1898 incident response. 1900 Examples. 1902 Some denial of service attacks are based on the ability to flood 1903 the victim with ICMP traffic. One quick way (admittedly with some 1904 negative side effects) to mitigate the effects of such attacks is 1905 to drop all ICMP traffic headed toward the victim. 1907 Warnings. 1909 None. 1911 2.8.2 Ability to Filter on Addresses 1913 Requirement. 1915 The function MUST be able to control the flow of traffic based on 1916 source and/or destination IP address or blocks of addresses such 1917 as Classless Inter-Domain Routing (CIDR) blocks. 1919 Justification. 1921 The capability to filter on addresses and address blocks is a 1922 fundamental tool for establishing boundaries between different 1923 networks. 1925 Examples. 1927 One example of the use of address based filtering is to implement 1928 ingress filtering per [RFC2827]. 1930 Warnings. 1932 None. 1934 2.8.3 Ability to Filter on Protocol Header Fields 1936 Requirement. 1938 The filtering mechanism MUST support filtering based on the 1939 value(s) of any portion of the protocol headers for IP, ICMP, UDP 1940 and TCP. It SHOULD support filtering of all other protocols 1941 supported at layer 3 and 4. It MAY support filtering based on 1942 the headers of higher level protocols. It SHOULD be possible to 1943 specify fields by name (e.g. "protocol = ICMP") rather than 1944 bit-offset/length/numeric value (e.g. 72:8 = 1). 1946 Justification. 1948 Being able to filter on portions of the header is necessary to 1949 allow implementation of policy, secure operations, and support 1950 incident response. 1952 Examples. 1954 This requirement implies that it is possible to filter based on 1955 TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, 1956 and ICMP type and code fields. One common example is to reject 1957 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 1958 or SYN bit set+ACK,FIN and RST bits clear). Another common 1959 example is the ability to control what services are allowed in/out 1960 of a network. It may be desirable to only allow inbound 1961 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 1962 web servers. 1964 Warnings. 1966 None. 1968 2.8.4 Ability to Filter Inbound and Outbound 1970 Requirement. 1972 It MUST be possible to filter both incoming and outgoing traffic 1973 on any interface. 1975 Justification. 1977 This requirement allows flexibility in applying filters at the 1978 place that makes the most sense. It allows invalid or malicious 1979 traffic to be dropped as close to the source as possible. 1981 Examples. 1983 It might be desirable on a border router, for example, to apply an 1984 egress filter outbound on the interface that connects a site to 1985 its external ISP to drop outbound traffic that does not have a 1986 valid internal source address. Inbound, it might be desirable to 1987 apply a filter that blocks all traffic from a site that is known 1988 to forward or originate lots of junk mail. 1990 Warnings. 1992 None. 1994 2.9 Packet Filtering Counter Requirements 1996 2.9.1 Ability to Accurately Count Filter Hits 1998 Requirement. 2000 The device MUST supply a facility for accurately counting all 2001 filter hits. 2003 Justification. 2005 Accurate counting of filter rule matches is important because it 2006 shows the frequency of attempts to violate policy. This enables 2007 resources to be focused on areas of greatest need. 2009 Examples. 2011 Assume, for example, that a ISP network implements anti-spoofing 2012 egress filters (see [RFC2827]) on interfaces of its edge routers 2013 that support single-homed stub networks. Counters could enable 2014 the ISP to detect cases where large numbers of spoofed packets are 2015 being sent. This may indicate that the customer is performing 2016 potentially malicious actions (possibly in violation of the ISPs 2017 Acceptable Use Policy), or that system(s) on the customers network 2018 have been "owned" by hackers and are being (mis)used to launch 2019 attacks. 2021 Warnings. 2023 None. 2025 2.9.2 Ability to Display Filter Counters 2027 Requirement. 2029 The device MUST provide a mechanism to display filter counters. 2031 Justification. 2033 Information that is collected is not useful unless it can be 2034 displayed in a useful manner. 2036 Examples. 2038 Assume there is a router with four interfaces. One is an up-link 2039 to an ISP providing routes to the Internet. The other three 2040 connect to separate internal networks. Assume that a host on one 2041 of the internal networks has been compromised by a hacker and is 2042 sending traffic with bogus source addresses. In such a situation, 2043 it might be desirable to apply ingress filters to each of the 2044 internal interfaces. Once the filters are in place, the counters 2045 can be examined to determine the source (inbound interface) of the 2046 bogus packets. 2048 Warnings. 2050 None. 2052 2.9.3 Ability to Display Filter Counters per Rule 2053 Requirement. 2055 The device MUST provide a mechanism to display filter counters per 2056 rule. 2058 Justification. 2060 This makes it possible to see which rules are matching and how 2061 frequently. 2063 Examples. 2065 Assume that a filter has been defined that has two rules, one 2066 permitting all SSH traffic (tcp/22) and the second dropping all 2067 remaining traffic. If three packets are directed toward/through 2068 the point at which the filter is applied, one to port 22, the 2069 others to different ports, then the counter display should show 1 2070 packet matching the permit tcp/22 rule and 2 packets matching the 2071 deny all others rule. 2073 Warnings. 2075 None. 2077 2.9.4 Ability to Display Filter Counters per Filter Application 2079 Requirement. 2081 If it is possible for a filter to be applied more than once at the 2082 same time, then the device MUST provide a mechanism to display 2083 filter counters per filter application. 2085 Justification. 2087 It may make sense to apply the same filter definition 2088 simultaneously more than one time (to different interfaces, etc.). 2089 If so, it would be much more useful to know which instance of a 2090 filter is matching than to know that some instance was matching 2091 somewhere. 2093 Examples. 2095 One way to implement this requirement would be to have the counter 2096 display mechanism show the interface (or other entity) to which 2097 the filter has been applied, along with the name (or other 2098 designator) for the filter. For example if a filter named 2099 "desktop_outbound" applied two different interfaces, say, 2100 "ethernet0" and "ethernet1", the display should indicate something 2101 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 2102 "matches of filter 'desktop_outbound' on ethernet1 ..." 2104 Warnings. 2106 None. 2108 2.9.5 Ability to Reset Filter Counters 2110 Requirement. 2112 It MUST be possible to reset counters to zero on a per filter 2113 basis. 2115 For the purposes of this requirement it would be acceptable for 2116 the system to maintain two counters: an "absolute counter", 2117 C[now], and a "reset" counter, C[reset]. The absolute counter 2118 would maintain counts that increase monotonically until they wrap 2119 or overflow the counter. The reset counter would receive a copy 2120 of the current value of the absolute counter when the reset 2121 function was issued for that counter. Functions that display or 2122 retrieve the counter could then display the delta (C[now] - 2123 C[reset]). 2125 Justification. 2127 This allows operators to get a current picture of the traffic 2128 matching particular rules/filters. 2130 Examples. 2132 Assume that filter counters are being used to detect internal 2133 hosts that are infected with a new worm. Once it is believed that 2134 all infected hosts have been cleaned up and the worm removed, the 2135 next step would be to verify that. One way of doing so would be 2136 to reset the filter counters to zero and see if traffic indicative 2137 of the worm has ceased. 2139 Warnings. 2141 None. 2143 2.9.6 Filter Counters Must Be Accurate 2144 Requirement. 2146 Filter counters MUST be accurate. They MUST reflect the actual 2147 number of matching packets since the last counter reset. Filter 2148 counters MUST be capable of holding up to 2^32 - 1 values without 2149 overflowing and SHOULD be capable of holding up to 2^64 - 1 2150 values. 2152 Justification. 2154 Inaccurate data can not be relied on as the basis for action. 2155 Underreported data can conceal the magnitude of a problem. 2157 Examples. 2159 If N packets matching a filter are sent to/through a device, then 2160 the counter should show N matches. 2162 Warnings. 2164 None. 2166 2.10 Other Packet Filtering Requirements 2168 2.10.1 Ability to Specify Filter Log Granularity 2170 Requirement. 2172 It MUST be possible to enable/disable logging on a per rule basis. 2174 Justification. 2176 The ability to tune the granularity of logging allows the operator 2177 to log only the information that is desired. Without this 2178 capability, it is possible that extra data (or none at all) would 2179 be logged, making it more difficult to find relevant information. 2181 Examples. 2183 If a filter is defined that has several rules, and one of the 2184 rules denies telnet (tcp/23) connections, then it should be 2185 possible to specify that only matches on the rule that denies 2186 telnet should generate a log message. 2188 Warnings. 2190 None. 2192 2.11 Event Logging Requirements 2194 2.11.1 Logging Facility Uses Protocols Subject To Open Review 2196 Requirement. 2198 The device MUST provide a logging facility that is based on 2199 protocols subject to open review. See Section 1.8. Custom or 2200 proprietary logging protocols MAY be implemented provided the same 2201 information is made available. 2203 Justification. 2205 The use of logging based on protocols subject to open review 2206 permits the operator to perform archival and analysis of logs 2207 without relying on vendor-supplied software and servers. 2209 Examples. 2211 This requirement may be satisfied by the use of one or more of 2212 syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ 2213 [RFC1492] or RADIUS [RFC2865]. 2215 Warnings. 2217 While [RFC3164] meets this requirement, it has many security 2218 issues and by itself does not meet the requirements of Section 2219 2.1.1. See the security considerations section of [RFC3164] for a 2220 list of issues. [RFC3195] provides solutions to most/all of these 2221 issues....however at the time of this writing there are few 2222 implementations. Other possible solutions might be to tunnel 2223 syslog over a secure transport...but this often raises difficult 2224 key management and scalability issues. 2226 The current best solution seems to be the following: 2228 * Implement [RFC3164]. 2230 * Consider implementing [RFC3195]. 2232 2.11.2 Logs Sent To Remote Servers 2233 Requirement. 2235 The device MUST support transmission of records of security 2236 related events to one or more remote devices. There MUST be 2237 configuration settings on the device that allow selection of 2238 servers. 2240 Justification. 2242 This is important because it supports individual accountability. 2243 It is important to store them on a separate server to preserve 2244 them in case of failure or compromise of the managed device. 2246 Examples. 2248 This requirement may be satisfied by the use of one or more of: 2249 syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ 2250 [RFC1492] or RADIUS [RFC2865]. 2252 Warnings. 2254 Note that there may be privacy or legal considerations when 2255 logging/monitoring user activity. 2257 High volumes of logging may generate excessive network traffic 2258 and/or compete for scarce memory and CPU resources on the device. 2260 2.11.3 Ability to Select Reliable Delivery 2262 Requirement. 2264 It SHOULD be possible to select reliable delivery of log messages. 2266 Justification. 2268 Reliable delivery is important to the extent that log data is 2269 depended upon to make operational decisions and forensic analysis. 2270 Without reliable delivery, log data becomes a collection of hints. 2272 Examples. 2274 One example of reliable syslog delivery is defined in [RFC3195]. 2275 Syslog-ng provides another example, although the protocol has not 2276 been standardized. 2278 Warnings. 2280 None. 2282 2.11.4 Ability to Log Locally 2284 Requirement. 2286 It SHOULD be possible to log locally on the device itself. Local 2287 logging SHOULD be written to non-volatile storage. 2289 Justification. 2291 Local logging of failed authentication attempts to non-volatile 2292 storage is critical. It provides a means of detecting attacks 2293 where the device is isolated from its authentication interfaces 2294 and attacked at the console. 2296 Local logging is important for viewing information when connected 2297 to the device. It provides some backup of log data in case remote 2298 logging fails. It provides a way to view logs relevant to one 2299 device without having to sort through a possibly large set of logs 2300 from other devices. 2302 Examples. 2304 One example of local logging would be a memory buffer that 2305 receives copies of messages sent to the remote log server. 2306 Another example might be a local syslog server (assuming the 2307 device is capable of running syslog and has some local storage). 2309 Warnings. 2311 Storage on the device may be limited. High volumes of logging may 2312 quickly fill available storage, in which case there are two 2313 options: new logs overwrite old logs (possibly via the use of a 2314 circular memory buffer or log file rotation), or logging stops. 2316 2.11.5 Ability to Maintain Accurate System Time 2318 Requirement. The device MUST maintain accurate, "high resolution" 2319 (see definition in Section 1.8) system time. 2321 Justification. 2323 Accurate time is important to the generation of reliable log data. 2324 Accurate time is also important to the correct operation of some 2325 authentication mechanisms. 2327 Examples. 2329 This requirement may be satisfied by supporting Network Time 2330 Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct 2331 connection to an accurate time source. 2333 Warnings. 2335 System clock chips are inaccurate to varying degrees. System time 2336 should not be relied upon unless it is regularly checked and 2337 synchronized with a known, accurate external time source (such as 2338 an NTP stratum-1 server). Also note that if network time 2339 synchronization is used, an attacker may be able to manipulate the 2340 clock unless cryptographic authentication is used. 2342 2.11.6 Display Timezone And UTC Offset 2344 Requirement. 2346 All displays and logs of system time MUST include a timezone or 2347 offset from UTC. 2349 Justification. 2351 Knowing the timezone or UTC offset makes correlation of data and 2352 coordination with data in other timezones possible. 2354 Examples. 2356 Bob is in Newfoundland, Canada which is UTC -3:30. Alice is 2357 somewhere in Indiana, USA. Some parts of Indiana switch to 2358 daylight savings time while others do not. A user on Bob's 2359 network attacks a user on Alice's network. Both are using logs 2360 with local timezones and no indication of UTC offset. Correlating 2361 these logs will be difficult and error prone. Including timezone, 2362 or better, UTC offset, eliminates these difficulties. 2364 Warnings. 2366 None. 2368 2.11.7 Default Timezone Should Be UTC 2370 Requirement. 2372 The default timezone for display and logging SHOULD be UTC. The 2373 device MAY support a mechanism to allow the operator to specify 2374 the display and logging of times in a timezone other than UTC. 2376 Justification. 2378 Knowing the timezone or UTC offset makes correlation of data and 2379 coordination with data in other timezones possible. 2381 Examples. 2383 Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or 2384 UTC -6 depending on the time of year and exact county in Indiana) 2385 are working an incident together using their logs. Both left the 2386 default settings, which was UTC, so there was no translation of 2387 time necessary to correlate the logs. 2389 Warnings. 2391 None. 2393 2.11.8 Logs Must Be Timestamped 2395 Requirement. 2397 By default, the device MUST timestamp all log messages. The 2398 timestamp MUST be accurate to within a second or less. The 2399 timestamp MUST include a timezone. There MAY be a mechanism to 2400 disable the generation of timestamps. 2402 Justification. 2404 Accurate timestamps are necessary for correlating events, 2405 particularly across multiple devices or with other organizations. 2406 This applies when it is necessary to analyze logs. 2408 Examples. 2410 This requirement MAY be satisfied by writing timestamps into 2411 syslog messages. 2413 Warnings. 2415 It is difficult to correlate logs from different time zones. 2416 Security events on the Internet often involve machines and logs 2417 from a variety of physical locations. For that reason, UTC is 2418 preferred, all other things being equal. 2420 2.11.9 Logs Contain Untranslated IP Addresses 2422 Requirement. 2424 Log messages MUST NOT list translated addresses (DNS names) 2425 associated with the address without listing the untranslated IP 2426 address where the IP address is available to the device generating 2427 the log message. 2429 Justification. 2431 Including IP address of access list violations authentication 2432 attempts, address lease assignments and similar events in logs 2433 enables a level of individual and organizational accountability 2434 and is necessary to enable analysis of network events, incidents, 2435 policy violations, etc. 2437 DNS entries tend to change more quickly than IP block assignments. 2438 This makes the address more reliable for data forensics. 2440 DNS lookups can be slow and consume resources. 2442 Examples. 2444 A failed network login should generate a record with the source 2445 address of the login attempt. 2447 Warnings. 2449 * Source addresses may be spoofed. Network-based attacks often 2450 use spoofed source addresses. Source addresses should not be 2451 completely trusted unless verified by other means. 2453 * Addresses may be reassigned to different individual, for 2454 example, in a desktop environment using DHCP. In such cases the 2455 individual accountability afforded by this requirement is weak. 2456 Having accurate time in the logs increases the chances that the 2457 use of an address can be correlated to an individual. 2459 * Network topologies may change. Even in the absence of dynamic 2460 address assignment, network topologies and address block 2461 assignments do change. Logs of an attack one month ago may not 2462 give an accurate indication of which host, network or 2463 organization owned the system(s) in question at the time. 2465 2.11.10 Logs Contain Records Of Security Events 2467 Requirement. 2469 The device MUST be able to send a record of at least the following 2470 events: 2472 * authentication successes, 2474 * authentication failures, 2476 * session Termination, 2478 * authorization changes, 2480 * configuration changes, 2482 * device status changes. 2484 The device SHOULD be able to send a record of all other security 2485 related events. 2487 Justification. 2489 This is important because it supports individual accountability. 2490 See section 4.5.4.4 of [RFC2196]. 2492 Examples. 2494 Examples of events for which there must be a record include: user 2495 logins, bad login attempts, logouts, user privilege level changes, 2496 individual configuration commands issued by users and system 2497 startup/shutdown events. 2499 Warnings. 2501 This list is far from complete. 2503 Note that there may be privacy or legal considerations when 2504 logging/monitoring user activity. 2506 2.11.11 Logs Do Not Contain Passwords 2508 Requirement. 2510 Passwords SHOULD be excluded from all audit records, including 2511 records of successful or failed authentication attempts. 2513 Justification. 2515 Access control and authorization requirements differ for 2516 accounting records (logs) and authorization databases (passwords). 2517 Logging passwords may grant unauthorized access to individuals 2518 with access to the logs. Logging failed passwords may give hints 2519 about actual passwords. See section 4.5.4.4 of [RFC2196]. 2521 Examples. 2523 A user may make small mistakes in entering a password such as 2524 using incorrect capitalization ("my password" vs. "My Password"). 2526 Warnings. 2528 There may be situations where it is appropriate/required to log 2529 passwords. 2531 2.12 Authentication, Authorization, and Accounting (AAA) Requirements 2533 2.12.1 Authenticate All User Access 2535 Requirement. 2537 The device MUST provide a facility to perform authentication of 2538 all user access to the system. 2540 Justification. 2542 This functionality is required so that access to the system can be 2543 restricted to authorized personnel. 2545 Examples. 2547 This requirement MAY be satisfied by implementing a centralized 2548 authentication system. See Section 2.12.5. It MAY also be 2549 satisfied using local authentication. See Section 2.12.6. 2551 Warnings. 2553 None. 2555 2.12.2 Support Authentication of Individual Users 2557 Requirement. 2559 Mechanisms used to authenticate interactive access for 2560 configuration and management MUST support the authentication of 2561 distinct, individual users. This requirement MAY be relaxed to 2562 support system installation Section 2.4.5 or recovery of 2563 authorized access Section 2.12.15. 2565 Justification. 2567 The use of individual accounts, in conjunction with logging, 2568 promotes accountability. The use of group or default accounts 2569 undermines individual accountability. 2571 Examples. 2573 A user may need to log in to the device to access CLI functions 2574 for management. Individual user authentication could be provided 2575 by a centralized authentication server or a username/password 2576 database stored on the device. It would be a violation of this 2577 rule for the device to only support a single "account" (with or 2578 without a username) and a single password shared by all users to 2579 gain administrative access. 2581 Warnings. 2583 This simply requires that the mechanism to support individual 2584 users be present. Policy (e.g., forbidding shared group accounts) 2585 and enforcement are also needed but beyond the scope of this 2586 document. 2588 2.12.3 Support Simultaneous Connections 2590 Requirement. 2592 The device MUST support multiple simultaneous connections by 2593 distinct users, possibly at different authorization levels. 2595 Justification. 2597 This allows multiple people to perform authorized management 2598 functions simultaneously. This also means that attempted 2599 connections by unauthorized users do not automatically lock out 2600 authorized users. 2602 Examples. 2604 None. 2606 Warnings. 2608 None. 2610 2.12.4 Ability to Disable All Local Accounts 2612 Requirement. 2614 The device MUST provide a means of disabling all local accounts 2615 including: 2617 * local users, 2619 * default accounts (vendor, maintenance, guest, etc.), 2621 * privileged and unprivileged accounts. 2623 A local account defined as one where all information necessary for 2624 user authentication is stored on the device. 2626 Justification. 2628 Default accounts, well-known accounts, and old accounts provide 2629 easy targets for someone attempting to gain access to a device. It 2630 must be possible to disable them to reduce the potential 2631 vulnerability. 2633 Examples. 2635 The implementation depends on the types of authentication 2636 supported by the device. 2638 Warnings. 2640 None. 2642 2.12.5 Support Centralized User Authentication Methods 2644 Requirement. 2646 The device MUST support a method of centralized authentication of 2647 all user access via standard authentication protocols. 2649 Justification. 2651 Support for centralized authentication is particularly important 2652 in large environments where the network devices are widely 2653 distributed and where many people have access to them. This 2654 reduces the effort needed to effectively restrict and track access 2655 to the system by authorized personnel. 2657 Examples. 2659 This requirement can be satisfied through the use of DIAMETER 2660 [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos 2661 [RFC1510]. 2663 The secure management requirements (Section 2.1.1) apply to AAA. 2665 See [RFC3579] for a discussion security issues related to RADIUS. 2667 Warnings. 2669 None. 2671 2.12.6 Support Local User Authentication Method 2673 Requirement. 2675 The device SHOULD support a local authentication method. If 2676 implemented, the method MUST NOT require interaction with anything 2677 external to the device (such as remote AAA servers), and MUST 2678 work in conjunction with Section 2.3.1 (Support a 'Console' 2679 Interface) and Section 2.12.7 (Support Configuration of Order of 2680 Authentication Methods). 2682 Justification. 2684 Support for local authentication may be required in smaller 2685 environments where there may be only a few devices and a limited 2686 number of people with access. The overhead of maintaining 2687 centralized authentication servers may not be justified. 2689 Examples. 2691 The use of local, per-device usernames and passwords provides one 2692 way to implement this requirement. 2694 Warnings. 2696 Authentication information must be protected wherever it resides. 2697 Having, for instance, local usernames and passwords stored on 100 2698 network devices means that there are 100 potential points of 2699 failure where the information could be compromised vs. storing 2700 authentication data centralized server(s), which would reduce the 2701 potential points of failure to the number of servers and allow 2702 protection efforts (system hardening, audits, etc.) to be focused 2703 on, at most, a few servers. 2705 2.12.7 Support Configuration of Order of Authentication Methods 2707 Requirement. 2709 The device MUST support the ability to configure the order in 2710 which supported authentication methods are attempted. 2711 Authentication SHOULD "fail closed", i.e. access should be denied 2712 if none of the listed authentication methods succeeds. 2714 Justification. 2716 This allows the operator flexibility in implementing appropriate 2717 security policies that balance operational and security needs. 2719 Examples. 2721 If, for example, a device supports RADIUS authentication and local 2722 usernames and passwords, it should be possible to specify that 2723 RADIUS authentication should be attempted if the servers are 2724 available, and that local usernames and passwords should be used 2725 for authentication only if the RADIUS servers are not available. 2726 Similarly, it should be possible to specify that only RADIUS or 2727 only local authentication be used. 2729 Warnings. 2731 None. 2733 2.12.8 Ability To Authenticate Without Plaintext Passwords 2735 Requirement. 2737 The device MUST support mechanisms that do not require the 2738 transmission of plaintext passwords in all cases that require the 2739 transmission of authentication information across networks. 2741 Justification. 2743 Plaintext passwords can be easily observed using packet sniffers 2744 on shared networks. See [RFC1704] and [RFC3631] for a through 2745 discussion. 2747 Examples. 2749 Remote login requires the transmission of authentication 2750 information across networks. Telnet transmits plaintext passwords. 2751 SSH does not. Telnet fails this requirement. SSH passes. 2753 Warnings. 2755 None. 2757 2.12.9 No Default Passwords 2759 Requirement. 2761 The initial configuration of the device MUST NOT contain any 2762 default passwords or other authentication tokens. 2764 Justification. 2766 Default passwords provide an easy way for attackers to gain 2767 unauthorized access to the device. 2769 Examples. 2771 Passwords such as the name of the vendor, device, "default", etc. 2772 are easily guessed. The SNMP community strings "public" and 2773 "private" are well known defaults that provide read and write 2774 access to devices. 2776 Warnings. 2778 Lists of default passwords for various devices are readily 2779 available at numerous websites. 2781 2.12.10 Passwords Must Be Explicitly Configured Prior To Use 2783 Requirement. 2785 The device MUST require the operator to explicitly configure 2786 "passwords" prior to use. 2788 Justification. 2790 This requirement is intended to prevent unauthorized management 2791 access. Requiring the operator to explicitly configure passwords 2792 will tend to have the effect of ensuring a diversity of passwords. 2793 It also shifts the responsibility for password selection to the 2794 user. 2796 Examples. 2798 Assume that a device comes with console port for management and a 2799 default administrative account. This requirement together with No 2800 Default Passwords says that the administrative account should come 2801 with no password configured. One way of meeting this requirement 2802 would be to have the device require the operator to choose a 2803 password for the administrative account as part of a dialog the 2804 first time the device is configured. 2806 Warnings. 2808 While this device requires operators to set passwords, it does not 2809 prevent them from doing things such as using scripts to configure 2810 hundreds of devices with the same easily guessed passwords. 2812 2.12.11 Ability to Define Privilege Levels 2814 Requirement. 2816 It MUST be possible to define arbitrary subsets of all management 2817 and configuration functions and assign them to groups or 2818 "privilege levels", which can be assigned to users per Section 2819 2.12.12. There MUST be at least three possible privilege levels. 2821 Justification. 2823 This requirement supports the implementation of the principal of 2824 "least privilege", which states that an individual should only 2825 have the privileges necessary to execute the operations he/she is 2826 required to perform. 2828 Examples. 2830 Examples of privilege levels might include "user" which only 2831 allows the initiation of a PPP or telnet session, "read only", 2832 which allows read-only access to device configuration and 2833 operational statistics, "root/superuser/administrator" which 2834 allows update access to all configurable parameters, and 2835 "operator" which allows updates to a limited, user defined set of 2836 parameters. Note that privilege levels may be defined locally on 2837 the device or on centralized authentication servers. 2839 Warnings. 2841 None. 2843 2.12.12 Ability to Assign Privilege Levels to Users 2845 Requirement. 2847 The device MUST be able to assign a defined set of authorized 2848 functions, or "privilege level", to each user once they have 2849 authenticated themselves to the device. Privilege level 2850 determines which functions a user is allowed to execute. Also 2851 see Section 2.12.11. 2853 Justification. 2855 This requirement supports the implementation of the principal of 2856 "least privilege", which states that an individual should only 2857 have the privileges necessary to execute the operations he/she is 2858 required to perform. 2860 Examples. 2862 The implementation of this requirement will obviously be closely 2863 coupled with the authentication mechanism. If RADIUS is used, an 2864 attribute could be set in the user's RADIUS profile that can be 2865 used to map the ID to a certain privilege level. 2867 Warnings. 2869 None. 2871 2.12.13 Default Privilege Level Must Be 'None' 2873 Requirement. 2875 The default privilege level SHOULD NOT allow any access to 2876 management or configuration functions. It MAY allow access to 2877 user-level functions (e.g. starting PPP or telnet). It SHOULD be 2878 possible to assign a different privilege level as the default. 2879 This requirement MAY be relaxed to support system installation per 2880 Section 2.4.5 or recovery of authorized access per Section 2881 2.12.15. 2883 Justification. 2885 This requirement supports the implementation of the principal of 2886 "least privilege", which states that an individual should only 2887 have the privileges necessary to execute the operations he/she is 2888 required to perform. 2890 Examples. 2892 Examples of privilege levels might include "user" which only 2893 allows the initiation of a PPP or telnet session, "read-only", 2894 which allows read-only access to device configuration and 2895 operational statistics, "root/superuser/administrator" which 2896 allows update access to all configurable parameters, and 2897 "operator" which allows updates to a limited, user defined set of 2898 parameters. Note that privilege levels may be defined locally on 2899 the device or on centralized authentication servers. 2901 Warnings. 2903 It may be required to provide exceptions to support the 2904 requirements to support recovery of privileged access (Section 2905 2.12.15) and to support OS installation and configuration (Section 2906 2.4.5), For example, if the OS and/or configuration has somehow 2907 become corrupt an authorized individual with physical access may 2908 need to have "root" level access to perform an install. 2910 2.12.14 Change in Privilege Levels Requires Re-Authentication 2911 Requirement. 2913 The device MUST re-authenticate a user prior to granting any 2914 change in user authorizations. 2916 Justification. 2918 This requirement ensures that users are able to perform only 2919 authorized actions. 2921 Examples. 2923 This requirement might be implemented by assigning base privilege 2924 levels to all users and allowing the user to request additional 2925 privileges, with the requests validated by the AAA server. 2927 Warnings. 2929 None. 2931 2.12.15 Support Recovery Of Privileged Access 2933 Requirement. 2935 The device MUST support a mechanism to allow authorized 2936 individuals to recover full privileged administrative access in 2937 the event that access is lost. Use of the mechanism MUST require 2938 physical access to the device. There MAY be a mechanism for 2939 disabling the recovery feature. 2941 Justification. 2943 There are times when local administrative passwords are forgotten, 2944 when the only person who knows them leaves the company, or when 2945 hackers set or change the password. In all these cases, 2946 legitimate administrative access to the device is lost. There 2947 should be a way to recover access. Requiring physical access to 2948 invoke the procedure makes it less likely that it will be abused. 2949 Some organizations may want an even higher level of security and 2950 be willing to risk total loss of authorized access by disabling 2951 the recovery feature, even for those with physical access. 2953 Examples. 2955 Some examples of ways to satisfy this requirement are to have the 2956 device give the user the chance to set a new administrative 2957 password when: 2959 * The user sets a jumper on the system board to a particular 2960 position. 2962 * The user sends a special sequence to the RS232 console port 2963 during the initial boot sequence. 2965 * The user sets a "boot register" to a particular value. 2967 Warnings. 2969 This mechanism, by design, provides a "back door" to complete 2970 administrative control of the device and may not be appropriate 2971 for environments where those with physical access to the device 2972 can not be trusted. 2974 Also see the warnings in Section 2.3.1 (Support a 'Console' 2975 Interface). 2977 2.13 Layer 2 Devices Must Meet Higher Layer Requirements 2979 Requirement. 2981 If a device provides layer 2 services that are dependent on layer 2982 3 or greater services, then the portions that operate at or above 2983 layer 3 MUST conform to the requirements listed in this document. 2985 Justification. 2987 All layer 3 devices have similar security needs and should be 2988 subject to similar requirements. 2990 Examples. 2992 Signaling protocols required for layer 2 switching may exchange 2993 information with other devices using layer 3 communications. In 2994 such cases, the device must provide a secure layer 3 facility. 2995 Also, if higher layer capabilities (say, SSH or SNMP) are used to 2996 manage a layer 2 device, then the rest of the requirements in this 2997 document apply to those capabilities. 2999 Warnings. 3001 None. 3003 2.14 Security Features Must Not Cause Operational Problems 3005 Requirement. 3007 The use of security features specified by the requirements in this 3008 document SHOULD NOT cause severe operational problems. 3010 Justification. 3012 Security features which cause operational problems are not useful 3013 and may leave the operator with no mechanism for enforcing 3014 appropriate policy. 3016 Examples. 3018 Some examples of severe operational problems include: 3020 * The device crashes. 3022 * The device becomes unmanageable. 3024 * Data is lost. 3026 * Use of the security feature consumes excessive resources (CPU, 3027 memory, bandwidth). 3029 Warnings. 3031 Determination of compliance with this requirement involves a level 3032 of judgment. What is "severe"? Certainly crashing is severe, but 3033 what about a %5 loss in throughput when logging is enabled? It 3034 should also be noted that there may be unavoidable physical 3035 limitations such as the total capacity of a link. 3037 2.15 Security Features Should Have Minimal Performance Impact 3039 Requirement. 3041 Security features specified by the requirements in this document 3042 SHOULD be implemented with minimal impact on performance. Other 3043 sections of this document may specify different performance 3044 requirements (e.g. "MUST"s). 3046 Justification. 3048 Security features which significantly impact performance may leave 3049 the operator with no mechanism for enforcing appropriate policy. 3051 Examples. 3053 If the application of filters is known to have the potential to 3054 significantly reduce throughput for non-filtered traffic, there 3055 will be a tendency, or in some cases a policy, not to use filters. 3057 Assume, for example, that a new worm is released that scans random 3058 IP addresses looking for services listening on TCP port 1433. An 3059 operator might want to investigate to see if any of the hosts on 3060 their networks were infected and trying to spread the worm. One 3061 way to do this would be to put up non-blocking filters counting 3062 and logging the number of outbound connection 1433, and then to 3063 block the requests that are determined to be from infected hosts. 3064 If any of these capabilities (filtering, counting, logging) have 3065 the potential to impose severe performance penalties, then this 3066 otherwise rational course of action might not be possible. 3068 Warnings. 3070 Requirements for which performance is a particular concern 3071 include: filtering, rate-limiting, counters, logging and 3072 anti-spoofing. 3074 3. Documentation Requirements 3076 The requirements in this section are intended to list information 3077 that will assist operators in evaluating and securely operating a 3078 device. 3080 3.1 Identify Services That May Be Listening 3082 Requirement. 3084 The vendor MUST provide a list of all services that may be active 3085 on the device. The list MUST identify the protocols and default 3086 ports (if applicable) on which the services listen. It SHOULD 3087 provide references to complete documentation describing the 3088 service. 3090 Justification. 3092 This information is necessary to enable a thorough assessment of 3093 the potential security risks associated with the operation of each 3094 service. 3096 Examples. 3098 The list will likely contain network and transport protocols such 3099 as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF, 3100 application protocols such as SSH and SNMP along with references 3101 to the RFCs or other documentation describing the versions of the 3102 protocols implemented. 3104 Web servers "usually" listen on port 80. In the default 3105 configuration of the device, it may have a web server listening on 3106 port 8080. In the context of this requirement "identify ... 3107 default port" would mean "port 8080". 3109 Warnings. 3111 There may be valid, non-technical reasons for not disclosing the 3112 specifications of proprietary protocols. In such cases, all that 3113 needs to be disclosed is the existence of the service and the 3114 default ports (if applicable). 3116 3.2 Document Service Defaults 3118 Requirement. 3120 The vendor MUST provide a list of the default state of all 3121 services. 3123 Justification. 3125 Understanding risk requires understanding exposure. Each service 3126 that is enabled presents a certain level of exposure. Having a 3127 list of the services that is enabled by default makes it possible 3128 to perform meaningful risk analysis. 3130 Examples. 3132 The list may be no more than the output of a command that 3133 implements Section 2.5.1. 3135 Warnings. 3137 None. 3139 3.3 Document Service Activation Process 3141 Requirement. 3143 The vendor MUST concisely document which features enable and 3144 disable services. 3146 Justification. 3148 Once risk has been assessed, this list provides the operator a 3149 quick means of understanding how to disable (or enable) undesired 3150 (or desired) services. 3152 Examples. 3154 This may be a list of commands to enable/disable services one by 3155 one or a single command which enables/disables "standard" groups 3156 of commands. 3158 Warnings. 3160 None. 3162 3.4 Document Command Line Interface 3163 Requirement. 3165 The vendor MUST provide complete documentation of the command line 3166 interface with each software release. The documentation SHOULD 3167 include highlights of changes from previous versions. The 3168 documentation SHOULD list potential output for each command. 3170 Justification. 3172 Understanding of inputs and outputs is necessary to support 3173 scripting. See Section 2.4.2. 3175 Examples. 3177 Separate documentation should be provided for each command listing 3178 the syntax, parameters, options, etc. as well as expected output 3179 (status, tables, etc.). 3181 Warnings. 3183 None. 3185 3.5 'Console' Default Communication Profile Documented 3187 Requirement. 3189 The console default profile of communications parameters MUST be 3190 published in the system documentation. 3192 Justification. 3194 Publication in the system documentation makes the settings 3195 accessible. Failure to publish them could leave the operator 3196 having to guess. 3198 Examples. 3200 None. 3202 Warnings. 3204 None. 3206 4. Assurance Requirements 3208 The requirements in this section are intended to 3210 o identify behaviors and information that will increase confidence 3211 that the device will meet the security functional requirements. 3213 o Provide information that will assist in the performance of 3214 security evaluations. 3216 4.1 Identify Origin of IP Stack 3218 Requirement. 3220 The vendor SHOULD disclose the origin or basis of the IP stack 3221 used on the system. 3223 Justification. 3225 This information is required to better understand the possible 3226 security vulnerabilities that may be inherent in the IP stack. 3228 Examples. 3230 "The IP stack was derived from BSD 4.4", or "The IP stack was 3231 implemented from scratch." 3233 Warnings. 3235 Many IP stacks make simplifying assumptions about how an IP packet 3236 should be formed. A malformed packet can cause unexpected behavior 3237 in the device, such as a system crash or buffer overflow which 3238 could result in unauthorized access to the system. 3240 4.2 Identify Origin of Operating System 3242 Requirement. 3244 The vendor SHOULD disclose the origin or basis of the operating 3245 system (OS). 3247 Justification. 3249 This information is required to better understand the security 3250 vulnerabilities that may be inherent to the OS based on its 3251 origin. 3253 Examples. 3255 "The operating system is based on Linux kernel 2.4.18." 3257 Warnings. 3259 None. 3261 5. Security Considerations 3263 General 3265 Security is the subject matter of this entire memo. The 3266 justification section of each individual requirement lists the 3267 security implications of meeting or not meeting the requirement. 3269 SNMP 3271 SNMP versions prior to SNMPv3 did not include adequate security. 3272 Even if the network itself is secure (for example by using IPSec), 3273 even then, there is no control as to who on the secure network is 3274 allowed to access and GET/SET (read/change/create/delete) the 3275 objects in the MIB. 3277 It is recommended that implementors consider the security features 3278 as provided by the SNMPv3 framework (see [RFC3410], section 8), 3279 including full support for the SNMPv3 cryptographic mechanisms 3280 (for authentication and privacy). 3282 Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT 3283 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 3284 enable cryptographic security. It is then a customer/operator 3285 responsibility to ensure that the SNMP entity giving access to MIB 3286 objects is properly configured to give access to the objects only 3287 to those principals (users) that have legitimate rights to indeed 3288 GET or SET (change/create/delete) them. 3290 Normative References 3292 [ANSI.X9-52.1998] 3293 American National Standards Institute, "Triple Data 3294 Encryption Algorithm Modes of Operation", ANSI X9.52, 3295 1998. 3297 [FIPS.197] 3298 National Institute of Standards and Technology, "Advanced 3299 Encryption Standard", FIPS PUB 197, November 2001, . 3302 [PKCS.3.1993] 3303 RSA Laboratories, "Diffie-Hellman Key-Agreement Standard, 3304 Version 1.4", PKCS 3, November 1993. 3306 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 3307 RFC 1208, March 1991. 3309 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3310 April 1992. 3312 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 3313 TACACS", RFC 1492, July 1993. 3315 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 3316 Authentication Service (V5)", RFC 1510, September 1993. 3318 [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", 3319 RFC 1704, October 1994. 3321 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 3322 1812, June 1995. 3324 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 3325 E. Lear, "Address Allocation for Private Internets", BCP 3326 5, RFC 1918, February 1996. 3328 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3329 3", BCP 9, RFC 2026, October 1996. 3331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3332 Requirement Levels", BCP 14, RFC 2119, March 1997. 3334 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 3335 1997. 3337 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 3339 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 3340 January 1999. 3342 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 3343 Signature Option", RFC 2385, August 1998. 3345 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 3346 Internet Protocol", RFC 2401, November 1998. 3348 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 3349 2631, June 1999. 3351 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3352 Defeating Denial of Service Attacks which employ IP Source 3353 Address Spoofing", BCP 38, RFC 2827, May 2000. 3355 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 3356 "Remote Authentication Dial In User Service (RADIUS)", RFC 3357 2865, June 2000. 3359 [RFC3013] Killalea, T., "Recommended Internet Service Provider 3360 Security Services and Procedures", BCP 46, RFC 3013, 3361 November 2000. 3363 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 3364 2001. 3366 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 3367 (SHA1)", RFC 3174, September 2001. 3369 [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3370 3195, November 2001. 3372 [RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control 3373 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 3374 September 2002. 3376 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 3377 2002. 3379 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 3380 BCP 60, RFC 3360, August 2002. 3382 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 3383 "Introduction and Applicability Statements for 3384 Internet-Standard Management Framework", RFC 3410, 3385 December 2002. 3387 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An 3388 Architecture for Describing Simple Network Management 3389 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 3390 December 2002. 3392 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 3393 Standards (PKCS) #1: RSA Cryptography Specifications 3394 Version 2.1", RFC 3447, February 2003. 3396 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 3397 Signature Option", RFC 3562, July 2003. 3399 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 3400 Dial In User Service) Support For Extensible 3401 Authentication Protocol (EAP)", RFC 3579, September 2003. 3403 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 3404 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3406 [RFC3631] Bellovin, S. and J. Schiller, "Security Mechanisms for the 3407 Internet", RFC 3631, December 2003. 3409 Non-normative References 3411 [I-D.ietf-bmwg-acc-bench-framework] 3412 Poretsky, S., "Framework for Accelerated Stress 3413 Benchmarking", draft-ietf-bmwg-acc-bench-framework-00 3414 (work in progress), October 2003. 3416 [I-D.orman-public-key-lengths] 3417 Orman, H. and P. Hoffman, "Determining Strengths For 3418 Public Keys Used For Exchanging Symmetric Keys", 3419 draft-orman-public-key-lengths-08 (work in progress), 3420 February 2004. 3422 [I-D.savola-bcp38-multihoming-update] 3423 Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3424 Networks", draft-savola-bcp38-multihoming-update-03 (work 3425 in progress), December 2003. 3427 [Schneier] 3428 Schneier, B., "Applied Crytography, 2nd Ed., Publisher 3429 John Wiley & Sons, Inc.", 1996. 3431 Author's Address 3433 George M. Jones, Editor 3434 The MITRE Corporation 3435 7515 Colshire Drive, M/S WEST 3436 McLean, Virginia 22102-7508 3437 U.S.A. 3439 Phone: +1 703 488 9740 3440 EMail: gmjones@mitre.org 3442 Appendix A. Requirement Profiles 3444 This Appendix lists different profiles. A profile is a list of list 3445 of requirements that apply to a particular class of devices. The 3446 minimum requirements profile applies to all devices. 3448 A.1 Minimum Requirements Profile 3450 The functionality listed here represents a minimum set of 3451 requirements to which managed infrastructure of large IP networks 3452 should adhere. 3454 The minimal requirements profile addresses functionality which will 3455 provide reasonable capabilities to manage the devices in the event of 3456 attacks, simplify troubleshooting, keep track of events which affect 3457 system integrity, help analyze causes of attacks, as well as provide 3458 administrators control over IP addresses and protocols to help 3459 mitigate the most common attacks and exploits. 3461 o Support Secure Channels For Management 3463 o Use Protocols Subject To Open Review For Management 3465 o Use Cryptographic Algorithms Subject To Open Review 3467 o Use Strong Cryptography 3469 o Allow Selection of Cryptographic Parameters 3471 o Management Functions Should Have Increased Priority 3473 o Support a 'Console' Interface 3475 o 'Console' Communication Profile Must Support Reset 3477 o 'Console' Default Communication Profile Documented 3479 o 'Console' Requires Minimal Functionality of Attached Devices. 3481 o Support Separate Management Plane IP Interfaces 3483 o No Forwarding Between Management Plane And Other Interfaces 3485 o 'CLI' Provides Access to All Configuration and Management 3486 Functions 3488 o 'CLI' Supports Scripting of Configuration 3489 o 'CLI' Supports Management Over 'Slow' Links 3491 o Document Command Line Interface 3493 o Support Software Installation 3495 o Support Remote Configuration Backup 3497 o Support Remote Configuration Restore 3499 o Support Text Configuration Files 3501 o Ability to Identify All Listening Services 3503 o Ability to Disable Any and All Services 3505 o Ability to Control Service Bindings for Listening Services 3507 o Ability to Control Service Source Addresses 3509 o Ability to Filter Traffic 3511 o Ability to Filter Traffic TO the Device 3513 o Support Route Filtering 3515 o Ability to Specify Filter Actions 3517 o Ability to Log Filter Actions 3519 o Ability to Filter Without Significant Performance Degradation 3521 o Ability to Specify Filter Log Granularity 3523 o Ability to Filter on Protocols 3525 o Ability to Filter on Addresses 3527 o Ability to Filter on Protocol Header Fields 3529 o Ability to Filter Inbound and Outbound 3531 o Packet Filtering Counter Requirements 3533 o Ability to Display Filter Counters 3535 o Ability to Display Filter Counters per Rule 3536 o Ability to Display Filter Counters per Filter Application 3538 o Ability to Reset Filter Counters 3540 o Filter Counters Must Be Accurate 3542 o Logging Facility Uses Protocols Subject To Open Review 3544 o Logs Sent To Remote Servers 3546 o Ability to Log Locally 3548 o Ability to Maintain Accurate System Time 3550 o Display Timezone And UTC Offset 3552 o Default Timezone Should Be UTC 3554 o Logs Must Be Timestamped 3556 o Logs Contain Untranslated IP Addresses 3558 o Logs Contain Records Of Security Events 3560 o Authenticate All User Access 3562 o Support Authentication of Individual Users 3564 o Support Simultaneous Connections 3566 o Ability to Disable All Local Accounts 3568 o Support Centralized User Authentication Methods 3570 o Support Local User Authentication Method 3572 o Support Configuration of Order of Authentication Methods 3574 o Ability To Authenticate Without Plaintext Passwords 3576 o Passwords Must Be Explicitly Configured Prior To Use 3578 o No Default Passwords 3580 o Ability to Define Privilege Levels 3582 o Ability to Assign Privilege Levels to Users 3583 o Default Privilege Level Must Be 'None' 3585 o Change in Privilege Levels Requires Re-Authentication 3587 o Support Recovery Of Privileged Access 3589 o Logs Do Not Contain Passwords 3591 o Security Features Must Not Cause Operational Problems 3593 o Security Features Should Have Minimal Performance Impact 3595 o Identify Services That May Be Listening 3597 o Document Service Defaults 3599 o Document Service Activation Process 3601 o Identify Origin of IP Stack 3603 o Identify Origin of Operating System 3605 o Identify Origin of IP Stack 3607 o Identify Origin of Operating System 3609 o Layer 2 Devices Must Meet Higher Layer Requirements 3611 A.2 Layer 3 Network Edge Profile 3613 This section builds on the minimal requirements listed in A.1 and 3614 adds more stringent security functionality specific to layer 3 3615 devices which are part of the network edge. The network edge is 3616 typically where much of the filtering and traffic control policies 3617 are implemented. 3619 An edge device is defined as a device that makes up the network 3620 infrastructure and connects directly to customers or peers. This 3621 would include routers connected to peering points, switches 3622 connecting customer hosts, etc. 3624 o Support Automatic Anti-spoofing for Single-Homed Networks 3626 o Support Automatic Discarding Of Bogons and Martians 3628 o Support Counters For Dropped Packets 3629 o Support Rate Limiting 3631 o Support Directional Application Of Rate Limiting Per Interface 3633 o Support Rate Limiting Based on State 3635 o Ability to Filter Traffic THROUGH the Device 3637 Appendix B. Acknowledgments 3639 This document grew out of an internal security requirements document 3640 used by UUNET for testing devices that were being proposed for 3641 connection to the backbone. 3643 The editor gratefully acknowledges the contributions of: 3645 o Greg Sayadian, author of a predecessor of this document. 3647 o Eric Brandwine, a major source of ideas/critiques. 3649 o The MITRE Corporation for supporting continued development of this 3650 document. NOTE: The editor's affiliation with The MITRE 3651 Corporation is provided for identification purposes only, and is 3652 not intended to convey or imply MITRE's concurrence with, or 3653 support for, the positions, opinions or viewpoints expressed by 3654 the editor. 3656 o The former UUNET network security team: Jared Allison, Eric 3657 Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent King, Neil 3658 Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd MacDermid, 3659 Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow, Robert Stone, 3660 Anne Williams, Pete White. 3662 o Others who have provided significant feedback at various stages of 3663 the life of this document are: Ran Atkinson, Fred Baker, Steve 3664 Bellovin, David L. Black, Michael H. Behringer, Matt Bishop, Scott 3665 Blake, Randy Bush, Pat Cain, Ross Callon, Steven Christey, Owen 3666 Delong, Sean Donelan, Robert Elmore, Barbara Fraser, Barry Greene, 3667 Jeffrey Haas, David Harrington, Dan Hollis, Jeffrey Hutzelman, 3668 Merike Kaeo, James Ko, John Kristoff, Chris Lonvick, Chris 3669 Liljenstolpe, James W. Laferriere, Jared Mauch, Perry E. Metzger, 3670 Mike O'Connor, Alan Paller, Rob Pickering, Pekka Savola, Gregg 3671 Schudel, Juergen Schoenwaelder, Don Smith, Rodney Thayer, David 3672 Walters, Joel N. Weber II, Russ White, Anthony Williams, Neal 3673 Ziring. 3675 o Madge B. Harrison and Patricia L. Jones, technical writing review. 3677 o This listing is intended to acknowledge contributions, not to 3678 imply that the individual or organizations approve the content of 3679 this document. 3681 o Apologies to those who commented on/contributed to the document 3682 and were not listed. 3684 Intellectual Property Statement 3686 The IETF takes no position regarding the validity or scope of any 3687 intellectual property or other rights that might be claimed to 3688 pertain to the implementation or use of the technology described in 3689 this document or the extent to which any license under such rights 3690 might or might not be available; neither does it represent that it 3691 has made any effort to identify any such rights. Information on the 3692 IETF's procedures with respect to rights in standards-track and 3693 standards-related documentation can be found in BCP-11. Copies of 3694 claims of rights made available for publication and any assurances of 3695 licenses to be made available, or the result of an attempt made to 3696 obtain a general license or permission for the use of such 3697 proprietary rights by implementors or users of this specification can 3698 be obtained from the IETF Secretariat. 3700 The IETF invites any interested party to bring to its attention any 3701 copyrights, patents or patent applications, or other proprietary 3702 rights which may cover technology that may be required to practice 3703 this standard. Please address the information to the IETF Executive 3704 Director. 3706 Full Copyright Statement 3708 Copyright (C) The Internet Society (2004). All Rights Reserved. 3710 This document and translations of it may be copied and furnished to 3711 others, and derivative works that comment on or otherwise explain it 3712 or assist in its implementation may be prepared, copied, published 3713 and distributed, in whole or in part, without restriction of any 3714 kind, provided that the above copyright notice and this paragraph are 3715 included on all such copies and derivative works. However, this 3716 document itself may not be modified in any way, such as by removing 3717 the copyright notice or references to the Internet Society or other 3718 Internet organizations, except as needed for the purpose of 3719 developing Internet standards in which case the procedures for 3720 copyrights defined in the Internet Standards process must be 3721 followed, or as required to translate it into languages other than 3722 English. 3724 The limited permissions granted above are perpetual and will not be 3725 revoked by the Internet Society or its successors or assignees. 3727 This document and the information contained herein is provided on an 3728 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3729 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3730 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3731 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3732 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3734 Acknowledgment 3736 Funding for the RFC Editor function is currently provided by the 3737 Internet Society.