Internet-Draft Grenville Armitage
Lucent Technologies
October 11th, 1997
Security issues for ION protocols
<draft-armitage-ion-security-01.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 aims to assist people attempting to understand the
security limitations of existing ION working group protocols RFC 2022
(MARS), and RFC xxxx (NHRP). As RFC 2022 and RFC xxxx share their
basic control message protocol(s), this document also identifies
common areas amenable to improvement using additional security TLVs.
Change History
September 1997
Armitage Expires April 11th, 1998 [Page 1]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
ATMARP specific sections extracted to form a stand-alone document,
called draft-armitage-ion-sec-arp-00.txt. This document now covers
only MARS and NHRP issues, revision number upped to 01.
July 1997
Initial release. 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].
Subsequently, NHRP was developed to support both intra-subnet and
inter-subnet 'shortcut' unicast SVCs, and MARS was developed to
support intra-subnet multicast.
Since the internet is an open community, and the ION model depends on
the correct MARS/NHRP 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 MARS and NHRP architectures. RFC1577 related
security issues are reviewed in [5], and IP related security issues
are reviewed in RFC 1825 [6].
Armitage Expires April 11th, 1998 [Page 2]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
In this document the term 'attacker' will be used to mean any
application actively utilizing the ATM network and IP/ATM protocol
elements to perform activities outside the intended scope of RFC 2022
and RFC xxxx.
The rest of this document is structured in the following manner.
Section 2 briefly notes the limited assumptions you can make about
ATM level security, section 3 summarizes the known issues with RFC
2022, and section 4 summarizes the known issues with RFC xxxx.
Section 5 briefly outlines the mechanism shared by RFC 2022 and RFC
xxxx for adding security related option fields to control messages.
2. ATM level security
RFC 2022 and RFC xxxx assume 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 [8,9] 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], Cluster [2], or LAG [3]. 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
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
Armitage Expires April 11th, 1998 [Page 3]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
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.
3. RFC 2022 (MARS)
The RFC 2022 protocol is primarily query/response. In addition to
triggering responses with direct queries, MARS clients also expect to
receive asynchronous updates from their MARS. This opens up
possibilities for an attacker to trigger client misbehavior.
3.1 Joining the cluster to eavesdrop and interject
MARS Clients automatically add new ATM level leaf nodes to their
outgoing pt-mpt VCs upon receipt of valid MARS_JOIN messages. An
attacker wishing to eavesdrop on any multicast group's traffic within
a Cluster need only register as a cluster member, and issue a
MARS_JOIN to the MARS for the groups of interest. The MARS will
inform all other cluster members, and all current senders will add
the attacker as a new leaf node. An attacker who was interested in
all traffic within the cluster need only issue a block MARS_JOIN to
cover the entire multicast address space (a promiscuous client) in
one operation.
Aside from the fact that information is leaking from your cluster,
such eavesdropping may have a debilitating effect on the wider ATM
cloud. If the attacker is topologically distant at the ATM level,
this action results in a sudden increase in traffic along the ATM
path from your cluster to the attacker's own access point.
Having registered with the MARS as a legitimate cluster member, the
attacker is also free to begin transmitting its own data to the
members of any group it chooses.
3.2 Joining as an MCS to eavesdrop and interject
An alternative approach to eavesdropping is for an attacker to
register as an MCS and claim to support the group or groups of
interest. The attacker then becomes the focal point of transmissions
from legitimate MARS Clients, and is in a position to make copies of
packets sent to it.
A non-disruptive attacker would actually provide MCS functionality,
to ensure packets from legitimate cluster members are distributed
Armitage Expires April 11th, 1998 [Page 4]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
around the cluster as expected. A disruptive attacker could simply
black-hole the group's traffic, or creatively modify the packet
stream flowing through itself. A totally debilitating attacker would
register to support all multicast groups, and then black-hole the
traffic. Since the MARS trusts the MCS, and the MARS Clients trust
the MARS, this makes an effective denial of service attack. (The
fact that MCS cannot issue a block join provides minimal defense. A
creative attacker would register as a normal client in promiscuous
mode, watch for new groups being joined, and then simultaneously
register as an MCS for the new group. A single application running on
an unsecured PC can conceivably emulate two distinct ATM entities.)
Aside from the fact that information is leaking from your cluster,
such eavesdropping may have a debilitating effect on the wider ATM
cloud. If the attacker is topologically distant at the ATM level,
this action results in a sudden increase in traffic along the ATM
path from your cluster to the attacker's own access point.
3.3 Bypassing or hi-jacking the MARS
The eavesdropping techniques described in the previous two sections
involve the attacker registering itself with the MARS as either a
legitimate client or MCS. If the MARS Clients within the Cluster fail
to perform sanity checks on the source of the MARS_JOIN messages they
listen to, it may be feasible for an attacker to target particular
senders directly. The attacker establishes a VC to the target MARS
Client and sends it a properly formatted MARS_JOIN. In this case,
the attacker only receives a copy of the traffic from the targetted
MARS Client.
A MARS Client that fails to sanity check MARS_LEAVE messages can be
effectively shut down by an attacker. The attacker finds the group
members by querying the MARS, then begins issuing MARS_LEAVEs to the
target MARS Client. Each MARS_LEAVE causes the target MARS client to
drop another leaf node from its forwarding VC. Eventually the VC is
closed down.
An MCS may be similarly vulnerable to fake MARS_SJOIN/SLEAVE messages
coming directly from an attacker.
This vulnerability may be partially closed if the MARS Client checks
the source of the VC on which MARS_JOIN/LEAVE messages arrive.
Messages to update outgoing pt-mpt VCs arrive on ClusterControlVC.
However, the current protocol does not provide Clients with a
definite mechanism for determining which incoming SVC represents
ClusterControlVC. If the ATM signaling is trusted, the sanity check
would be to only accept MARS_JOIN/LEAVE messages arriving on VCs
whose Calling Party number is that of the MARS entity. If the VCs
Armitage Expires April 11th, 1998 [Page 5]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
Calling Party number is unavailable, the target MARS Client can, at
best, make an assumption that the VC on which it first receives a
MARS_REDIRECT_MAP must be ClusterControlVC.
MARS_REDIRECT_MAP itself provides trouble for vulnerable MARS
Clients. An attacker who is prepared to emulate a complete MARS can
transmit a fake MARS_REDIRECT_MAP to all (or some subset) of the
Cluster's members, forcing them to voluntarily switch from the
current MARS. If a 'hard redirect' is demanded by the attacker, the
MARS Clients will also assist the attacker by re-MARS_JOINing every
group they were members of. Once redirected, cluster operation
continues as though nothing has happened. (Clients that depend on
seeing a MARS_REDIRECT_MAP to decide which VC is ClusterControlVC are
vulnerable to this attack if the first MARS_REDIRECT_MAP that they
see is from the attacker.) Having taken over as the cluster's MARS,
the attacker is pretty much free to cause further havoc.
3.4 Denial of Service
An attacker could disrupt or slow down MARS service by repetitive VC
setup/teardown events. An attacker who repeatedly registered and de-
registered as a cluster member would cause even more ATM signaling
activity, as the target MARS updates ClusterControlVC. Similarly, an
attacker could repeatedly register and deregister as an MCS to force
updates of ServerControlVC.
A direct attack on the MARS itself might involve explicitly joining,
in sequence, every possible multicast group, in the hope that the
internal database will overflow. Some MARS implementations may react
by crashing, providing a useful denial of service mechanism. Being
able to force a crash has additional uses - the attack can force a
restart, and while the clients are re-registering with the restarted
MARS, the attacker injects false MARS_REDIRECT_MAPs as described in
section 3.3.
Faking of an MCS by the attacker (as described in section 3.2) can be
used to create full or partial black-holes for traffic.
3.5 Hiding the MARS
Many scenarios involve the attacker knowing who the cluster members
are. In most situations this will be trivial to achieve, since there
is usually some well known multicast group joined by all cluster
members (e.g. 224.0.0.1 under IPv4). A MARS_REQUEST on this group
will provide the required information. (Interestingly, since MARS
Clients and ATMARP Clients are typically co-located, this search will
reveal the locations of all ATMARP Clients in the LIS as well.
Probing each client by opening a direct VC is likely to elicit an
Armitage Expires April 11th, 1998 [Page 6]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
InARP Request that reveals the client's unicast IP address.)
Keeping the address of the MARS secret can help discourage many of
the preceding attacks. However, experience with RFC 1577
implementations suggests that there will be little attempt to hide
the configuration information from users. If the person behind the
attacks has user level access to any machine on the LIS, they will
have access to the MARS address.
Even if the MARS address could be kept a secret, a determined search
would make use of the fact that a MARS reacts in a predictable way
when it is sent a correctly formatted registration MARS_JOIN. 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 correctly to
MARS_JOIN.
An attacker with physical access to your ATM cloud can place a tap on
any link, parse the UNI signalling traffic going past, and draw
conclusions from the AESAs it sees in SETUP messages.
4. RFC xxxx (NHRP)
The RFC xxxx protocol is primarily query/response. In addition to
triggering responses with direct queries, NHRP clients also expect to
receive asynchronous updates from their NHS, which opens up
possibilities for an attacker to trigger client misbehavior.
Although RFC xxxx provides an optional TLV for authentication
purposes, its use is not currently mandatory. Therefore, this section
assumes NHRP installations where no use is being made of the
authentication TLV.
[insert cites to any prior work here.]
[This section is very much under construction.]
4.1 IP/ATM address spoofing
Address spoofing involves the insertion of incorrect {IP,ATM}
mappings into the NHS' database. An attacker establishes a VC to the
NHS for a given LIS/LAG, and provides a fake {IP,ATM} mapping in its
NHRP Register Request. An attacker may also attempt to register fake
{IP,ATM} mappings in NHSes serving remote LIS/LAGs, by specifying a
remote NHS as the Destination of the NHRP Register Request.
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
Armitage Expires April 11th, 1998 [Page 7]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
IP services (e.g. register the IP address of the local NFS server or
router immediately after an NHS reboot). As fake mappings can be
inserted into NHSes outside the immediate LIS/LAG, the scope for
damage is far greater than that presented in ATMARP installations.
An attacker may find value in attempting to register mappings with a
target NHS that represent IP addresses from a LIS/LAG not served by
the target NHS, in case the NHS implementation fails to sanity check
the mapping. If the fake registration succeeds, no other NHSes
(including the NHS that actually serves the target IP address) will
know that the compromised NHS is handing out false information. The
compromised NHS may also respond to non-authoritative requests for
the affected IP addresses mapping from remote clients if their NHRP
Requests are routed through it.
(Note that registering with an NHS outside the local LIS/LAG only
requires that the IP address of the remote NHS be placed into the
attacker's NHRP Registration Request. Thus the attacker need only
know the ATM address of one NHS. The IP addresses of potential
target NHS(es) may be surmised by checking the IP addresses of
routers in the region, as reported by tools such as 'traceroute'.)
4.2 Scanning the {IP,ATM} mapping space.
It is usually undesirable for outsiders to know the entire set of IP
addresses (and associated ATM addresses) that make up your LIS/LAG.
However, there is little to stop an attacker from establishing a VC
to your NHS, registering an innocuous {IP,ATM} mapping, and
proceeding to issue NHRP Requests for a range (or ranges) of
'interesting' IP addresses.
Since the NHRP service's design goal is the resolution of IP
addresses outside the LIS/LAG, the attacker can also choose to scan
the mappings for other LIS/LAGs through the local NHS. Knowing the
address of any one NHS opens up an entire set of LIS/LAGs.
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 NHRP Requests are issued, this scanning can itself keep the
NHS so busy as to constitute a denial of service attack. If the
target IP addresses are outside the local LIS/LAG, the request
traffic propagates to other NHSes too.
Not knowing the LIS/LAG address range makes the attack less
efficient, but not impossible since the server actively responds to
bad guesses with NHRP Reply indicating failure. A selective search
would make intelligent guesses as to the probable range of net/subnet
Armitage Expires April 11th, 1998 [Page 8]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
numbers to scan.
4.3 Denial of Service attacks.
An attacker can present two types of overload to an NHS - repetative
VC setup/teardown events without actually registering any {IP,ATM}
mappings (simply to consume cpu cycles in the NHS' underlying UNI
stack), and repeated VC setup/teardown/registration events (where the
attacker explicitly NHRP Registers with a different {IP,ATM} mapping
each time).
The first type of attack wastes time at the NHS, 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 NHS. This can 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.
As noted in section 4.1, the second type of attack can be launched
against remote NHSes without even knowing their ATM addresses.
Harrassment through repetative VC setup/teardown may also be launched
against NHCs whose addresses were learned through scanning of the NHS
database.
An attacker can transmit fake NHRP Purge messages to both NHSes and
NHCs. At minimum this is likely to result in unnecessary VC
teardown/setup sequences between NHCs whose current short-cuts are
prematurely purged.
4.5 Hiding the NHS
Keeping the ATM addresses of NHS secret would help discourage many of
the preceding attacks. However, this is unlikely to be even remotely
achievable.
As noted in section 4.1, if only one NHS ATM address is known this is
sufficient to cover all NHSes. Their IP addresses can be guessed from
the IP addresses of routers in the network, and if required the
attacker can query the initial NHS to discover the matching ATM
addresses.
Even if all NHS ATM addresses could be kept a secret, a determined
Armitage Expires April 11th, 1998 [Page 9]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
search would make use of the fact that an NHS reacts in a predictable
way when it is sent a correctly formatted NHRP messages. 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 correctly to NHRP Registration
Request.
An attacker with physical access to your ATM cloud can place a tap on
any link, parse the UNI signalling traffic going past, and draw
conclusions from the AESAs it sees in SETUP messages.
5. Common extensions to MARS and NHRP
Both MARS and NHRP share a common control packet syntax that supports
optional TLV-based fields. RFC xxxx contains an authentication TLV,
and it would seem reasonable to build on this TLV for MARS.
[TBD]
[TLV exists, but key distribution is a problem.]
6. Conclusion
[TBD]
Security Consideration
Security considerations are covered in this document.
Acknowledgments
Author's Address
Grenville Armitage
Bell Labs, Lucent Technologies.
101 Crawfords Corner Rd,
Holmdel, NJ, 07733
USA
Email: gja@lucent.com
Armitage Expires April 11th, 1998 [Page 10]
Internet Draft <draft-armitage-ion-security-01.txt>October 11th, 1997
References
[1] Laubach, M., "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] G. Armitage, C. Wang, "Security issues for the ATMARP protocol",
INTERNET DRAFT, draft-armitage-ion-sec-arp-00.txt, October 1997
[6] R. Atkinson, "Security Architecture for the Internet Protocol",
RFC 1825, August 1995
[7] ATM Forum, "ATM User-Network Interface Specification Version
3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
[8] ATM Forum, "ATM User Network Interface (UNI) Specification
Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,
NJ, June 1995.
Armitage Expires April 11th, 1998 [Page 11]