Internet-Draft Grenville Armitage
Lucent Technologies
Cliff X. Wang
IBM Corporation
October 11th, 1997
Security issues for the ATMARP protocol
<draft-armitage-ion-sec-arp-00.txt>
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 <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-
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 <draft-armitage-ion-sec-arp-00.txt> 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 <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
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 <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
'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 <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
document.
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.
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 <draft-armitage-ion-sec-arp-00.txt> 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]