DePaul University Networks and Telecom J. Kristoff Request for Comments: 2 R&D/N&T Category: Informational January, 2002 Class: Public Revision: 1.0 Network Security Principles Status of this Memo This memo provides information for the DePaul University community and does not specify a standard of any kind. Redistribution of this memo is unlimited. Copyright Notice Copyright (C) DePaul University (2002). All rights reserved. Abstract DePaul University and its network security practices are growing in an evolutionary fashion from an initial starting point of a wide open infrastructure to one that is secure from abuse either by accident or intent. While it is important to secure the network infrastructure from attack, it is as important to protect privacy, academic freedom and the unfettered flow of data. Thus, the design and implementation of security mechanisms for the DePaul University network must way in balance these often conflicting qualities of security, freedom and privacy. This memo is intended to be used for general guidance on the design and implementation of network security at DePaul University. Kristoff Informational [Page 1] RFC 2 Network Security Principles January 2002 Table of Contents 1. Defense in Depth............................................2 2. Belt and Suspenders.........................................3 3. Security through Obscurity..................................3 4. Network Layer Security......................................3 4.1. Address Spoofing..........................................3 4.2. Denial of Service.........................................4 4.3. Network Control Protocols.................................5 4.3.1. Address Resolution Protocol.............................5 4.3.2. Internet Control Message Protocol.......................5 4.3.2.1. Source Quench.........................................5 4.3.2.2. Redirect..............................................5 4.3.3. Internet Group Management Protocol......................6 4.3.4. Source Routing..........................................6 4.3.5. Routing Protocols.......................................6 4.4. Fragmentation.............................................7 4.5. Man-in-the-middle.........................................7 4.6. Eavesdropping.............................................7 5. Middle Box Issues...........................................8 5.1. Address Translators.......................................8 5.2. Firewalls.................................................9 5.3. Virtual Private Networks..................................9 5.4. Other Middle Boxes........................................9 6. End-to-end Security........................................10 7. General Design Considerations..............................10 Acknowledgments...............................................10 References....................................................10 Security Considerations.......................................12 Editor's Address..............................................12 1. Defense in Depth In striving for the utmost security of network elements, we must remember that the infrastructure is only as strong as the weakest link in the chain of internetworked components. A good analogy for understanding the consequence of a system ignoring the threat of the weakest link is that of a system employing strong computer security controls, but succumbing to the carelessness of a user. For example, the strongest authentication and encryption mechanisms cannot stop someone from leaving a plain text print-out of the data on the bus on the way into work. The network security principles therefore aim to provide a reasonable framework in light of all potential attacks against a system. Since network security can only protect against attacks on the network layer a more complete security posture is required. One well known solution is a "Defense in Depth" approach, which aims to provide multiple security protections for all links on the chain. From the physical locks to the data handling practices users employ, defense Kristoff Informational [Page 2] RFC 2 Network Security Principles January 2002 in depth is deployed to guard against various kinds of information security attacks. 2. Belt and Suspenders Depth defense helps eliminate weak links on the chain, but any one link is still a single point of failure. Attacks often target a single link in the chain, perhaps because that link is the most visible or perhaps because it is the part of a system an attacker understands best. An accomplished or even determined attacker that is able to compromise even a single link in the chain has still compromised the system even if the other links are intact. To guard against single points of failure, the "Belt and Suspenders" approach to security installs redundant layers of security to the system. The idea being that if your belt gives way, the suspenders are still there to hold your pants up. An analogy for understanding the belt and suspenders approach is when a user must both have something and know something in order to access a system. For example, the user must have a key to turn the knob, but must also know and enter an identification code to release the deadbolt. The belt and suspenders approach forces an attacker to be adept at compromising multiple, different types of security just to compromise a single link in the chain. Even if this approach does not completely stop an attacker it may buy the defender some time to detect and respond to an attack. 3. Security through Obscurity Hiding information and hoping that inherent security weaknesses in system implementations will not be attacked is a popular strategy in dealing with vulnerabilities. Unfortunately, these vulnerabilities usually end up being discovered with devastatingly harmful results. The DePaul University network must not rely on security through obscurity to thwart network attacks. 4. Network Layer Security The DePaul University network layer is usually referred to as the Internet Protocol (IP) layer [RFC791]. Specific observations and conclusions for IP layer security will be described in this section. 4.1. Address Spoofing Hosts that generate IP datagrams should use their locally configured address (or one from the selected interface if applicable) as the source IP address of any datagrams transmitted. While it is sometimes useful for hosts to be able to use another IP address as the source address, the faking or 'spoofing' of source addresses is often used to help support a network-based attack. Kristoff Informational [Page 3] RFC 2 Network Security Principles January 2002 Attackers may spoof source addresses to hide the origin of an attack, often as part of a denial of service as described in the next section. Attackers may also employ spoofed source addresses to circumvent name or address based host authentication schemes [RFC1675]. As described in [RFC2827], network layer routers should implement ingress filtering to prevent invalid source addresses from propagating between subnets or to the public Internet. Egress filtering or reverse path forwarding may also be used to help prevent invalid source addressed datagrams from being forwarded by routers. 4.2. Denial of Service Explicit attempts to prevent legitimate service of network resources are called denial of service (DoS) attacks. This memo describes two general types of DoS attacks that target the network layer. First, a flood of attack packets can prevent legitimate packets from gaining access to the network infrastructure. Second, attack packets can target control protocols and services used by the network, possibly disrupting access by altering the behavior of the network. The control protocols will be handled separately in the next section. Whenever offered load exceeds available capacity an overload condition exists. A network overload or network flood may cause network service interruption if some packets are discarded or delayed. If a network flood is extensive and long lasting, severe interruption is possible as the network forwards fewer and fewer valid packets. Attackers can purposely attempt to overwhelm points in the network that are susceptible to an overload condition. In a simple scenario, an attacker may be capable of generating a rate of traffic higher than the target network can sustain. In another scenario, an attacker may use an amplification technique to generate an even larger load towards the target network. For example, an attacker may issue an ICMP echo request to a directed broadcast address where dozens of hosts reside. If the attacker spoofs the source IP address, each of the hosts on the destination network may all reply in unison to the spoofed source. The spoofed source address in this case would be a victim host, the recipient of an amplification attack using the ICMP echo request/reply service. This particular scenario is well documented and is often called a "smurf" attack based on the name of a tool that was created to implement this style of attack [CA-1998-01]. Network floods due to amplification using directed broadcast addresses should be mitigated by configuring routers not to forward directed broadcast packets across subnets [RFC2644]. Other network floods should be detected and pinpointed by network management tools. Network administrators should keep statistics on aggregate traffic patterns in order to identify anomalies that may indicate a network flooding attack. Kristoff Informational [Page 4] RFC 2 Network Security Principles January 2002 Setting traffic rate limits on network devices is another way to manage overloads when traffic crosses routers from a high-speed link to a low-speed link, but it is not generally recommended. Setting artificial limits on traffic rates or instances of particular protocols can cause unpredictable problems. 4.3. Network Control Protocols A number of protocols used by the network layer must be protected from attack. This section briefly outlines some of the threats and recommendations for specific network layer control protocol security. 4.3.1. Address Resolution Protocol Routers and hosts maintain IP to layer 2 address mappings which are susceptible to poisoning, spoofing and flooding. Protection of the address resolution protocol (ARP) tables, particularly in network layer devices such as routers should be protected from attack [RFC826]. While static address entries could be used to guard against many ARP attacks, the size of the network and the need for mobile hosts make this strategy unworkable from an administration perspective. Network administrators should monitor and track ARP table history for potential abuse. 4.3.2. Internet Control Message Protocol The Internet control message protocol (ICMP) is generally used to issue status and error messages to IP layer or higher protocols [RFC792]. Two particular ICMP type messages are of primary interest to the security of DePaul University's network. They are the source quench and redirect messages. 4.3.2.1. Source Quench Source quench is a rudimentary flow control mechanism for IP hosts. Although some systems still generate source quench messages when they are receiving more packets than they can process, many hosts may choose to ignore them. Due to address spoofing and with the preferred use of other congestion avoidance mechanisms, received ICMP source quench messages should be silently discarded. 4.3.2.2. Redirect ICMP redirect messages are sent by routers to a host when that host should use a different router. Administrators should be suspicious when a host is receiving excessive redirect messages. An attacker may be attempting a "man-in-the-middle" attack or simply trying to "black hole" traffic in an attempt at a DoS. DePaul University network routers should not listen to unauthenticated ICMP redirect messages, Kristoff Informational [Page 5] RFC 2 Network Security Principles January 2002 nor should routers base routing decisions upon received ICMP redirect messages. 4.3.3. Internet Group Management Protocol The Internet group management protocol (IGMP) is used by hosts and routers to support IP multicast group membership [RFC2236]. The university network supports IP multicasting throughout and care must be taken to avoid multicast storms and excessive multicast forwarding state in routers. There are a number of well known multicast groups that should filtered at subnet edges and between ASs [ID-Nickless, Cisco-MSDP-filter]. In addition, network administrators should monitor multicast group membership state and aggregate multicast traffic on network routers for potential abuse. 4.3.4. IP Source Routing An IP option header can be used by a source host to specify the partial or complete route an IP datagram should take. Hosts specifying a route rather than letting routers select a route automatically has a number of useful purposes, however much like address spoofing, this option can be abused by attackers to give the false appearance of where packets are being originated. IP source routing should be disabled within the DePaul University network, but it should be allowed between AS boundaries for purposes of troubleshooting complex paths between the University and external networks. 4.3.5. Routing Protocols IP routing is perhaps the most important function of the network layer at DePaul University. It is of utmost importance that the routing system is resilient to attack. Routing protocols must be configured to support authentication using a keyed MD5 hash (or better algorithm) for all routing update and synchronization packets sent on the network. Routers must not advertise or listen to routing updates on edge networks or on networks where the network staff does not support any routers. Routing processes should not install, accept or advertise invalid routes. This includes, but is not limited to private address space [RFC1918], special use addresses (e.g. 0.0.0.0/8, 127.0.0.0/8, etc.) and IANA reserved address space. Kristoff Informational [Page 6] RFC 2 Network Security Principles January 2002 Inter-AS routing should be very restrictive with routes accepted or advertised to avoid problems due to abuse or accident. Route flap damping should be used on inter-AS connections to avoid excessive route changes from affecting router performance. Network staff should monitor routing table stability throughout the university network in order to ensure attacks against the IP routing infrastructure are prevented. 4.4. Fragmentation IPv4 routers are required to fragment IP datagrams that exceed the maximum transmission unit (MTU) size of the outgoing interface. The fragmentation process can create additional load on the network due to the fragmentation process and protocol overhead used for each successive fragment of the original datagram. While fragmentation must not be disabled, it is best avoided. Network administrators should monitor for the steady state rate of fragments and be able to identify if fragmentation is becoming excessive and potentially abusive. 4.5. Man-in-the-middle An attacker may attempt to insert a compromised host in the path of a victim's communication with the intent of taking over or even just to monitor a session. An attacker who sits between the real endpoints is called a "man-in-the-middle" and in this scenario would be an unauthorized party to the communication session. Protections against address and host spoofing should be used to help mitigate these type of attacks. Digital signatures should be used for connection management, which can help alert users to man-in-the- middle attack attempts. Network staff should educate users about the dangers of accepting connections from hosts with unknown or suspicious security credentials. 4.6. Eavesdropping Many network devices support the ability for a network interface to be run in promiscuous mode, allowing the device to monitor and eavesdrop on all network communications whether or not the host is an intended participant in the network communications path. Many network devices must operate in promiscuous mode in order to operate, thus an inherent level of trust has been assumed in order for the network to operate properly. In addition, some types of data link media are shared among many hosts, making eavesdropping a requirement in order for a host to determine when a packet is intended for itself. Kristoff Informational [Page 7] RFC 2 Network Security Principles January 2002 Attackers may gather sensitive information from network elements by eavesdropping on a conversation somewhere on the communications path. Attackers may compromise key network elements on the communications path or place a host on shared media segments into promiscuous mode. Communicating endpoints should always use encryption to guard against eavesdropping attacks. Eavesdropping must only be used by authorized personnel to support the proper operation of the network or endpoints. Network staff may often capture network traffic for administrative purposes. Network staff must not make publicly available any personal data from any eavesdropping session without the consent of the DePaul University users involved in the communications or without valid legal requests for disclosure. 5. Middle Box Issues The original Internet concept of end-to-end assumes network packets will travel from the original source to the ultimate destination essentially unaltered in transit [E2E]. Recent inventions commonly called "middle boxes" such as network address translators, firewalls, caches and application layer gateways have been developed by the industry for numerous reasons, but all have had an impact that is at odds with the end-to-end concept. The introduction of middle boxes dilutes the significance of a simple network layer as the only feature necessary for internetwork communications. The DePaul University network strives to maintain the transparent end-to-end model throughout its network. This section discusses the concepts and consequences of certain types of middle boxes deployed on a network as they relate to DePaul University network security principles. 5.1. Address Translators Address translators initially arose as a short term solution to the Internet's IPv4 address space shortage problem. Network address translation (NAT), as it is commonly called, is often used to convert private IP address space on one side to public Internet address space on the other. NAT has a number of well known problems that adversely affect the DePaul University network [RFC2993]. Of the most important to DePaul University is that NAT breaks the end-to-end model of the original Internet. NAT complicates the use of end-to-end security and the flexibility of network applications. While NAT inhibits some forms of network communications, NAT should not be used as means to improve the security of the network. Kristoff Informational [Page 8] RFC 2 Network Security Principles January 2002 5.2. Firewalls Administrators have implemented firewalls to keep out unauthorized traffic from a protected network. Firewalls reside on the boundary of a trusted and untrusted pair of networks. Packets that are allowed to pass between the boundaries are strictly controlled by the firewall. Firewalls fundamentally limit the end-to-end model of the original Internet by selecting only certain types of traffic to pass. Firewalls are inherently difficult to deploy and configure since they must interpret the meaning of each network packet. As long as some traffic is allowed to pass, attack traffic may be disguised as conforming traffic to bypass firewall configurations. While firewalls impose limits on the transparency of end-to-end communications, they can be very useful in places where fine grained control over network traffic can be managed. DePaul University may use network firewalls at the edges of its network, but firewalls must not disrupt the use of current or future standard TCP/IP protocols. Furthermore, firewalls must not be used to inhibit the user or application's flexibility to transmit and receive the free flow of data across the University network. 5.3. Virtual Private Networks A virtual private network (VPN) middle box intermediates a connection between two endpoints when a subset of the path travels an untrusted internetwork. VPNs generally employ strong authentication and encryption services to protect packets across the untrusted network. As a middle box, a VPN also acts much like a firewall, providing a boundary between a trusted and untrusted network. However, VPNs usually terminate and initiate protocol endpoints between the original source and destination endpoints. The comments ascribed to firewalls above also apply to VPN middle boxes. An additional caution must be addressed with any VPN deployment at DePaul University. VPN middle boxes represent a significant network security single point of failure. The security of a VPN middle box is reliant on the overall security of each endpoint and user that is configured to make use of its services. 5.4. Other Middle Boxes Middle boxes that divert or significantly alter network layer communications between original source and destination should be avoided. It should also be noted that diversion or alteration of data at any of the protocol layers should generally be avoided. Kristoff Informational [Page 9] RFC 2 Network Security Principles January 2002 As middle boxes lend to network complexity, they increase single points of failure and reduce end-to-end robustness. In general, security can only be completely and correctly implemented on an end-to-end basis. While some middle boxes may be useful, for example, SMTP relays, those at odds with the end-to-end principle should be avoided. 6. End-to-end Security End-to-end applications should use end-to-end security mechanisms such as IPSec, SSL and SSH to protect all network traffic [RFC2401, SSL3, SSH2]. Network connections should also be authenticated using digital signatures. By implementing end-to-end security at the network layer, many of the network layer attacks can be mitigated while still allowing the free flow of data to traverse networks unfettered. 7. General Design Considerations Network security should be implemented where there is an architectural benefit. DePaul University should avoid network security solutions that interfere with the end-to-end transparent model of the Internet. Deployment of middle boxes in the DePaul University network must be carefully scrutinized. Whenever a new network security problem is encountered, Occam's Razor should be a guiding principle in deciding how to address the issue from a network infrastructure perspective. Acknowledgments The concepts in this document echo much of the work done in the Internet community, and in particular the IETF and IAB bodies. References [CA-1998-01] CERT/CC Advisory CA-1998-01, Smurf IP Denial of Service Attacks, 1998. [Cisco-MSDP-filter] Cisco Configuration note, available at: ftp://ftpeng.cisco.com/ipmulticast/ as: config-notes/msdp-sa-filter.txt. [E2E] End-To-End Arguments in System Design, J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288. [ID-Nickless] B. Nickless, Internet draft work in progress, IPv4 Multicast Best Current Practice. [MIDTAX] B. Carpenter, S. Brim, Internet draft work in progress, Middle Boxes and Taxonomy. Kristoff Informational [Page 10] RFC 2 Network Security Principles January 2002 [RFC791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC792] J. Postel, Internet Control Message Protocol, RFC 792, September 1981. [RFC826] D. Plummer, An Ethernet Address Resolution Protocol, RFC 826, November 1982. [RFC1631] K. Egevang, P. Francis, The IP Network Address Translator (NAT), RFC 1631, May 1994. [RFC1675] S. Bellovin, Security Concerns for IPng, RFC 1675, August 1994. [RFC1858] G. Ziemba, D. Reed, P. Traina, Security Considerations for IP Fragment Filtering, RFC 1858, October 1995. [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, Address Allocation for Private Internets, RFC 1918, February 1996. [RFC2236] W. Fenner, Internet Group Management Protocol, Version 2, RFC 2236, November 1997. [RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998. [RFC2644] D. Senie, Changing the Default for Directed Broadcasts in Routers, RFC 2775, August 1999. [RFC2775] B. Carpenter, Internet Transparency, RFC 2775, February 2000. [RFC2827] P. Ferguson, D. Senie, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, RFC 2827, May 2000. [RFC2956] M. Kaat, Overview of 1999 IAB Network Layer Workshop, RFC 2956, October 2000. [RFC2979] N. Freed, Behavior of and Requirements for Internet Firewalls, RFC 2979, October 2000. [RFC2993] T. Hain, Architectural Implications of NAT, RFC 2993, November 2000. Kristoff Informational [Page 11] RFC 2 Network Security Principles January 2002 [SSL3] Secure Sockets Layer 3, Netscape Draft Standard, work in progress. [SSH2] Secure SHell version 2, SSH Corporation. [Stevens] W. R. Stevens, TCP/IP Illustrated: Volume I, Addison Wesley, 1994. Security Considerations This memo describes a general framework for thinking about how to implement network security protection on the DePaul University network. Editor's Address John Kristoff Research & Design, Networks and Telecom DePaul University 1 East Jackson Boulevard Chicago, IL 60604 USA Phone: +01 312 362-5878 EMail: jtk@depaul.edu Kristoff Informational [Page 12]