idnits 2.17.1 draft-ietf-mip4-generic-notification-message-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (February 2, 2010) is 5197 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) == Unused Reference: 'RFC3115' is defined on line 1315, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Standards Track H. Levkowetz 5 Expires: August 6, 2010 Ericsson Research 6 V. Devarapalli 7 WiChorus 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 February 2, 2010 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-13.txt 17 Abstract 19 This document specifies protocol enhancements that allow Mobile IPv4 20 entities to send and receive explicit notification messages using a 21 new Mobile IPv4 message type designed for this purpose. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on August 6, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Notification message - Usage Scenario's . . . . . . . . . . . 6 66 3.1. Notification message between a Home Agent and a Mobile 67 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1.1. Mobile Registered using a Foreign Agent Care-of 69 Address . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.2. Mobile Registered using a Co-located Care-of 71 Address . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Notification message between a Foreign Agent and a 73 Mobile Node . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. Notification message between a Home Agent and a 75 Foreign Agent . . . . . . . . . . . . . . . . . . . . . . 7 76 4. Generic Notification Message and Considerations . . . . . . . 8 77 4.1. Generic Notification Message . . . . . . . . . . . . . . . 8 78 4.2. Generic Notification Acknowledgment Message . . . . . . . 11 79 4.3. Notification Retransmision . . . . . . . . . . . . . . . . 15 80 4.4. Mobile Node Consideration . . . . . . . . . . . . . . . . 15 81 4.4.1. Receiving Generic Notification Messages . . . . . . . 15 82 4.4.2. Sending Generic Notification Acknowledgement 83 Message . . . . . . . . . . . . . . . . . . . . . . . 16 84 4.4.3. Sending Generic Notification Messages . . . . . . . . 17 85 4.4.4. Receiving Generic Notification Acknowledgement 86 Messages . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.5. Foreign Agent Consideration . . . . . . . . . . . . . . . 18 88 4.5.1. Receiving Generic Notification Message . . . . . . . . 18 89 4.5.2. Sending Generic Notification Acknowledgement 90 Messages . . . . . . . . . . . . . . . . . . . . . . . 20 91 4.5.3. Sending Generic Notification Messages . . . . . . . . 21 92 4.5.4. Receiving Generic Notification Acknowledgement 93 Messages . . . . . . . . . . . . . . . . . . . . . . . 22 94 4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 22 95 4.6.1. Sending Generic Notification Messages . . . . . . . . 23 96 4.6.2. Receiving Generic Notification Acknowledgement 97 Messages . . . . . . . . . . . . . . . . . . . . . . . 23 98 4.6.3. Receiving Generic Notification Messages . . . . . . . 24 99 4.6.4. Sending Generic Notification Acknowledgement 100 Messages . . . . . . . . . . . . . . . . . . . . . . . 25 101 5. Future Extensibility . . . . . . . . . . . . . . . . . . . . . 26 102 5.1. Generic String Extension . . . . . . . . . . . . . . . . . 26 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 105 7.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 28 106 7.1.1. Replay Protection using Timestamps . . . . . . . . . . 29 107 7.1.2. Replay Protection using Nonces . . . . . . . . . . . . 30 108 7.2. Non-authentication Extensions Handling in Foreign Agent . 30 110 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 111 9. Normative References . . . . . . . . . . . . . . . . . . . . . 32 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 114 1. Introduction 116 In some situations, there is a need for Mobile IPv4 entities, such as 117 the home agent(HA), foreign agent(FA) and mobile node(MN) to send and 118 receive asynchronous notification messages during a mobility session. 119 The base Mobile IP Specification [RFC3344] does not have a provision 120 for this. 122 This document defines a generic message and a notification model that 123 can be used by Mobile IPv4 entities to send various notifications. 124 It also defines a corresponding acknowledgement message to allow for 125 reliable delivery of notifications. The messages defined in this 126 document are capable of carrying the same extensions that have been 127 defined for the existing Mobile IPv4 messages. However, this 128 document requires for now that only the following extensions be 129 present in the new messages defined herein: 131 - MN-HA Authentication Extension 133 - MN-FA Authentication Extension 135 - FA-HA Authentication Extension 137 - Generic String Extension 139 For now, the semantics of receiving a generic notification message 140 are null; i.e., it has no effect on the state of a mobile node's 141 existing registration. See Section 5 for some prospective 142 application examples that motivate the new messages defined in this 143 document. Future documents may specify additional extension types 144 that may be used in a generic notification message and their 145 semantics. 147 2. Terminology 149 It is assumed that the reader is familiar with the terminology used 150 in [RFC4917], [RFC3344]. In addition, the following terms are 151 defined: 153 Notification Message 155 A message from a mobility agent to a MN or other mobility agent to 156 asynchronously notify it about an event that is relevant to the 157 mobility service it is currently providing. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119, [RFC2119]. 163 3. Notification message - Usage Scenario's 165 There are several scenarios where a mobility agent could initiate 166 notification events. Some of these are described in the following 167 sections. 169 3.1. Notification message between a Home Agent and a Mobile Node 171 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 173 In this case, the HA cannot directly notify the MN, but must send the 174 notification via the FA, vice versa. 176 +----+ notification +----+ notification +----+ 177 | MN |<================>| FA |<=============>| HA | 178 +----+ +----+ +----+ 180 Figure 1: HA notifies MN or MN notifies HA through FA 182 3.1.2. Mobile Registered using a Co-located Care-of Address 184 In this case, the MN has registered with the home agent directly, so 185 the notification message can go directly to the MN. 187 The notification mechanism as specified here does not support the 188 case of Co-located CoA mode with registration through a FA (due to 189 the 'R' bit being set in the FA's advertisement messages). 191 +----+ notification +----+ 192 | MN |<===================================>| HA | 193 +----+ +----+ 195 Figure 2: HA directly notifies MN or MN directly notifies HA 197 3.2. Notification message between a Foreign Agent and a Mobile Node 199 There are two cases where a FA may send notification messages to a 200 MN, one where it is relaying a message, the other where the 201 notification is triggered by a message from another network entity, 202 for example a AAA node(notification messages between a AAA entity and 203 the FA could be based on RADIUS or Diameter, but this is out of scope 204 for this document). If the notification is initiated by a FA, the FA 205 may need to also notify the HA about the event. 207 +----+ notification +----+ trigger +--------+ 208 | MN |<================>| FA |<=============| AAA | 209 +----+ +----+ +--------+ 210 || notification +----+ 211 ================>| HA | 212 +----+ 214 Figure 3: FA notifies MN 216 3.3. Notification message between a Home Agent and a Foreign Agent 218 The HA may also need to send a notification to the FA, but not to the 219 MN, The FA may also need to send a notification to the HA, as 220 illustrated below: 222 +----+ notification +----+ 223 | FA |<=============>| HA | 224 +----+ +----+ 226 Figure 4: HA notifies FA or FA notifies HA 228 4. Generic Notification Message and Considerations 230 This section describes in detail the Generic Notification Message 231 (GNM), Generic Notification Acknowledgement Message (GNAM), and some 232 considerations related to the handling of these messages in the MN, 233 FA and HA. 235 The MN and HA MUST maintain the following information, FA also needs 236 to maintain both the HA's and MN's direction the below information: 238 - the IP source address of the Registration Request/Reply 240 - the IP destination address of the Registration Request/Reply 242 - the UDP source port of the Registration Request/Reply 244 - the UDP destination port of the Registration Request/Reply 246 The sending node always sends the GNM message following the same 247 procedure for sending Registration Request as in section 3.3 of 248 [RFC3344] and the receiving node follows the same procedure for 249 Registration Reply as in section 3.4. of [RFC3344] when sending GNAM. 251 4.1. Generic Notification Message 253 A GNM is sent by a mobility agent to inform another mobility agent, 254 or a MN, of MIP-related information such as generic string 255 notification[RFC4917]. These messages MUST use the same IP and UDP 256 headers as any previous Registration Request(RRQ) or Reply (RRP) 257 message to the same entity. This would support NAT traversal and 258 ensure same security association used for GNM/GNAM and RRQ/RRP. The 259 GNM is defined as follows: 261 IP Fields: 263 Source Address Typically copied from the destination 264 address of the last Registration Reply/ 265 Request message that the agent received from 266 the agent to which it is sending the GNM. 268 Destination Address Copied from the source address of the last 269 Registration Reply/Request message that the 270 agent received from the agent to which it is 271 sending the GNM. 273 UDP Fields: 275 Source Port Typically copied from the destination port 276 of the last Registration Reply/Request 277 message that the agent received from the 278 agent to which it is sending the GNM. 280 Destination Port Copied from the source port of the last 281 Registration Reply/Request message that the 282 agent received from the agent to which it is 283 sending the GNM. 285 The UDP header is followed by the Mobile IP fields shown below: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Subtype | MD |A| Reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Home Address | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Home Agent Address | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Care-of Address | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 + Identification + 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Extensions... 303 +-+-+-+-+-+-+-+-+-+-+-+-+- 305 Type (To be assigned by IANA) 307 Subtype 309 This field describes the particular type of notification which is 310 carried in the notification message. The following values are 311 reserved in this document. 313 0 Reserved 315 1 Information carried in Generic String extensions which is 316 specified in [RFC4917]. 318 The value 0 is reserved and SHOULD NOT be used. The value 1 319 indicates that the actual information is carried in generic string 320 extensions. Other values are reserved for future extensions. 322 MD: Message Direction 324 This memo defines the semantics of the following MD field value: 326 0 -- Message sent by the HA to the MN 328 1 -- Message sent by the HA to the FA 330 2 -- Message sent by the MN to the HA 332 3 -- Message sent by the MN to the FA 334 4 -- Message sent by the FA to the MN 336 5 -- Message sent by the FA to the HA 338 A 340 This bit indicates whether the notification message MUST be 341 acknowledged by the recipient. If "A" bit has been set during the 342 message, but the sender doesn't receive any acknowledgement 343 message, then the sender will have to resend the notification 344 message again. 346 Set to "1" to indicate that acknowledgement is required. 348 Set to "0" to indicate that acknowledgement is optional. 350 Reserved 352 MUST be sent as 0, and ignored when received. 354 Home Address 356 The home IP address of the mobile node. 358 Home Agent Address 360 The IP address of the mobile node's HA. 362 Care-of Address 364 The mobile node's care-of address, either the Co-located Care-of 365 Address or the foreign agent care-of address. 367 Identification 368 A 64-bit number, constructed by the sender, used for matching GNM 369 with GNAM, and for protecting against replay attacks of 370 notification messages. See Sections 8.1.1 and 8.1.2. Timestamps 371 is mandatory and nonces is optional. 373 Extensions 375 The fixed portion of the GNM is followed by one or more extensions 376 which may be used with this message, and by one or more 377 authentication extensions (as defined in Section 3.5 of [RFC3344]. 378 This document mandates the MN-HA Authentication Extension (AE) 379 when this message is sent between the MN and the HA, MN-FA AE and 380 FA-HA AE are optional. This document also mandate the MN-FA AE 381 when this message is sent between the MN and the FA, MN-HA AE and 382 FA-HA AE are not needed. This document mandate the FA-HA AE when 383 this message is sent between the FA and the HA, MN-HA AE and MN-FA 384 AE are not needed. This could be judged based on "MD" value.). 385 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 386 order of these extensions as they appear in Mobile IPv4 RRQ and 387 RRP messages. The same rules are applicable to GNM and GNAM. 389 4.2. Generic Notification Acknowledgment Message 391 A GNAM is sent by mobility agents or MNs to indicate the successful 392 receipt of a GNM. 394 IP Fields: 396 Source Address Typically copied from the destination 397 address of the GNM to which the agent is 398 replying. 400 Destination Address Copied from the source address of the GNM to 401 which the agent is replying. 403 UDP Fields: 405 Source Port Copied from the destination port of the 406 corresponding GNM. 408 Destination Port Copied from the source port of the 409 corresponding GNM. 411 The UDP header is followed by the Mobile IP fields shown below: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Subtype | MD | code | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Home Address | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Home Agent Address | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Care-of Address | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | 425 + Identification + 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Extensions... 429 +-+-+-+-+-+-+-+-+-+-+-+-+- 431 Type (To be assgined by IANA) 433 Subtype 435 This field specifies the particular type of notification 436 acknowledgement message. The following values are reserved in 437 this document. 439 0 Reserved 441 1 Information carried in Generic String extensions which is 442 specified in [RFC4917]. 444 The value 0 is reserved and SHOULD NOT be used. The value 1 445 indicates that the actual information is carried in Generic String 446 extensions Other values are reserved for future extensions. 448 MD: Message Direction 450 This memo defines the semantics of the following MD field value: 452 0 -- Message sent by the HA to the MN 454 1 -- Message sent by the HA to the FA 456 2 -- Message sent by the MN to the HA 458 3 -- Message sent by the MN to the FA 459 4 -- Message sent by the FA to the MN 461 5 -- Message sent by the FA to the HA 463 code 465 A value indicating the result of the GNM. See below for a list of 466 currently defined Code values. 468 Notification suceessful 470 0 -- notification accepted 472 Notification denied by the HA 474 128 -- reason unspecified 476 129 -- administratively prohibited 478 130 -- insufficient resources 480 131 -- mobile node failed authentication 482 132 -- foreign agent failed authentication 484 133 -- notification Identification mismatch 486 Notification denied by the FA 488 64 -- reason unspecified 490 65 -- administratively prohibited 492 66 -- insufficient resources 494 67 -- mobile node failed authentication 496 68 -- home agent failed authentication 498 69 -- notification Identification mismatch 500 Notification denied by the mobile node 502 192 -- reason unspecified 504 193 -- administratively prohibited 505 194 -- insufficient resources 507 195 -- foreign agent failed authentication 509 196 -- home agent failed authentication 511 197 -- notification Identification mismatch 513 Home Address 515 The home IP address of the mobile node. 517 Home Agent Address 519 The IP address of the sender's home agent. 521 Care-of Address 523 The mobile node's care-of address, either the Co-located Care-of 524 Address or the foreign agent care-of address. 526 Identification 528 A 64-bit number used for matching GNM message with GNAM mesage and 529 for protecting against replay attacks of registration messages. 530 See Sections 8.1.1 and 8.1.2. Timestamps is mandatory and nonces 531 is optional. The value is based on the Identification field from 532 the GNM message from the sender, and on the style of replay 533 protection used in the security context between the sender and its 534 receiver (defined by the mobility security association between 535 them, and SPI value in the authorization-enabling extension). 537 Extensions 539 The fixed portion of the GNAM is followed by one or more 540 extensions which may be used with this message, and by one or more 541 authentication extensions (as defined in Section 3.5 of [RFC3344]. 542 This document mandates the MN-HA Authentication Extension (AE) 543 when this message is sent between the MN and the HA, MN-FA AE and 544 FA-HA AE are optional. This document also mandate the MN-FA AE 545 when this message is sent between the MN and the FA, MN-HA AE and 546 FA-HA AE are not needed. This document mandate the FA-HA AE when 547 this message is sent between the FA and the HA, MN-HA AE and MN-FA 548 AE are not needed. This could be judged based on "MD" value.). 549 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 550 order of these extensions as they appear in Mobile IPv4 RRQ and 551 RRP messages. The same rules are applicable to GNM and GNAM. 553 4.3. Notification Retransmision 555 If "A" flag has been set during the GNM message, but the sender 556 doesn't receive any GNAM message within a reasonable time, then 557 another GNM will be retransmited. When timestamps are used, a new 558 registration Identification is chosen for each retransmision; Thus it 559 counts as a new GNM. When nonces are used, the unanswered GNM 560 message is retransmitted unchanged; thus the retransmission does not 561 count as a new GNM (Section 8.1). In this way a retransmission will 562 not require the receiver to resynchronize with the sender by issuing 563 another nonce in the case in which the original GNM message (rather 564 than its GNAM message) was lost by the network. 566 The maximum time until a new GNM message is sent SHOULD be no greater 567 than the requested Lifetime of the last GNM message. The minimum 568 value SHOULD be large enough to account for the size of the messages, 569 twice the round trip time for transmission to the receiver, and at 570 least an additional 100 milliseconds to allow for processing the 571 messages before responding. The round trip time for transmission to 572 the receiver will be at least as large as the time required to 573 transmit the messages at the link speed of the sender's current point 574 of attachment. Some circuits add another 200 milliseconds of 575 satellite delay in the total round trip time to the receiver. The 576 minimum time between GNM MUST NOT be less than 1 second. Each 577 successive retransmission timeout period SHOULD be at least twice the 578 previous period, as long as that is less than the maximum as 579 specified above. 581 4.4. Mobile Node Consideration 583 It is possible that the MN MAY receive a GNM from a FA or HA. Both 584 in the case of FA-CoA and Co-located CoA, the MN MAY reply with a 585 GNAM based on the "A" flag in the GNM message. 587 4.4.1. Receiving Generic Notification Messages 589 When the MN is using FA-CoA and receives a Notification message, if 590 the "MD" value is 0, it means that the notification message came from 591 the HA. If the "MD" value is 4, the notification came from the FA. 593 If this notification message came from a FA and the MN accepts the 594 FA's GNM, then it will process the notification extension according 595 to the specific rules for that extension. 597 The MN MUST check for the presence of an authorization-enabling 598 extension, and perform the indicated authentication. Exactly one 599 authorization-enabling extension MUST be present in the GNM, if this 600 message came from a FA, then MN-FA AE MUST be present. If no MN-FA 601 AE is found, or if more than one MN-FA AE is found, or if the 602 Authenticator is invalid, then the MN MUST reject the GNM and MAY 603 send a GNAM to the FA with Code 195, including an Identification 604 field computed in accordance with the rules specified in Section 8.1. 605 The MN MUST do no further processing with such a notification, though 606 it SHOULD log the error as a security exception. 608 The MN MUST check that the Identification field is correct using the 609 context selected by the SPI within mandatory authentication extension 610 like MN-FA AE or MN-HA AE. See Section 8.1 for a description of how 611 this is performed. If incorrect, the MN MUST reject the GNM and MAY 612 send a GNAM to the initiator with Code 197, including an 613 Identification field computed in accordance with the rules specified 614 in Section 8.1. The MN MUST do no further processing with such a 615 notification, though it SHOULD log the error as a security exception. 617 After that, the MN MAY reply GNAM back to the FA. If the "A" flag is 618 set in the GNM, then the MN MUST send the GNAM. 620 If this notification message came from the HA, relayed by the FA, or 621 is a Co-located CoA, then the MN-HA AE MUST be checked and the MN 622 MUST check the Authenticator value in the Extension. If no MN-HA AE 623 is found, or if more than one MN-HA AE is found, or if the 624 Authenticator is invalid, then the MN MUST reject the GNM and MAY 625 send a GNAM to the initiator with Code 196, including an 626 Identification field computed in accordance with the rules specified 627 in Section 8.1. The MN MUST do no further processing with such a 628 notification, though it SHOULD log the error as a security exception. 629 If the MN accepts the HA's GNM, then it will process it according to 630 the specific rules for that extension. After that, the MN MAY reply 631 with a GNAM with Code 0 back to the HA based on the "A" flag in the 632 GNM. 634 4.4.2. Sending Generic Notification Acknowledgement Message 636 Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply 637 with a GNAM based on the "A" flag in the GNM as follows: 639 If the GNM was initiated from the FA to the MN ("MD" value is set to 640 4), then MN-FA AE MUST be the last extension in order to protect all 641 other non-authentication extensions as defined in section 3.5.3 of 642 [RFC3344]. 644 In the case of a FA-CoA, the source address is the MN's address, the 645 destination address is the FA's address. 647 The Code field of the GNAM is chosen in accordance with the rules 648 specified in the section 4.2. When replying to an accepted 649 notification, a MN SHOULD respond with Code 0. 651 There are a number of reasons the MN might reject a notification such 652 as administrative in nature returning a GNAM with a code of 193, 653 similarly and provides the Code value 192 or 194 for the unspecified 654 reason and insufficient resources. 656 If the GNM was initiated from the HA to the MN ("MD" value is set to 657 0) and in the case of Co-located CoA, then MN-HA AE MUST be the last 658 extension in order to protect all other non-authentication extensions 659 as defined in section 3.5.2 of [RFC3344] 661 In the case of a FA-CoA, the source address is the MN's HoA address 662 and the destination address is the FA's address ("MD" value is set to 663 2), the ordering of the extension is: any non-authentication 664 Extensions used only by the HA, followed by the MN-HA AE defined in 665 section 3.5.2. of [RFC3344], followed by any non-authentication 666 Extensions used only by the FA, followed by the MN-FA AE defined in 667 section 3.5.3 of [RFC3344]. 669 4.4.3. Sending Generic Notification Messages 671 The MN may either send a GNM to notify the FA or HA. 673 If the message is sent to the FA, then the source address is the MN's 674 address, and the destination address is the FA's address 676 If the FA is the target of this notification message, then the "MD" 677 value is set to 3, MN-FA AE MUST be the last extension in order to 678 protect all other non-authentication extensions. Computing 679 Authentication Extension Value is the same as section 3.5.1 of 680 [RFC3344]. 682 If the FA is working only as a relay agent, then the "MD" value is 683 set to 2, and the ordering of the extension is: the notification 684 extension, followed by any non-authentication extension expected to 685 be used by HA, followed by MN-HA AE defined in section 3.5.2. of 686 [RFC3344], followed by any non-authentication Extensions used only by 687 the FA, followed by The MN-FA AE defined in section 3.5.3 of 688 [RFC3344]. Computing Authentication Extension Value is the same as 689 section 3.5.1 of [RFC3344]. 691 In the case of a Co-located CoA, the MN MAY send a notification 692 message directly to the HA if it needs to be notified. The "MD" 693 value is set to 2, and the ordering of the extension is: the 694 notification extension, followed by any non-authentication extension 695 expected to be used by HA, followed by MN-HA AE defined in section 696 3.5.2 of [RFC3344]. 698 The MN chooses the Identification field in accordance with the style 699 of replay protection it uses with its HA. This is part of the 700 mobility security association the MN shares with its HA. See Section 701 8.1 for the method by which the MN computes the Identification field. 703 4.4.4. Receiving Generic Notification Acknowledgement Messages 705 In the case of a FA-CoA, if the MN receives this message, and the 706 "MD" value is set to 0, it means that the GNAM came from HA 708 If the "MD" value is set to 4, then the MN-FA AE MUST be checked, and 709 the MN MUST check the Authenticator value in the Extension. If no 710 MN-FA AE is found, or if more than one MN-FA AE is found, or if the 711 Authenticator is invalid, then the MN MUST silently discard the GNAM. 713 In addition, the low-order 32 bits of the Identification field in the 714 GNAM MUST be compared to the low-order 32 bits of the Identification 715 field in the most recent GNM sent to the replying agent. If they do 716 not match, then the GNAM MUST be silently discarded. 718 If the "MD" value is set to 0, then the MN-HA AE MUST be checked, and 719 the MN MUST check the Authenticator value in the Extension. If no 720 MN-HA AE is found, or if more than one MN-HA AE is found, or if the 721 Authenticator is invalid, then the MN MUST silently discard the GNAM. 722 If the MN accepted this message, then the MN MAY also process it 723 based on the notification event. 725 In the case of a Co-located CoA, if the MN received this message, 726 then the MN-HA AE MUST be checked, and the MN MUST check the 727 Authenticator value in the Extension. If no MN-HA AE is found, or if 728 more than one MN-HA AE is found, or if the Authenticator is invalid, 729 then the MN MUST silently discard the Notification Acknowledgement 730 message. 732 4.5. Foreign Agent Consideration 734 The FA may initiate a GNM to the MN or the HA. Additionally, the FA 735 also relays GNM and GNAM messages between the MN and its HA as long 736 as there is an active binding for the MN at the FA. 738 4.5.1. Receiving Generic Notification Message 740 If the FA receives a GNM, and the "MD" value is set to 0, then it 741 means that the HA is asking the FA to relay the message to the MN. 742 If the "MD" value is set to 1, then it means that the target of the 743 notification is the FA. If the "MD" value is set to 2, then it means 744 that the MN is asking the FA to relay the message to the HA. If the 745 "MD" value is set to 3, then it means that the notification came from 746 the MN to the FA. 748 If the "MD" value is set to 0, then the FA MAY validate the FA-HA AE 749 if present. If the FA-HA AE is invalid, then all extensions between 750 the HA-MN AE and the HA-FA AE MUST be removed, FA SHOULD relay the 751 GNM to the MN's home address as specified in the Home Address field 752 of the GNM, MN will eventually validate the MN-HA AE to ensure that 753 all information sent to the MN is integrity protected. If the FA-HA 754 AE is valid, FA MUST relay the GNM to the MN's home address as 755 specified in the Home Address field of the GNM. The FA MUST NOT 756 modify any of the fields beginning with the fixed portion of the GNM 757 through the MN-HA AE or other authentication extension supplied by 758 the HA as an authorization-enabling extension for the MN. 760 Furthermore, the FA MUST process and remove any extensions following 761 the MN-HA AE. If the FA shares a mobility security association with 762 the MN, the FA MAY append any of its own non-authentication 763 extensions which of relevance to the MN. In this case, the FA MUST 764 append the MN-FA AE after these non-authentication extensions. 766 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 767 FA MUST check the Authenticator value in the Extension. If no FA-HA 768 AE is found, or if more than one FA-HA AE is found, or if the 769 Authenticator is invalid, the FA MUST reject the GNM and MAY send a 770 GNAM to the HA with Code 68, including an Identification field 771 computed in accordance with the rules specified in Section 8.1. The 772 FA MUST do no further processing with such a notification, though it 773 SHOULD log the error as a security exception. 775 The FA MUST check that the Identification field is correct using the 776 context selected by the SPI within mandatory FA-HA AE. See Section 777 8.1 for a description of how this is performed. If incorrect, the FA 778 MUST reject the GNM and MAY send a GNAM to the initiator with Code 779 69, including an Identification field computed in accordance with the 780 rules specified in Section 8.1. The FA MUST do no further processing 781 with such a notification, though it SHOULD log the error as a 782 security exception. 784 If FA accepts the HA's GNM, it will process it based on the specific 785 rules for that extension. The FA MAY then reply with a GNAM with 786 Code 0 back to the MN based on the "A" flag in the GNM. 788 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 789 received this message, and if the MN-FA AE is present, the MN-FA AE 790 MUST be checked, and the FA MUST check the Authenticator value in the 791 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 792 found, or if the Authenticator is invalid, the FA MUST silently 793 discard the GNM message. If MN-FA is valid, FA MUST relay the GNM to 794 the HA's address as specified in the Home Agent Address field of the 795 GNM, HA will eventually validate the MN-HA AE to ensure that all 796 information sent to the HA is integrity protected. The FA MUST NOT 797 modify any of the fields beginning with the fixed portion of the GNM 798 through the MN-HA AE or other authentication extension supplied by 799 the MN as an authorization-enabling extension for the HA. 801 Furthermore, the FA MUST process and remove any Extensions following 802 the MN-HA AE, and MAY append any of its own non-authentication 803 Extensions of relevance to the HA if applicable, and MUST append the 804 FA-HA AE, if the FA shares a mobility security association with the 805 HA. 807 If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the 808 FA MUST check the Authenticator value in the Extension which is the 809 same as the section 3.7.2.1 of RFC 3344. If no MN-FA AE is found, or 810 if more than one MN-FA AE is found, or if the Authenticator is 811 invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN 812 with Code 67, including an Identification field computed in 813 accordance with the rules specified in Section 8.1. The FA MUST do 814 no further processing with such a notification, though it SHOULD log 815 the error as a security exception. 817 The FA MUST check that the Identification field is correct using the 818 context selected by the SPI within mandatory MN-FA AE. See Section 819 8.1 for a description of how this is performed. If incorrect, the FA 820 MUST reject the GNM and MAY send a GNAM to the initiator with Code 821 69, including an Identification field computed in accordance with the 822 rules specified in Section 8.1. The FA MUST do no further processing 823 with such a notification, though it SHOULD log the error as a 824 security exception. 826 If FA accepts the MN's GNM, it will process it based on the specific 827 rules for that extension. The FA MAY then reply with a GNAM with 828 Code 0 back to the MN based on the "A" flag in the GNM. 830 4.5.2. Sending Generic Notification Acknowledgement Messages 832 The FA may need to either relay a GNAM message between the MN and the 833 HA or send one as a response to a GNM messsage that was sent to it. 834 In both cases, the GNAM message is defined as follows: 836 The source address is the FA address, the destination address is HA's 837 or MN's home address. 839 The Code field of the GNAM is chosen in accordance with the rules 840 specified in the section 4.2. When replying to an accepted 841 notification, a FA SHOULD respond with Code 0. 843 There are a number of reasons the FA might reject a notification such 844 as administrative in nature returning a GNAM with a code of 65, 845 similarly and provides the Code value 64 or 66 for the unspecified 846 reason and insufficient resources. 848 If the FA is only relaying this message to the HA, the FA MUST NOT 849 modify any of the fields beginning with the fixed portion of the GNAM 850 through the including the MN-HA AE or other authentication extension 851 supplied by the MN as an authorization-enabling extension for the MN. 852 Furthermore, the foreign agent MUST process and remove any Extensions 853 following the MN-HA AE. If the FA shares a mobility security 854 association with the HA, the FA MAY append any of its own non- 855 authentication extensions which of relevance to the HA, In this case 856 the FA MUST append the FA-HA AE after these non-authentication 857 extensions. 859 If the notification message is from the HA to the FA then the "MD" 860 value is set to 5 and the ordering of the extension is: any non- 861 authentication Extensions used only by the FA, followed by The FA-HA 862 AE defined in section 3.5.4 of [RFC3344]. 864 If the notification message is from the MN to the FA then the "MD" 865 value is set to 4 and the ordering of the extension is: any non- 866 authentication Extensions used only by the FA, followed by The MN-FA 867 AE defined in section 3.5.3 of [RFC3344]. 869 4.5.3. Sending Generic Notification Messages 871 If the FA is initiating a notification to the MN using the GNM, it 872 MAY also notify the HA as well. 874 In the message to the MN, the source address is the FA address, the 875 destination address is the MN's address, the "MD" value is set to 4, 876 and the ordering of the extension is: the notification extension, 877 followed by any non-authentication Extensions used only by the MN, 878 followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 879 Computing Authentication Extension Value is the same as section 3.5.1 880 of [RFC3344] except the payload is the notification other than 881 registration. 883 In the message to the HA, the source address is the FA's address, the 884 destination address is the HA's address (the "MD" value is set to 5), 885 and the ordering of the extension is: notification extension, 886 followed by any non-authentication Extensions used only by the HA, 887 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 888 Computing Authentication Extension Value is the same as section 3.5.1 889 of [RFC3344] except the payload is the notification other than 890 registration. 892 4.5.4. Receiving Generic Notification Acknowledgement Messages 894 In the case of a FA-CoA, if the FA receives this message, and the 895 "MD" value is set to 3, it means that the notification 896 acknowledgement message came from the MN, otherwise it came from the 897 HA. 899 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 900 FA MUST check the Authenticator value in the Extension. If no FA-HA 901 AE is found, or if more than one FA-HA AE is found, or if the 902 Authenticator is invalid, the FA MUST silently discard the 903 Notification Acknowledgement message. If the FA accepted this 904 message, the FA MAY also process it based on the notification event. 906 If the "MD" value is set to 3, if the MN-FA AE is present, it MUST be 907 checked, and the FA MUST check the Authenticator value in the 908 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 909 found, or if the Authenticator is invalid, the FA MUST silently 910 discard the GNAM message. If the FA accepted this message, the FA 911 MAY also process it based on the notification event. 913 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 914 received this message, and if the MN-FA AE is present, the MN-FA AE 915 MUST be checked, and the FA MUST check the Authenticator value in the 916 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 917 found, or if the Authenticator is invalid, the FA MUST silently 918 discard the GNAM message. If FA accepted the MN's GNAM message, it 919 MUST relay this message to the HA. The FA MUST NOT modify any of the 920 fields beginning with the fixed portion of the GNAM message through 921 the including the MN-HA AE or other authentication extension supplied 922 by the HA as an authorization-enabling extension for the MN. 923 Furthermore, the FA MUST process and remove any Extensions following 924 the MN-HA AE and MAY append any of its own non-authentication 925 Extensions of relevance to the HA, if applicable, and MUST append the 926 FA-HA AE, if the FA shares a mobility security association with the 927 HA. 929 4.6. Home Agent Consideration 931 The HA MAY initiate a GNM message to both the mobile node and FA, and 932 it also MAY receive a GNAM message from both the FA and MN. The HA 933 also MAY receive a GNM message from the FA, but only when there is a 934 binding for a MN. If the HA receives a GNM from a FA and there is no 935 corresponding MN registration, the HA SHOULD drop the GNM message. 937 4.6.1. Sending Generic Notification Messages 939 In the case of a FA-CoA, the HA may either send a GNM to notify the 940 FA, or have the FA relay the GNM to the MN if the MN needs to be 941 notified. 943 If the message is from the HA to the FA, the source address is the 944 HA's address, and the destination address is the FA's address 946 If the FA is working only as a relay agent, the "MD" value is set to 947 0, and the ordering of the extension is: the notification extension, 948 followed by any non-authentication extension expected to be used by 949 MN, followed by MN-HA AE defined in section 3.5.2. of [RFC3344], 950 followed by any non-authentication Extensions used only by the FA, 951 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 952 Computing Authentication Extension Value is the same as section 3.5.1 953 of [RFC3344]. 955 If the FA is the target of this notification message, then the "MD" 956 value is set to 1, and the ordering of the extension is: the 957 notification extension, followed by any non-authentication Extensions 958 used only by the FA, followed by The FA-HA AE defined in section 959 3.5.4 of [RFC3344]. Computing Authentication Extension Value is the 960 same as section 3.5.1 of [RFC3344]. 962 In the case of a Co-located CoA, the HA MAY send a notification 963 message directly to the MN if it needs to be notified. The "MD" 964 value is set to 0, and the ordering of the extension is: the 965 notification extension, followed by any non-authentication extension 966 expected to be used by MN, followed by MN-HA AE defined in section 967 3.5.2. of [RFC3344]. 969 4.6.2. Receiving Generic Notification Acknowledgement Messages 971 In the case of a FA-CoA, if the HA receives this message, and the 972 "MD" value is set to 2, it means that the GNAM message came from MN. 974 If the "MD" value is set to 5, and the HA accepted this message, the 975 HA MAY also process it based on the notification event. The FA-HA AE 976 MUST be checked, and the HA MUST check the Authenticator value in the 977 Extension. If no FA-HA AE is found, or if more than one FA-HA AE is 978 found, or if the Authenticator is invalid, the HA MUST silently 979 discard the GNAM message. 981 If the "MD" value is set to 2, in the case of a FA-CoA, and if FA-HA 982 AE is present, the FA-HA AE MUST be checked, and the HA MUST check 983 the Authenticator value in the Extension. If more than one FA-HA AE 984 is found, or if the Authenticator is invalid, the HA MUST silently 985 discard the GNAM message. Anyway, MN-HA AE MUST be checked, and the 986 HA MUST check the Authenticator value in the Extension. If no MN-HA 987 AE is found, or if more than one MN-HA AE is found, or if the 988 Authenticator is invalid, the HA MUST silently discard the GNAM. If 989 the HA accepted this message, the HA MAY also process it based on the 990 notification event. 992 If the "MD" value is set to 2, in the case of a Co-located CoA, MN-HA 993 AE MUST be checked, and the HA MUST check the Authenticator value in 994 the Extension. If no MN-HA AE is found, or if more than one MN-HA AE 995 is found, or if the Authenticator is invalid, the HA MUST silently 996 discard the GNAM. If the HA accepted this message, the HA MAY also 997 process it based on the notification event. 999 4.6.3. Receiving Generic Notification Messages 1001 The HA MAY receive a GNM message sent from the FA. When the HA 1002 receives this message, if the the "MD" value is set to 5, this 1003 message came from FA. FA-HA AE MUST be checked, and the HA MUST 1004 check the Authenticator value in the Extension. If no FA-HA AE is 1005 found, or if more than one FA-HA AE is found, or if the Authenticator 1006 is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA 1007 with Code 132, including an Identification field computed in 1008 accordance with the rules specified in Section 8.1. The HA MUST do 1009 no further processing with such a notification, though it SHOULD log 1010 the error as a security exception. 1012 The HA MUST check that the Identification field is correct using the 1013 context selected by the SPI within mandatory authentication extension 1014 like MN-HA AE or FA-HA AE. See Section 8.1 for a description of how 1015 this is performed. If incorrect, the HA MUST reject the GNM and MAY 1016 send a GNAM to the initiator with Code 133, including an 1017 Identification field computed in accordance with the rules specified 1018 in Section 8.1. The HA MUST do no further processing with such a 1019 notification, though it SHOULD log the error as a security exception. 1020 If HA accepts the FA's GNM message, it will process it based on the 1021 notification extension. Furthermore, the HA MAY reply with a GNAM 1022 message with Code 0 back to the FA based on the "A" flag in the GNM 1023 message. 1025 If the the "MD" value is set to 2, this message come from MN, in the 1026 case of FA-COA, if FA-HA AE is present, it MUST be checked, and the 1027 HA MUST check the Authenticator value in the Extension. If more than 1028 one FA-HA AE Extension is found, or if the Authenticator is invalid, 1029 the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 1030 132, including an Identification field computed in accordance with 1031 the rules specified in Section 8.1. The HA MUST do no further 1032 processing with such a notification, though it SHOULD log the error 1033 as a security exception. And MN-HA AE MUST be checked, and the HA 1034 MUST check the Authenticator value in the Extension. If no MN-HA AE 1035 is found, or if more than one MN-HA AE is found, or if the 1036 Authenticator is invalid, the HA MUST reject the GNM and MAY send a 1037 GNAM to the MN with Code 131, including an Identification field 1038 computed in accordance with the rules specified in Section 8.1. The 1039 HA MUST do no further processing with such a notification, though it 1040 SHOULD log the error as a security exception. If HA accepts the MN's 1041 GNM message, it will process it based on the notification extension. 1042 Furthermore, the HA MAY reply with a GNAM message back to the MN with 1043 Code 0 based on the "A" flag in the GNM message. 1045 If the the "MD" value is set to 2, in the case of a Co-located CoA, 1046 the MN-HA AE MUST be checked, and the HA MUST check the Authenticator 1047 value in the Extension. If no MN-HA AE is found, or if more than one 1048 MN-HA AE is found, or if the Authenticator is invalid, the HA MUST 1049 reject the GNM and MAY send a GNAM to the MN with Code 131, including 1050 an Identification field computed in accordance with the rules 1051 specified in Section 8.1. The HA MUST do no further processing with 1052 such a notification, though it SHOULD log the error as a security 1053 exception. If HA accepts the MN's GNM message, it will process it 1054 based on the notification extension. Furthermore, the HA MAY reply 1055 with a GNAM message back to the MN with Code 0 based on the "A" flag 1056 in the GNM message. 1058 4.6.4. Sending Generic Notification Acknowledgement Messages 1060 If the GNM message came from the FA only, and if the "A" flag is set 1061 in the GNM message, then the HA MUST send a GNAM message. The 1062 message is as follows: The source address is HA's address, the 1063 destination address is the FA's address, the "MD" value is set to 1. 1064 The ordering of the extension is: any non-authentication Extensions 1065 used only by the FA, followed by The Foreign-Home Authentication 1066 extension defined in section 3.5.4 of [RFC3344]. 1068 The Code field of the GNAM is chosen in accordance with the rules 1069 specified in the section 4.2. When replying to an accepted GNM, a MN 1070 SHOULD respond with Code 0. 1072 If the GNM message came from the MN, and if the "A" flag is set in 1073 the GNM message, then the HA MUST send a GNAM message. The message 1074 is as follows: The source address is HA's address, the destination 1075 address is the FA's address, the "MD" value is set to 0. The 1076 ordering of the extension is: any non-authentication Extensions used 1077 only by the MN, followed by the MN-HA AE defined in section 3.5.2. of 1078 [RFC3344], optionly followed by any non-authentication Extensions 1079 used only by the FA, optionly followed by The MN-FA AE defined in 1080 section 3.5.3 of [RFC3344] 1082 5. Future Extensibility 1084 The HA, FA, and MN SHOULD expose a list of the supported 1085 notifications to operators via some management interface, and there 1086 SHOULD be switches to enable / disable individual types of 1087 notifications and to tune the retransmission timers for each type. 1089 There are several applications that could use this GNM. For example, 1090 during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP 1091 resource of CDMA side have to be removed on the FA (PDSN) to avoid 1092 over-charging subscribers, anyway existing Registration Revocation 1093 RFC [RFC3543] is a one way to do this. Other applications such as HA 1094 switch over when HA decide to go offline and would like to scheduled 1095 notify the MN to register to the other candidate HAs , NEMO prefix 1096 changes when MN is notified by HA about NEMO prefix changes , service 1097 or billing related events which is more operational requirement, load 1098 balancing where the HA wants to move some of the registered mobile 1099 nodes to other HAs, service termination due to end of prepaid time, 1100 and service interruption due to system maintenance. 1102 Here we describe some possible event which could use the generic 1103 string extension [RFC4917] based on this notification mechanism. 1105 For now, none of these future semantics are supported and only the 1106 Generic String Extension is supported for informational purposes. 1107 There should be minimum requirements given here for adding additional 1108 extension types to the allowed set and defining their semantics; It 1109 would better follow the way of the specification required. 1111 5.1. Generic String Extension 1113 In some case, the HA or FA needs to notify the mobile node about 1114 service termination due to the end of prepaid time, or service 1115 interruption due to system maintenance. This information could be 1116 defined based on a string [RFC4917] which is recognized by the MN 1117 easily. An example would be "Maintenance Downtime", "Prepaid 1118 Expiration". These string MUST be strictly defined so they could be 1119 easily understood by all of the network entities, and a suitable GNM 1120 Subtype number would have to be allocated. All such definitions are 1121 left for future specifications. 1123 6. IANA Considerations 1125 This document describes two new messages, the GNM in section 4.1 and 1126 the GNAM in section 4.2. These two messages SHOULD be allocated from 1127 the same address space used by the Registration Request and 1128 Registration Reply messages in [RFC3344]. The subtype of these two 1129 messages indicate what kind of information is carried and will be 1130 under assigned by IANA namespace. 1132 This document creates a new IANA registry for the Subtype field in 1133 the GNM and GNAM. New values MUST be allocated by Standards Actions 1134 or IETF Consensus. This document reserves two values for the Subtype 1135 field 1137 0 Reserved 1139 1 Information carried in Generic String Extension 1141 This GNAM message, specified in section section 4.2, has a Code 1142 field. The number space for the Code field values is also specified 1143 in section 4.2. The Code number space is strucutred according to 1144 whether the notification was successful, or whether the HA denied the 1145 notification, or whether FA denied the notification, or whether MN 1146 denied the notification, as follows 1148 0 Success Code 1149 64-69 Error Codes from the FA 1150 128-133 Error Codes from the HA 1151 192-197 Error Codes from the MN 1153 Approval of new Code values require expert review. 1155 7. Security Considerations 1157 This specification operates in the security constraints and 1158 requirements of [RFC3344]. It require that when these message is 1159 transmitted between the MN and the HA, MN-HA AE is mandatory, when 1160 this message is transmitted between the MN and the FA, MN-FA AE is 1161 mandatory, when this message is transmitted between the FA and the 1162 HA, FA-HA AE is mandatory. It extends the operations of MN, HA and 1163 FA defined in [RFC3344] to notify each other about some events. The 1164 GNM message defined in the specification could carry information that 1165 modifies the mobility bindings. Therefore the message MUST be 1166 integrity protected. Replay protection MUST also be guaranteed. 1168 RFC 3344 provides replay protection only for registration requests 1169 sent by the MN. There is no mechanism for replay protection for 1170 messages initiated by a FA or a HA. The 64-bit Identification field 1171 specified in this document (Section 4.1 and 4.2) for the GNM message 1172 is used to provide replay protection for the notification messages 1173 initiated by the FA or HA. 1175 7.1. Replay Protection for GNM, GNAM messages 1177 The Identification field is used to let the receiving node verify 1178 that a GNM has been freshly generated by the sending node, not 1179 replayed by an attacker from some previous registration. Two methods 1180 are described in this section: timestamps (mandatory) and "nonces" 1181 (optional). All senders and receivers MUST implement timestamp-based 1182 replay protection. These nodes MAY also implement nonce-based replay 1183 protection 1185 The style of replay protection in effect between any two peer nodes 1186 among MN, FA and HA is part of the mobile security association. A 1187 sending node and its receiving node MUST agree on which method of 1188 replay protection will be used. The interpretation of the 1189 Identification field depends on the method of replay protection as 1190 described in the subsequent subsections. 1192 Whatever method is used, the low-order 32 bits of the Identification 1193 MUST be copied unchanged from the GNM to the GNMA. The receiver uses 1194 those bits (and the sender's source address) to match GNAM with 1195 corresponding replies. The receiver MUST verify that the low-order 1196 32 bits of any GNAM are identical to the bits it sent in the GNM. 1198 The Identification in a new GNM MUST NOT be the same as in an 1199 immediately preceding GNM, and SHOULD NOT repeat while the same 1200 security context is being used between the MN and the HA. 1202 7.1.1. Replay Protection using Timestamps 1204 The basic principle of timestamp replay protection is that the node 1205 generating a message inserts the current time of day, and the node 1206 receiving the message checks that this timestamp is sufficiently 1207 close to its own time of day. Unless specified differently in the 1208 security association between the nodes, a default value of 7 seconds 1209 MAY be used to limit the time difference. This value SHOULD be 1210 greater than 3 seconds. Obviously the two nodes must have adequately 1211 synchronized time-of-day clocks. As with any messages, time 1212 synchronization messages may be protected against tampering by an 1213 authentication mechanism determined by the security context between 1214 the two nodes. 1216 In this document, the timestamps are used, the sender MUST set the 1217 Identification field to a 64-bit value formatted as specified by the 1218 Network Time Protocol[RFC1305]. The low-order 32 bits of the NTP 1219 format represent fractional seconds . Note, however, that when using 1220 timestamps, the 64-bit Identification used in a GNM message from the 1221 sender MUST be greater than that used in any previous GNM message, as 1222 the receiver uses this field also as a sequence number. Without such 1223 a sequence number, it would be possible for a delayed duplicate of an 1224 earlier GNM message to arrive at the receiver (within the clock 1225 synchronization required by the receiver), and thus be applied out of 1226 order, mistakenly altering the sender's current status. 1228 Upon receipt of a GNM message with an authorization-enabling 1229 extension, the receiver MUST check the Identification field for 1230 validity. In order to be valid, the timestamp contained in the 1231 Identification field MUST be close enough to the receiver's time of 1232 day clock and the timestamp MUST be greater than all previously 1233 accepted timestamps for the requesting sender. Time tolerances and 1234 resynchronization details are specific to a particular mobility 1235 security association. 1237 If the timestamp is valid, the receiver copies the entire 1238 Identification field into the GNAM it returns the GNAM message to the 1239 sender. If the timestamp is not valid, the receiver copies only the 1240 low-order 32 bits into the GNAM, and supplies the high-order 32 bits 1241 from its own time of day. In this latter case, the receiver MUST 1242 reject the registration by returning Code 69/133/197 (identification 1243 mismatch) in the GNAM message. 1245 Furthermore, the receiver MUST verify that the low-order 32 bits of 1246 the Identification in the GNAM are identical to those in the rejected 1247 GNM attempt, before using the high-order bits for clock 1248 resynchronization. 1250 7.1.2. Replay Protection using Nonces 1252 The basic principle of nonce replay protection is that node A 1253 includes a new random number in every message to node B, and checks 1254 that node B returns that same number in its next message to node A. 1255 Both messages use an authentication code to protect against 1256 alteration by an attacker. At the same time node B can send its own 1257 nonces in all messages to node A (to be echoed by node A), so that it 1258 too can verify that it is receiving fresh messages. 1260 The receiver may be expected to have resources for computing pseudo- 1261 random numbers useful as nonces [RFC1750]. It inserts a new nonce as 1262 the high-order 32 bits of the identification field of every GNAM 1263 message. The receiver copies the low-order 32 bits of the 1264 Identification from the GNM message into the low-order 32 bits of the 1265 Identification in the GNAM message. When the sender receives an 1266 authenticated GNAM message from the receiver, it saves the high-order 1267 32 bits of the identification for use as the high-order 32 bits of 1268 its next GNM message. 1270 The sender is responsible for generating the low-order 32 bits of the 1271 Identification in each GNM message. Ideally it should generate its 1272 own random nonces. However it may use any expedient method, 1273 including duplication of the random value sent by the receiver. The 1274 method chosen is of concern only to the sender , because it is the 1275 node that checks for valid values in the GNAM message. The high- 1276 order and low-order 32 bits of the identification chosen SHOULD both 1277 differ from their previous values. The receiver uses a new high- 1278 order value and the sender uses a new low-order value for each 1279 registration message. 1281 If a GNM message is rejected because of an invalid nonce, the GNAM 1282 always provides the sender with a new nonce to be used in the next 1283 registration. Thus the nonce protocol is self- synchronizing. 1285 7.2. Non-authentication Extensions Handling in Foreign Agent 1287 When the FA is relaying the GNM message between the MN and the HA, 1288 and if the FA does not share a mobility security association with the 1289 MN or HA, all non-authentication extensions between MN and FA, or FA 1290 and HA are not protected; In this case, all non-authentication 1291 extensions should be silently discarded. 1293 8. Acknowledgments 1295 The author appreciate the efforts of Ahmad Muhanna for his detail 1296 reviewing of this document and his many contributions to the text of 1297 this document. The author also wants to thank Kent Leung, Peng Yang 1298 and Peter McCann et al. for their helping developing this document. 1299 Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E. 1300 Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu, 1301 Tim Polk, Amanda Baber, and Joseph Salowey's discussion and comments. 1302 Thanks to Jari Arkko for each step of this document. 1304 9. Normative References 1306 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1307 Specification, Implementation", RFC 1305, March 1992. 1309 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1310 Recommendations for Security", RFC 1750, December 1994. 1312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1313 Requirement Levels", BCP 14, RFC 2119, March 1997. 1315 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ 1316 Organization-Specific Extensions", RFC 3115, April 2001. 1318 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1319 August 2002. 1321 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1322 Mobile IPv4", RFC 3543, August 2003. 1324 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 1325 String Extension", RFC 4917, June 2007. 1327 Authors' Addresses 1329 Hui Deng 1330 China Mobile 1331 53A,Xibianmennei Ave., 1332 Xuanwu District, 1333 Beijing 100053 1334 China 1336 Email: denghui02@gmail.com 1338 Henrik Levkowetz 1339 Ericsson Research 1340 Torshamsgatan 23 1341 S-164 80, Stockholm 1342 SWEDEN 1344 Email: henrik@levkowetz.com 1346 Vijay Devarapalli 1347 WiChorus 1348 3590 North First St 1349 San Jose, CA 1350 USA 1352 Email: dvijay@gmail.com 1354 Sri Gundavelli 1355 Cisco Systems 1356 170 W.Tasman Drive 1357 San Jose, CA 95134 1358 USA 1360 Email: sgundave@cisco.com 1362 Brian Haley 1363 Hewlett-Packard Company 1364 110 Spitbrook Road 1365 Nashua, NH 03062 1366 USA 1368 Email: brian.haley@hp.com