OPSEC R. Bonica Internet-Draft Juniper Networks Expires: April 16, 2006 S. Ahmed Booz Allen Hamilton October 13, 2005 Network Management Access Security Capabilities draft-bonica-opsec-nmasc-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes how network management stations can communicate with the devices that they manage using either the in- band network, an out-of-band network, or a virtual out-of-band network. This document also evaluates each access method in terms of its security capabilities and lists the device capabilities needed to support each method. Bonica & Ahmed Expires April 16, 2006 [Page 1]
Internet-Draft Network Management Access October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 2. Network Management Access Methods . . . . . . . . . . . . . . 3 3. In-band Access . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 4 3.2. Required Security Capabilities . . . . . . . . . . . . . . 4 3.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Out-of-Band Access . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 6 4.2. Required Security Capabilities . . . . . . . . . . . . . . 6 4.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Virtual Out-of-band Access . . . . . . . . . . . . . . . . . . 7 5.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 8 5.2. Required Security Capabilities . . . . . . . . . . . . . . 8 5.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Bonica & Ahmed Expires April 16, 2006 [Page 2]
Internet-Draft Network Management Access October 2005 1. Introduction The Framework for Operational Security Capabilities [1] outlines the proposed effort of the IETF OPSEC working group. This includes producing a series of drafts to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. Current plans include separate capabilities documents for Packet Filtering; Event Logging; In-Band and Out-of-Band Management; Configuration and Management Interfaces; AAA; and Documentation and Assurance. This document describes in-band management, out-of-band-management, and a hybrid approach, called virtual out-of-band management. 1.1. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2]. 2. Network Management Access Methods Network management stations can communicate with the devices that they manage using either the in-band network, an out-of-band network, or a virtual out-of-band network. The following sections describe each of the above mentioned network management access methods. 3. In-band Access User1----- R1----User2 / \ / \ / \ / \ R2--------R3 / \ / \ / \ / \ / \ / \ NMS1 User3 User4 NMS2 Figure 1: In-Band Access Figure 1 depicts two network management stations (NMS1 and NMS2) Bonica & Ahmed Expires April 16, 2006 [Page 3]
Internet-Draft Network Management Access October 2005 managing three routers (R1-R3). Network management stations use the in-band network to communicate with the routers that they manage. Therefore, network management traffic is intermixed with user traffic on in-band network interfaces. 3.1. Vulnerabilities RFC 3871 [3] identifies the following security vulnerabilities associated with in-band management: 1. Saturation of customer lines or interfaces can make the device unmanageable unless out-of-band management resources have been reserved. 2. Since public interfaces/channels are used, it is possible for attackers to directly address and reach the device and to attempt management functions. 3. In-band management traffic on public interfaces may be intercepted, however this would typically require a significant compromise in the routing system. 4. Public interfaces used for in-band management may become unavailable due to bugs (e.g., buffer overflows being exploited) while out-of-band interfaces (such as a serial console device) remain available. Expanding upon the final point, listed above, the in-band network can be misconfigured, such that the managed device becomes isolated with regard to the network management stations. When this happens, operators cannot access the router in order to remedy the configuration error. They become reliant upon physical access to the managed device. 3.2. Required Security Capabilities RFC 3871 requires the following security capabilities to mitigate the effects of the above mentioned vulnerabilities: 1. Increased priority for management traffic 2. Use of strong cryptography 3. Selection of cryptographic parameters 4. Use of cryptographic algorithms subject to open review Bonica & Ahmed Expires April 16, 2006 [Page 4]
Internet-Draft Network Management Access October 2005 5. Use of management protocols subject to open review 3.3. Analysis The cryptographic methods mentioned in Section 3.2 prevent users from accessing management functions and eavesdropping on management traffic. The strength of the cryptographic algorithms deployed should be a determined by cost and perceived threat. Increasing the priority of management traffic reduces, but does not eliminate, the risk associated with denial of service attacks against the router's management plane. In order to completely eliminate this risk, a network would have to police high priority traffic at each ingress point as well as elevate the priority of management traffic. None of the capabilities mentioned in Section 3.2 address the final vulnerability mentioned in Section 3.1. Failure of the in-band network will render the network unmanageable. This is an inherent weakness of in-band management. 4. Out-of-Band Access NMS1 NMS2 \ / Management Network /|\ / | \ / | \ / R1 \ | / \ | | /User \ | |/Network\| R2--------R3 / \ / \ / \ / \ / \ / \ NMS1 User3 User4 NMS2 Figure 2: Out-of-Band Access Figure 2 also depicts two network management stations managing three routers. In this figure, the network management stations use a dedicated, out-of-band network to communicate with the routers that they manage. Bonica & Ahmed Expires April 16, 2006 [Page 5]
Internet-Draft Network Management Access October 2005 Each router maintains a dedicated management interface. The dedicated management interface is connected to the dedicated, out-of- band management network. Management functions are accessible only through the dedicated management interface. They are not accessible through any other interfaces. RFC 3871 assumes the following regarding out-of-band management: - The out-of-band management network is secure - There is no need for encryption of communication on out-of-band management interfaces - Security measures are in place to prevent unauthorized physical access 4.1. Vulnerabilities Although RFC 3871 does not explicitly identify this as a vulnerability, if a router maintains only one dedicated management interface, that interface constitutes a single point of failure. If the dedicated management interface fails, the router will become unmanageable (although it will continue to forward traffic). Therefore, a router should maintain at least two connections to the management network. Many networks solve this problem by connecting both the dedicated management interface and a terminal server to the out-of-band management network. 4.2. Required Security Capabilities RFC 3871 states that routers must not forward traffic between dedicated management interfaces and non-management interfaces. The router must never forward a datagram received from a non-management interface through the dedicated management interface. Likewise, the router must never forward a datagram received from the dedicated management interface through a non-management interface. Operators should refrain from activating dynamic routing protocols on the dedicated management interface. Alternatively, they should rely upon direct or static routes. If static routes are configured, they should be as specific as possible. 4.3. Analysis Out-of-band management networks isolate network users from communication channels that are dedicated to network management. Therefore, network users cannot access management functions, Bonica & Ahmed Expires April 16, 2006 [Page 6]
Internet-Draft Network Management Access October 2005 eavesdrop on management traffic or launch denial of service attacks against the network management plane. Although the dedicated management interface is somewhat susceptible to misconfiguration, it is less susceptible because its configuration is so simple (i.e., limited to interface definition and a few static routes). 5. Virtual Out-of-band Access ----- a\ /mgmt \ / User1---- R1----User2 / \ |\a / \ a/| | \ / \ / | --R2--------R3--- mgmt / \ / \ mgmt / \ / \ / \ / \ NMS1 User3 User4 NMS2 Figure 3: Virtual Out-of-Band Access Figure 3 is identical to Figure 1, except that three loop circuits have been added. Each loop circuit connects an a-end interface to a dedicated management interface. The function of these looping circuits is described below. In the figure, Routers R1-R3 provide a Layer 3 Virtual Private Network (VPN) [4] service. Although the three routers can support a very large number of Virtual Routing and Forwarding (VRF) instances, for the purpose of example, we will say that they support only two. The first VRF supports access to the global Internet. This VRF includes interfaces to User1, User2, User3 and User4. It also contains several gateway interfaces to the global Internet (which are not included in the figure). The second VRF is dedicated to network management traffic. This VRF includes the interfaces to NMS1 and NMS2, as well as the a-end of each looping interface. Each router maintains a dedicated management interface that functions Bonica & Ahmed Expires April 16, 2006 [Page 7]
Internet-Draft Network Management Access October 2005 exactly as described in Section 4. Management functions are accessible only through the dedicated management interface. They are not accessible any other interfaces. The dedicated management interface is connected to the a-end of the looping circuit. Therefore, it is accessible only through the management VRF. Note that the this section describes only one method of constructing a virtual out-of-band management network. An operator could construct a virtual out-of-band management network from in-band pseudowires or an in-band Virtual Private LAN Service. (Layer 3 VPN service is not required.) Likewise, the looping interface need not consume two physical ports. The same results can be achieved with a single, channelized interface or an internal interface. 5.1. Vulnerabilities RFC 3871 is silent regarding virtual out-of-band network management. However, because virtual out-of-band management networks rely upon physically in-band channels, they are susceptible to the following vulnerabilities: 1. Saturation of an in-band trunk can make the device unmanageable. 2. Management traffic may be intercepted. However this would typically require a significant compromise in the routing system. 3. Public interfaces used for management may become unavailable due to bugs (e.g., buffer overflows being exploited). Expanding upon the final point, listed above, the virtual out-of-band network can be misconfigured, such that the managed device becomes isolated with regard to the network management stations. When this happens, operators cannot access the router in order to remedy the configuration error. They become reliant upon physical access to the managed device. 5.2. Required Security Capabilities In order to provide a secure management mechanism, the virtual out- of-band management network must effectively separate the management VPN from all user VPNs. Traffic must never cross from the management VPN to a user VPN or vice versa. Routers must not forward traffic between dedicated management interfaces and non-management interfaces. The router must never forward a datagram received from a non-management interface through Bonica & Ahmed Expires April 16, 2006 [Page 8]
Internet-Draft Network Management Access October 2005 the dedicated management interface. Likewise, the router must never forward a datagram received from the dedicated management interface through a non-management interface. Operators should refrain from activating dynamic routing protocols on the dedicated management interface. Alternatively, they should rely upon direct or static routes. If static routes are configured, they should be as specific as possible. Operators may also choose to elevate the priority of management traffic so that it will be preserved during periods of trunk congestion. 5.3. Analysis None of the capabilities mentioned in Section 5.2 address the final vulnerability mentioned in Section 5.1. Failure of the virtual out- of-band network will render the network unmanageable. This is an inherent weakness of virtual management. 6. Evaluation Based on the analysis above, we conclude that out-of-band management is both more secure and more reliable than either of the other options. However, it is typically more expensive than either of the other options. When out-of-band management does not offer a feasible economic approach, operators must choose between in-band management with cryptographic protection or a virtual out-of-band management network. In either case, the operator must deal with some additional complexity. So, operators should determine which class of threat (DoS, eavesdropping) poses the greatest risk to their network and choose a strategy accordingly. 7. Security Considerations Security is the subject matter of this entire memo. 8. Normative References [1] Jones, G., "Framework for Operational Security Capabilities for IP Network Infrastructure", draft-ietf-opsec-framework-00 (work in progress), June 2005. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Bonica & Ahmed Expires April 16, 2006 [Page 9]
Internet-Draft Network Management Access October 2005 Levels", BCP 14, RFC 2119, March 1997. [3] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. [4] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 (work in progress), October 2004. Bonica & Ahmed Expires April 16, 2006 [Page 10]
Internet-Draft Network Management Access October 2005 Authors' Addresses Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US Email: rbonica@juniper.net Syed F. Ahmed Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US Email: ahmed_syed@bah.com Bonica & Ahmed Expires April 16, 2006 [Page 11]
Internet-Draft Network Management Access October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bonica & Ahmed Expires April 16, 2006 [Page 12]