idnits 2.17.1 draft-armitage-ion-sec-arp-00.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-25) 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. 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) ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-11 ** Obsolete normative reference: RFC 1247 (ref. '4') (Obsoleted by RFC 1583) -- No information found for draft-ion-ipatm-classic2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-01 -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1825 (ref. '8') (Obsoleted by RFC 2401) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1828 (ref. '10') ** Obsolete normative reference: RFC 1293 (ref. '11') (Obsoleted by RFC 2390) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 14 errors (**), 0 flaws (~~), 3 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 Cliff X. Wang 5 IBM Corporation 6 October 11th, 1997 8 Security issues for the ATMARP protocol 9 11 Status of this Memo 13 This document was submitted to the IETF Internetworking over NBMA 14 (ION) WG. Publication of this document does not imply acceptance by 15 the ION WG of any ideas expressed within. Comments should be 16 submitted to the ion@nexen.com mailing list. 18 Distribution of this memo is unlimited. 20 This memo is an internet draft. Internet Drafts are working documents 21 of the Internet Engineering Task Force (IETF), its Areas, and its 22 Working Groups. Note that other groups may also distribute working 23 documents as Internet Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet 28 Drafts as reference material or to cite them other than as a "working 29 draft" or "work in progress". 31 Please check the lid-abstracts.txt listing contained in the 32 internet-drafts shadow directories on ds.internic.net (US East 33 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 34 munnari.oz.au (Pacific Rim) to learn the current status of any 35 Internet Draft. 37 Abstract 39 This document discusses some security issues associated with IP over 40 ATM operation. RFC1577 defines the Classic IP model for sending IP 41 traffic over ATM. However, security issues were not addressed in the 42 standard. Since internet is an open architecture, security measures 43 to protect network integrity are essential for normal operation. The 44 security loopholes in the current RFC 1577 model are analyzed and 45 discussed. Possible solutions are proposed. 47 Change History 49 September 1997 50 ATMARP specific sections extracted to form a stand-alone document. 51 Substantial contributions from IBM co-authors. Name changed from 52 draft-armitage-ion-security-00.txt to draft-armitage-ion-sec-arp- 53 00.txt 55 July 1997 56 Initial release covering ATMARP, MARS, and NHRP. Begins to 57 describe the problems. Solutions still TBD. 59 1. Introduction 61 Security is a broad term, and often used subjectively when a given 62 protocol is said to be 'secure' or 'insecure'. The context and prior 63 assumptions need to be clearly understood for each assertion of an 64 overall system's level of security. Typically most security can 65 summarised as 'no-one would find me interesting enough to bother'. 66 Unfortunately, innocent hackers and/or malicious crackers will find 67 most IP/ATM installations 'interesting' at some point. Whether you 68 are victim of a denial-of-service attack, or denial-of-service 69 screw-up, the effect is similarly annoying. 71 The ION working group and its predecessors (the IP-ATM and ROLC 72 working groups) are responsible for three key protocols to support 73 unicast and multicast IP over ATM (and other NBMA) networks - RFC 74 1577 (ATMARP) [1], RFC 2022 (MARS) [2], and RFC xxxx (NHRP) [3]. The 75 development of these protocols focussed on achieving a set of goals 76 that did not initally include specific security issues. 78 The Classical IP over ATM model was first suggested in 1993 at the 79 Internet Engineering Task Force IETF spring meeting and was later 80 documented in RFC 1577. In this model, IP end-stations are grouped 81 into Logical IP Subnet (LIS). Within the LIS, ATM Address Resolution 82 Protocol (ATMARP) [1] supports IP data communication. Traffic between 83 different LISs is routed using conventional IP routing protocols such 84 as OSPF[4]. 86 Since the internet is an open community, and RFC1577 model depends on 87 the correct ATMARP client/server operation, it is important for the 88 industry to be aware of the various security risks, and what can be 89 done to reduce these risks. This document focusses on the security 90 risks inherent in the RFC1577 architecture. IP related security 91 issues are reviewed in RFC 1825 [8]. 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 96 1577. 98 The rest of this document is structured in the following manner. 99 Section 2 provides a brief review of the RFC 1577 model, and section 100 3 notes the limited assumptions one can make about ATM level 101 security. Section 4 summarizes the known security limitations of RFC 102 1577, and section 5 discusses possible solutions. 104 2. Review of the RFC 1577 model 106 Classical IP over ATM is currently defined by RFC 1577. Recently, an 107 updated version of RFC1577 has also been proposed [5]. 109 In the RFC 1577 model, IP end-stations are grouped into Logical IP 110 Subnets (LIS) based on the end-station's IP address and the subnet 111 mask. For each LIS, a dedicated ATMARP server provides the protocol 112 to physical address resolution service for all the clients of the 113 same LIS. Each client of the LIS registers with the ATMARP server to 114 obtain the address translation service from the server as well supply 115 its own address information to the server. When a client wants to 116 setup an IP data path to another client, it checks if it knows the 117 associated destination ATM address. If such information is not 118 available, the sending client contacts the ATMARP server by sending 119 an ATMARP request packet to query the destination's ATM address. If 120 the destination's ATMARP client has registered with the server and is 121 active, the ATMARP server will send an ATMARP reply packet to the 122 requesting ATMARP client with the destination's ATM address. 124 Upon receiving the reply from the server, the sending client can 125 initiate communication to the receiving client. If the server doesn't 126 have the requested information, an ATMARP NAK packet is sent back and 127 no connection can be established. 129 RFC 1577 also defines the use of Inverse ARP [11] in the ATM 130 environment. An ATMARP client may have knowledge of a destination's 131 ATM address but want to discover (or confirm) the matching IP 132 address. To obtain the destination's IP address, an InATMARP packet 133 is sent directly to the destination, and an InATMARP reply packet is 134 sent back with the destination's IP address associated with the ATM 135 address supplied in the InATMARP Request. The InATMARP request and 136 reply is not restricted to pairs of clients. It is used to register 137 new ATMARP Clients with the ATMARP Server - when a new client ATMARP 138 client establishes a VC to the ATMARP Server, the first thing done by 139 the server is to send an InATMARP Request. The ATMARP Client's 140 InATMARP Reply carries the IP/ATM mapping then used by the ATMARP 141 Server. 143 A distributed ATMARP server protocol is also being developed [6,7]. 144 More than one ATMARP server may be implemented in a subnet such that 145 the critical address resolution service will be un-interrupted when 146 one or more ATMARP servers (but not all of them) break down. Under 147 the distributed ATMARP server scheme, ATMARP client may register and 148 use any of the active ATMARP server. Each active ATMARP server 149 maintains the address information for the whole subnet. The address 150 resolution information is exchanged and kept synchronized among the 151 participating ATMARP servers. 153 For the purposes of this document, references to "the ATMARP Server" 154 can be taken to apply to both the single server case, and the 155 distributed server case. Security weaknesses inherent in the 156 protocols used to create the distributed ATMARP Server will be 157 covered in another document. 159 3. ATM level security 161 RFC 1577 assumes that the underlying ATM network itself is 162 trustworthy. There is an implicit assumption that if a SETUP message 163 arrives at your node, the Calling Party Information Element (IE) 164 contains a legitimate address correctly identifying the SETUP's 165 originator. (In line with the 'surely I'm too un-interesting to 166 bother' philosophy, there is an additional assumption that the SETUP 167 message came from someone with a right to establish the VC, 168 regardless of the address in the Calling Party IE.) 170 Unfortunately, UNI 3.0/3.1 ATM signaling [12,13] does not utilize any 171 form of end-node authentication. This leaves the SETUP phase 172 vulnerable to 'man in the middle' attacks (where a switch somewhere 173 in the ATM network is compromised, or a link is broken and an 174 additional entity introduced that is capable of intercepting and 175 modifying UNI or NNI signaling traffic on the fly). 177 Even if end points were authenticated, UNI 3.0/3.1 does not support 178 the notion of closed user groups. This allows anyone with UNI access 179 to your underlying ATM cloud to establish VCs to any entity within 180 your LIS [1]. This can become a problem if UNI access to your ATM 181 cloud is possible - e.g. through poorly restricted physical access 182 such as spare switch ports, or functional access through machines 183 running insecure OSes. (An insecure OS environment can be anything 184 that allows user space applications direct access to either the local 185 hosts's UNI signaling stack, or the underlying ATM NIC itself.) 187 Weak access controls to a host's UNI signaling stack may allow a 188 local user application to establish VCs using Calling Party numbers 189 with arbitrary SEL values (the choice of the other 19 octets of a 190 Calling Party AESA is limited by the ESIs initially registered by the 191 client with the local switch using ILMI). Sufficiently weak access 192 controls might even allow an application to choose Calling Party 193 numbers that clash with other local ATM-based applications. Weak 194 access controls to the host's ATM NIC itself could allow user 195 deployment of a complete ILMI/UNI signaling stack of their own, 196 customized for whatever task is required. 198 A single PC attached to a campus-wide ATM network meets all the 199 criteria for a weakly controlled access point. 201 4. Security in the RFC 1577 model 203 The RFC 1577 protocol is query/response based. ATMARP Clients 204 initiate activity that leads to responses from the ATMARP Server 205 (either by establishing a VC, or issuing an ATMARP Request). The 206 ATMARP Server trusts mapping information it receives from ATMARP 207 Clients. ATMARP Clients never change their behavior based on 208 asynchronous control messages from the ATMARP Server. 210 Many of the observed security weaknesses stem from the lack of 211 meaningful access control available to ATMARP Servers, and the lack 212 of ATMARP level authentication mechanisms for either Server(s) or 213 Clients to use. 215 4.1 IP/ATM address spoofing 217 Address spoofing involves the insertion of incorrect {IP,ATM} 218 mappings into the ATMARP Server's database. This is trivial to 219 achieve. An attacker establishes a VC to the ATMARP Server for a 220 given LIS, the Server issues a pre-emptive InARP REQUEST, and the 221 attacker provides a fake {IP,ATM} mapping in its InARP Reply. 223 This sort of spoofing can be used either as a denial of service 224 attack or a stepping stone to subsequent hi-jacking of higher level 225 IP services (e.g. register the IP address of the local NFS server or 226 router immediately after an ARP Server reboot). 228 If the ATM addresses of LIS members are known, an attacker can 229 attempt to directly insert misleading {IP,ATM} mappings into another 230 LIS member's ATMARP Client. ATMARP Client implementations that 231 attempt to learn {IP,ATM} mappings from the InARP exchange with other 232 clients can be fooled in this way. The attacker simply establishes a 233 VC to a known member and passes back an arbitrary IP address in its 234 reply to the target Client's InARP Request. If the supplied IP 235 address matches that of an important node in the LIS (e.g. a router) 236 to which the target client has yet to establish legitimate 237 communication, the attack can be the prelude to hi-jacking of higher 238 level IP services. 240 As ATMARP Clients never query for IP addresses outside their LIS, 241 there is little value in an attacker attempting to spoof mappings for 242 IP addresses that lie outside the scope of the LIS. 244 4.2 Scanning of the LIS. 246 It is usually undesirable for outsiders to know the entire set of IP 247 addresses (and associated ATM addresses) that make up your LIS. 248 However, there is little to stop an attacker from establishing a VC 249 to your ATMARP Server, registering an innocuous {IP,ATM} mapping, and 250 then proceeding to issue ATMARP_REQUESTs for a range (or ranges) of 251 'interesting' IP addresses. 253 The ATM addresses thus learned might be used in subsequent denial of 254 service attacks against specific hosts. Depending on range of IP 255 addresses chosen during the scan, and the speed with which the 256 repeated ATMARP_REQUESTs are issued, this scanning can itself keep 257 the ATMARP Server so busy as to constitute a denial of service 258 attack. Not knowing the LIS address range makes the attack less 259 efficient, but not impossible since the server actively responds to 260 bad guesses with ATMARP_NAKs. A selective search would make 261 intelligent guesses as to the probable range of net/subnet numbers to 262 scan. 264 4.3 Denial of Service attacks. 266 Denial of service is any action that subverts the normal and timely 267 operation of the total IP/ATM system. Attacks may aim to either slow 268 down normal operations, or cause a cessation of operations altogether 269 by exploting implementation weaknesses. 271 An attacker can present two types of overload to an ATMARP Server - 272 repetative VC setup/teardown events without actually registering any 273 {IP,ATM} mappings (simply to consume time in the ATMARP Server's 274 underlying UNI stack), and repeated VC setup/teardown/registration 275 events (where the attacker responds to the Server's initial InARP 276 Request with a different {IP,ATM} mapping each time). 278 The first type of attack wastes time at the ATMARP Server, and causes 279 additional loading of the control processor in the switch to which 280 the target is attached (and other switches along the path between the 281 attacker and target). 283 The second type of attack will be slower (although parallel VC setup 284 attempts can be used to keep the average rate up), but results in 285 additional database manipulation activity in the Server. This can 286 result in collisions with IP addresses already registered, or set the 287 stage for later collisions when the legitimate owners of a particular 288 IP address attempt to register. 290 Depending on the ATMARP Server's design, it may happily accept 291 {IP,ATM} mappings outside the range of IP addresses of the LIS it is 292 nominally supporting. (This is not strictly illegal, since the 293 'Classical IP' restrictions on resolving addresses outside the LIS 294 actually derive from host-side behavior not server-side behavior.) 295 This would have the affect of avoiding collisions while filling up 296 the Server's database with useless information, possibly avoiding 297 detection of the attack until the Server's database collapses. 299 An attacker may also choose to launch similar attacks on LIS Clients 300 whose addresses were learned through previous scanning of the ATMARP 301 Server's database. 303 4.4 ATMARP Server spoofing 305 ATMARP Clients never receive asynchronous updates from server. This 306 makes it unlikely that a client implementation would listen to a 307 faked ARP Reply, ARP Nak, or InARP Reply arriving on a VC that the 308 client did not believe to be connected to the ATMARP Server (or 309 another client). 311 However, if authentication is not used in message exchanges between 312 server and its clients, an attacker might be in the position to 313 modify packets sent from server to client and interrupt the normal 314 operation of the client. For example, the address field of the 315 ATMARP replay message can be modified, or any other field can be over 316 written. The simplest attack is to over write the packet content with 317 garbage data and force the client to flush the received packets. This 318 can consequently disrupt client registration or attempts to establish 319 the IP/ATM address mapping for another client. 321 An attack on the identity of the ATMARP Server would either involve 322 compromising the security of the Client's local configuration file, 323 or compromising the ATM network itself (to redirect a client's SETUP 324 towards the attacker's own substitute ATMARP Server). These are both 325 feasible, but do not depend on characteristics of the RFC 1577 326 protocol itself. 328 4.5 Hiding the ATMARP Server 330 Keeping the address of the ATMARP Server secret can help discourage 331 many of the preceding attacks. However, few RFC 1577 implementations 332 make any attempt to hide the configuration information from users. If 333 the person behind the attacks has user level access to any machine on 334 the LIS, he will have access to the ATMARP Server address. 336 Even if the ATMARP Server's address could be kept a secret, a 337 determined search would make use of the fact that an ATMARP Server 338 announces its existence with a pre-emptive InARP Request whenever a 339 new VC is established to it. An attacker with complete or partial 340 knowledge of the AESAs in your region of the cloud can poll possible 341 AESA variations (varying the SEL field) looking for an endpoint that 342 reacts with InARP Requests. 344 An attacker with physical access to your ATM cloud might conceivably 345 place a passive or active tap on suitable links, parse the UNI 346 signalling traffic going past, and draw conclusions from the AESAs it 347 sees in SETUP messages. 349 4.6 Security issues for distributed servers 351 Server Cache Synchronization protocol (SCSP)[6] supports distributed 352 ATMARP server operation. More than one ATMARP server may be 353 implemented in a subnet such that the critical address resolution 354 service will be un-interrupted when one or more ATMARP servers (but 355 not all of them) break down. Under the distributed ATMARP server 356 scheme, ATMARP client may register and use any of the active ATMARP 357 server. Each active ATMARP server maintains the address information 358 for the whole subnet. The address resolution information is exchanged 359 and kept synchronized among the participating ATMARP servers. 361 Two types of attacks are possible when running distributed ATMARP 362 servers. One type is that intruder has access to the link between 363 two servers. The other type is that an ATMARP server is compromised. 364 When the intruder has access to the link between two servers, the 365 cache synchronization message can be intercepted, altered, or 366 replayed. Message authentication between two servers will protect the 367 integrity of messages, but cannot solve the problem of replay attack 368 unless combined with timestamp. For the second case when a server is 369 compromised, it can send false cache information to any other servers 370 participated in the server group and bring down the whole LIS. There 371 is no clear solution to such attack, unless system administration is 372 alerted and disconnect the compromised server from the group. 373 Specific security analysis and solution on distributed server 374 synchronization operation is outside the scope of this draft. 376 5. Possible solutions 378 5.1 Access control 379 Protection against un-motivated or accidental attackers may be 380 provided by insisting that the ATMARP Server respond only to known 381 clients. However, this raises the question of how a client is 382 'known'. 384 - Prior configuration of the ATMARP Server with a list of valid 385 client ATM addresses can involve significant management 386 overhead. It constrains the physical attachement points of 387 ATMARP Clients to the ATM cloud (since their attachment point 388 affects their AESA). It is not effective against attackers who 389 are able to spoof their ATM attachment point. 391 - The ATMARP Server could be configured with a list of valid 392 client IP addresses, or the range of legal addresses in the LIS. 393 This would enable rejection of any mappings for IP addresses 394 outside of the LIS, but doesn't provide any serious security 395 since most attackers already have a fair idea of the Server's 396 LIS before hand. 398 - The ATMPARP Server could be configured with lists of both legal 399 IP addresses and legal ATM addresses. This would constrain all 400 ATMARP Clients to dynamically map only legal IP addresses to 401 legal ATM addresses. 403 - The ATMARP Server could be statically configured with all the 404 legal IP/ATM mappings for the LIS, and act as a 'read-only' 405 ATMARP Server. Disallowing arbitrary client registrations 406 removes many of the security weaknesses in the RFC 1577 model, 407 but at a severe cost in flexibility. 409 In each case, the notion of proving a client's right to use the 410 ATMARP Server through its IP or ATM address is simply a weak form of 411 authentication, because the IP or ATM address can be easily spoofed 412 It is also inflexible - in the case of defining 'legal' ATM 413 addresses, it assumes apriori knowledge of all attachment points to 414 the ATM network that a legal ATMARP Client might use. What is 415 preferable is a means of authenticating clients that is associated 416 with the client itself, and not its topological position in the ATM 417 or IP network. 419 5.2 Authentication 421 Currently RFC 1577 clients or servers do not authenticate request and 422 reply messages. The IP or ATM addresses contained within the current 423 control messages do not constitute authentication information. There 424 is no way for a client to 'prove' to a server that the client is 425 entitled to use the server, and no way for a server to ascertain the 426 client's right. 428 Without an authentication mechanism, access control is weak. However, 429 if an authentication mechanism were put in place, access control 430 could be coupled to the information used to authenticate clients and 431 servers, rather than the weak address-based approaches described in 432 the previous section. 434 One current authentication mechanism involves the hashing of an IP 435 packet's contents using a Keyed MD5 algorithm (RFC 1321 [9] and RFC 436 1828 [10]). The resulting digital signature is sent along with the IP 437 packet. The packet's recipient authenticates the packet and its 438 source by running the same algorithm over the packet, using the same 439 key. If the result matches the signature supplied along with the 440 packet, the recipient considers the packet to be valid. 442 This form of authentication is based on the shared knowledge of a 443 secret key between the source and destination of each packet. 444 Generalizing this to an ATMARP environment requires that the ATMARP 445 control message format be extended to carry a Keyed MD5 signature, 446 and that configuration of an ATMARP LIS support the secure 447 distribution of secret keys. 449 The use of authentication would increase the processing overhead in 450 both servers and clients, increasing the query/response latency. 451 However, since ATMARP is only used when the client doesn't have a 452 local mapping already cached, or when initially registering, the 453 impact of actual IP traffic flows will be minimal. 455 Pragmatically, it is not clear that RFC 1577 control packet 456 extensions are worthwhile pursuing. Future IP/ATM installations are 457 expected to transition to NHRP for both inter-LIS and intra-LIS 458 address resolution functions. NHRP has its own facilities for 459 carrying authentication information. 461 5.3 Management alerts 463 While not directly a tool for preventing attacks, RFC 1577 464 implementations may choose to provide custom SNMP based mechanisms 465 for issuing alerts when a range of unusual activities occur. One 466 obvious example would be to issue an alert when excessive signaling 467 activity is detected, suggesting a possible denial of service attack. 469 Specific proposals for such alert mechanisms are not covered by this 470 document. 472 6. Conclusion and Open Issues 474 This draft provides a security analysis on IP over ATM operation 475 (ATMARP) based on RFC 1577. Solutions to safeguard the normal 476 operation of ATMARP from attacks are suggested. However, due to 477 limitations of current ATMARP control message format, ATMARP packet 478 authentication cannot be directly built in. The addition of TLV 479 extensions may be required to the current ATMARP packet in order to 480 carry authentication message. 482 At time of writing, a new Classic2 draft is in progress which will 483 ultimately replace RFC 1577. This security analysis draft will be 484 updated accordingly when Classic2 become RFC status. 486 Security Consideration 488 Security considerations are dealt with throughout this document. 490 Acknowledgments 492 Author's Addresses 494 Grenville Armitage 495 Bell Labs, Lucent Technologies. 496 101 Crawfords Corner Rd, 497 Holmdel, NJ, 07733 498 USA 500 Email: gja@lucent.com 502 Cliff X. Wang 503 Networking Hardware Division 504 International Business Machines Corporation. 505 P.O. Box 12195, 506 Research Triangle Park, 507 NC 27709 508 USA 510 Email: cliff_wang@vnet.ibm.com 512 References 514 [1] M. Laubach, "Classical IP and ARP over ATM", RFC1577, Hewlett- 515 Packard Laboratories, December 1993. 517 [2] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM 518 Networks", Bellcore, RFC 2022, November 1996. 520 [3] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", 521 INTERNET DRAFT, draft-ietf-rolc-nhrp-11.txt, February 1997. 523 [4] J. Moy, "OSPF Version 2", RFC 1247, March 1994 525 [5] M. Laubach, J. Halpern, "Classic IP and ARP over ATM", INTERNET 526 DRAFT, draft-ion-ipatm-classic2-02.txt, March 1997. 528 [6] J. Luciani, G. Armitage, J. Halpern, "Server Cache 529 Synchronization Protocol (SCSP)", INTERNET DRAFT, draft-ietf-ion- 530 scsp-01.txt, April 1997 532 [7] J. Luciani, B. Fox, "A Distributed ATMARP Service Using SCSP", 534 [8] R. Atkinson, "Security Architecture for the Internet Protocol", 535 RFC 1825, August 1995 537 [9] R. Rivest, "MD5 Digest Algorithm", RFC 1321, April, 1992 539 [10] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", 540 RFC 1828, August 1995 542 [11] T. Bradely, C. Brown, "Inverse Address Resolution Protocol", RFC 543 1293, Wellfleet Communications, Inc., January 1992 545 [12] ATM Forum, "ATM User-Network Interface Specification Version 546 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993. 548 [13] ATM Forum, "ATM User Network Interface (UNI) Specification 549 Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, 550 NJ, June 1995.