idnits 2.17.1 draft-glass-mobileip-reg-revok-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** 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. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 109: '... or foreign agent MAY stop servicing a...' RFC 2119 keyword, line 130: '...traffic, MAY implement the tunnel endp...' RFC 2119 keyword, line 154: '...[1] understands the FA has lost their binding, and MUST reregister if...' RFC 2119 keyword, line 168: '... this time, the mobile node SHOULD use...' RFC 2119 keyword, line 171: '...agent MAY again unicast its agent adve...' (56 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If a foreign agent revoks a particular mobile node's binding(s) with it, the home agent MAY or MAY NOT revok any of the mobile node's other bindings (with other foreign agents). If a home agent is revoking one of a mobile node's bindings, it MAY revoke none, or all of the mobile node's other bindings as it sees fit. If a home agent decides to revok a single binding for a mobile node, the foreign agent MAY decide to revok other bindings for the same mobile node as it sees fit. -- 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 (14 July 2000) is 8685 days in the past. Is this intentional? 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 section? '1' on line 629 looks like a reference -- Missing reference section? '2' on line 632 looks like a reference -- Missing reference section? '3' on line 635 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Glass 2 INTERNET DRAFT Sun Microsystems 3 Individual Submission 14 July 2000 5 Registration Revocation for Mobile IP 6 draft-glass-mobileip-reg-revok-00.txt 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 This document is a submission to the Mobile IP Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Abstract 36 During the original design of Mobile IP, the potential need for an 37 administrative domain to be able to actively revoke a current Mobile 38 IP registration was recognized. Due to the lack of a specific 39 scenario requiring such a mechanism, it was decided that a passive 40 mechanism, namely short registration lifetimes, and the denial of a 41 subsequent registration from a MN, would be sufficient for this 42 purpose. 44 Recent investigations into requirements for a AAA protocol has 45 forced a reconsideration of a more active Mobile IP registration 46 revocation feature to not only terminate a MN's current registraion, 47 but to provide a way to inform the other end of the tunnel when all 48 future registrations are revoked, and to also at least inform a MN 49 that it's current registration has been revoked. In some cases the 50 current registration may be terminated to simply force the MN to 51 renegotiate its registration, and in other cases the registration is 52 terminated absolutely with no renegotiation allowed by the terminating 53 side. What is obvious from this is revocation is be possible from 54 either home or foriegn agents, so any registration revocation being 55 defined must also allow signaling to the agent at the other end of the 56 tunnel that the current registration has been revoked. 58 This document defines a general use registration revocation 59 mechanism to meet these requirements. 61 1. Introduction 63 During the original design of Mobile IP, the potential was 64 recognized for one administrative domain to cancel a current mobile 65 node registration. Due to the lack of specific need for such a 66 mechanism, it was decided that a passive mechanism, namely the denial 67 of a subsequent registration from a MN, could be used for this 68 purpose. Recently, investigating requirements for a AAA protocol has 69 forced reconsideration of a more active mobile IP feature to not only 70 cancel a MN's current registraion, and to also allow a MN to be 71 informed that it's current registration has been revoked. 73 A general registration revocation mechanism is defined to handle 74 these situations. The protocol is broken into two disjoint pieces. 75 First, a mechanism to inform the mobile node of the revocation of it's 76 current binding is described using a mechanism which already exists in 77 the base protocol [1]. This means any mobile node which complies with 78 [1] will understand it's registration has been revoked. Next, a 79 signaling mechanism between home and horeign agents is described which 80 allows either the home agent, or foreign agent to initiate the 81 registration revocation, and to inform the agent at the other end of 82 the tunnel to tear down the current tunnel, and allow it to free up 83 resources. In addition, revocation messages pass information between 84 the agents as to whether the registration is revoked conditionally, or 85 absolutely. A conditional revocation means the MN's current 86 registration is terminated, but may be renegotiated in subsequent 87 reregistration attempts. An absolute revocation, as the name implies, 88 means the mobile node's current registration is terminated and no 89 renegotiation [through the current FA] is allowed. These messages are 90 a logical addition to the group defined in [1] for the generic mobile 91 IP registration processing. 93 The methods described in [1] for deregistrations apply to 94 situations where the mobile node is playing the active roll in 95 informing the home agent of its location, and maintaining its care-of 96 address(es). This document describes methods to be used only when the 97 mobility agents are initiating the revocation of individual bindings 98 for specific mobile nodes. 100 This reader is assumed to be familiar with the concepts and 101 terminology used in [1]. Knowledge of the concepts of [2] and [3] may 102 also be beneficial. 104 2. Motivation 106 Mobile IP [1] [3] defines registration of a mobile node's location 107 to permit connectivity between the mobile node and its home domain, 108 permiting communication between a mobile node and any correspondant 109 node. At any time the home or foreign agent MAY stop servicing a 110 mobile node, but no mechanism is described to inform the other end of 111 the tunnel that service is being terminated. If the HA shuts down the 112 tunnel, the FA will simply stop seeing tunnel packets for the MN, just 113 as if a route stopped functioning, or if there is simply nothing being 114 sent to the mobile node. If the FA shuts down the tunnel, the HA will 115 continue to send tunnel packets, which will likely be silently 116 discarded. An aware mobile node may notice the lack of response to 117 packets it is generating, eventually figure it's binding has vanished 118 for one reason or another, and may attempt to reregister. When the MN 119 attempts to reregister its binding, only at that time can it get a 120 registration denied error with some hint as to why it service was 121 stopped, by whom, then attempt to renegotiate. Clearly a more active 122 mechanism should be designed. 124 3. Registration Revocation Details 126 Registration revocation consists of two disjoint pieces, a 127 signalling mechanism between the tunnel endpoints, and a signalling 128 mechanism between the foreign agent and mobile node. A colocated 129 mobile node, that is one which is decapsulating it's own tunnel 130 traffic, MAY implement the tunnel endpoint-signaling portion of this 131 protocol so that its home agent may signal it if it's binding is being 132 terminated. 134 3.1 Foreign Agent Notification to the Mobie Node 136 A mechanism providing a foreign agent a way to activly notify a 137 mobile node that its binding has been reset already exists in [1], 138 though it has been mainly overlooked. As described by [1], when a 139 foreign agent begins sending agent advertisements, it starts with a 140 sequence number of 0, and increments this sequence number with each 141 subsequent agent advertisement. Instead off allowing the sequence 142 number to roll-over, it is instead set to 256 so a mobile node can 143 distinguish between a foreign agent state-reset from a rolled-over 144 sequence number. Leveraging this mechanism, though unspecified 145 explicity by [1], a foreign agent may notify all mobile node's 146 currently bound to it that it is resetting all their bindings by 147 simply resetting its sequence number to 0 (or anywhere in the range 0 148 - 255 inclusive), even if the agent itself has not been reset. 149 Moreover, a foreign agent may inform all mobile nodes currently bound 150 to it to reregister with a different foreign agent by simultaneously 151 setting the 'B' bit to 1 in such an agent advertisement where the 152 sequence number has been reset to 0 (or anywhere in the range 0 - 255 153 inclusive). In these situations, any mobile node in compliance with 154 [1] understands the FA has lost their binding, and MUST reregister if 155 they wish to reestablish the tunnels with their home agent. 157 By using this mechanism actively, a foreign agent may also notify 158 a single mobile node that it's binding has been reset by unicasting to 159 it an agent advertisement with the sequence number set to 0. If such 160 a foreign agent wishes to indicate to the mobile node that it is to 161 not attempt to refresh it's registration with it, it may also set the 162 'B' bit to 1. Note that such a foreign agent is likely to not be 163 advertising with the 'B' bit set to 1 in its multicast/broadcast agent 164 advertisements, so other mobile node's will still register with it. 165 If upon hearing the multicast agent advertisement, should a mobile 166 node that has recently had it's registration revoked by this FA 167 attempt to [re]register with it, the agent can simply deny the MN with 168 an appropriate error code. At this time, the mobile node SHOULD use 169 foreign agent fallback to attempt to register with a different agent. 170 If the mobile node decides to send an agent solicitation, this foreign 171 agent MAY again unicast its agent advertisement to the mobile node 172 with the 'B' bit set to 1 indicating the mobile node should not 173 register with it, or alternatively, this foreign agent MAY ignore the 174 mobile node's agent solicitation. 176 Agent Advertisements unicast to a mobile node MUST be sent as 177 described in [1]. This includes any methods currently in use on the 178 link to make them secure or authenticatable by the mobile node. 180 3.2 Mobility Agent Registration Revocation Signalling Mechanism 182 Any active mechanism designed to be useful to both home and foreign 183 domains must contain a way for either side to revoke the current 184 binding, and securely inform the other domain of its intension. 186 In the case where the foreign domain is revoking a mobile node's 187 binding, the foreign agent SHOULD notify the mobile node as described 188 in section 3.1 above. In addtion, an FA which is terminating the 189 binding of a mobile node SHOULD inform the mobile node's current home 190 agent that it is shutting-down the tunnel exit point. This will allow 191 the home agent to stop generating tunnel packets for the mobile node, 192 and also allow it to free resourses it is currently reserving for the 193 mobile node. In this case an foreign-home security association MUST 194 exist, and must be included in the registration revocation message. 195 Upon receiving a registration revocation message the home agent MUST 196 check the foreign-home authenticator, and if the packet passes the 197 authentication, MAY free up any resources associated with the former 198 binding. If a home agent receives a registration revocation message 199 that does not contain a foreign-home authenticator, it MUST be 200 ignored. 202 In the case where the home agent is revoking a mobile node's 203 binding, the home agent SHOULD notify the care-of address it is 204 terminating the tunnel entry point. If the mobile node is not 205 colocated (as indicated to the HA by the setting of the 'D' bit in its 206 registration request) a home-foreign security association must exist, 207 and MUST be included in the registration revocation message. Upon 208 receiving such a notification, the foreign agent MUST check the 209 home-foreign authenticator, and if the packet passes the 210 authentication, the foreign agent SHOULD notify the mobile node that 211 its binding has been reset by using the method described in section 212 3.1 above, and MAY free up any resources being used by the former 213 binding. If a foreign agent receives a registration revocation 214 message that does not contain a home-foreign authenticator, it MUST be 215 ignored. If the home agent is revoking the registration of a mobile 216 node which is colocated, a mobile-home autenticator MUST be used. 217 Upon receiving such a notification, the mobile node MUST check the 218 mobile-home authenticator, and if the packet passes authentication, 219 the mobile node MUST terminate any reverse tunnel encapsulation it is 220 using to the home agent. The mobile node may also optionally free up 221 any other resources associated with the former binding. 223 The case where a colocated mobile node is registered directly with 224 it's home agent, and wishes to terminate it's own binding is 225 considered unnecessary. In this case the mobile node MAY simply 226 deregsiter with its home agent as described by [1] [3]. A foreign 227 agent advertising the 'R' bit, however, causes a colocated mobile node 228 to register it's colocated address as its care-of address, which is 229 the tunnel exit point. In this case, a foreign agent is capable of 230 revocing the mobile node's registration (as it is privy to the 231 information in the registration request, namely the mobile node's home 232 address, and the address of the mobile node's home agent) by sending a 233 Registration Revocation to either home agent, or mobile node, or by 234 simply unicasting an agent advertisement with a sequence number of 0 235 to the mobile node, indicating it's visitor list entry for the mobile 236 node is gone. In the situation where the foreign agent chooses to use 237 a Registration Revocation message, a foreign-home or foreign-mobile 238 security association MUST exist for the registration revocation to be 239 successful. If one does not exist, the foreign agent MAY deny the 240 original registration request using the usual registration reply 241 mecanism described in [1]. In addition, a colocated mobile node that 242 has had it's registration revoked by such a foreign agent MAY notify 243 it's home agent by either deregistering directly, but as this may 244 fail, MAY opt instead to attempt to send a registration revocation 245 message (via any foreign agent as all foreign agents on a link are 246 required to all advertise the same setting for the "R" bit) to its 247 home agent. In this scenario, a mobile-home authenticator MUST be 248 included in the registration revocation message. 250 3.3 Registration Revocation Message Format 252 This section details the format of the signalling protocol between 253 home and foreign agent, or between home agent and colocated mobile node. 255 The format of a registration revocation message nearly identical to 256 registration request and registration request messages. 258 IP fields: 260 Source Address In the case of the home agent issuing the 261 Registration Revocation, the address 262 registered with the care-of address as 263 that of the home agent. In the case of 264 the foreign agent issuing the 265 registration revocation, the address 266 registered with the home agent as the 267 care-of address. 269 Destination Address In the case of the home agent issuing the 270 registration revocation, that of the 271 care-of addressed registered by the 272 mobile node whose registration is being 273 revoked. In the case of the foreign 274 agent issuing the registration 275 revocation, the home agent address 276 registered by the mobile node whose 277 registration is being revoked. 278 UDP fields: 280 Source Port 434 282 Destination Port 434 284 The UDP header is followed by the Mobile IP fields shown below: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Code | Lifetime | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Home Address | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Home Agent | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Care-of Address | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 + Identification + 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Extensions ... 302 +-+-+-+-+-+-+-+-+-+- 303 | Authenticator ... 304 +-+-+-+-+-+-+-+-+-+- 306 Type 7 (Registration Revocation) (T.B.A.) 308 Code A value indicating the desired 'level' of Registration 309 Revocation. See below for a list of currently defined 310 code values. 312 Lifetime 313 The amount of time the mobile node is to be denied 314 reregistration. That is, the lifetime of the 315 registration revocation. A value of zero indicates the 316 mobile node's current registration is terminated, but 317 may be allowed reregistration attempts immediately. A 318 value of 0xffff indicates the current registration is 319 revoked for an infinite time, and no further 320 reregistration attempts will be accepted. 322 Home Address 323 The IP address of the mobile node whose registration is 324 being revoked. 326 Home Agent 327 The IP address of the Home Agent, namely the tunnel 328 entry point, or the zero address (see below) 330 Care-of Address 331 The IP address serving as the tunnel exit point, or the 332 zero address (see below). 334 Identification 335 A 32-bit number used for protecting against replay 336 attacks. See section 6 (below). 338 Extensions 339 Any relavent extensions for this registration 340 revocation. e.g. Vendor-specific extensions. 342 Authenticator 343 An authenticator as defined in [1] MUST be present. 344 This is usually in the form of an HA-FA authenticator, 345 or a HA-MN authenticator when the mobile node is using 346 a colocated care-of address. 348 3.4 Protocol Details 350 A foreign-home authenticator MUST follow any Registration 351 Revocation message whenever a home agent is performing a Registration 352 Revocation, and sending this message to a foreign agent, or whenever a 353 foreign agent is initiating the registration revocation, and sending 354 this message to a home agent. A mobile-home authenticator MUST appear 355 if a home agent is sending this message to a colocated mobile node 356 which is serving as its own tunnel-exit point, or when a mobile node 357 is notifying its home agent that the local domain has issued a 358 registration revocation (in this latter case, the mobile node MAY 359 instead/also attempt to issue a deregistration request as defined in 360 [1]). 362 Registration Revocation messages MUST be sent from the source 363 address of one end of the tunnel, that is from the Care-of address 364 being used by the mobile node whose home address appears in the 365 message, or from the address of the address of the home agent being 366 used by the mobile node whose home address appears in the same 367 message. In this way, the agent receiving this message can uniquely 368 identify which mobile node's binding is to be revoked even in the case 369 of overlapping privately addressed mobile nodes. 371 If a home agent is revocing a specific registration for a mobile 372 node, it MUST include it's own address (a.k.a. the tunnel entry 373 point), the mobile node's home address, and the registered care-of 374 address (a.k.a. the tunnel exit point). If a home agent is revoking 375 all of a particular mobile node's binding with a foreign agent, it 376 MUST include it's own address (a.k.a. the tunnel entry point), the 377 mobile node's addres, and it MAY set the care-of address to the zero 378 address indicating "all bindings for this mobile node." If the home 379 agent wishes to have the foreign agent revoke all mobile node bindings 380 that use it as a home agent, it MAY set the home address field to the 381 zero address. The home agent MUST NOT set the home agent field to the 382 zero address. If a foreign agent receives a registration revocation 383 message with the home agent field set to the zero addressm it MUST be 384 silently ignored. This is to prevent confusion in the case of 385 overlapping private addresses; when multiple mobile nodes are 386 registered via the same care-of address using the same 387 (disparate/private) home address, the home agent address is the only 388 way a foreign agent can discern these mobile nodes. 390 If a foreign agent is revocing a specific registration for a 391 mobile node, it MUST include the registered care-of address, the home 392 address of the mobile node whose registration is being revoked, and 393 the home agent address of the current binding. If a foreign agent is 394 revoking the bindings of all mobile nodes using a particular home 395 agent, it MAY set the home address field to the zero address. If a 396 foreign agent is revoking multiple care-of address bindings for the 397 same mobile node, it MAY set the care-of address to the zero address. 398 However, if a home agent receives a registration revocation from a 399 foreign agent indicating the registration for a colocated mobile node 400 has been revoked, the home agent MUST verify this message is comming 401 from the same foreign agent that relayed the registration request for 402 this binding. If this can not be verified, or it can be determined 403 that the foreign agent issuing this registration revocation is not the 404 foreign agent which relayed the registration request for the current 405 binding, the home agent MUST silently ignore it. This means if a 406 mobile node has one or more bindings with different colocated care-of 407 addresses, and in addition has one or more bindings using foreign 408 agent provided care-of addresses (as in the case of multi-homed 409 foreign agent), each set of bindings must be revoked separately. 411 3.4.1 Revocation Codes 413 The registration revocation message contains a code. This is used 414 to indicate the "severity" of the revocation. In all cases, the 415 revocation message indicates the current binding has been lost. The 416 following codes are defined: 418 Value Meaning 419 ----- ----------------------------------------------------------- 420 0 Future registrations accepted 421 1 Future registrations with this care-of address denied 422 255 No future registrations accepted 424 Code value of 0 indicates only the current binding is lost, and 425 any new binding may be negotiated. 427 Code value of 1 indicates a mobile node may not use this care of 428 address. If this message is being sent to a colocated mobile node, it 429 SHOULD attempt to obtain another care-of address to be used in a 430 subsequent registration. If this message is being sent to a foreign 431 agent, it SHOULD set the "B" bit in it's unicast agent advertisement 432 to the mobile node indicating the mobile node SHOULD use a different 433 foreign agent when reregistering. If this message is being sent by a 434 foreign agent, it is indicating to the home agent that it will no 435 longer provide service for this mobile node. Such a foreign agent 436 SHOULD set the "B" bit in it's unicast agent advertisemetn to the 437 mobile node indicating the mobile node SHOULD use a different foreign 438 agent when reregistering. 440 A Code value of 255 means no future registrations will be approved 441 from this mobile node. 443 The code should be interpreted in conjunction with the lifetime. 444 For example, a code of 0 with a lifetime of 0 indicates the current 445 binding is revoked, and future registrations will be accepted 446 immediately. A code of 0 with a lifetime of 10 indicates the current 447 registration is revoked, and future registrations will be accepted 448 after 10 seconds have passed. For this reason, code 0 MUST NOT be 449 used with a lifetime of 255, and conversely code 255 MUST be used with 450 a lifetime of 255. 452 If a mobile node attempts to reregister before the revocation 453 lifetime has expired, the foreign agent MAY simply reply with error 454 65, "Administratively prohibited" saving it from tying up resources 455 while the registration would otherwise be pending approval by the home 456 agent. 458 It is expected that new codes will be added in the future 459 indicating what needs to be required in the new binding. For example, 460 if a mobile node is currently bound without a reverse tunnel defined, 461 but one is now required, the home agent may revok the current binding 462 with a new code indicating to the foreign agent that, if it supports 463 reverse tunneling, future registration requests which do not set the 464 "T" bit should be denied with error 75, "Reverse tunnel is mandatory 465 and 'T' bit not set" so the registration request does not have to come 466 to the home agent to be denied. 468 4. Inter-Mobility Agent Communication 470 As the intent of a registration revocation message is not a 471 request, but essentially a notification, there are no new error codes. 472 If any Registration Revocation fails authentication, or replay 473 protection (as described in section 6 below), it MUST be silently 474 discarded. 476 Upon processing a registration revocation, a mobility agent MAY 477 repsond with its own registration revocation to indicate it has 478 received and processed the message. 480 5. Multiple Binding Support 482 RFC2002 [1] allows a mobile node to register multiple care-of 483 addresses with its home agent. Each one of these bindings is it's own 484 discrete tunnel, and hence can be treated as a separate case for 485 registration revocation. Consider the situation where a mobile node 486 has multiple care-of addresses registered with a single foreign agent 487 (either because the mobile node has multiple colocated care-of 488 addresses and the foreign agent has the 'R' bit set, or because the 489 foreign agent is multi-homed). Either agent can indicate the 490 revocation of all these bindings by setting the care-of address in the 491 registration revocation message to the zero address as described in 492 section 3.4 above. 494 If a foreign agent revoks a particular mobile node's binding(s) 495 with it, the home agent MAY or MAY NOT revok any of the mobile node's 496 other bindings (with other foreign agents). If a home agent is 497 revoking one of a mobile node's bindings, it MAY revoke none, or all 498 of the mobile node's other bindings as it sees fit. If a home agent 499 decides to revok a single binding for a mobile node, the foreign agent 500 MAY decide to revok other bindings for the same mobile node as it sees 501 fit. 503 6. Replay Protection 505 As Registration Revocation messages are designed to terminate 506 service for a mobile node, replay protection is crucial to prevent 507 denial of service attacks. 509 Replay protection is handled through a 32-bit identification field 510 in the registration revocation message. Whenever such a message is 511 received by a mobility agent, the authenticator MUST be checked, and 512 MUST be valid. If not the message MUST be silent discarded. After 513 the message has been authenticated, the ID field MUST NOT match that 514 in any other authenticated registration revocation message from the 515 same mobility agent (care-of address/home agent address), and for the 516 same mobile node home address. If the ID field is not unique, the 517 message MUST be silently discarded. 519 Note: as it is possible for a mobile node to register at different 520 times with different home agents, and at different times with 521 different foreign agents, it is crucial that it not be required that 522 this ID feild be unique in messages from different agents as there is 523 no method for this information to be communicated between agents. For 524 example, if a mobile node has simultaneous bindingings with multiple 525 foreign agents, and these are being revoked, it is possible the 526 revocation message from one of the foreign agents may contain an ID 527 field that happens to match that of a previous registration 528 revocation. This MUST NOT result in the latter revocation message 529 being ignored. 531 7. Disparate Address, and Receiver Considerations 533 Since the registration revocation message comes from a source 534 address that is topologically routable from the interface receiving 535 the datagram, the agents, by definition, are topologically connected 536 (if this were not the case, the initial registration mechanism would 537 have failed). If either are connecting this topologically connected 538 region to one or more disparate address spaces no problems are 539 forseen. In order for the mobile node to have sucessfully registered 540 with its home agent, it MUST have provided the network to which it is 541 currently attached a routeable address of its home agent. Conversely, 542 the care of address being used by the mobile node must also be 543 topologically significant to the home agent in order for the 544 registration reply to have been received, and the tunnel initiated. 545 By definition, then, the home agent address and the care of address 546 must each be significant, and either address, when combined with the 547 mobile node's home address, must for a unique pair to the entity on 548 the other end of the tunnel. 550 Another way of understanding this is that the tunnel endpoint are 551 in some way connected, and hence are unique as far as the other end is 552 concerned. The address at the other end of the tunnel, in combination with 553 the address of the mobile node, must form a unique pair that can be 554 identified by the agent receiving the registration revocation message. 556 As an example, consider a mobile node who's home address lies in 557 disparate address space A behind it's home agent. 559 MN[a]-----[c]FA[b]-----((()))-----[b]HA[a]-----[a]CN 561 Address Some topologically Address 562 Space C conected network Space A 564 If we assume there must be a tunnel in existence at the time of 565 the registration revocation, namely between FA[b] and HA[b], then the 566 pair {FA[b],MN[a]} is guaranteed to be unique in the home agent 567 bindings, and the pair {HA[b],MN[a]} is guaranteed to be unique in the 568 foreign agent's visitor list. 570 As a result of this, a home agent receiving a regstration 571 revocation message and FA-HA authenticator for MN[a] from (IP source 572 address) FA[b] is able to determine the unique mobile node address 573 being deregistered (if one is provided). Conversely a foreign agent 574 feceiving a registration revocation message and HA-FA authenticator 575 for MN[a] from HA[b] is able to determine the unique mobile node 576 address being deregistered (if one is provided). 578 8. Examples 580 T.B.D. 582 9. Security Considerations 584 [1] provides an existing security mechanism used by this 585 enhancement to [1]. All messages between entities on different 586 subnets MUST use the security mechanisms defined in [1], and are 587 therefore as secure as those in the core mobile IP protocol. As 588 registration revocation, when performed, terminates mobile IP services 589 being provided to the mobile node, it is crucial that all security and 590 replay protections mechanisms are used before a mobility agent accepts 591 the other agent has revoked a mobile node's binding, and cleans up the 592 resources it has reserved for this service. Messages which are sent 593 link-local MAY also be secured by methods outlined in [1]. 595 10. Where to Direct Comments 597 Questions and comments about this draft should be directed at the 598 Mobile IP working group: 600 mobile-ip@standards.nortelnetworks.com 602 Questions and comments about this draft can also be directed to 603 the author: 605 Steven M. Glass 606 Internet Engineering 607 Sun Microsystems 608 1 Network Drive 609 Burlington, MA. 01801 611 Phone: 1.781.442.0504 612 Fax: 1.781.442.1706 613 E-mail: Steven.Glass@Sun.COM 615 The working group may also be contacted via the current chairs: 617 Basavaraj Patil Phil Roberts 618 Nokia Corporation Motorola 619 6000 Connection Drive 1501 West Shure Drive 620 M/S M8-540 621 Irving, Texas 75039 Arlington Heights, IL 60004 622 USA USA 623 Phone: +1 972-894-6709 Phone: +1 847-632-3148 624 Fax : +1 972-894-5349 625 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com 627 11. References 629 [1] C. Perkins, Editor. IPv4 Mobility Support. RFC 2002, 630 October 1996. 632 [2] G. Montenegro, Editor. Reverse Tunneling for Mobile IP. 633 RFC 2344, May 1998. 635 [3] D. Johnson, Mobility Support in IPv6, work in progress 637 12.0 Full Copyright Statement 639 "Copyright (C) The Internet Society (2000). All Rights Reserved. 641 This document and translations of it may be copied and furnished 642 to others, and derivative works that comment on or otherwise 643 explain it or assist in its implementation may be prepared, copied, 644 published and distributed, in whole or in part, without 645 restriction of any kind, provided that the above copyright notice 646 and this paragraph are included on all such copies and derivative 647 works. However, this document itself may not be modified in any 648 way, such as by removing the copyright notice or references to the 649 Internet Society or other Internet organizations, except as needed 650 for the purpose of developing Internet standards in which case the 651 procedures for copyrights defined in the Internet Standards 652 process must be followed, or as required to translate it into 653 languages other than English. 655 The limited permissions granted above are perpetual and will not 656 be revoked by the Internet Society or its successors or assigns. 658 This document and the information contained herein is provided on 659 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 660 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 661 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 662 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 665 13.0 Working Group Chair's Address 667 The Working Group can be contacted via its current chairs: 669 Basavaraj Patil Phil Roberts 670 Nokia Corporation Motorola 671 M/S M8-540 672 6000 Connection Drive 1501 West Shure Drive 673 Irving, TX 75039 Arlington Heights, IL 60004 674 USA USA 675 Phone: +1 972-894-6709 Phone: +1 847-632-3148 676 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 677 Fax : +1 972-894-5349