idnits 2.17.1 draft-rfced-info-hamzeh-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-16) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 197: '... MUST This word, or...' RFC 2119 keyword, line 201: '... MUST NOT This phrase m...' RFC 2119 keyword, line 204: '... SHOULD This word, or...' RFC 2119 keyword, line 212: '... MAY This word, or...' RFC 2119 keyword, line 215: '...nclude this option MUST be prepared to...' (16 more instances...) 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.) -- The document date (May 1996) is 10198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1334 (ref. '2') (Obsoleted by RFC 1994) -- No information found for draft-ietf-radius - is the name correct? ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) Summary: 12 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kory Hamzeh 2 Internet-Draft Ascend Communications 3 Category: Informational May 1996 5 Ascend Tunnel Management Protocol - ATMP 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 "working draft" or "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Europe) 28 ds.internic.net (US East Coast) 29 ftp.isi.edu (US West Coast) 30 munnari.oz.au (Pacific Rim) 32 Abstract 34 This document specifies a generic tunnel management protocol that 35 allows remote dial-in users to access their home network as if they 36 were directly attached to the home network. The user's client 37 software uses an address contained in the home network address space 38 for the remote access. Packets to and from the home network are 39 tunneled by the Network Access Server (NAS) to which the user 40 connects and a Home Agent (HA) on the user's home network. This 41 allows for the support of access to Virtual Private Networks and also 42 allows for the use of protocols other than IP to be carried over the 43 tunnel. An example of how the RADIUS (Remote Authentication Dial In 44 User Service) can be used to provide the necessary configuration 45 information to support this service is also provided. 47 1. Introduction 48 The Ascend Tunnel Management Protocol (ATMP) is a protocol currently 49 being used in Ascend Communication products to allow dial-in client 50 software to obtain virtual presence on a user's home network from 51 remote locations. A user calls into a remote NAS but, instead of 52 using an address belonging to a network directly supported by the 53 NAS, the client software uses an address belonging to the user's 54 "Home Network". This address can be either provided by the client 55 software or assigned from a pool of addresses from the Home Network 56 address space. In either case, this address belongs to the Home 57 Network and therefore special routing considerations are required in 58 order to route packets to and from these clients. A tunnel between 59 the NAS and a special "Home Agent" (HA) located on the Home Network 60 is used to carry data to and from the client. 62 ATMP currently allows for both IP and IPX protocols to be tunneled 63 between the NAS and the HA. The protocol to be used, the HA to use, 64 and other user specific information is provided by some configuration 65 mechanism that is beyond the scope of this document. Appendix A 66 illustrates how RADIUS [5] is used to convey this information to the 67 NAS. 69 The determination of the Home Network address to be used can be 70 accomplished in different ways. It could, for example, be configured 71 in the client and negotiated by IPCP (or IPXCP). Alternatively, it 72 could be defined to be an address specific to the given user ID, or 73 it could be assigned from a pool of addresses provided by the Home 74 Network for the purpose of remote dial-in access. Again, how this 75 address is assigned and how the NAS decides to invoke ATMP for a 76 specific call is beyond the scope of this document. 78 1.1 Protocol Goals and Assumptions 80 The ATMP protocol is implemented only by the NAS and HA. No other 81 systems need to be aware of ATMP. All other systems communicate in 82 the normal manner and are unaware that they may be communicating with 83 remote clients. The clients themselves are unaware of ATMP. It is 84 assumed that standard PPP [8] (or SLIP) clients are being used. 86 Unlike the mobile-IP protocol [3], ATMP assumes that a single NAS 87 will provide the physical connection to a remote client for the 88 duration of the session. The client will not switch between NASes 89 expecting to keep the same IP address and all associated sessions 90 active during these transitions. A particular client can be 91 registered with a given HA only once at any given time. 92 Deregistration with a HA implies loss of all higher layer sessions 93 for that client. 95 IP multicasting is currently not provided by ATMP. 97 1.2 Terminology 99 The terminology used in this document is similar to that used in 100 mobile-IP. As pointed out in the previous section, however, ATMP 101 provides a subset of the functionality provided by mobile-IP and the 102 meanings of the various terms used herein have been modified 103 accordingly. 105 Connection Profile 107 A table used to route packets other than by destination 108 address. The Connection Profile is a named entity that 109 contains information indicating how packets addressed to it are 110 to be routed. It may be used to route packets to unregistered 111 IP addresses and for routing protocols other than IP (e.g., 112 IPX). 114 Foreign Agent (FA) 116 A routing entity that resides in a NAS on a remote network that 117 allows a mobile node to utilize a home network address. It 118 tunnels datagrams to, and detunnels datagrams from, the home 119 agent for the given home network. 121 Home Address 123 An address that is assigned for an extended period of time to a 124 mobile node. It may remain unchanged regardless of where the 125 MN is attached to the Internet. Alternatively, it could be 126 assigned from a pool of addresses. The management of this pool 127 is beyond the scope of this document. 129 Home Agent (HA) 131 A router on a mobile node's home network which tunnels 132 datagrams for delivery to, and detunnels datagrams from, a 133 mobile node when it is away from home. 135 Home Network 137 The address space of the network to which a user logically 138 belongs. When a workstation is physically connected to a LAN, 139 the LAN address space is the user's home network. ATMP 140 provides for a remote virtual connection to a LAN. 142 Mobile Node (MN) 144 A host that wishes to use a Home Network address while 145 physically connected by a point-to-point link (phone line, 146 ISDN, etc.) to a NAS that does not reside on the Home Network. 147 Also referred to as the client. 149 Mobility Binding 151 The association of a Home Address with a Foreign Agent IP 152 address and a Tunnel ID. 154 Network Access Server (NAS) 156 A device providing temporary, on-demand, network access to 157 users. This access is point-to-point using phone or ISDN 158 lines. 160 Tunnel 162 The path followed by a datagram when it is encapsulated. The 163 model is that, while it is encapsulated, a datagram is routed 164 to a knowledgeable decapsulation agent, which decapsulates the 165 datagram and then correctly delivers it to its ultimate 166 destination. Each mobile node connecting to a home agent does 167 so over a unique tunnel, identified by a tunnel identifier 168 which is unique to a given FA-HA pair. A tunnel can carry both 169 IP and IPX datagrams simultaneously. 171 1.3 Protocol Overview 173 A mobile node that wishes to use a home address while connected to a 174 remote NAS must register with the appropriate home agent. The 175 foreign agent entity of the remote NAS performs this registration on 176 behalf of the MN. Once registered, a tunnel is established between 177 the FA and HA to carry datagrams to and from the MN. While a MN is 178 registered with an HA, the HA must intercept any packets destined for 179 the MN's home address and forward them via the tunnel to the FA. When 180 the FA detects that the MN has disconnected from the NAS, it issues a 181 deregister request to the HA. 183 Because ATMP allows protocols other than IP to be carried on its 184 tunnels and also allows unregistered IP address to be used to provide 185 for access to enterprise networks, the HA doesn't necessarily route 186 datagrams received from the MN in the conventional manner. The 187 registration request allows for a named "Connection Profile" to be 188 specified in the registration request. This Connection Profile 189 contains configuration information that tells the HA where to send 190 packets that it receives from the MN. 192 1.4 Specification Language 194 In this document, several words are used to signify the requirements 195 of the specification. These words are often capitalized. 197 MUST This word, or the adjective "required", means 198 that the definition is an absolute requirement 199 of the specification. 201 MUST NOT This phrase means that the definition is an 202 absolute prohibition of the specification. 204 SHOULD This word, or the adjective "recommended", 205 means that, in some circumstances, valid 206 reasons may exist to ignore this item, but 207 the full implications must be understood and 208 carefully weighed before choosing a different 209 course. Unexpected results may result 210 otherwise. 212 MAY This word, or the adjective "optional", means 213 that this item is one of an allowed set of 214 alternatives. An implementation which does 215 not include this option MUST be prepared to 216 interoperate with another implementation which 217 does include the option. 219 silently discard The implementation discards the datagram 220 without further processing, and without 221 indicating an error to the sender. The 222 implementation SHOULD provide the capability of 223 logging the error, including the contents of 224 the discarded datagram, and SHOULD record the 225 event in a statistics counter. 227 2.0 Protocol Specification 229 ATMP defines a set of request and reply messages sent with UDP [4]. 230 The HA listens on UDP port 5150 (not yet registered in "Assigned 231 Numbers" [6]) for requests from FA's. The UDP checksum field MUST be 232 computed and verified. There are 7 different ATMP message types 233 represented by the following Type values: 235 Message Type Type code 237 Registration Request 1 239 Challenge Request 2 241 Challenge Reply 3 243 Registration Reply 4 245 Deregister Request 5 247 Deregister Reply 6 248 Error Notification 7 250 2.1 Registration Request 252 The FA issues a Registration Request to request the HA to establish a 253 mobility binding for the specified MN home address. The request is 254 issued to the HA by the FA upon detecting a MN that wishes to use a 255 home address supported by the HA receiving the request. 257 IP fields 259 Source Address The IP address of the foreign agent 260 interface from which the request is 261 issued. 263 Destination Address The IP address of the home agent. 265 UDP fields: 267 Source Port variable 269 Destination Port 5150 (or port number configured in FA 270 for given HA) 272 The UDP header is followed by the ATMP fields shown below: 274 0 1 2 3 275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Version | Type | Identifier | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Foreign Agent | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Mobile Node | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Mobile Node Mask | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Mobile Node IPX Net | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |Mobile Node IPX Station . . . 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | reserved | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Home Network Name . . . 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Version The ATMP protocol version. MUST be 1. 296 Type 1 for Registration Request. 298 Identifier A 16 bit number used to match replies 299 with requests. A new value should be 300 provided in each new request. 301 Retransmissions of the same request 302 should use the same identifier. 304 Foreign Agent The IP address of the foreign agent 305 issuing the request (typically the same 306 as the UDP source address). 308 Mobile Node The IP address to be used by the mobile 309 node. This is the mobile node's home 310 address. This field can be all 0's if 311 IPX is to be tunneled to the mobile node. 313 Mobile Node Mask The network bit mask for the mobile node. 314 Currently this value should be set to all 315 1's. 317 Mobile Node IPX Net The Network portion of the mobile node's 318 IPX address. This value should be set to 319 all 0's if only IP is to be tunneled. 321 Mobile Node IPX Station The 6 octet value used to represent the 322 station portion of the mobile node's IPX 323 address. This value should be set to all 324 0's if only IP is to be tunneled instead 325 of IPX. 327 Reserved This field is for future extensibility 328 and MUST be set to all 0's. 330 HN Name This is the name of the "Connection 331 Profile" to be used by the home agent to 332 forward all packets received from the 333 mobile node. This character string is 334 terminated by a NUL character and can be 335 up to 32 characters long, including the 336 NUL terminator. 338 2.2 Challenge Request 340 The Home Agent issues a Challenge Request in response to the receipt 341 of a Registration Request from a Foreign Agent. It is used by the 342 Home Agent, in conjunction with the Challenge Reply, to authenticate 343 the Foreign Agent. 345 IP fields 347 Source Address The IP address of the Home Agent 348 interface from which the request is 349 issued. 351 Destination Address Copied form the Source Address of the 352 Registration Request. 354 UDP fields: 356 Source Port variable 358 Destination Port Copied from the Source Port of the 359 Registration Request. 361 The UDP header is followed by the ATMP fields shown below: 363 0 1 2 3 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Version | Type | Identifier | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 | Authenticator | 370 | | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Result Code | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Version The ATMP protocol version. MUST be 1. 378 Type 2 for Challenge Request 380 Identifier A 16 bit number used to match replies 381 with requests. A new value should be 382 provided in each new request. 383 Retransmissions of the same request 384 should use the same identifier. 386 Authenticator A series of 16 octet values randomly 387 generated by the Home Agent. The 388 receiving Foreign Agent is to perform an 389 MD5 [7] hash of these values along with a 390 shared secret. The resultant digest is 391 returned in the Challenge Reply. See 392 Sec. 2.3 Retransmissions of the Challenge 393 Request should use the same Authenticator 394 value. 396 A value of all 0's in this field 397 indicates an error occurred with the 398 Registration Request. The error code 399 will be in the following field. 401 Result Code If non-zero, this value indicates the 402 error condition that occurred. See Sec. 403 2.8 for a list of Result Code values and 404 their meanings. 406 A non-zero value in this field implies 407 that the Authenticator field will be 408 zero. 410 2.3 Challenge Reply 412 The Foreign Agent issues a Challenge Reply upon receipt of a valid 413 Challenge Request (one with a Result Code of 0) from the Home Agent. 414 The Foreign Agent uses the randomly generated Authenticator value 415 from the Challenge Request along with a shared secret to produce an 416 MD5 digest value which is returned to the Home Agent in the Challenge 417 Reply. 419 IP fields 421 Source Address The IP address of the Foreign Agent 422 interface from which the reply is issued. 424 Destination Address Copied from the Source Address of the 425 Challenge Request. 427 UDP fields: 429 Source Port variable 431 Destination Port Copied from the Source Port of the 432 Challenge Request. 434 The UDP header is followed by the ATMP fields shown below: 436 0 1 2 3 437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Version | Type | Identifier | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Reply Length | Reply . . . 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Version The ATMP protocol version. MUST be 1. 446 Type 3 for Challenge Reply 448 Identifier Copied from the corresponding 449 Deregistration Request. 451 Reply Length This field specifies the length of the 452 challenge reply computation based on the 453 received Authenticator and the shared 454 secret. For MD5 this length will always 455 be 16. This field is provided for future 456 extensibility. 458 Reply This is the computed challenge reply. It 459 is computed by performing an MD5 message 460 digest computation over the Authenticator 461 value received in the Challenge Request 462 appended with the secret shared between 463 the Foreign Agent and the Home Agent. 464 The digests produced by MD5 are always 16 465 octets long. 467 2.4 Registration Reply 469 A Registration Reply is issued by a Home Agent in reply to a 470 Challenge Reply received from a Foreign Agent. The Registration 471 Reply indicates to the Foreign Agent whether the registration was 472 accepted by the Home Agent or not. It also provides a "tunnel ID" to 473 uniquely identify the tunnel to be associated with this session. 475 The Home Agent calculates the same MD5 hash on the Challenge Request 476 Authenticator field and the shared secret. The resulting digest is 477 compared with the Reply value in the Challenge Reply and if it is 478 equal, authentication is successful. Otherwise the registration is 479 not accepted and the Foreign Agent is informed by the Result Code of 480 the Registration Reply that registration failed due to an 481 authentication failure. 483 IP fields 485 Source Address The IP address of the Home Agent 486 interface from which the reply is issued. 488 Destination Address Copied from the Source Address of the 489 Challenge Reply. 491 UDP fields: 493 Source Port variable 495 Destination Port Copied from the Source Port of the 496 Challenge Reply. 498 The UDP header is followed by the ATMP fields shown below: 500 0 1 2 3 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Version | Type | Identifier | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Result Code | Tunnel ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Version The ATMP protocol version. MUST be 1. 510 Type 4 for Registration Reply 511 Identifier Copied from the corresponding 512 Registration Request. 514 Result Code Specifies the result of the registration 515 and authentication attempt by the Foreign 516 Agent. Sec. 2.8 for a list of Result 517 Code values and their meanings. 519 Tunnel ID This is the identifier used to indicate a 520 given mobility binding between a given 521 Mobile Node and Home Agent. This 522 identifier is used to distinguish 523 multiple tunnels between a given Foreign 524 Agent-Home Agent pair. It is carried in 525 the "key" field of the GRE [1] tunnel 526 packets that ATMP uses as the tunnel 527 protocol. It is also used in 528 Deregistration Requests and Error 529 Notification messages to indicate the 530 particular mobility binding to which they 531 relate. 533 2.5 Deregistration Request 535 The Deregistration Request is issued by the Foreign Agent to the Home 536 Agent to indicate that the specified mobility binding is to be ended. 537 This request may result from the Foreign Agent detecting that its 538 connection to the Mobile Node has terminated. It can also be issued 539 in response to a detected error condition by the Foreign Agent or 540 receipt of an Error Notification message from the Home Agent. 542 IP fields 544 Source Address The IP address of the Foreign Agent 545 interface from which the request is 546 issued. 548 Destination Address 5150 (or port number configured in FA 549 for given HA) 551 UDP fields: 553 Source Port variable 555 Destination Port Copied from the Source Port of the 556 Challenge Reply. 558 The UDP header is followed by the ATMP fields shown below: 560 0 1 2 3 561 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Version | Type | Identifier | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Tunnel ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Version The ATMP protocol version. MUST be 1. 570 Type 5 for Deregistration Request 572 Identifier A 16 bit number used to match replies 573 with requests. A new value should be 574 provided in each new request. 575 Retransmissions of the same request 576 should use the same identifier. 578 Tunnel ID Tunnel identifier of the mobility binding 579 to be terminated. 581 2.6 Deregistration Reply 583 The Deregistration Reply is issued by the Home Agent in response to a 584 Deregistration Request received from a Foreign Agent. If the 585 Deregistration Request was valid, the Home Agent removes the 586 specified mobility binding from its tables and issues an affirmative 587 reply. Otherwise the Home Agent issues a Deregistration Reply with a 588 Result Code indicating the reason for failure of the Deregistration 589 Request. 591 IP fields 593 Source Address The IP address of the Home Agent 594 interface from which the reply is issued. 596 Destination Address Copied from the Source Address of the 597 received Deregistration Request. 599 UDP fields: 601 Source Port variable 603 Destination Port Copied from the Source Port of the 604 received Deregistration Request. 606 The UDP header is followed by the ATMP fields shown below: 608 0 1 2 3 609 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Version | Type | Identifier | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Result Code | Tunnel ID | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Version The ATMP protocol version. MUST be 1. 618 Type 6 for Deregistration Reply 620 Identifier Copied from the corresponding 621 Deregistration Request. 623 Result Code Specifies the result of the registration 624 and authentication attempt by the Foreign 625 Agent. Sec. 2.8 for a list of Result 626 Code values and their meanings. 628 Tunnel ID Tunnel identifier of the mobility binding 629 specified in the Deregistration Request. 631 2.7 Error Notification 633 This message is sent by either agent to inform the other agent that 634 an error condition has occurred. It provides a last-ditch error 635 recovery mechanism that is used for conditions that cannot be 636 reported back to the sender by the normal request-reply mechanism, 637 such as the receipt of a spontaneously generated reply. 639 IP fields 641 Source Address The IP address of the issuing agent 642 interface from which this message is 643 issued. 645 Destination Address The IP address of the Home Agent or 646 Foreign Agent to which this message is to 647 be issued. 649 UDP fields: 651 Source Port variable 653 Destination Port If issued to a Home Agent, 5150 (or the 654 port number configured for the given HA). 655 If issued to a Foreign Agent, the source 656 port number saved from the original 657 Registration Request. 659 The UDP header is followed by the ATMP fields shown below: 661 0 1 2 3 662 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Version | Type | Identifier | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Result Code | Tunnel ID | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 Version The ATMP protocol version. MUST be 1. 671 Type 7 for Error Notification 673 Identifier If issued in response to a received reply 674 type message, this value should be copied 675 from the identifier field of the reply. 677 Otherwise the identifier should be the 678 value that would be used for the next 679 generated request. 681 Result Code This indicates the type of error 682 detected. The possible result codes are 683 defined in Sec. 2.8. 685 Tunnel ID Tunnel identifier of the mobility binding 686 to which this message pertains. If the 687 Error Notification is being sent in 688 response to an unsolicited reply, the 689 Tunnel ID is copied from the reply. 691 2.8 Result Codes 693 Error Code Description 695 0 NO_ERROR Successful operation 697 1 AUTH_FAILED Authentication of the Foreign Agent failed. 698 Registration denied. 700 2 NOT_ENABLED The Home Agent is not configured to run ATMP. 702 3 TOO_MANY Too many Mobile Node sessions. Home Agent is out 703 of resources. 705 4 PARAMETER_ERROR An invalid value was detected in an ATMP message. 707 5 INVALID_TUNNEL_ID The Tunnel ID contained in a GRE packet is 708 invalid or the corresponding mobility binding 709 does not exist. This usually occurs when either 710 the MN or HA has reset. 712 6 TIMEOUT A response to an ATMP request was not received in 713 time. 715 7 NET_UNREACHABLE The Home Network for this mobility binding is not 716 operational (the "Connection Profile" is "down" 717 or is not defined). 719 8 GENERAL_ERROR General Error indication. 721 2.9 Protocol Operation 723 Upon detection of a Mobile Node requiring ATMP service, the NAS 724 invokes its ATMP Foreign Agent entity.The FA retrieves configuration 725 information for the user involved.This information is obtained in a 726 method particular to the NAS and is not specified by this document. 727 The information obtained MUST include the Home Agent address and the 728 shared secret for this HA.It also MAY include the Home Network Name, 729 if a Connection Profile is to be used for this session. 731 The FA then sends a Registration Request to the HA informing it that 732 an MN wishes to register with it. The FA then waits for the HA to 733 respond with a Challenge Request. The FA retransmits the 734 Registration Request every 2 seconds until it receives the Challenge 735 Request. If, after 10 retransmissions, no Challenge Request is 736 received, the FA will terminate the Registration Request, logs the 737 registration failure, and disconnects the MN. 739 Upon receipt of the Challenge Request, the FA examines the Result 740 code. If it indicates an error condition, the condition is logged 741 and the MN is disconnected. If the result is zero, the FA generates 742 a Challenge Reply. The Challenge Reply is generated by appending the 743 Authenticator obtained from the Challenge Request with the shared 744 secret (obtained from the configuration data) and then computing the 745 MD5 hash of this concatenated string (authenticator + secret). The 746 16 octet hash is then returned in the Challenge Reply for validation 747 by the HA. 749 Upon receipt of the Challenge Reply from the FA, the HA does the same 750 computation of the MD5 hash based on the Challenge Request 751 Authenticator and the shared-secret (which it too must be configured 752 with). If this digest matches that provided in the Challenge Reply 753 by the FA then the authentication is successful and the registration 754 is accepted. If the authentication fails, or resource limitations 755 prohibit the registration attempt, the HA returns a Registration 756 Reply with a non-zero result code to the FA. 758 If the HA accepts the Challenge Reply from the FA, it assigns a 759 Tunnel ID to this session and returns this Tunnel ID in a 760 Registration Reply with a zero result code. This Tunnel ID needs to 761 be unique for the FA-HA pair. The Tunnel ID is used to multiplex and 762 demultiplex the packets sent between a given FA-HA pair. 764 At the time the HA decides to accept a registration, it creates a 765 control block that associates the Tunnel ID with the appropriate 766 routing information. If the Registration Request included a Home 767 Network Name, this name is saved in the table and used as the name of 768 the Connection Profile for this session. 770 Upon receipt of the Registration Reply, the FA examines the result 771 code. If it is non-zero, the FA logs the registration failure and 772 disconnects the MN. If it is zero, the FA saves the Tunnel ID in a 773 control block associated with the MN session. The FA and HA are now 774 ready to exchange data packets for this MN session. 776 On the FA side, all data received from the MN will be encapsulated 777 using GRE and sent to the HA with the assigned Tunnel ID included in 778 the GRE Key field. When the HA receives a GRE packet it decapsulates 779 it and routes it using the routing information contained in the HA's 780 control block associated with this Tunnel ID. 782 When the HA receives a packet destined for the MN's Home Address, it 783 MUST encapsulate it in a GRE packet and forward it to the appropriate 784 FA. The Tunnel ID is included in the GRE Key field to allow the FA 785 to demultiplex the packet. 787 When the FA receives a GRE packet, it will examine the Tunnel ID in 788 the GRE Key field to see if it matches the Tunnel ID assigned to any 789 of the MN's currently connected to the FA. If so, the packet is 790 decapsulated and forwarded to the MN. If the Tunnel ID doesn't match 791 any active MN's, an Error Notification message is issued to the HA 792 and the GRE packet is silently discarded. 794 When the FA wishes to disconnect the MN from the HA, it issues a 795 Deregistration Request. This request is issued every 2 seconds. If 796 after 10 attempts a Deregistration Reply is not received from the HA, 797 an error condition is logged and the MN is disconnected. Upon 798 receipt of a Deregistration Reply from the HA, the FA deallocates the 799 Tunnel ID and disconnects the MN. 801 3.0 Security Considerations 803 The Registration function of ATMP is protected by a 804 Challenge/Response mechanism similar to CHAP [2]. The Home Agent 805 challenges each registration attempt by a Foreign Agent for 806 authentication.This authentication requires the configuration of a 807 shared secret for each HA/client pair. 809 4.0 Author's Address 811 Kory Hamzeh 812 Ascend Communications 813 1275 Harbor Bay Parkway 814 Alameda, CA 94502 815 Email: kory@ascend.com 817 5.0 References 819 [1] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing 820 Encapsulation (GRE)", RFC 1701, October 1994. 822 [2] Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334, 823 October 1992. 825 [3] Perkins, C. (editor), "IP Mobility Support, "draft-ietf-mobileip- 826 protocol-15.txt, February 1996, Work In Progress. 828 [4] Postel, J. B., "User Data Protocol", RFC 768, August 1990. 830 [5] Rigney, C., Rubens, A., Simpson, W. A., Willens, S., "Remote 831 Authentication Dial In User Service (RADIUS)", draft-ietf-radius- 832 02.txt, February 1996, Work In Progress. 834 [6] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October, 835 1994. 837 [7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 838 1992. 840 [8] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC 1661, 841 July 1994. 843 Appendix A 845 Additional RADIUS Attributes for ATMP 847 This appendix indicates the RADIUS attributes that have been added by 848 Ascend to support ATMP for IP. Currently these are defined as non- 849 vendor-specific attributes but have been included in [5]. 851 Attribute: "Ascend-Home-Agent-IP-Addr" 852 Type: IP-Address 853 Value: The IP address of the Home Agent 855 Attribute: "Ascend-Home-Agent-Password" 856 Type: String 857 Value: Secret shared for this user with HA 859 Attribute: "Ascend-Home-Network-Name" 860 Type: String 861 Value: Name of Connection Profile for this session 863 Attribute: "Ascend-Home-Agent-UDP-Port" 864 Type: Integer 865 Value: The destination UDP port number for the specified HA 867 Appendix B 869 IPX Operation 871 ATMP specifies a mechanism which allows IPX clients to receive 872 mobility services from a HA. Section 2 details the protocol used 873 to register, deregister, and authenticate a tunnel used for IPX. 874 Note that ATMP is based on IP datagrams for the management of 875 tunnels and, thus, IPX tunneling with ATMP always requires an 876 underlying IP network. 878 Each IPX mobile client requires an IPX network number and node 879 address pair. Since IPX does not support a similar facility to 880 IP's "host route," an enterprise-unique network number needs to be 881 chosen for each home agent. This network number MUST be distinct 882 from the IPX network number assigned to any of the home agent's 883 LAN interfaces. Each mobile client tunneled to the home agent MUST 884 use the same IPX network number. 886 For example, consider a home agent which supports two mobile 887 clients. The home agent is on a LAN network with an IPX address 888 of AA000001. The home agent's client network may be assigned 889 AA000002. The two mobile clients may have addresses 890 AA000002:0040F1000001 and AA000002:0040F1000002 respectively. 892 IPX node numbers need to be unique on a given network. A mechanism 893 must exist to guarantee that for each home agent's network, a 894 given mobile client's node address is unique. Several techniques 895 may be employed to assure unique node addresses. The current 896 implementation of ATMP described in this document relies on RADIUS 897 to assign a node address at the foreign agent. The following 898 RADIUS attributes are included for IPX operation in addition to 899 the attributes described in Appendix A for IP operation: 901 Attribute: "Framed-IPX-Network" (See [5] for details). 903 Attribute: "Ascend-IPX-Node-Addr" 904 Type: String 905 String: The node address for the mobile client in 12 octet 906 ASCII representing the hexadecimal string. Both 907 lower and upper case characters are permissible.