Internet DRAFT - draft-armitage-ipp-security

draft-armitage-ipp-security



HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:35:54 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 01 Aug 1997 16:42:00 GMT
ETag: "2e7d43-7d2d-33e211d8"
Accept-Ranges: bytes
Content-Length: 32045
Connection: close
Content-Type: text/plain


Internet-Draft                                      Grenville Armitage
                                                   Lucent Technologies
                                                       July 28th, 1997


                   Security issues for ION protocols
                  <draft-armitage-ion-security-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 aims to assist people attempting to understand the
   security limitations of existing ION working group protocols RFC 1577
   (ATMARP), 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
   July 1997


Armitage               Expires January 28th, 1998                [Page 1]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 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. 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 include specific security
   issues.

   As deployment of IP begins to occur using these protocols, it is
   important for the industry to be aware of the various security risks,
   and what can be done to reduce these risks.

   [cites to prior public work, if any, on each of RFC1577, RFC2022, and
   NHRP security are solicited here.]

   A common architectural component of all three protocols is the use of
   query/response to establish IP to ATM address mappings. MARS and NHRP
   both add to this model by having the clients accept unsolicited
   control messages that result in asynchronous modifications of client
   behavior.  There is an implicit trust that only legitimate clients or
   servers are generating messages at each point in the control message
   exchanges that make up these protocols. 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 term 'attacker' will be used in this document to mean any
   application actively utilizing the ATM network and IP/ATM protocol
   elements to perform activities outside the intended scope of RFC
   1577, RFC 2022, or 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 security
   limitations of RFC 1577, section 4 summarizes the known issues with
   RFC 2022, and section 5 summarizes the known issues with RFC xxxx.
   Section 6 briefly outlines the mechanism shared by RFC 2022 and RFC


Armitage               Expires January 28th, 1998                [Page 2]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   xxxx for adding security related option fields to control messages.

2. ATM level security

   All three protocols 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 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 through poorly restricted
   physical access (e.g. spare switch ports), or logical 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
   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.






Armitage               Expires January 28th, 1998                [Page 3]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


3. RFC 1577 (Classical IP over ATM)

   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.

   [Editors note: this section is from memory. corrections or
   clarifications solicited. impact of Classic2 has not been
   considered.]

3.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
   level IP services.

   There is little value in an attacker registering IP addresses outside
   the scope of the LIS, as intra-LIS clients will never query the
   ATMARP Server for them.


3.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


Armitage               Expires January 28th, 1998                [Page 4]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   to your ATMARP Server, registering an innocuous {IP,ATM} mapping, and
   the 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.


3.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 cpu cycles 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
   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.)


Armitage               Expires January 28th, 1998                [Page 5]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   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.


3.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). 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.


3.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 the LIS, they 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
   blurts out InARP Requests.

   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 2022 (MARS)

   As with RFC 1577, the RFC 2022 protocol is primarily query/response.
   However, MARS clients also expect to receive asynchronous updates


Armitage               Expires January 28th, 1998                [Page 6]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   from their MARS, which opens up possibilities for an attacker to
   trigger client misbehavior.


4.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.


4.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
   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


Armitage               Expires January 28th, 1998                [Page 7]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   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.


4.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
   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


Armitage               Expires January 28th, 1998                [Page 8]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   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.


4.4 Denial of Service

   As with RFC 1577, 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 4.3.

   Faking of an MCS by the attacker (as described in section 4.2) can be
   used to create full or partial black-holes for traffic.


4.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
   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


Armitage               Expires January 28th, 1998                [Page 9]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   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.

5. RFC xxxx (NHRP)

   As with RFC 1577, the RFC xxxx protocol is primarily query/response.
   However, 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 mandated. 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.]

5.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
   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


Armitage               Expires January 28th, 1998               [Page 10]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   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'.)


5.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
   numbers to scan.


5.3 Denial of Service attacks.

   An attacker can present two types of overload to an NHS - repetative


Armitage               Expires January 28th, 1998               [Page 11]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   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 5.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.


5.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 5.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
   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)


Armitage               Expires January 28th, 1998               [Page 12]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 1997


   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.


6. Common extensions to MARS and NHRP

   The RFC1577 control packet format cannot be extended to support an
   authentication field in a backward compatible manner. However, 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.]


7. Conclusion

   [TBD]





Security Consideration

   This document is all about security considerations.

Acknowledgments



Author's Address

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

   Email: gja@lucent.com




Armitage               Expires January 28th, 1998               [Page 13]


Internet Draft    <draft-armitage-ion-security-00.txt>   July 28th, 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.








































Armitage               Expires January 28th, 1998               [Page 14]