idnits 2.17.1 draft-armitage-ion-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '9' is mentioned on line 116, but not defined -- Looks like a reference, but probably isn't: 'TBD' on line 451 == Unused Reference: '7' is defined on line 485, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1247 (ref. '4') (Obsoleted by RFC 1583) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1825 (ref. '6') (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Grenville Armitage 3 Lucent Technologies 4 October 11th, 1997 6 Security issues for ION protocols 7 9 Status of this Memo 11 This document was submitted to the IETF Internetworking over NBMA 12 (ION) WG. Publication of this document does not imply acceptance by 13 the ION WG of any ideas expressed within. Comments should be 14 submitted to the ion@nexen.com mailing list. 16 Distribution of this memo is unlimited. 18 This memo is an internet draft. Internet Drafts are working documents 19 of the Internet Engineering Task Force (IETF), its Areas, and its 20 Working Groups. Note that other groups may also distribute working 21 documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a "working 27 draft" or "work in progress". 29 Please check the lid-abstracts.txt listing contained in the 30 internet-drafts shadow directories on ds.internic.net (US East 31 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 32 munnari.oz.au (Pacific Rim) to learn the current status of any 33 Internet Draft. 35 Abstract 37 This document aims to assist people attempting to understand the 38 security limitations of existing ION working group protocols RFC 2022 39 (MARS), and RFC xxxx (NHRP). As RFC 2022 and RFC xxxx share their 40 basic control message protocol(s), this document also identifies 41 common areas amenable to improvement using additional security TLVs. 43 Change History 45 September 1997 46 ATMARP specific sections extracted to form a stand-alone document, 47 called draft-armitage-ion-sec-arp-00.txt. This document now covers 48 only MARS and NHRP issues, revision number upped to 01. 50 July 1997 51 Initial release. Begins to describe the problems. Solutions still 52 TBD. 54 1. Introduction 56 Security is a broad term, and often used subjectively when a given 57 protocol is said to be 'secure' or 'insecure'. The context and prior 58 assumptions need to be clearly understood for each assertion of an 59 overall system's level of security. Typically most security can 60 summarised as 'no-one would find me interesting enough to bother'. 61 Unfortunately, innocent hackers and/or malicious crackers will find 62 most IP/ATM installations 'interesting' at some point. Whether you 63 are victim of a denial-of-service attack, or denial-of-service 64 screw-up, the effect is similarly annoying. 66 The ION working group and its predecessors (the IP-ATM and ROLC 67 working groups) are responsible for three key protocols to support 68 unicast and multicast IP over ATM (and other NBMA) networks - RFC 69 1577 (ATMARP) [1], RFC 2022 (MARS) [2], and RFC xxxx (NHRP) [3]. The 70 development of these protocols focussed on achieving a set of goals 71 that did not initally include specific security issues. 73 The Classical IP over ATM model was first suggested in 1993 at the 74 Internet Engineering Task Force IETF spring meeting and was later 75 documented in RFC 1577. In this model, IP end-stations are grouped 76 into Logical IP Subnet (LIS). Within the LIS, ATM Address Resolution 77 Protocol (ATMARP) [1] supports IP data communication. Traffic between 78 different LISs is routed using conventional IP routing protocols such 79 as OSPF[4]. 81 Subsequently, NHRP was developed to support both intra-subnet and 82 inter-subnet 'shortcut' unicast SVCs, and MARS was developed to 83 support intra-subnet multicast. 85 Since the internet is an open community, and the ION model depends on 86 the correct MARS/NHRP client/server operation, it is important for 87 the industry to be aware of the various security risks, and what can 88 be done to reduce these risks. This document focusses on the security 89 risks inherent in the MARS and NHRP architectures. RFC1577 related 90 security issues are reviewed in [5], and IP related security issues 91 are reviewed in RFC 1825 [6]. 93 In this document the term 'attacker' will be used to mean any 94 application actively utilizing the ATM network and IP/ATM protocol 95 elements to perform activities outside the intended scope of RFC 2022 96 and RFC xxxx. 98 The rest of this document is structured in the following manner. 99 Section 2 briefly notes the limited assumptions you can make about 100 ATM level security, section 3 summarizes the known issues with RFC 101 2022, and section 4 summarizes the known issues with RFC xxxx. 102 Section 5 briefly outlines the mechanism shared by RFC 2022 and RFC 103 xxxx for adding security related option fields to control messages. 105 2. ATM level security 107 RFC 2022 and RFC xxxx assume that the underlying ATM network itself 108 is trustworthy. There is an implicit assumption that if a SETUP 109 message arrives at your node, the Calling Party Information Element 110 (IE) contains a legitimate address correctly identifying the SETUP's 111 originator. (In line with the 'surely I'm too un-interesting to 112 bother' philosophy, there is an additional assumption that the SETUP 113 message came from someone with a right to establish the VC, 114 regardless of the address in the Calling Party IE.) 116 Unfortunately, UNI 3.0/3.1 ATM signaling [8,9] does not utilize any 117 form of end-node authentication. This leaves the SETUP phase 118 vulnerable to 'man in the middle' attacks (where a switch somewhere 119 in the ATM network is compromised, or a link is broken and an 120 additional entity introduced that is capable of intercepting and 121 modifying UNI or NNI signaling traffic on the fly). 123 Even if end points were authenticated, UNI 3.0/3.1 does not support 124 the notion of closed user groups. This allows anyone with UNI access 125 to your underlying ATM cloud to establish VCs to any entity within 126 your LIS [1], Cluster [2], or LAG [3]. This can become a problem if 127 UNI access to your ATM cloud is possible - e.g. through poorly 128 restricted physical access such as spare switch ports, or functional 129 access through machines running insecure OSes. (An insecure OS 130 environment can be anything that allows user space applications 131 direct access to either the local hosts's UNI signaling stack, or the 132 underlying ATM NIC itself.) 134 Weak access controls to a host's UNI signaling stack may allow a 135 local user application to establish VCs using Calling Party numbers 136 with arbitrary SEL values (the choice of the other 19 octets of a 137 Calling Party AESA is limited by the ESIs initially registered by the 138 client with the local switch using ILMI). Sufficiently weak access 139 controls might even allow an application to choose Calling Party 140 numbers that clash with other local ATM-based applications. Weak 141 access controls to the host's ATM NIC itself could allow user 142 deployment of a complete ILMI/UNI signaling stack of their own, 143 customized for whatever task is required. 145 A single PC attached to a campus-wide ATM network meets all the 146 criteria for a weakly controlled access point. 148 3. RFC 2022 (MARS) 150 The RFC 2022 protocol is primarily query/response. In addition to 151 triggering responses with direct queries, MARS clients also expect to 152 receive asynchronous updates from their MARS. This opens up 153 possibilities for an attacker to trigger client misbehavior. 155 3.1 Joining the cluster to eavesdrop and interject 157 MARS Clients automatically add new ATM level leaf nodes to their 158 outgoing pt-mpt VCs upon receipt of valid MARS_JOIN messages. An 159 attacker wishing to eavesdrop on any multicast group's traffic within 160 a Cluster need only register as a cluster member, and issue a 161 MARS_JOIN to the MARS for the groups of interest. The MARS will 162 inform all other cluster members, and all current senders will add 163 the attacker as a new leaf node. An attacker who was interested in 164 all traffic within the cluster need only issue a block MARS_JOIN to 165 cover the entire multicast address space (a promiscuous client) in 166 one operation. 168 Aside from the fact that information is leaking from your cluster, 169 such eavesdropping may have a debilitating effect on the wider ATM 170 cloud. If the attacker is topologically distant at the ATM level, 171 this action results in a sudden increase in traffic along the ATM 172 path from your cluster to the attacker's own access point. 174 Having registered with the MARS as a legitimate cluster member, the 175 attacker is also free to begin transmitting its own data to the 176 members of any group it chooses. 178 3.2 Joining as an MCS to eavesdrop and interject 180 An alternative approach to eavesdropping is for an attacker to 181 register as an MCS and claim to support the group or groups of 182 interest. The attacker then becomes the focal point of transmissions 183 from legitimate MARS Clients, and is in a position to make copies of 184 packets sent to it. 186 A non-disruptive attacker would actually provide MCS functionality, 187 to ensure packets from legitimate cluster members are distributed 188 around the cluster as expected. A disruptive attacker could simply 189 black-hole the group's traffic, or creatively modify the packet 190 stream flowing through itself. A totally debilitating attacker would 191 register to support all multicast groups, and then black-hole the 192 traffic. Since the MARS trusts the MCS, and the MARS Clients trust 193 the MARS, this makes an effective denial of service attack. (The 194 fact that MCS cannot issue a block join provides minimal defense. A 195 creative attacker would register as a normal client in promiscuous 196 mode, watch for new groups being joined, and then simultaneously 197 register as an MCS for the new group. A single application running on 198 an unsecured PC can conceivably emulate two distinct ATM entities.) 200 Aside from the fact that information is leaking from your cluster, 201 such eavesdropping may have a debilitating effect on the wider ATM 202 cloud. If the attacker is topologically distant at the ATM level, 203 this action results in a sudden increase in traffic along the ATM 204 path from your cluster to the attacker's own access point. 206 3.3 Bypassing or hi-jacking the MARS 208 The eavesdropping techniques described in the previous two sections 209 involve the attacker registering itself with the MARS as either a 210 legitimate client or MCS. If the MARS Clients within the Cluster fail 211 to perform sanity checks on the source of the MARS_JOIN messages they 212 listen to, it may be feasible for an attacker to target particular 213 senders directly. The attacker establishes a VC to the target MARS 214 Client and sends it a properly formatted MARS_JOIN. In this case, 215 the attacker only receives a copy of the traffic from the targetted 216 MARS Client. 218 A MARS Client that fails to sanity check MARS_LEAVE messages can be 219 effectively shut down by an attacker. The attacker finds the group 220 members by querying the MARS, then begins issuing MARS_LEAVEs to the 221 target MARS Client. Each MARS_LEAVE causes the target MARS client to 222 drop another leaf node from its forwarding VC. Eventually the VC is 223 closed down. 225 An MCS may be similarly vulnerable to fake MARS_SJOIN/SLEAVE messages 226 coming directly from an attacker. 228 This vulnerability may be partially closed if the MARS Client checks 229 the source of the VC on which MARS_JOIN/LEAVE messages arrive. 230 Messages to update outgoing pt-mpt VCs arrive on ClusterControlVC. 231 However, the current protocol does not provide Clients with a 232 definite mechanism for determining which incoming SVC represents 233 ClusterControlVC. If the ATM signaling is trusted, the sanity check 234 would be to only accept MARS_JOIN/LEAVE messages arriving on VCs 235 whose Calling Party number is that of the MARS entity. If the VCs 236 Calling Party number is unavailable, the target MARS Client can, at 237 best, make an assumption that the VC on which it first receives a 238 MARS_REDIRECT_MAP must be ClusterControlVC. 240 MARS_REDIRECT_MAP itself provides trouble for vulnerable MARS 241 Clients. An attacker who is prepared to emulate a complete MARS can 242 transmit a fake MARS_REDIRECT_MAP to all (or some subset) of the 243 Cluster's members, forcing them to voluntarily switch from the 244 current MARS. If a 'hard redirect' is demanded by the attacker, the 245 MARS Clients will also assist the attacker by re-MARS_JOINing every 246 group they were members of. Once redirected, cluster operation 247 continues as though nothing has happened. (Clients that depend on 248 seeing a MARS_REDIRECT_MAP to decide which VC is ClusterControlVC are 249 vulnerable to this attack if the first MARS_REDIRECT_MAP that they 250 see is from the attacker.) Having taken over as the cluster's MARS, 251 the attacker is pretty much free to cause further havoc. 253 3.4 Denial of Service 255 An attacker could disrupt or slow down MARS service by repetitive VC 256 setup/teardown events. An attacker who repeatedly registered and de- 257 registered as a cluster member would cause even more ATM signaling 258 activity, as the target MARS updates ClusterControlVC. Similarly, an 259 attacker could repeatedly register and deregister as an MCS to force 260 updates of ServerControlVC. 262 A direct attack on the MARS itself might involve explicitly joining, 263 in sequence, every possible multicast group, in the hope that the 264 internal database will overflow. Some MARS implementations may react 265 by crashing, providing a useful denial of service mechanism. Being 266 able to force a crash has additional uses - the attack can force a 267 restart, and while the clients are re-registering with the restarted 268 MARS, the attacker injects false MARS_REDIRECT_MAPs as described in 269 section 3.3. 271 Faking of an MCS by the attacker (as described in section 3.2) can be 272 used to create full or partial black-holes for traffic. 274 3.5 Hiding the MARS 276 Many scenarios involve the attacker knowing who the cluster members 277 are. In most situations this will be trivial to achieve, since there 278 is usually some well known multicast group joined by all cluster 279 members (e.g. 224.0.0.1 under IPv4). A MARS_REQUEST on this group 280 will provide the required information. (Interestingly, since MARS 281 Clients and ATMARP Clients are typically co-located, this search will 282 reveal the locations of all ATMARP Clients in the LIS as well. 283 Probing each client by opening a direct VC is likely to elicit an 284 InARP Request that reveals the client's unicast IP address.) 286 Keeping the address of the MARS secret can help discourage many of 287 the preceding attacks. However, experience with RFC 1577 288 implementations suggests that there will be little attempt to hide 289 the configuration information from users. If the person behind the 290 attacks has user level access to any machine on the LIS, they will 291 have access to the MARS address. 293 Even if the MARS address could be kept a secret, a determined search 294 would make use of the fact that a MARS reacts in a predictable way 295 when it is sent a correctly formatted registration MARS_JOIN. An 296 attacker with complete or partial knowledge of the AESAs in your 297 region of the cloud can poll possible AESA variations (varying the 298 SEL field) looking for an endpoint that reacts correctly to 299 MARS_JOIN. 301 An attacker with physical access to your ATM cloud can place a tap on 302 any link, parse the UNI signalling traffic going past, and draw 303 conclusions from the AESAs it sees in SETUP messages. 305 4. RFC xxxx (NHRP) 307 The RFC xxxx protocol is primarily query/response. In addition to 308 triggering responses with direct queries, NHRP clients also expect to 309 receive asynchronous updates from their NHS, which opens up 310 possibilities for an attacker to trigger client misbehavior. 312 Although RFC xxxx provides an optional TLV for authentication 313 purposes, its use is not currently mandatory. Therefore, this section 314 assumes NHRP installations where no use is being made of the 315 authentication TLV. 317 [insert cites to any prior work here.] 319 [This section is very much under construction.] 321 4.1 IP/ATM address spoofing 323 Address spoofing involves the insertion of incorrect {IP,ATM} 324 mappings into the NHS' database. An attacker establishes a VC to the 325 NHS for a given LIS/LAG, and provides a fake {IP,ATM} mapping in its 326 NHRP Register Request. An attacker may also attempt to register fake 327 {IP,ATM} mappings in NHSes serving remote LIS/LAGs, by specifying a 328 remote NHS as the Destination of the NHRP Register Request. 330 This sort of spoofing can be used either as a denial of service 331 attack or a stepping stone to subsequent hi-jacking of higher level 332 IP services (e.g. register the IP address of the local NFS server or 333 router immediately after an NHS reboot). As fake mappings can be 334 inserted into NHSes outside the immediate LIS/LAG, the scope for 335 damage is far greater than that presented in ATMARP installations. 337 An attacker may find value in attempting to register mappings with a 338 target NHS that represent IP addresses from a LIS/LAG not served by 339 the target NHS, in case the NHS implementation fails to sanity check 340 the mapping. If the fake registration succeeds, no other NHSes 341 (including the NHS that actually serves the target IP address) will 342 know that the compromised NHS is handing out false information. The 343 compromised NHS may also respond to non-authoritative requests for 344 the affected IP addresses mapping from remote clients if their NHRP 345 Requests are routed through it. 347 (Note that registering with an NHS outside the local LIS/LAG only 348 requires that the IP address of the remote NHS be placed into the 349 attacker's NHRP Registration Request. Thus the attacker need only 350 know the ATM address of one NHS. The IP addresses of potential 351 target NHS(es) may be surmised by checking the IP addresses of 352 routers in the region, as reported by tools such as 'traceroute'.) 354 4.2 Scanning the {IP,ATM} mapping space. 356 It is usually undesirable for outsiders to know the entire set of IP 357 addresses (and associated ATM addresses) that make up your LIS/LAG. 358 However, there is little to stop an attacker from establishing a VC 359 to your NHS, registering an innocuous {IP,ATM} mapping, and 360 proceeding to issue NHRP Requests for a range (or ranges) of 361 'interesting' IP addresses. 363 Since the NHRP service's design goal is the resolution of IP 364 addresses outside the LIS/LAG, the attacker can also choose to scan 365 the mappings for other LIS/LAGs through the local NHS. Knowing the 366 address of any one NHS opens up an entire set of LIS/LAGs. 368 The ATM addresses thus learned might be used in subsequent denial of 369 service attacks against specific hosts. Depending on range of IP 370 addresses chosen during the scan, and the speed with which the 371 repeated NHRP Requests are issued, this scanning can itself keep the 372 NHS so busy as to constitute a denial of service attack. If the 373 target IP addresses are outside the local LIS/LAG, the request 374 traffic propagates to other NHSes too. 376 Not knowing the LIS/LAG address range makes the attack less 377 efficient, but not impossible since the server actively responds to 378 bad guesses with NHRP Reply indicating failure. A selective search 379 would make intelligent guesses as to the probable range of net/subnet 380 numbers to scan. 382 4.3 Denial of Service attacks. 384 An attacker can present two types of overload to an NHS - repetative 385 VC setup/teardown events without actually registering any {IP,ATM} 386 mappings (simply to consume cpu cycles in the NHS' underlying UNI 387 stack), and repeated VC setup/teardown/registration events (where the 388 attacker explicitly NHRP Registers with a different {IP,ATM} mapping 389 each time). 391 The first type of attack wastes time at the NHS, and causes 392 additional loading of the control processor in the switch to which 393 the target is attached (and other switches along the path between the 394 attacker and target). 396 The second type of attack will be slower (although parallel VC setup 397 attempts can be used to keep the average rate up), but results in 398 additional database manipulation activity in the NHS. This can result 399 in collisions with IP addresses already registered, or set the stage 400 for later collisions when the legitimate owners of a particular IP 401 address attempt to register. 403 As noted in section 4.1, the second type of attack can be launched 404 against remote NHSes without even knowing their ATM addresses. 406 Harrassment through repetative VC setup/teardown may also be launched 407 against NHCs whose addresses were learned through scanning of the NHS 408 database. 410 An attacker can transmit fake NHRP Purge messages to both NHSes and 411 NHCs. At minimum this is likely to result in unnecessary VC 412 teardown/setup sequences between NHCs whose current short-cuts are 413 prematurely purged. 415 4.5 Hiding the NHS 417 Keeping the ATM addresses of NHS secret would help discourage many of 418 the preceding attacks. However, this is unlikely to be even remotely 419 achievable. 421 As noted in section 4.1, if only one NHS ATM address is known this is 422 sufficient to cover all NHSes. Their IP addresses can be guessed from 423 the IP addresses of routers in the network, and if required the 424 attacker can query the initial NHS to discover the matching ATM 425 addresses. 427 Even if all NHS ATM addresses could be kept a secret, a determined 428 search would make use of the fact that an NHS reacts in a predictable 429 way when it is sent a correctly formatted NHRP messages. An attacker 430 with complete or partial knowledge of the AESAs in your region of the 431 cloud can poll possible AESA variations (varying the SEL field) 432 looking for an endpoint that reacts correctly to NHRP Registration 433 Request. 435 An attacker with physical access to your ATM cloud can place a tap on 436 any link, parse the UNI signalling traffic going past, and draw 437 conclusions from the AESAs it sees in SETUP messages. 439 5. Common extensions to MARS and NHRP 441 Both MARS and NHRP share a common control packet syntax that supports 442 optional TLV-based fields. RFC xxxx contains an authentication TLV, 443 and it would seem reasonable to build on this TLV for MARS. 445 [TBD] 447 [TLV exists, but key distribution is a problem.] 449 6. Conclusion 451 [TBD] 453 Security Consideration 455 Security considerations are covered in this document. 457 Acknowledgments 459 Author's Address 461 Grenville Armitage 462 Bell Labs, Lucent Technologies. 463 101 Crawfords Corner Rd, 464 Holmdel, NJ, 07733 465 USA 467 Email: gja@lucent.com 468 References 470 [1] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett- 471 Packard Laboratories, December 1993 473 [2] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM 474 Networks.", Bellcore, RFC 2022, November 1996 476 [3] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", 478 [4] J. Moy, "OSPF Version 2", RFC 1247, March 1994 480 [5] G. Armitage, C. Wang, "Security issues for the ATMARP protocol", 482 [6] R. Atkinson, "Security Architecture for the Internet Protocol", 483 RFC 1825, August 1995 485 [7] ATM Forum, "ATM User-Network Interface Specification Version 486 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993. 488 [8] ATM Forum, "ATM User Network Interface (UNI) Specification 489 Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, 490 NJ, June 1995.