[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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.


   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    <draft-armitage-ion-sec-arp-00.txt> 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-

   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    <draft-armitage-ion-sec-arp-00.txt> October 11th, 1997

   elements to perform activities outside the intended scope of RFC

   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

Armitage, Wang          Expires April 11th, 1998                 [Page 3]

Internet Draft    <draft-armitage-ion-sec-arp-00.txt> 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    <draft-armitage-ion-sec-arp-00.txt> 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    <draft-armitage-ion-sec-arp-00.txt> 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

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    <draft-armitage-ion-sec-arp-00.txt> 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    <draft-armitage-ion-sec-arp-00.txt> 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    <draft-armitage-ion-sec-arp-00.txt> 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

      - 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    <draft-armitage-ion-sec-arp-00.txt> 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

Armitage, Wang          Expires April 11th, 1998                [Page 10]

Internet Draft    <draft-armitage-ion-sec-arp-00.txt> 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.


Author's Addresses

   Grenville Armitage
   Bell Labs, Lucent Technologies.
   101 Crawfords Corner Rd,
   Holmdel, NJ, 07733

   Email: gja@lucent.com

   Cliff X. Wang
   Networking Hardware Division
   International Business Machines Corporation.
   P.O. Box 12195,
   Research Triangle Park,
   NC 27709

   Email: cliff_wang@vnet.ibm.com

Armitage, Wang          Expires April 11th, 1998                [Page 11]

Internet Draft    <draft-armitage-ion-sec-arp-00.txt> October 11th, 1997


   [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]