Internet-Draft Grenville Armitage Lucent Technologies Cliff X. Wang IBM Corporation October 11th, 1997 Security issues for the ATMARP protocol Status of this Memo This document was submitted to the IETF Internetworking over NBMA (ION) WG. Publication of this document does not imply acceptance by the ION WG of any ideas expressed within. Comments should be submitted to the ion@nexen.com mailing list. Distribution of this memo is unlimited. This memo is an internet draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim) to learn the current status of any Internet Draft. Abstract This document discusses some security issues associated with IP over ATM operation. RFC1577 defines the Classic IP model for sending IP traffic over ATM. However, security issues were not addressed in the standard. Since internet is an open architecture, security measures to protect network integrity are essential for normal operation. The security loopholes in the current RFC 1577 model are analyzed and discussed. Possible solutions are proposed. Armitage, Wang Expires April 11th, 1998 [Page 1] Internet Draft October 11th, 1997 Change History September 1997 ATMARP specific sections extracted to form a stand-alone document. Substantial contributions from IBM co-authors. Name changed from draft-armitage-ion-security-00.txt to draft-armitage-ion-sec-arp- 00.txt July 1997 Initial release covering ATMARP, MARS, and NHRP. Begins to describe the problems. Solutions still TBD. 1. Introduction Security is a broad term, and often used subjectively when a given protocol is said to be 'secure' or 'insecure'. The context and prior assumptions need to be clearly understood for each assertion of an overall system's level of security. Typically most security can summarised as 'no-one would find me interesting enough to bother'. Unfortunately, innocent hackers and/or malicious crackers will find most IP/ATM installations 'interesting' at some point. Whether you are victim of a denial-of-service attack, or denial-of-service screw-up, the effect is similarly annoying. The ION working group and its predecessors (the IP-ATM and ROLC working groups) are responsible for three key protocols to support unicast and multicast IP over ATM (and other NBMA) networks - RFC 1577 (ATMARP) [1], RFC 2022 (MARS) [2], and RFC xxxx (NHRP) [3]. The development of these protocols focussed on achieving a set of goals that did not initally include specific security issues. The Classical IP over ATM model was first suggested in 1993 at the Internet Engineering Task Force IETF spring meeting and was later documented in RFC 1577. In this model, IP end-stations are grouped into Logical IP Subnet (LIS). Within the LIS, ATM Address Resolution Protocol (ATMARP) [1] supports IP data communication. Traffic between different LISs is routed using conventional IP routing protocols such as OSPF[4]. Since the internet is an open community, and RFC1577 model depends on the correct ATMARP client/server operation, it is important for the industry to be aware of the various security risks, and what can be done to reduce these risks. This document focusses on the security risks inherent in the RFC1577 architecture. IP related security issues are reviewed in RFC 1825 [8]. In this document the term 'attacker' will be used to mean any application actively utilizing the ATM network and IP/ATM protocol Armitage, Wang Expires April 11th, 1998 [Page 2] Internet Draft October 11th, 1997 elements to perform activities outside the intended scope of RFC 1577. The rest of this document is structured in the following manner. Section 2 provides a brief review of the RFC 1577 model, and section 3 notes the limited assumptions one can make about ATM level security. Section 4 summarizes the known security limitations of RFC 1577, and section 5 discusses possible solutions. 2. Review of the RFC 1577 model Classical IP over ATM is currently defined by RFC 1577. Recently, an updated version of RFC1577 has also been proposed [5]. In the RFC 1577 model, IP end-stations are grouped into Logical IP Subnets (LIS) based on the end-station's IP address and the subnet mask. For each LIS, a dedicated ATMARP server provides the protocol to physical address resolution service for all the clients of the same LIS. Each client of the LIS registers with the ATMARP server to obtain the address translation service from the server as well supply its own address information to the server. When a client wants to setup an IP data path to another client, it checks if it knows the associated destination ATM address. If such information is not available, the sending client contacts the ATMARP server by sending an ATMARP request packet to query the destination's ATM address. If the destination's ATMARP client has registered with the server and is active, the ATMARP server will send an ATMARP reply packet to the requesting ATMARP client with the destination's ATM address. Upon receiving the reply from the server, the sending client can initiate communication to the receiving client. If the server doesn't have the requested information, an ATMARP NAK packet is sent back and no connection can be established. RFC 1577 also defines the use of Inverse ARP [11] in the ATM environment. An ATMARP client may have knowledge of a destination's ATM address but want to discover (or confirm) the matching IP address. To obtain the destination's IP address, an InATMARP packet is sent directly to the destination, and an InATMARP reply packet is sent back with the destination's IP address associated with the ATM address supplied in the InATMARP Request. The InATMARP request and reply is not restricted to pairs of clients. It is used to register new ATMARP Clients with the ATMARP Server - when a new client ATMARP client establishes a VC to the ATMARP Server, the first thing done by the server is to send an InATMARP Request. The ATMARP Client's InATMARP Reply carries the IP/ATM mapping then used by the ATMARP Server. Armitage, Wang Expires April 11th, 1998 [Page 3] Internet Draft October 11th, 1997 A distributed ATMARP server protocol is also being developed [6,7]. More than one ATMARP server may be implemented in a subnet such that the critical address resolution service will be un-interrupted when one or more ATMARP servers (but not all of them) break down. Under the distributed ATMARP server scheme, ATMARP client may register and use any of the active ATMARP server. Each active ATMARP server maintains the address information for the whole subnet. The address resolution information is exchanged and kept synchronized among the participating ATMARP servers. For the purposes of this document, references to "the ATMARP Server" can be taken to apply to both the single server case, and the distributed server case. Security weaknesses inherent in the protocols used to create the distributed ATMARP Server will be covered in another document. 3. ATM level security RFC 1577 assumes that the underlying ATM network itself is trustworthy. There is an implicit assumption that if a SETUP message arrives at your node, the Calling Party Information Element (IE) contains a legitimate address correctly identifying the SETUP's originator. (In line with the 'surely I'm too un-interesting to bother' philosophy, there is an additional assumption that the SETUP message came from someone with a right to establish the VC, regardless of the address in the Calling Party IE.) Unfortunately, UNI 3.0/3.1 ATM signaling [12,13] does not utilize any form of end-node authentication. This leaves the SETUP phase vulnerable to 'man in the middle' attacks (where a switch somewhere in the ATM network is compromised, or a link is broken and an additional entity introduced that is capable of intercepting and modifying UNI or NNI signaling traffic on the fly). Even if end points were authenticated, UNI 3.0/3.1 does not support the notion of closed user groups. This allows anyone with UNI access to your underlying ATM cloud to establish VCs to any entity within your LIS [1]. This can become a problem if UNI access to your ATM cloud is possible - e.g. through poorly restricted physical access such as spare switch ports, or functional access through machines running insecure OSes. (An insecure OS environment can be anything that allows user space applications direct access to either the local hosts's UNI signaling stack, or the underlying ATM NIC itself.) Weak access controls to a host's UNI signaling stack may allow a local user application to establish VCs using Calling Party numbers with arbitrary SEL values (the choice of the other 19 octets of a Calling Party AESA is limited by the ESIs initially registered by the Armitage, Wang Expires April 11th, 1998 [Page 4] Internet Draft October 11th, 1997 client with the local switch using ILMI). Sufficiently weak access controls might even allow an application to choose Calling Party numbers that clash with other local ATM-based applications. Weak access controls to the host's ATM NIC itself could allow user deployment of a complete ILMI/UNI signaling stack of their own, customized for whatever task is required. A single PC attached to a campus-wide ATM network meets all the criteria for a weakly controlled access point. 4. Security in the RFC 1577 model The RFC 1577 protocol is query/response based. ATMARP Clients initiate activity that leads to responses from the ATMARP Server (either by establishing a VC, or issuing an ATMARP Request). The ATMARP Server trusts mapping information it receives from ATMARP Clients. ATMARP Clients never change their behavior based on asynchronous control messages from the ATMARP Server. Many of the observed security weaknesses stem from the lack of meaningful access control available to ATMARP Servers, and the lack of ATMARP level authentication mechanisms for either Server(s) or Clients to use. 4.1 IP/ATM address spoofing Address spoofing involves the insertion of incorrect {IP,ATM} mappings into the ATMARP Server's database. This is trivial to achieve. An attacker establishes a VC to the ATMARP Server for a given LIS, the Server issues a pre-emptive InARP REQUEST, and the attacker provides a fake {IP,ATM} mapping in its InARP Reply. This sort of spoofing can be used either as a denial of service attack or a stepping stone to subsequent hi-jacking of higher level IP services (e.g. register the IP address of the local NFS server or router immediately after an ARP Server reboot). If the ATM addresses of LIS members are known, an attacker can attempt to directly insert misleading {IP,ATM} mappings into another LIS member's ATMARP Client. ATMARP Client implementations that attempt to learn {IP,ATM} mappings from the InARP exchange with other clients can be fooled in this way. The attacker simply establishes a VC to a known member and passes back an arbitrary IP address in its reply to the target Client's InARP Request. If the supplied IP address matches that of an important node in the LIS (e.g. a router) to which the target client has yet to establish legitimate communication, the attack can be the prelude to hi-jacking of higher Armitage, Wang Expires April 11th, 1998 [Page 5] Internet Draft October 11th, 1997 level IP services. As ATMARP Clients never query for IP addresses outside their LIS, there is little value in an attacker attempting to spoof mappings for IP addresses that lie outside the scope of the LIS. 4.2 Scanning of the LIS. It is usually undesirable for outsiders to know the entire set of IP addresses (and associated ATM addresses) that make up your LIS. However, there is little to stop an attacker from establishing a VC to your ATMARP Server, registering an innocuous {IP,ATM} mapping, and then proceeding to issue ATMARP_REQUESTs for a range (or ranges) of 'interesting' IP addresses. The ATM addresses thus learned might be used in subsequent denial of service attacks against specific hosts. Depending on range of IP addresses chosen during the scan, and the speed with which the repeated ATMARP_REQUESTs are issued, this scanning can itself keep the ATMARP Server so busy as to constitute a denial of service attack. Not knowing the LIS address range makes the attack less efficient, but not impossible since the server actively responds to bad guesses with ATMARP_NAKs. A selective search would make intelligent guesses as to the probable range of net/subnet numbers to scan. 4.3 Denial of Service attacks. Denial of service is any action that subverts the normal and timely operation of the total IP/ATM system. Attacks may aim to either slow down normal operations, or cause a cessation of operations altogether by exploting implementation weaknesses. An attacker can present two types of overload to an ATMARP Server - repetative VC setup/teardown events without actually registering any {IP,ATM} mappings (simply to consume time in the ATMARP Server's underlying UNI stack), and repeated VC setup/teardown/registration events (where the attacker responds to the Server's initial InARP Request with a different {IP,ATM} mapping each time). The first type of attack wastes time at the ATMARP Server, and causes additional loading of the control processor in the switch to which the target is attached (and other switches along the path between the attacker and target). The second type of attack will be slower (although parallel VC setup attempts can be used to keep the average rate up), but results in additional database manipulation activity in the Server. This can Armitage, Wang Expires April 11th, 1998 [Page 6] Internet Draft October 11th, 1997 result in collisions with IP addresses already registered, or set the stage for later collisions when the legitimate owners of a particular IP address attempt to register. Depending on the ATMARP Server's design, it may happily accept {IP,ATM} mappings outside the range of IP addresses of the LIS it is nominally supporting. (This is not strictly illegal, since the 'Classical IP' restrictions on resolving addresses outside the LIS actually derive from host-side behavior not server-side behavior.) This would have the affect of avoiding collisions while filling up the Server's database with useless information, possibly avoiding detection of the attack until the Server's database collapses. An attacker may also choose to launch similar attacks on LIS Clients whose addresses were learned through previous scanning of the ATMARP Server's database. 4.4 ATMARP Server spoofing ATMARP Clients never receive asynchronous updates from server. This makes it unlikely that a client implementation would listen to a faked ARP Reply, ARP Nak, or InARP Reply arriving on a VC that the client did not believe to be connected to the ATMARP Server (or another client). However, if authentication is not used in message exchanges between server and its clients, an attacker might be in the position to modify packets sent from server to client and interrupt the normal operation of the client. For example, the address field of the ATMARP replay message can be modified, or any other field can be over written. The simplest attack is to over write the packet content with garbage data and force the client to flush the received packets. This can consequently disrupt client registration or attempts to establish the IP/ATM address mapping for another client. An attack on the identity of the ATMARP Server would either involve compromising the security of the Client's local configuration file, or compromising the ATM network itself (to redirect a client's SETUP towards the attacker's own substitute ATMARP Server). These are both feasible, but do not depend on characteristics of the RFC 1577 protocol itself. 4.5 Hiding the ATMARP Server Keeping the address of the ATMARP Server secret can help discourage many of the preceding attacks. However, few RFC 1577 implementations make any attempt to hide the configuration information from users. If the person behind the attacks has user level access to any machine on Armitage, Wang Expires April 11th, 1998 [Page 7] Internet Draft October 11th, 1997 the LIS, he will have access to the ATMARP Server address. Even if the ATMARP Server's address could be kept a secret, a determined search would make use of the fact that an ATMARP Server announces its existence with a pre-emptive InARP Request whenever a new VC is established to it. An attacker with complete or partial knowledge of the AESAs in your region of the cloud can poll possible AESA variations (varying the SEL field) looking for an endpoint that reacts with InARP Requests. An attacker with physical access to your ATM cloud might conceivably place a passive or active tap on suitable links, parse the UNI signalling traffic going past, and draw conclusions from the AESAs it sees in SETUP messages. 4.6 Security issues for distributed servers Server Cache Synchronization protocol (SCSP)[6] supports distributed ATMARP server operation. More than one ATMARP server may be implemented in a subnet such that the critical address resolution service will be un-interrupted when one or more ATMARP servers (but not all of them) break down. Under the distributed ATMARP server scheme, ATMARP client may register and use any of the active ATMARP server. Each active ATMARP server maintains the address information for the whole subnet. The address resolution information is exchanged and kept synchronized among the participating ATMARP servers. Two types of attacks are possible when running distributed ATMARP servers. One type is that intruder has access to the link between two servers. The other type is that an ATMARP server is compromised. When the intruder has access to the link between two servers, the cache synchronization message can be intercepted, altered, or replayed. Message authentication between two servers will protect the integrity of messages, but cannot solve the problem of replay attack unless combined with timestamp. For the second case when a server is compromised, it can send false cache information to any other servers participated in the server group and bring down the whole LIS. There is no clear solution to such attack, unless system administration is alerted and disconnect the compromised server from the group. Specific security analysis and solution on distributed server synchronization operation is outside the scope of this draft. 5. Possible solutions 5.1 Access control Armitage, Wang Expires April 11th, 1998 [Page 8] Internet Draft October 11th, 1997 Protection against un-motivated or accidental attackers may be provided by insisting that the ATMARP Server respond only to known clients. However, this raises the question of how a client is 'known'. - Prior configuration of the ATMARP Server with a list of valid client ATM addresses can involve significant management overhead. It constrains the physical attachement points of ATMARP Clients to the ATM cloud (since their attachment point affects their AESA). It is not effective against attackers who are able to spoof their ATM attachment point. - The ATMARP Server could be configured with a list of valid client IP addresses, or the range of legal addresses in the LIS. This would enable rejection of any mappings for IP addresses outside of the LIS, but doesn't provide any serious security since most attackers already have a fair idea of the Server's LIS before hand. - The ATMPARP Server could be configured with lists of both legal IP addresses and legal ATM addresses. This would constrain all ATMARP Clients to dynamically map only legal IP addresses to legal ATM addresses. - The ATMARP Server could be statically configured with all the legal IP/ATM mappings for the LIS, and act as a 'read-only' ATMARP Server. Disallowing arbitrary client registrations removes many of the security weaknesses in the RFC 1577 model, but at a severe cost in flexibility. In each case, the notion of proving a client's right to use the ATMARP Server through its IP or ATM address is simply a weak form of authentication, because the IP or ATM address can be easily spoofed It is also inflexible - in the case of defining 'legal' ATM addresses, it assumes apriori knowledge of all attachment points to the ATM network that a legal ATMARP Client might use. What is preferable is a means of authenticating clients that is associated with the client itself, and not its topological position in the ATM or IP network. 5.2 Authentication Currently RFC 1577 clients or servers do not authenticate request and reply messages. The IP or ATM addresses contained within the current control messages do not constitute authentication information. There is no way for a client to 'prove' to a server that the client is entitled to use the server, and no way for a server to ascertain the client's right. Armitage, Wang Expires April 11th, 1998 [Page 9] Internet Draft October 11th, 1997 Without an authentication mechanism, access control is weak. However, if an authentication mechanism were put in place, access control could be coupled to the information used to authenticate clients and servers, rather than the weak address-based approaches described in the previous section. One current authentication mechanism involves the hashing of an IP packet's contents using a Keyed MD5 algorithm (RFC 1321 [9] and RFC 1828 [10]). The resulting digital signature is sent along with the IP packet. The packet's recipient authenticates the packet and its source by running the same algorithm over the packet, using the same key. If the result matches the signature supplied along with the packet, the recipient considers the packet to be valid. This form of authentication is based on the shared knowledge of a secret key between the source and destination of each packet. Generalizing this to an ATMARP environment requires that the ATMARP control message format be extended to carry a Keyed MD5 signature, and that configuration of an ATMARP LIS support the secure distribution of secret keys. The use of authentication would increase the processing overhead in both servers and clients, increasing the query/response latency. However, since ATMARP is only used when the client doesn't have a local mapping already cached, or when initially registering, the impact of actual IP traffic flows will be minimal. Pragmatically, it is not clear that RFC 1577 control packet extensions are worthwhile pursuing. Future IP/ATM installations are expected to transition to NHRP for both inter-LIS and intra-LIS address resolution functions. NHRP has its own facilities for carrying authentication information. 5.3 Management alerts While not directly a tool for preventing attacks, RFC 1577 implementations may choose to provide custom SNMP based mechanisms for issuing alerts when a range of unusual activities occur. One obvious example would be to issue an alert when excessive signaling activity is detected, suggesting a possible denial of service attack. Specific proposals for such alert mechanisms are not covered by this document. Armitage, Wang Expires April 11th, 1998 [Page 10] Internet Draft October 11th, 1997 6. Conclusion and Open Issues This draft provides a security analysis on IP over ATM operation (ATMARP) based on RFC 1577. Solutions to safeguard the normal operation of ATMARP from attacks are suggested. However, due to limitations of current ATMARP control message format, ATMARP packet authentication cannot be directly built in. The addition of TLV extensions may be required to the current ATMARP packet in order to carry authentication message. At time of writing, a new Classic2 draft is in progress which will ultimately replace RFC 1577. This security analysis draft will be updated accordingly when Classic2 become RFC status. Security Consideration Security considerations are dealt with throughout this document. Acknowledgments Author's Addresses Grenville Armitage Bell Labs, Lucent Technologies. 101 Crawfords Corner Rd, Holmdel, NJ, 07733 USA Email: gja@lucent.com Cliff X. Wang Networking Hardware Division International Business Machines Corporation. P.O. Box 12195, Research Triangle Park, NC 27709 USA Email: cliff_wang@vnet.ibm.com Armitage, Wang Expires April 11th, 1998 [Page 11] Internet Draft October 11th, 1997 References [1] M. Laubach, "Classical IP and ARP over ATM", RFC1577, Hewlett- Packard Laboratories, December 1993. [2] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks", Bellcore, RFC 2022, November 1996. [3] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", INTERNET DRAFT, draft-ietf-rolc-nhrp-11.txt, February 1997. [4] J. Moy, "OSPF Version 2", RFC 1247, March 1994 [5] M. Laubach, J. Halpern, "Classic IP and ARP over ATM", INTERNET DRAFT, draft-ion-ipatm-classic2-02.txt, March 1997. [6] J. Luciani, G. Armitage, J. Halpern, "Server Cache Synchronization Protocol (SCSP)", INTERNET DRAFT, draft-ietf-ion- scsp-01.txt, April 1997 [7] J. Luciani, B. Fox, "A Distributed ATMARP Service Using SCSP", INTERNET DRAFT, draft-ietf-ion-scsp-atmarp-00.txt, April 1997 [8] R. Atkinson, "Security Architecture for the Internet Protocol", RFC 1825, August 1995 [9] R. Rivest, "MD5 Digest Algorithm", RFC 1321, April, 1992 [10] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995 [11] T. Bradely, C. Brown, "Inverse Address Resolution Protocol", RFC 1293, Wellfleet Communications, Inc., January 1992 [12] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993. [13] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995. Armitage, Wang Expires April 11th, 1998 [Page 12]