idnits 2.17.1 draft-ietf-tuba-mobility-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-03-28) 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-tuba-mobility-00.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-tuba-mobility-00.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-tuba-mobility-00.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-tuba-mobility-00.txt)', but the file name used is 'draft-ietf-tuba-mobility-00' ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 an Authors' Addresses Section. ** 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 129: '...se, the datagram MUST be silently disc...' RFC 2119 keyword, line 130: '... CLNP ER Destination Unreachable MUST...' RFC 2119 keyword, line 185: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 188: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 191: '... SHOULD This word, or the adjecti...' (38 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 56 has weird spacing: '...ing its addre...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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: 'RFC-768' is mentioned on line 401, but not defined == Missing Reference: 'RFC-1305' is mentioned on line 486, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) -- Looks like a reference, but probably isn't: '2' on line 637 == Unused Reference: 'Voydock83' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: 'ISO9542' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'Glenn' is defined on line 1175, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Voydock83' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin89' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO9542' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8473' -- Possible downref: Normative reference to a draft: ref. 'Glenn' Summary: 14 errors (**), 1 flaw (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Rekhter 3 INTERNET-DRAFT (T.J. Watson Research Center, IBM Corp.) 4 Richard Colella (NIST) 6 TUBA Mobility Support 8 (draft-ietf-tuba-mobility-00.txt) 10 (Posted: May 16, 1994/Expires: November 16, 1994) 12 Status of this Memo 14 This document is a submission to the TUBA Working Group of the Inter- 15 net Engineering Task Force (IETF). Comments should be submitted to 16 the tuba@lanl.gov mailing list. 18 Distribution of this memo is unlimited. 20 Internet Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its Areas, and its Working Groups. Note that 22 other groups may also distribute working documents as Internet 23 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 1id-abstracts.txt listing contained in the 32 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 33 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 34 status of any Internet Draft. 36 Abstract 38 This document specifies protocol enhancements that allow transparent 39 routing of CLNP datagrams to Mobile Nodes in the Internet. The 40 Mobile Node is always identified by its Home-Address, regardless of 41 its current point of attachment to the Internet. While situated away 42 from its home, a Mobile Node is also associated with a Care-Of- 43 Address, which provides information about its current point of 44 attachment to the Internet. The protocol provides for registering 45 the Care-Of-Address with the Home Agent. The Home Agent tunnels 46 traffic destined for the Mobile Node to the Care-Of-Address. 48 Acknowledgements 50 This document is taken almost verbatim from the draft-ietf-mobileip- 51 protocol-02.txt Internet Draft. The latter is the product of the 52 mobile-ip WG. 54 1. Introduction 56 If a node moves while keeping its address unchanged, the address may 57 not reflect its new point of attachment. The routing protocols will 58 not be able to route datagrams to it correctly. 60 This document defines new functions that allow a node to roam on the 61 Internet, without changing its network layer address (NSAP). 63 The following entities are defined: 65 Mobile Node 67 A TUBA host or router that changes connections from one network 68 or subnetwork to another. 70 Home Agent 72 A router on a network that advertises reachability for a Mobile 73 Node, maintains a registry of the current Mobility Bindings for 74 that node while it is away from home, and tunnels datagrams for 75 delivery to a Mobile Node. 77 Foreign Agent 79 A router that assists a locally reachable Mobile Node that is 80 away from its home network. 82 The following support services are defined: 84 Agent Discovery 86 Agents advertise their availability on each link. 88 A newly arrived Mobile Node can send a solicitation on the link 89 to learn if any prospective Agents are present. 91 Care-Of-Address Assignment 93 The Care-Of-Address terminates the end of a tunnel toward a 94 Mobile Node. Depending on the foreign network configuration, 95 the Care- Of-Address may be dynamically assigned to the Mobile 96 Node, or associated with a Foreign Agent. 98 Registration 100 When the Mobile Node is away from home, it registers the Care- 101 Of- Address with the Home Agent. 103 Depending on its method of attachment, the Mobile Node will 104 register either directly with a Home Agent, or through a 105 Foreign Agent which forwards the registration to the Home 106 Agent. 108 Encapsulation 110 Once a Mobile Node has registered a Care-Of-Address with a Home 111 Agent, the Home Agent intercepts datagrams destined for the 112 Mobile Node, formulates another datagram with the intercepted 113 datagram enclosed within, and forwards the resulting datagram 114 to the Care- Of-Address. 116 Decapsulation 118 At the Care-Of-Address, the enclosed datagram is extracted. 120 When the Mobile Node has its own Care-Of-Address, it decapsu- 121 lates its own datagrams. 123 When the Care-Of-Address is associated with a Foreign Agent, 124 the Foreign Agent decapsulates the datagrams. If the datagram 125 is addressed to a Mobile Node which the Foreign Agent is 126 currently serving, it will deliver the datagram to the Mobile 127 Node. 129 Otherwise, the datagram MUST be silently discarded (rather than 130 being further forwarded). CLNP ER Destination Unreachable MUST 131 NOT be sent when a Foreign Agent is unable to forward a 132 datagram. 134 1.1. Requirements 136 A Mobile Node using its Home-Address shall be able to communicate 137 with other nodes after having been disconnected from the Internet, 138 and then reconnected at a different point. 140 A Mobile Node shall continue to be capable of communicating directly 141 with existing nodes that do not implement the mobility functions 142 described in this document. 144 A Mobile Node shall provide authentication in its registration mes- 145 sages. 147 1.2. Goals 149 As few administrative messages as possible are sent between a Mobile 150 Node and a Foreign Agent. The link is likely to be bandwidth lim- 151 ited. 153 The size of messages on the Mobile Node's directly attached link are 154 to be kept as short as possible. The link is likely to be bandwidth 155 limited. 157 1.3. Assumptions 159 The protocols defined in this document place no additional require- 160 ments on assignment of addresses (NSAPs). That is, a Mobile Node 161 will be assigned an address (NSAP) by the organization that owns the 162 machine, and will be able to use that address (NSAP) regardless of 163 the current point of attachment. 165 Mobile Nodes are able to change their point of attachment to the 166 Internet as frequently as once per second. 168 No protocol enhancements are required in hosts or routers that are 169 not serving any of the mobility functions. Similarly, no additional 170 protocols are needed by a router (that is not acting as a Home Agent 171 or a Foreign Agent) to route datagrams to or from a Mobile Node. 173 The operation of this specification assumes that CLNP datagrams are 174 routed to a destination without regard to the source of the datagram. 176 If desired, the Mobile Node can tunnel to its Home Agent. The 177 definition of such tunneling mechanisms is outside the scope of this 178 specification. 180 1.4. Specification Language 182 In this document, several words are used to signify the requirements 183 of the specification. These words are often capitalized. 185 MUST This word, or the adjective "required", means that the 186 definition is an absolute requirement of the specification. 188 MUST NOT This phrase means that the definition is an absolute 189 prohibition of the specification. 191 SHOULD This word, or the adjective "recommended", means that there 192 may exist valid reasons in particular circumstances to 193 ignore this item, but the full implications must be 194 understood and carefully weighed before choosing a 195 different course. 197 MAY This word, or the adjective "optional", means that this 198 item is one of an allowed set of alternatives. An 199 implementation which does not include this option MUST be 200 prepared to interoperate with another implementation which 201 does include the option. 203 silently discard 204 The implementation discards the packet without further 205 processing, and without indicating an error to the sender. 206 The implementation SHOULD provide the capability of logging 207 the error, including the contents of the discarded packet, 208 and SHOULD record the event in a statistics counter. 210 1.5. Terminology 212 This document frequently uses the following terms: 214 Authentication Type 215 This includes the algorithm and algorithm mode. Note that a 216 single algorithm (such as DES) might have several modes (for 217 example, CBC and ECB). 219 Correspondent Host 220 The peer with which a Mobile Node is communicating. The 221 Correspondent Host may be either mobile or stationary. 223 Home-Address 224 A long term address (NSAP) that is assigned to a Mobile Node. 225 It remains unchanged regardless of where the node is attached 226 to the Internet. The Home-Address is intercepted by the Home 227 Agent while the Mobile Node is registered with that Home Agent. 229 Link 230 A communication facility or medium over which nodes can commun- 231 icate at the link layer; underlying the network layer. 233 Mobility Binding 234 The association of a Home-Address with a Care-Of-Address, and 235 the remaining LifeTime of the association. 237 Mobility Security Association 238 The security relationship between two nodes that is used with 239 Mobile CLNP protocol messages. This relationship includes the 240 authentication type (including algorithm and algorithm mode), 241 the secret (such as a shared key, or appropriate public/private 242 key pair), and possibly other information such as labelling. 244 Triangle Routing 245 A path followed by a datagram destined for a Mobile Node, when 246 that datagram arrives first at the Home Agent, and then is 247 encapsulated and tunneled by the Home Agent. 249 2. Agent Discovery 251 To communicate with a Foreign or Home Agent, a Mobile Node must learn 252 either the network layer address (NSAP) or the link layer address of 253 that Agent. 255 It is assumed that a link-layer connection has been established 256 between the Agent and the Mobile Node. The method used to establish 257 such a link-layer connection is not specified in this document. 259 After establishing a link-layer connection that supports the attach- 260 ment of Mobile Nodes, the node must learn if there are any prospec- 261 tive Foreign Agents available to serve it while it is away from home. 262 If the Mobile Node is returning home, it must learn if its Home Agent 263 is available. 265 There are often several methods of learning the availability of an 266 Agent. Those described here are recommended. 268 Multi-Point Link-Layers 269 Link establishment protocol, IEEE 802.11, might yield the link 270 address of an agent. This link-layer address is used to 271 attempt registration. 273 ES-IS 275 Configuration information provided by ES-IS protocol allows a 276 Mobile Node to discover the existence and reachability of a 277 Foreign Agent, and permits a Foreign Agent to discover the 278 existence and reachability of a Mobile Node. 280 It is recommended that as few messages as possible which duplicate 281 functionality be sent on mobile links. This is particularly impor- 282 tant on wireless and congested links. 284 When multiple methods are in use, the Mobile Node SHOULD first 285 attempt registration with routers sending ISH packets in preference 286 to those sending link-layer advertisements. This ordering maximizes 287 the likelihood that the registration will be recognized, thereby 288 minimizing the number of registration attempts. 290 An Administrative Domain MAY require registration with a Foreign 291 Agent even when another registration method is in use. This facility 292 is envisioned for service providers with packet filtering fire-walls, 293 or visiting policies (such as accounting) which require exchanges of 294 authorization. 296 2.1. Authentication 298 No authentication is required for the advertisement and solicitation 299 process. 301 These messages MAY be authenticated using a TUBA Authentication 302 mechanism (as described in draft-ietf-inlsp-tuba-00.txt), which is 303 external to the messages described here. Further work on authentica- 304 tion of advertisement and solicitation is outside of the scope of 305 this document. 307 Whenever an externally authenticated message fails authentication, 308 the message is silently discarded. 310 2.2. Agent Solicitation 311 Every Mobile Node is required to implement ES-IS. However, the ESH 312 packet is only sent when no link-layer identification has been 313 received. 315 Any Foreign Agent and Home Agent which is not identified by a link- 316 layer protocol MUST implement ES-IS. 318 2.3. Agent Advertisement 320 Every Mobile Node is required to correctly process ES-IS packets. 322 Any Foreign Agent and Home Agent which is not identified by a link- 323 layer protocol MUST implement ES-IS. 325 An Agent which is identified by a link-layer protocol SHOULD also 326 implement ES-IS. 328 It is assumed that the ISH packet format is extended as to allow an 329 indication of whether a router is willing to act as an Agent. 331 The Mobile Node chooses a Care-Of-Address from among advertising 332 Agents in the same fashion as it would choose a first hop router. 334 3. Registration 336 The registration function exchanges information between Mobile Nodes 337 and Home Agents. This function creates a Mobility Binding, linking 338 the Home-Address with the Care-Of-Address currently used by the 339 Mobile Node. 341 When assigned a transient Care-Of-Address, a Mobile Node can act 342 without a Foreign Agent. When registering or deregistering directly 343 with the Home Agent, the registration process involves the exchange 344 of only 2 messages. 346 a) The Mobile Node sends a Registration Request to the Home Agent, 347 to ask the Home Agent to provide the requested service. 349 b) The Home Agent sends a Registration Reply to the Mobile Node to 350 grant or deny service. 352 An Administrative Domain MAY require registration through a Foreign 353 Agent, as indicated in Agent Advertisements. 355 When the Care-Of-Address is associated with a Foreign Agent, the 356 Foreign Agent acts as a relay between the Mobile Node and Home Agent. 357 The extended registration process involves the exchange of 4 mes- 358 sages: 360 a) The Mobile Node sends a Registration Request to the prospective 361 Foreign Agent to begin the registration process. 363 b) The Foreign Agent relays the request by sending a Registration 364 Request to the Home Agent, to ask the Home Agent to provide the 365 requested service. 367 c) The Home Agent sends a Registration Reply to the Foreign Agent 368 to grant or deny service. 370 d) The Foreign Agent sends a copy of the Registration Reply to the 371 Mobile Node to inform it of the disposition of its request. 373 3.1. Authentication 375 Each Mobile Node, Foreign Agent, and Home Agent MUST support an 376 internal table holding a list of NSAP addresses, and the Mobility 377 Security Association for each address. 379 Mobile Node to Home Agent registration messages are required to be 380 authenticated with the Mobile-Home Authentication Extension. The 381 Mobile Node and Home Agent MUST support authentication using keyed 382 MD5 and key sizes of 128 bits or greater, with manual key distribu- 383 tion. Additional authentication algorithms, algorithm modes, and key 384 distribution methods MAY also be supported. 386 In addition, the Foreign Agent SHOULD support authentication using 387 keyed MD5 and key sizes of 128 bits or greater, with manual key dis- 388 tribution. Additional authentication algorithms, algorithm modes, 389 and key distribution methods MAY also be supported. 391 Only one Mobility Security Association exists between any given pair 392 of participating nodes at any given time. 394 Whenever a Mobility Security Association exists between a pair of 395 nodes, all registration messages between these nodes MUST be authen- 396 ticated, using the appropriate authentication extension. 398 3.2. UDP 400 The Registration messages defined herein use the User Datagram Proto- 401 col header [RFC-768]. The UDP well-known port is used. 403 The UDP checksum is required. Any mobility message with an incorrect 404 or zero UDP checksum is silently discarded. 406 3.3. Registration Request 408 The UDP Header is followed by the fields shown below: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Code | LifeTime | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |HAg Addr Len | Home Agent Address (variable)... | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | .... | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |HA Addr Len | Home Address (variable)... | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | .... | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |CO Addr Len | Care-Of-Address (variable)... | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | .... | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 + TimeStamp + 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |Extensions ... 432 +-+-+-+-+-+-+-+- 434 CLNP fields: 436 Source The Home-Address of the Mobile Node. 438 Destination The NSAP address of the Agent, when known. When 439 the NSAP address is unknown (i.e., the agent was 440 discovered via a link-layer protocol), the "all 441 Mobile Agents" multicast address. The link-layer 442 unicast address is used to deliver the datagram 443 to the correct Agent. 445 UDP fields: 447 Source Port variable 449 Destination Port 451 MobileTUBA fields: 453 Type 455 1 when sent by the Mobile Node 456 2 when sent by the Foreign Agent 458 Code Optional capabilities: 460 0 - remove prior registrations 461 1 - retain prior registrations 463 LifeTime The seconds remaining before the registration is 464 considered expired. A value of zero indicates a 465 request for de-registration. A value of all ones 466 indicates infinity. 468 The LifeTime SHOULD NOT be set to greater than the 469 LifeTime learned in an Agent Advertisement. 471 HAg Addr Len The length of the Home Agent Address (in octets) 473 Home Agent The NSAP address of the Home Agent. 475 HA Addr Len The length of the Home NSAP address of the Mobile 476 Node (in octets) 478 Home-Address The Home NSAP address of the Mobile Node. 480 CO Addr Len The length of the Care-Of-Address (in octets) 482 Care-Of-Address The NSAP address for the decapsulation end of a 483 tunnel. 485 TimeStamp 64 bits. A sequence number assigned by the Mobile 486 Node. A Network Time Protocol [RFC-1305] value is 487 preferred, but the elapsed time since system 488 startup, or any other monotonically increasing 489 counter MAY be used. The value MUST NOT be the same 490 as an immediately preceeding request. 492 The Mobile-Home Authentication Extension is required, and immediately 493 follows all non-authentication extensions. 495 Authenticator A hash value taken over a stream of bytes consisting 496 of the shared secret between the Mobile Node and 497 Home Agent, followed by (concatenated with) the 498 fields in the message beginning with the Code field, 499 including all prior extensions, and the Type and 500 Length of this extension, but not including the 501 Authenticator field itself, and finally the shared 502 secret again. 504 The Mobile-Foreign or Foreign-Home Authentication Extension is 505 optional, and immediately follows the Mobile-Home Authentication 506 Extension. 508 When forwarded by a Foreign Agent, fields and extensions are copied 509 from the Registration Request without modification. 511 3.4. Registration Reply 513 The UDP Header is followed by the fields shown below: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type | Code | LifeTime | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |HA Addr Len | Home-Address (variable)... | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | .... | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 + TimeStamp + 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |Extensions ... 529 +-+-+-+-+-+-+-+- 531 CLNP fields: 533 The Source and Destination of the Request message are swapped for the 534 Reply message. 536 Note that the Source of the original Registration Request must be 537 saved in order for the Foreign Agent to return the reply to the 538 correct Mobile Node. 540 UDP fields: 542 The Source Port and Destination Port of the Request message are 543 swapped for the Reply message. 545 Note that the Source Port of the original Registration Request must 546 be saved in order for the Foreign Agent to return the reply to the 547 correct Mobile Node port. 549 MobileTUBA fields: 551 Type 3 553 Code One of the following codes: 555 0 service will be provided. 557 denied by Foreign Agent, 558 16 reason unspecified. 559 17 administratively prohibited. 560 18 insufficient resources. 561 19 Mobile Node failed authentication. 562 20 Home Agent failed authentication. 563 21 Request LifeTime too long. 565 denied by Home Agent, 566 32 reason unspecified. 567 33 administratively prohibited. 568 34 insufficient resources. 569 35 Mobile Node failed authentication. 570 36 Foreign Agent failed authentication. 572 Up-to-date values of the Code field are specified in 573 the most recent "Assigned Numbers" RFC [2]. 575 LifeTime The seconds remaining before the registration is 576 considered expired. A value of zero confirms a 577 request for de-registration. A value of all ones 578 indicates infinity. 580 May be modified by the Home Agent. 582 HA Addr Len Copied from the Request message. 584 Home-Address Copied from the Request message. 586 TimeStamp Copied from the Request message. 588 The Mobile-Home Authentication Extension is required, and immediately 589 follows all non-authentication extensions. 591 Authenticator A hash value taken over a stream of bytes consisting 592 of the shared secret between the Mobile Node and 593 Home Agent, followed by (concatenated with) all of 594 the fields in the message beginning with the Code 595 field, including all prior extensions, and the Type 596 and Length of this extension, but not including the 597 Authenticator field itself, and finally the shared 598 secret again. 600 Note that the Care-Of-Address and Home Agent are not 601 present in the message. This provides a separate 602 calculation value for mutual authentication from the 603 Home Agent to the Mobile Node. 605 The Mobile-Foreign or Foreign-Home Authentication Extension is 606 optional, and immediately follows the Mobile-Home Authentication 607 Extension. 609 When forwarded by a Foreign Agent, fields and extensions are copied 610 from the Registration Reply without modification. 612 4. Mobility Message Extensions 614 To promote extensibility, each message begins with a short fixed 615 part, which is followed by one or more extensions in Type-Length- 616 Value format. 618 Extensions allow variable amounts of information to be carried within 619 each datagram. The end of the list of Extensions is indicated by the 620 Total Length of the CLNP datagram. 622 0 1 2 623 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 625 | Extension | Length | Data ... 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 628 Extension Current values are assigned as follows: 630 16 Mobility 631 32 Mobile-Home Authentication 632 33 Mobile-Foreign Authentication 633 34 Foreign-Home Authentication 634 65 GRE Encapsulation 636 Up-to-date values are specified in the most recent 637 "Assigned Numbers" RFC [2]. 639 Length Indicates the length of the Data field. The Length 640 does not include the Extension and Length bytes. 642 Data This field is zero or more bytes and contains the 643 value(s) for this Extension. The format and length 644 of the Data field is determined by the Extension 645 and Length fields. 647 When an extension is encountered which is not recognized, it is 648 ignored. The length field is used to skip the data field in search- 649 ing for the next extension. 651 4.1. Mobility Extension 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Extension | Length | Sequence Number | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |R| Reserved | 659 +-+-+-+-+-+-+-+-+ 661 Extension 16 663 Length 3 665 Sequence Number Contains the number of advertisement messages sent 666 since the node was initialized. This number MUST 667 include this advertisement. 669 When this value decreases, the Mobile Node MUST 670 assume that any current registration has been lost. 671 This field cannot roll over in less than 2**16 672 seconds, and rollover is unambiguously indicated by 673 the value zero. 675 R Registration required bit. When this bit is set to 676 1, registration with the Foreign Agent is required, 677 even when the Mobile Node has acquired a transient 678 Care-Of-Address. 680 Reserved Sent as zero; ignored on reception. 682 4.2. Authentication Extensions 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Extension | Length | Authenticator 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Extension 692 32 Mobile-Home 693 33 Mobile-Foreign 694 34 Foreign-Home 696 Length The number of data bytes in the Extension (16 when 697 MD5 is used). 699 Authenticator Variable length (128 bits for MD5). 701 For Mobile-Home authentication, the value differs 702 depending on the direction the message is sent. 703 These calculations are defined in the Registration 704 Request and Reply messages. 706 For Mobile-Foreign and Foreign-Home authentication, 707 a hash value taken over a stream of bytes 708 consisting of the shared secret, followed by 709 (concatenated with) the Source, the Destination, 710 the remaining fields in the message beginning with 711 the UDP header, including all prior extensions, and 712 the Type and Length of this extension, but not 713 including the Authenticator field itself, and 714 finally the shared secret again. 716 5. Forwarding Datagrams to the Mobile Node 718 5.1. CLNP in CLNP Encapsulation 720 Support for CLNP in CLNP encapsulated tunneling is required. 722 The format of the CLNP header is as described in [ISO8473]. The 723 outer CLNP header Source and Destination addresses identify the "end- 724 points" of the tunnel. The inner CLNP header Source and Destination 725 addresses identify the sender and recipient of the datagram. 727 The Destination field in the CLNP header is replaced by the Care-Of- 728 Address of the Mobile Node. 730 If the encapsulating agent is not the original source of the 731 datagram, the Source field in the CLNP header is replaced by the CLNP 732 address of the encapsulating agent. 734 When the Home Agent encapsulates the datagram, it sets the CLNP Life- 735 time (CLNP TTL) field to be the same as the original datagram. 737 When decapsulating, the outer CLNP TTL minus one is inserted into the 738 inner CLNP TTL. Thus, CLNP hops are counted, but the actual routers 739 interior to the tunnel are not identified. 741 5.2. Tunneling Management 743 It is possible that one of the routers along the tunnel interior 744 might encounter an error while processing the datagram, causing it to 745 return a CLNP ER message to the source end of the tunnel. The three 746 types of CLNP errors that can occur in this circumstance are: 748 - Segmentation needed but not permitted. 749 - Lifetime expired. 750 - Destination address unreachable. 752 Unfortunately, CLNP ER only requires routers to return the CLNP 753 header of the datagram. This is not enough to include the encapsu- 754 lated header, so it is not generally possible for the Home Agent to 755 immediately reflect the CLNP ER message from the interior of a tunnel 756 back to the source host. 758 However, by carefully maintaining "soft state" about its tunnels, a 759 Home Agent can return accurate CLNP ER messages in most cases. The 760 Home Agent SHOULD maintain at least the following soft state informa- 761 tion about each tunnel: 763 - MTU of the tunnel. 764 - TTL (path length) of the tunnel 765 - Reachability of the end of the tunnel. 767 The Home Agent uses the CLNP ER messages it receives from the inte- 768 rior of a tunnel to update the soft state information for that tun- 769 nel. When subsequent datagrams arrive that would transit the tunnel, 770 the router checks the soft state for the tunnel. If the datagram 771 would violate the state of the tunnel (such as, the TTL is less than 772 the tunnel TTL) the Home Agent sends a CLNP ER message back to the 773 source, but also forwards the datagram into the tunnel. 775 Using this technique, the CLNP ER messages sent by Home Agents will 776 not always match up one-to-one with errors encountered within the 777 tunnel, but they will accurately reflect the state of the network. 779 6. Mobile Node Considerations 781 A Mobile Node listens for ISH messages at all times that it has a 782 link connection. In this manner, it can learn that its Foreign Agent 783 has changed, or that it has arrived home. 785 Whenever a Mobile Node changes its point of attachment to the Inter- 786 net, it must initiate the registration process. If it is away from 787 home, it must register with a Foreign Agent. If it is returning 788 home, it must deregister with its Home Agent. 790 A Mobile Node will operate without the support of mobility functions 791 when it is at home. 793 6.1. Configuration and Registration Tables 795 Each Mobile Node will need: 797 - Home-Address 799 - one or more Home Agents 801 For each pending registration: 803 - Media Address of Agent 804 - Care-Of-Address 806 - TimeStamp used 808 - LifeTime 810 For each Mobility Security Association: 812 - Authentication Type 814 - Authentication Key 816 6.2. Registration When Away From Home 818 A Mobile Node SHOULD re-register with its Foreign Agent(s) before the 819 LifeTime of its registration expires. The Mobile Node MAY re- regis- 820 ter with its Foreign Agent(s) at any time. A Mobile Node can ask the 821 Home Agent to terminate forwarding service through a particular 822 Care-Of-Address, by sending a registration with a LifeTime of zero. 824 6.3. Registration without a Foreign Agent 826 In cases where a Mobile Node away from home is able to dynamically 827 acquire a transient CLNP address, the Mobile Node can serve without a 828 Foreign Agent, using the transient address as the Care-Of-Address. 829 Thus, the registration function and the tunnel decapsulation function 830 can be co-located in a single node. This eliminates the need to 831 deploy separate entities as Foreign Agents. 833 The direct registration process involves the exchange of only two 834 messages: 836 a) The Mobile Node sends a Registration Request to the Home Agent, 837 to ask the Home Agent to provide the requested service. 839 b) The Home Agent sends a Registration Reply to the Mobile Node to 840 grant or deny service. 842 All communication between the Mobile Node and its Home Agent is 843 direct, and there is no need to use the Agent Solicitation, Agent 844 Advertisement, and Registration Request. 846 It is assumed that such a Mobile Node has mechanisms to detect 847 changes in its link-layer connectivity, and to initiate acquisition 848 of a new transient address each time such a change occurs. The 849 mechanisms will be specific to the particular link-layer technology, 850 and are outside the scope of this document. 852 6.4. De-registration When At Home 854 At times, a Mobile Node will attach itself to its home link. Since a 855 Mobile Node that is at home needs no forwarding, a de-registration 856 procedure MAY be used between the Mobile Node and its Home Agent. 858 The de-registration process involves the exchange of only two mes- 859 sages: 861 a) The Mobile Node sends a Registration Request directly to its 862 Home Agent, with the LifeTime set to zero, and the Code field 863 set to 0, to indicate that the Home Agent remove all related 864 entries. 866 b) The Home Agent sends a Registration Reply to the Mobile Node to 867 grant or deny service. 869 In this special case, for Authenticator calculation, the Care-Of- 870 Address is set to the Home-Address. 872 This procedure is specified for the sake of convenience. The Mobile 873 Node is not required to register with its Home Agent. It MAY de- 874 register with each Foreign Agent, or it MAY allow its Mobility Bind- 875 ings to simply expire. 877 It is not necessary to re-register with a Home Agent when a change of 878 Incarnation Number occurs, or the Advertisement LifeTime expires, 879 since the Mobile Node is not seeking tunneling service. 881 6.5. Registration Replies 883 When a Mobile Node receives a Registration Reply which has a TimeS- 884 tamp which is not the same as the TimeStamp of its most recent Regis- 885 tration Request to the putative sender, the message is silently dis- 886 carded. 888 When a Reply is received which has a Code indicating information from 889 the Foreign Agent, the Mobile-Home Authenticator will be missing or 890 invalid. However, if no other reply has as yet been received, the 891 reason for denial SHOULD be accepted, and result in an appropriate 892 action. If a later authenticated reply is received, that reply 893 supercedes the unauthenticated reply. 895 When a Reply is received which has a Code indicating that authentica- 896 tion failed with the Home Agent, the reason for denial SHOULD result 897 in an appropriate action. 899 Otherwise, when a Reply is received with an invalid Authenticator, 900 the message is silently discarded. 902 When the LifeTime of the reply is greater than the original request, 903 the excess time SHOULD be ignored. When the LifeTime of the reply is 904 smaller than the original request, re-registration SHOULD occur 905 before the LifeTime expires. 907 The Mobile Node is not required to issue any message in reply to a 908 Registration Reply. 910 6.6. Simultaneous Registrations 912 Under normal circumstances, sending a new Registration Request 913 removes other unexpired registrations for a Mobile Node from the Home 914 Agent. 916 An optional capability is to allow multiple simultaneous registra- 917 tions. For example, this is particularly useful when a Mobile Node 918 is on a border between multiple cellular systems. 920 In order to request simultaneous registrations, the Mobile Node sends 921 the Registration Request with a Code set to 1. 923 The return Code in the Registration Reply is the same. No error 924 occurs if the Home Agent is unable to fulfill the request. 926 IP explicitly allows duplication of datagrams. When the Home Agent 927 is able to fulfill the request, the Home Agent will encapsulate a 928 copy of each arriving datagram to each Care-Of-Address, and the 929 Mobile Node will receive multiple copies of its datagrams. 931 7. Foreign Agent Considerations 933 It is the intent that Foreign Agent involvement be as minimal as pos- 934 sible. The role of the Foreign Agent is passive, passing registra- 935 tion requests to the Home Agent, and decapsulating tunneled datagrams 936 to pass to the Mobile Node. 938 When no Mobility Security Association exists, this also reduces the 939 risks resulting from absence of authentication from Foreign Agent 940 messages. 942 The Foreign Agent MUST NOT originate a Request or Reply that has not 943 been prompted by the Mobile Node. No Request or Reply is generated 944 to indicate that the service LifeTime has expired. 946 A Foreign Agent MUST NOT originate a message which revokes the regis- 947 tration of a different Foreign Agent. A Foreign Agent SHOULD forward 948 such revocations without modification when such revocation messages 949 originated from an appropriate Mobile Node or Home Agent. 951 7.1. Configuration and Registration Tables 953 Each Foreign Agent will need: 955 - Care-Of-Address 957 For each pending or current registration, the Foreign Agent will need 958 a Visitor List: 960 - Media Address (aka SNPA) of Mobile 962 - Home-Address 964 - Home Agent 966 - LifeTime 968 A Foreign Agent that has implemented and is using authentication will 969 also need to have the Mobility Security Association information for 970 each pending or current authenticated registration. Even if a 971 Foreign Agent implements authentication, it might not use authentica- 972 tion with each registration, because of the key management difficul- 973 ties. 975 7.2. Receiving Registration Requests 977 Upon receipt of a Registration Request, the Foreign Agent may: 979 - immediately deny service to the Mobile Node, by sending a 980 Registration Reply with the appropriate Code set. 982 - request permission from the Home Agent to provide service to 983 the Mobile Node, by sending a Registration Request. 985 If the Foreign Agent is unable to satisfy the request for some rea- 986 son, such as the Mobile Node proposes a Lifetime longer than the 987 Foreign Agent has advertised, then the Foreign Agent sends a Regis- 988 tration Reply with an appropriate Code, and does not forward the 989 request to the Home Agent. 991 The Foreign Agent must maintain a list of pending Requests, which 992 includes the Source NSAP Address and UDP Source Port, in order that 993 the Reply can be returned to the Mobile Node. 995 7.3. Receiving Registration Replies 997 A Registration Reply which does not relate to a pending Registration 998 Request, or to a currently registered Mobile Node, is silently dis- 999 carded. 1001 If the Registration Reply granted permission to provide service to 1002 the Mobile Node, then the Foreign Agent updates its Visitor List 1003 accordingly. 1005 8. Home Agent Considerations 1007 It is the intent that the Home Agent have primary responsibility for 1008 processing and coordinating services. 1010 The Home Agent for a given Mobile Node SHOULD be located on the link 1011 identified by the Home-Address. This link MAY be virtual. 1013 8.1. Configuration and Registration Tables 1015 Each Home Agent will need: 1017 - an NSAP Address 1019 For each authorized Mobile Node, the Home Agent will need: 1021 - Home-Address assigned to that Node 1023 For each registered Mobile Node, the Home Agent will need a Forward- 1024 ing List: 1026 - Home-Address 1028 - Care-Of-Address 1030 - LifeTime 1032 For each Mobility Security Association: 1034 - Authentication Type 1036 - Authentication Key 1038 8.2. Receiving Requests from the Foreign Agent 1040 Upon receipt of a Registration Request from the Foreign Agent, the 1041 Home Agent grants or denies the service requested by sending a Regis- 1042 tration Reply to the sender of the request, with the appropriate Code 1043 set. 1045 When a Registration Request has an invalid Authenticator for the 1046 Mobile Node, a Reply is sent to the Foreign Agent, in order that the 1047 Foreign Agent can clear its pending request list. 1049 If permission is granted for the Foreign Agent to provide service to 1050 the Mobile Node, the Home Agent will update its Forwarding List with 1051 the Home-Address of the Mobile Node, and the Care-Of-Address of the 1052 tunnel. 1054 The Home Agent MAY shorten the LifeTime of the request. 1056 If the Request asks for termination of service by indicating a Life- 1057 Time of zero, the Home Agent removes the Mobility Binding for that 1058 Care-Of-Address from its Forwarding List. 1060 8.3. Receiving Requests from the Mobile Node 1062 Upon receipt of a Registration Request from the Mobile Node, the Home 1063 Agent grants or denies the service requested by sending a Registra- 1064 tion Reply to the sender of the request, with the appropriate Code 1065 set. 1067 In this special case, for Authenticator calculation, the Care-Of- 1068 Address is a copy of the Home-Address. 1070 The Home Agent MAY shorten the LifeTime of the request. 1072 If the Request asks for termination of service by indicating a Life- 1073 Time of zero, and the Code field set to 0, the Home Agent removes the 1074 Mobility Bindings for all Foreign Agents associated with that Mobile 1075 Node from its Forwarding List. 1077 No special Reply is sent to associated Foreign Agents. The entries 1078 in their Visiting Lists are allowed to expire naturally. 1080 8.4. Simultaneous Registrations 1082 When a Home Agent supports the optional capability of multiple simul- 1083 taneous registrations, any datagrams forwarded are simply duplicated, 1084 and a copy is sent to each Care-Of-Address. 1086 The return Code in the Registration Reply is the same. No error 1087 occurs if the Home Agent is unable to fulfill the request, and ear- 1088 lier entries in the Forwarding List are removed. 1090 8.5. Registration Expiration 1092 If the LifeTime for a given Mobile Node expires before the Home Agent 1093 has received a re-registration request, then the associated Mobility 1094 Binding is erased from the Forwarding List. 1096 No special Registration Reply is sent to the Foreign Agents. The 1097 entries in the Visiting Lists will expire naturally, and probably at 1098 the same time. 1100 Appendix A. TCP Timers 1102 Most hosts and routers which implement TCP/IP do not permit easy con- 1103 figuration of the TCP Timer values. When high-delay (e.g. SATCOM) or 1104 low-bandwidth (e.g. High-Frequency Radio) links are in use, the 1105 default TCP Timer values in many systems will cause retransmissions 1106 or timeouts when the link and network is actually operating properly, 1107 though with greater than usual delays because of the media in use. 1108 This can cause an inability to create or maintain connections over 1109 such links, and can also cause unneeded retransmissions which consume 1110 already scarce bandwidth. Vendors are encouraged to make TCP Timers 1111 more configurable. Vendors of systems designed for the mobile com- 1112 puting markets should pick default timer values more suited to low- 1113 bandwidth, high-delay links. Users of Mobile Nodes should be sensi- 1114 tive to the possibility of timer-related difficulties. 1116 Security Considerations 1118 The mobile computing environment is potentially very different from 1119 the ordinary computing environment. In many cases, mobile computers 1120 will be connected to the network via wireless links. Such links are 1121 particularly vulnerable to passive eavesdropping, active replay 1122 attacks, and other active attacks. 1124 The registration protocol described here will result in a host's 1125 traffic being source routed to its mobile location. Such traffic 1126 redirection could be a significant vulnerability when the registra- 1127 tion were not authentic. Also, source routing is widely understood 1128 to be a security problem in the current Internet. [Bellovin89]. 1130 This specification includes a strong authentication mechanism (keyed 1131 MD5) which precludes many potential attacks based on the Mobile TUBA 1132 registration protocol. However, because key distribution is diffi- 1133 cult in the absence of a network key management protocol, not all 1134 messages with the Foreign Agent are authenticated. Vulnerabilities 1135 remain in the registration protocol whenever a registration message 1136 is not authenticated. For example, in a commercial environment it 1137 might be important to authenticate all messages between the Foreign 1138 Agent and the Home Agent, so that billing is possible, and service 1139 providers don't provide service to users that are not legitimate cus- 1140 tomers of that service provider. 1142 The strength of any authentication mechanism is dependent on several 1143 factors, including the innate strength of the authentication algo- 1144 rithm, the secrecy of the key used, the strength of the key used, and 1145 the quality of the particular implementation. This specification 1146 requires implementation of keyed MD5 for authentication, but does not 1147 preclude the use of other authentication algorithms and modes. For 1148 keyed MD5 authentication to be useful, the 128-bit key must be both 1149 secret (that is, known only to authorised parties) and pseudo-random. 1150 RFC-XXXX provides more information on generating pseudo-random 1151 numbers. 1153 Users who have sensitive data that they do not wish others to see 1154 should use mechanisms outside the scope of this specification (such 1155 as encryption) to provide appropriate protection. Users concerned 1156 about traffic analysis should consider appropriate use of link 1157 encryption. 1159 References 1161 [Voydock83] "V.L. Voydock & S.T. Kent, "Security Mechanisms in High- 1162 level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983." 1164 [Bellovin89] Steven M. Bellovin, "Security Problems in the TCP/IP 1165 Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, 1166 March 1989." 1168 [ISO9542] ISO9542 "End System to Intermediate System Routeing 1169 Exchange protocol for use in conjuction with the Protocol for provid- 1170 ing the connectionless-mode network service (ISO8473)" 1172 [ISO8473] ISO8473 "Protocol for providing the connectionless-mode 1173 network service" 1175 [Glenn] Glenn, K., R., "Intergrated Network Layer Security Protocol 1176 for TUBA", draft-ietf-tuba-inlsp-00.txt (work in progress)