idnits 2.17.1 draft-ietf-opsec-nmasc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 3, 2006) is 6629 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3871 (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-opsec-framework-01 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC R. Bonica 3 Internet-Draft Juniper Networks 4 Expires: August 7, 2006 S. Ahmed 5 Booz Allen Hamilton 6 February 3, 2006 8 Network Management Access Security Capabilities 9 draft-ietf-opsec-nmasc-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 7, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes how network management stations can 43 communicate with the devices that they manage using either the in- 44 band network, an out-of-band network, or a virtual out-of-band 45 network. This document also evaluates each access method in terms of 46 its security capabilities and lists the device capabilities needed to 47 support each method. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 53 2. Network Management Access Methods . . . . . . . . . . . . . . 3 54 3. In-band Access . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Required Security Capabilities . . . . . . . . . . . . . . 4 57 3.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Out-of-Band Access . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Required Security Capabilities . . . . . . . . . . . . . . 6 61 4.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Virtual Out-of-Band Access . . . . . . . . . . . . . . . . . . 7 63 5.1. Virtual Out-of-Band Access using VPNs . . . . . . . . . . 7 64 5.1.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . 8 65 5.1.2. Required Security Capabilities . . . . . . . . . . . . 9 66 5.1.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.2. Virtual Out-of-Band Access using CoS . . . . . . . . . . . 9 68 5.2.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . 9 69 5.2.2. Required Security Capabilities . . . . . . . . . . . . 10 70 5.2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Intellectual Property and Copyright Statements . . . . . . . . . . 13 80 1. Introduction 82 The Framework for Operational Security Capabilities [4] outlines the 83 proposed effort of the IETF OPSEC working group. This includes 84 producing a series of drafts to codify knowledge gained through 85 operational experience about feature sets that are needed to securely 86 deploy and operate managed network elements providing transit 87 services at the data link and IP layers. Current plans include 88 separate capabilities documents for Packet Filtering; Event Logging; 89 In-Band and Out-of-Band Management; Configuration and Management 90 Interfaces; AAA; and Documentation and Assurance. 92 This document describes in-band management, out-of-band-management, 93 and a hybrid approach, called virtual out-of-band management. 95 1.1. Conventions Used In This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC2119 [1]. 101 2. Network Management Access Methods 103 Network management stations can communicate with the devices that 104 they manage using either the in-band network, an out-of-band network, 105 or a virtual out-of-band network. The following sections describe 106 each of the above mentioned network management access methods. 108 3. In-band Access 110 User1----- R1----User2 111 / \ 112 / \ 113 / \ 114 / \ 115 R2--------R3 116 / \ / \ 117 / \ / \ 118 / \ / \ 119 NMS1 User3 User4 NMS2 121 Figure 1: In-Band Access 122 Figure 1 depicts two network management stations (NMS1 and NMS2) 123 managing three routers (R1-R3). Network management stations use the 124 in-band network to communicate with the routers that they manage. 125 Therefore, network management traffic is intermixed with user traffic 126 on in-band network interfaces. 128 3.1. Vulnerabilities 130 RFC 3871 [2] identifies the following security vulnerabilities 131 associated with in-band management: 133 1. Saturation of customer lines or interfaces can make the device 134 unmanageable unless out-of-band management resources have been 135 reserved. 137 2. Since public interfaces/channels are used, it is possible for 138 attackers to directly address and reach the device and to attempt 139 management functions. 141 3. In-band management traffic on public interfaces may be 142 intercepted, however this would typically require a significant 143 compromise in the routing system. 145 4. Public interfaces used for in-band management may become 146 unavailable due to bugs (e.g., buffer overflows being exploited) 147 while out-of-band interfaces (such as a serial console device) 148 remain available. 150 Expanding upon the final point, listed above, the in-band network can 151 be misconfigured, such that the managed device becomes isolated with 152 regard to the network management stations. Similarly, DoS attacks 153 against the routers or routing protocols, instability in the routing 154 protocols, or other problems could cause the in-band network to 155 become unavailable. When this happens, operators cannot access the 156 router in order to remedy the configuration error. They become 157 reliant upon physical access to the managed device. 159 3.2. Required Security Capabilities 161 RFC 3871 requires the following security capabilities to mitigate the 162 effects of the above mentioned vulnerabilities: 164 1. Increased priority for management traffic. 166 2. Use of strong cryptography 168 3. Selection of cryptographic parameters 169 4. Use of cryptographic algorithms subject to open review 171 5. Use of management protocols subject to open review 173 3.3. Analysis 175 The cryptographic methods mentioned in Section 3.2 prevent users from 176 accessing management functions and eavesdropping on management 177 traffic. The strength of the cryptographic algorithms deployed 178 should be a determined by cost and perceived threat. 180 Increasing the priority of management traffic reduces, but does not 181 eliminate, the risk associated with denial of service attacks against 182 the router's management plane. In order to completely eliminate this 183 risk, a network would have to police high priority traffic at each 184 ingress point as well as elevate the priority of management traffic. 185 See Section 5.2 below and also see section 4 of [5]. 187 None of the capabilities mentioned in Section 3.2 address the final 188 vulnerability mentioned in Section 3.1. Failure of the in-band 189 network will render the network unmanageable. This is an inherent 190 weakness of in-band management. 192 4. Out-of-Band Access 194 NMS1 NMS2 195 \ / 196 Management 197 Network 198 /|\ 199 / | \ 200 / | \ 201 / R1 \ 202 | / \ | 203 | /User \ | 204 |/Network\| 205 R2--------R3 206 / \ / \ 207 / \ / \ 208 / \ / \ 209 NMS1 User3 User4 NMS2 211 Figure 2: Out-of-Band Access 213 Figure 2 also depicts two network management stations managing three 214 routers. In this figure, the network management stations use a 215 dedicated, out-of-band network to communicate with the routers that 216 they manage. 218 Each router maintains a dedicated management interface. The 219 dedicated management interface is connected to the dedicated, out-of- 220 band management network. Management functions are accessible only 221 through the dedicated management interface. They are not accessible 222 through any other interfaces. 224 RFC 3871 assumes the following regarding out-of-band management: 226 - The out-of-band management network is secure 228 - There is no need for encryption of communication on out-of-band 229 management interfaces 231 - Security measures are in place to prevent unauthorized physical 232 access 234 4.1. Vulnerabilities 236 Although RFC 3871 does not explicitly identify this as a 237 vulnerability, if a router maintains only one dedicated management 238 interface, that interface constitutes a single point of failure. If 239 the dedicated management interface fails, the router will become 240 unmanageable (although it will continue to forward traffic). 242 Therefore, a router should maintain at least two connections to the 243 management network. Many networks solve this problem by connecting 244 both the dedicated management interface and a terminal server to the 245 out-of-band management network. 247 4.2. Required Security Capabilities 249 RFC 3871 states that routers must not forward traffic between 250 dedicated management interfaces and non-management interfaces. The 251 router must never forward a datagram received from a non-management 252 interface through the dedicated management interface. Likewise, the 253 router must never forward a datagram received from the dedicated 254 management interface through a non-management interface. 256 Operators should refrain from activating dynamic routing protocols on 257 the dedicated management interface. Alternatively, they should rely 258 upon direct or static routes. If static routes are configured, they 259 should be as specific as possible. 261 4.3. Analysis 263 Out-of-band management networks isolate network users from 264 communication channels that are dedicated to network management. 265 Therefore, network users cannot access management functions, 266 eavesdrop on management traffic or launch denial of service attacks 267 against the network management plane. 269 Although the dedicated management interface is somewhat susceptible 270 to misconfiguration, it is less susceptible because its configuration 271 is so simple (i.e., limited to interface definition and a few static 272 routes). 274 5. Virtual Out-of-Band Access 276 5.1. Virtual Out-of-Band Access using VPNs 278 ----- 280 a\ /mgmt 281 \ / 282 User1---- R1----User2 283 / \ 284 |\a / \ a/| 285 | \ / \ / | 286 --R2--------R3--- 287 mgmt / \ / \ mgmt 288 / \ / \ 289 / \ / \ 290 NMS1 User3 User4 NMS2 292 Figure 3: Virtual Out-of-Band Access using VPNs 294 Figure 3 is identical to Figure 1, except that three loop circuits 295 have been added. Each loop circuit connects an a-end interface to a 296 dedicated management interface. The function of these looping 297 circuits is described below. 299 In the figure, Routers R1-R3 provide a Layer 3 Virtual Private 300 Network (VPN) [3] service. Although the three routers can support a 301 very large number of Virtual Routing and Forwarding (VRF) instances, 302 for the purpose of example, we will say that they support only two. 304 The first VRF supports access to the global Internet. This VRF 305 includes interfaces to User1, User2, User3 and User4. It also 306 contains several gateway interfaces to the global Internet (which are 307 not included in the figure). 309 The second VRF is dedicated to network management traffic. This VRF 310 includes the interfaces to NMS1 and NMS2, as well as the a-end of 311 each looping interface. 313 Each router maintains a dedicated management interface that functions 314 exactly as described in Section 4. Management functions are 315 accessible only through the dedicated management interface. They are 316 not accessible any other interfaces. 318 The dedicated management interface is connected to the a-end of the 319 looping circuit. Therefore, it is accessible only through the 320 management VRF. 322 Note that the this section describes only one method of constructing 323 a virtual out-of-band management network. An operator could 324 construct a virtual out-of-band management network from in-band 325 pseudowires or an in-band Virtual Private LAN Service. (Layer 3 VPN 326 service is not required.) Likewise, the looping interface need not 327 consume two physical ports. The same results can be achieved with a 328 single, channelized interface or an internal interface. 330 5.1.1. Vulnerabilities 332 RFC 3871 is silent regarding virtual out-of-band network management. 333 However, because virtual out-of-band management networks rely upon 334 physically in-band channels, they are susceptible to the following 335 vulnerabilities: 337 1. Saturation of an in-band trunk can make the device unmanageable. 339 2. Management traffic may be intercepted. However this would 340 typically require a significant compromise in the routing system. 342 3. Public interfaces used for management may become unavailable due 343 to attacks, bugs, or similar problems (e.g., buffer overflows 344 being exploited). 346 Expanding upon the final point, listed above, the virtual out-of-band 347 network can be misconfigured, such that the managed device becomes 348 isolated with regard to the network management stations. Similarly, 349 the in-band network may become unavailable due to attacks, bugs, or 350 other problems. When this happens, operators cannot access the 351 router in order to remedy the configuration error. They become 352 reliant upon physical access to the managed device. 354 5.1.2. Required Security Capabilities 356 In order to provide a secure management mechanism, the virtual out- 357 of-band management network must effectively separate the management 358 VPN from all user VPNs. Traffic must never cross from the management 359 VPN to a user VPN or vice versa. 361 Routers must not forward traffic between dedicated management 362 interfaces and non-management interfaces. The router must never 363 forward a datagram received from a non-management interface through 364 the dedicated management interface. Likewise, the router must never 365 forward a datagram received from the dedicated management interface 366 through a non-management interface. 368 Operators should refrain from activating dynamic routing protocols on 369 the dedicated management interface. Alternatively, they should rely 370 upon direct or static routes. If static routes are configured, they 371 should be as specific as possible. 373 Operators may also choose to elevate the priority of management 374 traffic so that it will be preserved during periods of trunk 375 congestion. 377 5.1.3. Analysis 379 None of the capabilities mentioned in Section 5.1.2 address the final 380 vulnerability mentioned in Section 5.1.1. Failure of the virtual 381 out-of-band network will render the network unmanageable. This is an 382 inherent weakness of virtual management. 384 5.2. Virtual Out-of-Band Access using CoS 386 Some significant separation of management traffic may be achieved by 387 assigning all management traffic to a specific Class of Service (CoS) 388 which is separate from the CoS's used for other (particularly user) 389 traffic. Specific link and other resources may then be assigned to 390 the management CoS. Typically this approach may be combined with 391 either in-band management or virtual out-of-band management using 392 VPNs. 394 5.2.1. Vulnerabilities 396 Because virtual out-of-band management networks rely upon physically 397 in-band channels, they are susceptible to the same vulnerabilities 398 discussed in Section 5.1.1 above. 400 5.2.2. Required Security Capabilities 402 In order to provide a secure management mechanism using a separate 403 class of service to create a virtual out-of-band capability, the 404 network must effectively separate the management CoS from all user 405 CoSs. User traffic must never be permitted to use the management 406 CoS. This requires that ALL PE devices be capable of ensuring that 407 user traffic entering the network via that PE be mapped to a non- 408 management CoS. 410 5.2.3. Analysis 412 Failure of the in-band network will render the network unmanageable. 413 This is an inherent weakness of virtual management using CoS. 415 6. Evaluation 417 Based on the analysis above, we conclude that out-of-band management 418 is both more secure and more reliable than either of the other 419 options. However, it is typically more expensive than either of the 420 other options. 422 When out-of-band management does not offer a feasible economic 423 approach, operators must choose between in-band management with 424 cryptographic protection or a virtual out-of-band management network. 425 In either case, the operator must deal with some additional 426 complexity. So, operators should determine which class of threat 427 (DoS, eavesdropping) poses the greatest risk to their network and 428 choose a strategy accordingly. 430 7. Security Considerations 432 Security is the subject matter of this entire memo. 434 8. Acknowledgements 436 The authors gratefully acknowledge the contributions of: 438 o Ross Callon for his comments and suggestions. 440 This listing is intended to acknowledge contributions, not to imply 441 that the individual or organizations approve the content of this 442 document. 444 Apologies to those who commented on/contributed to the document and 445 were not listed. 447 9. References 449 9.1. Normative References 451 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 452 Levels", BCP 14, RFC 2119, March 1997. 454 [2] Jones, G., "Operational Security Requirements for Large Internet 455 Service Provider (ISP) IP Network Infrastructure", RFC 3871, 456 September 2004. 458 [3] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 459 (work in progress), October 2004. 461 9.2. Informative References 463 [4] Jones, G., "Framework for Operational Security Capabilities for 464 IP Network Infrastructure", draft-ietf-opsec-framework-01 (work 465 in progress), October 2005. 467 [5] Callon, R. and G. Jones, "Miscellaneous Capabilities for IP 468 Network Infrastructure", draft-callon-misc-cap-00 (work in 469 progress), October 2005. 471 Authors' Addresses 473 Ronald P. Bonica 474 Juniper Networks 475 2251 Corporate Park Drive 476 Herndon, VA 20171 477 US 479 Email: rbonica@juniper.net 481 Syed F. Ahmed 482 Booz Allen Hamilton 483 8283 Greensboro Drive 484 McLean, VA 22102 485 US 487 Email: ahmed_syed@bah.com 489 Intellectual Property Statement 491 The IETF takes no position regarding the validity or scope of any 492 Intellectual Property Rights or other rights that might be claimed to 493 pertain to the implementation or use of the technology described in 494 this document or the extent to which any license under such rights 495 might or might not be available; nor does it represent that it has 496 made any independent effort to identify any such rights. Information 497 on the procedures with respect to rights in RFC documents can be 498 found in BCP 78 and BCP 79. 500 Copies of IPR disclosures made to the IETF Secretariat and any 501 assurances of licenses to be made available, or the result of an 502 attempt made to obtain a general license or permission for the use of 503 such proprietary rights by implementers or users of this 504 specification can be obtained from the IETF on-line IPR repository at 505 http://www.ietf.org/ipr. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights that may cover technology that may be required to implement 510 this standard. Please address the information to the IETF at 511 ietf-ipr@ietf.org. 513 Disclaimer of Validity 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 518 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 519 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 520 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Copyright Statement 525 Copyright (C) The Internet Society (2006). This document is subject 526 to the rights, licenses and restrictions contained in BCP 78, and 527 except as set forth therein, the authors retain all their rights. 529 Acknowledgment 531 Funding for the RFC Editor function is currently provided by the 532 Internet Society.