idnits 2.17.1 draft-ietf-mip4-generic-notification-message-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2009) is 5342 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) ** 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 (~~), 1 warning (==), 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: March 14, 2010 Ericsson Research 6 V. Devarapalli 7 WiChorus 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 September 10, 2009 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-12.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on March 14, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 This document specifies protocol enhancements that allow Mobile IPv4 64 entities to send and receive explicit notification messages using a 65 new Mobile IPv4 message type designed for this purpose. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Notification message - Usage Scenario's . . . . . . . . . . . 7 72 3.1. Notification message between a Home Agent and a Mobile 73 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1.1. Mobile Registered using a Foreign Agent Care-of 75 Address . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.1.2. Mobile Registered using a Co-located Care-of 77 Address . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.2. Notification message between a Foreign Agent and a 79 Mobile Node . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Notification message between a Home Agent and a 81 Foreign Agent . . . . . . . . . . . . . . . . . . . . . . 8 82 4. Generic Notification Message and Considerations . . . . . . . 9 83 4.1. Generic Notification Message . . . . . . . . . . . . . . . 9 84 4.2. Generic Notification Acknowledgment Message . . . . . . . 12 85 4.3. Notification Retransmision . . . . . . . . . . . . . . . . 16 86 4.4. Mobile Node Consideration . . . . . . . . . . . . . . . . 16 87 4.4.1. Receiving Generic Notification Messages . . . . . . . 16 88 4.4.2. Sending Generic Notification Acknowledgement 89 Message . . . . . . . . . . . . . . . . . . . . . . . 17 90 4.4.3. Sending Generic Notification Messages . . . . . . . . 18 91 4.4.4. Receiving Generic Notification Acknowledgement 92 Messages . . . . . . . . . . . . . . . . . . . . . . . 19 93 4.5. Foreign Agent Consideration . . . . . . . . . . . . . . . 20 94 4.5.1. Receiving Generic Notification Message . . . . . . . . 20 95 4.5.2. Sending Generic Notification Acknowledgement 96 Messages . . . . . . . . . . . . . . . . . . . . . . . 22 97 4.5.3. Sending Generic Notification Messages . . . . . . . . 22 98 4.5.4. Receiving Generic Notification Acknowledgement 99 Messages . . . . . . . . . . . . . . . . . . . . . . . 23 100 4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 24 101 4.6.1. Sending Generic Notification Messages . . . . . . . . 24 102 4.6.2. Receiving Generic Notification Acknowledgement 103 Messages . . . . . . . . . . . . . . . . . . . . . . . 25 104 4.6.3. Receiving Generic Notification Messages . . . . . . . 25 105 4.6.4. Sending Generic Notification Acknowledgement 106 Messages . . . . . . . . . . . . . . . . . . . . . . . 26 107 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 28 108 5.1. Generic String Extension . . . . . . . . . . . . . . . . . 28 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 110 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 111 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 112 8.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 31 113 8.1.1. Replay Protection using Timestamps . . . . . . . . . . 32 114 8.1.2. Replay Protection using Nonces . . . . . . . . . . . . 33 115 8.2. Non-authentication Extensions Handling in Foreign Agent . 33 116 9. Normative References . . . . . . . . . . . . . . . . . . . . . 34 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 119 1. Introduction 121 In some situations, there is a need for Mobile IPv4 entities, such as 122 the home agent(HA), foreign agent(FA) and mobile node(MN) to send and 123 receive asynchronous notification messages during a mobility session. 124 The base Mobile IP Specification [RFC3344] does not have a provision 125 for this. 127 This document defines a generic message and a notification model that 128 can be used by Mobile IPv4 entities to send various notifications. 129 However, this specification does not define any specific notification 130 message or the actions that the receiving entity is required to 131 perform on receiving that message. Specific extensions and the 132 corresponding handler actions are outside the scope of this document. 134 This document recommends that the HA, FA, and MN should expose a list 135 of the supported notifications be accessible to operators via some 136 management interface, that there would be switches to enable / 137 disable notifications, and the capability to tune timers of 138 retransmission. 140 2. Terminology 142 It is assumed that the reader is familiar with the terminology used 143 in [RFC4917], [RFC3344]. In addition, the following terms are 144 defined: 146 Notification Message 148 A message from a mobility agent to a MN or other mobility agent to 149 asynchronously notify it about an event that is relevant to the 150 mobility service it is currently providing. 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119, [RFC2119]. 156 3. Notification message - Usage Scenario's 158 There are several scenarios where a mobility agent could initiate 159 notification events. Some of these are described in the following 160 sections. 162 3.1. Notification message between a Home Agent and a Mobile Node 164 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 166 In this case, the HA cannot directly notify the MN, but must send the 167 notification via the FA, vice versa. 169 +----+ notification +----+ notification +----+ 170 | MN |<================>| FA |<=============>| HA | 171 +----+ +----+ +----+ 173 Figure 1: HA notifies MN or MN notifies HA through FA 175 3.1.2. Mobile Registered using a Co-located Care-of Address 177 In this case, the MN has registered with the home agent directly, so 178 the notification message can go directly to the MN. 180 The notification mechanism as specified here does not support the 181 case of Co-located CoA mode with registration through a FA (due to 182 the 'R' bit being set in the FA's advertisement messages). 184 +----+ notification +----+ 185 | MN |<===================================>| HA | 186 +----+ +----+ 188 Figure 2: HA directly notifies MN or MN directly notifies HA 190 3.2. Notification message between a Foreign Agent and a Mobile Node 192 There are two cases where a FA may send notification messages to a 193 MN, one where it is relaying a message, the other where the 194 notification is triggered by a message from another network entity, 195 for example a AAA node(notification messages between a AAA entity and 196 the FA could be based on RADIUS or Diameter, but this is out of scope 197 for this document). If the notification is initiated by a FA, the FA 198 may need to also notify the HA about the event. 200 +----+ notification +----+ trigger +--------+ 201 | MN |<================>| FA |<=============| AAA | 202 +----+ +----+ +--------+ 203 || notification +----+ 204 ================>| HA | 205 +----+ 207 Figure 3: FA notifies MN 209 3.3. Notification message between a Home Agent and a Foreign Agent 211 The HA may also need to send a notification to the FA, but not to the 212 MN, The FA may also need to send a notification to the HA, as 213 illustrated below: 215 +----+ notification +----+ 216 | FA |<=============>| HA | 217 +----+ +----+ 219 Figure 4: HA notifies FA or FA notifies HA 221 4. Generic Notification Message and Considerations 223 This section describes in detail the Generic Notification Message 224 (GNM), Generic Notification Acknowledgement Message (GNAM), and some 225 considerations related to the handling of these messages in the MN, 226 FA and HA. 228 The MN and HA MUST maintain the following information, FA also needs 229 to maintain both the HA's and MN's direction the below information: 231 - the IP source address of the Registration Request/Reply 233 - the IP destination address of the Registration Request/Reply 235 - the UDP source port of the Registration Request/Reply 237 - the UDP destination port of the Registration Request/Reply 239 The sending node always sends the GNM message following the same 240 procedure for sending Registration Request as in section 3.3 of 241 [RFC3344] and the receiving node follows the same procedure for 242 Registration Reply as in section 3.4. of [RFC3344] when sending GNAM. 244 4.1. Generic Notification Message 246 A GNM is sent by a mobility agent to inform another mobility agent, 247 or a MN, of MIP-related information such as vendor specific 248 extensions[RFC3115] and generic string notification[RFC4917]. These 249 messages MUST use the same IP and UDP headers as any previous 250 Registration Request(RRQ) or Reply (RRP) message to the same entity. 251 This would support NAT traversal and ensure same security association 252 used for GNM/GNAM and RRQ/RRP. The GNM is defined as follows: 254 IP Fields: 256 Source Address Copied from the source address field of the 257 last Registration Reply/Request message 258 sent. 260 Destination Address Copied from the source address field of the 261 last Registration Reply/Request message 262 sent. 264 UDP Fields: 266 Source Port Copied from the source address field of the 267 last Registration Reply/Request message 268 sent. 270 Destination Port Copied from the source address field of the 271 last Registration Reply/Request message 272 sent. 274 The UDP header is followed by the Mobile IP fields shown below: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Subtype | MD |A| Reserved | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Home Address | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Home Agent Address | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Care-of Address | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 + Identification + 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Extensions... 292 +-+-+-+-+-+-+-+-+-+-+-+-+- 294 Type (To be assigned by IANA) 296 Subtype 298 This field describes the particular type of notification which is 299 carried in the notification message. The following values are 300 reserved in this document. 302 0 Reserved 304 1 Information carried in Vendor specific extensions which is 305 specified in [RFC3115]. 307 2 Information carried in Generic String extensions which is 308 specified in [RFC4917]. 310 The value 0 is reserved and SHOULD NOT be used. The value 1 311 indicates that the actual information is carried in vendor 312 specific extensions. Vendor/Org-ID and Vendor-CVSE-T defined in 313 vendor specific extensions could help to identify itself, if the 314 receiver don't understand this, this extensions could be just 315 silently discarded. The value 2 indicates that the actual 316 information is carried in generic string extensions. Other values 317 are reserved for future extensions. 319 MD: Message Direction 321 This memo defines the semantics of the following MD field value: 323 0 -- Message sent by the HA to the MN 325 1 -- Message sent by the HA to the FA 327 2 -- Message sent by the MN to the HA 329 3 -- Message sent by the MN to the FA 331 4 -- Message sent by the FA to the MN 333 5 -- Message sent by the FA to the HA 335 A 337 This bit indicates whether the notification message MUST be 338 acknowledged by the recipient. If "A" bit has been set during the 339 message, but the sender doesn't receive any acknowledgement 340 message, then the sender will have to resend the notification 341 message again. 343 Set to "1" to indicate that acknowledgement is required. 345 Set to "0" to indicate that acknowledgement is optional. 347 Reserved 349 MUST be sent as 0, and ignored when received. 351 Home Address 353 The home IP address of the mobile node. 355 Home Agent Address 357 The IP address of the mobile node's HA. 359 Care-of Address 360 The mobile node's care-of address, either the Co-located Care-of 361 Address or the foreign agent care-of address. 363 Identification 365 A 64-bit number, constructed by the sender, used for matching GNM 366 with GNAM, and for protecting against replay attacks of 367 notification messages. See Sections 8.1.1 and 8.1.2. Timestamps 368 is mandatory and nonces is optional. 370 Extensions 372 The fixed portion of the GNM is followed by one or more extensions 373 which may be used with this message, and by one or more 374 authentication extensions (as defined in Section 3.5 of [RFC3344]. 375 This document mandates the MN-HA Authentication Extension (AE) 376 when this message is sent between the MN and the HA, MN-FA AE and 377 FA-HA AE are optional. This document also mandate the MN-FA AE 378 when this message is sent between the MN and the FA, MN-HA AE and 379 FA-HA AE are not needed. This document mandate the FA-HA AE when 380 this message is sent between the FA and the HA, MN-HA AE and MN-FA 381 AE are not needed. This could be judged based on "MD" value.). 382 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 383 order of these extensions as they appear in Mobile IPv4 RRQ and 384 RRP messages. The same rules are applicable to GNM and GNAM. 386 4.2. Generic Notification Acknowledgment Message 388 A GNAM is sent by mobility agents or MNs to indicate the successful 389 receipt of a GNM. 391 IP Fields: 393 Source Address Typically copied from the destination 394 address of the GNM to which the agent is 395 replying. 397 Destination Address Copied from the source address of the GNM to 398 which the agent is replying. 400 UDP Fields: 402 Source Port Copied from the destination port of the 403 corresponding GNM. 405 Destination Port Copied from the source port of the 406 corresponding GNM. 408 The UDP header is followed by the Mobile IP fields shown below: 410 0 1 2 3 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Subtype | MD | code | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Home Address | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Home Agent Address | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Care-of Address | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 + Identification + 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Extensions... 426 +-+-+-+-+-+-+-+-+-+-+-+-+- 428 Type (To be assgined by IANA) 430 Subtype 432 This field specifies the particular type of notification 433 acknowledgement message. The following values are reserved in 434 this document. 436 0 Reserved 438 1 Information carried in Vendor specific extensions which is 439 specified in [RFC3115]. 441 2 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 vendor 446 specific extensions. Other values are reserved for future 447 extensions. 449 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 460 4 -- Message sent by the FA to the MN 462 5 -- Message sent by the FA to the HA 464 code 466 A value indicating the result of the GNM. See below for a list of 467 currently defined Code values. 469 Notification suceessful 471 0 -- notification accepted 473 Notification denied by the HA 475 128 -- reason unspecified 477 129 -- administratively prohibited 479 130 -- insufficient resources 481 131 -- mobile node failed authentication 483 132 -- foreign agent failed authentication 485 133 -- notification Identification mismatch 487 Notification denied by the FA 489 64 -- reason unspecified 491 65 -- administratively prohibited 493 66 -- insufficient resources 495 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 506 194 -- insufficient resources 508 195 -- foreign agent failed authentication 510 196 -- home agent failed authentication 512 197 -- notification Identification mismatch 514 Home Address 516 The home IP address of the mobile node. 518 Home Agent Address 520 The IP address of the sender's home agent. 522 Care-of Address 524 The mobile node's care-of address, either the Co-located Care-of 525 Address or the foreign agent care-of address. 527 Identification 529 A 64-bit number used for matching GNM message with GNAM mesage and 530 for protecting against replay attacks of registration messages. 531 See Sections 8.1.1 and 8.1.2. Timestamps is mandatory and nonces 532 is optional. The value is based on the Identification field from 533 the GNM message from the sender, and on the style of replay 534 protection used in the security context between the sender and its 535 receiver (defined by the mobility security association between 536 them, and SPI value in the authorization-enabling extension). 538 Extensions 540 The fixed portion of the GNAM is followed by one or more 541 extensions which may be used with this message, and by one or more 542 authentication extensions (as defined in Section 3.5 of [RFC3344]. 543 This document mandates the MN-HA Authentication Extension (AE) 544 when this message is sent between the MN and the HA, MN-FA AE and 545 FA-HA AE are optional. This document also mandate the MN-FA AE 546 when this message is sent between the MN and the FA, MN-HA AE and 547 FA-HA AE are not needed. This document mandate the FA-HA AE when 548 this message is sent between the FA and the HA, MN-HA AE and MN-FA 549 AE are not needed. This could be judged based on "MD" value.). 550 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 551 order of these extensions as they appear in Mobile IPv4 RRQ and 552 RRP messages. The same rules are applicable to GNM and GNAM. 554 4.3. Notification Retransmision 556 If "A" flag has been set during the GNM message, but the sender 557 doesn't receive any GNAM message within a reasonable time, then 558 another GNM will be retransmited. When timestamps are used, a new 559 registration Identification is chosen for each retransmision; Thus it 560 counts as a new GNM. When nonces are used, the unanswered GNM 561 message is retransmitted unchanged; thus the retransmission does not 562 count as a new GNM (Section 8.1). In this way a retransmission will 563 not require the receiver to resynchronize with the sender by issuing 564 another nonce in the case in which the original GNM message (rather 565 than its GNAM message) was lost by the network. 567 The maximum time until a new GNM message is sent SHOULD be no greater 568 than the requested Lifetime of the last GNM message. The minimum 569 value SHOULD be large enough to account for the size of the messages, 570 twice the round trip time for transmission to the receiver, and at 571 least an additional 100 milliseconds to allow for processing the 572 messages before responding. The round trip time for transmission to 573 the receiver will be at least as large as the time required to 574 transmit the messages at the link speed of the sender's current point 575 of attachment. Some circuits add another 200 milliseconds of 576 satellite delay in the total round trip time to the receiver. The 577 minimum time between GNM MUST NOT be less than 1 second. Each 578 successive retransmission timeout period SHOULD be at least twice the 579 previous period, as long as that is less than the maximum as 580 specified above. 582 4.4. Mobile Node Consideration 584 It is possible that the MN MAY receive a GNM from a FA or HA. Both 585 in the case of FA-CoA and Co-located CoA, the MN MAY reply with a 586 GNAM based on the "A" flag in the GNM message. 588 4.4.1. Receiving Generic Notification Messages 590 When the MN is using FA-CoA and receives a Notification message, if 591 the "MD" value is 0, it means that the notification message came from 592 the HA. If the "MD" value is 4, the notification came from the FA. 594 If this notification message came from a FA and the MN accepts the 595 FA's GNM, then it will process the notification extension according 596 to the specific rules for that extension. 598 The MN MUST check for the presence of an authorization-enabling 599 extension, and perform the indicated authentication. Exactly one 600 authorization-enabling extension MUST be present in the GNM, if this 601 message came from a FA, then MN-FA AE MUST be present. If no MN-FA 602 AE is found, or if more than one MN-FA AE is found, or if the 603 Authenticator is invalid, then the MN MUST reject the GNM and MAY 604 send a GNAM to the FA with Code 195, including an Identification 605 field computed in accordance with the rules specified in Section 8.1. 606 The MN MUST do no further processing with such a notification, though 607 it SHOULD log the error as a security exception. 609 The MN MUST check that the Identification field is correct using the 610 context selected by the SPI within mandatory authentication extension 611 like MN-FA AE or MN-HA AE. See Section 8.1 for a description of how 612 this is performed. If incorrect, the MN MUST reject the GNM and MAY 613 send a GNAM to the initiator with Code 197, including an 614 Identification field computed in accordance with the rules specified 615 in Section 8.1. The MN MUST do no further processing with such a 616 notification, though it SHOULD log the error as a security exception. 618 After that, the MN MAY reply GNAM back to the FA. If the "A" flag is 619 set in the GNM, then the MN MUST send the GNAM. 621 If this notification message came from the HA, relayed by the FA, or 622 is a Co-located CoA, then the MN-HA AE MUST be checked and the MN 623 MUST check the Authenticator value in the Extension. If no MN-HA AE 624 is found, or if more than one MN-HA AE is found, or if the 625 Authenticator is invalid, then the MN MUST reject the GNM and MAY 626 send a GNAM to the initiator with Code 196, including an 627 Identification field computed in accordance with the rules specified 628 in Section 8.1. The MN MUST do no further processing with such a 629 notification, though it SHOULD log the error as a security exception. 630 If the MN accepts the HA's GNM, then it will process it according to 631 the specific rules for that extension. After that, the MN MAY reply 632 with a GNAM with Code 0 back to the HA based on the "A" flag in the 633 GNM. 635 4.4.2. Sending Generic Notification Acknowledgement Message 637 Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply 638 with a GNAM based on the "A" flag in the GNM as follows: 640 If the GNM was initiated from the FA to the MN ("MD" value is set to 641 4), then MN-FA AE MUST be the last extension in order to protect all 642 other non-authentication extensions as defined in section 3.5.3 of 643 [RFC3344]. 645 In the case of a FA-CoA, the source address is the MN's address, the 646 destination address is the FA's address. 648 The Code field of the GNAM is chosen in accordance with the rules 649 specified in the section 4.2. When replying to an accepted 650 notification, a MN SHOULD respond with Code 0. 652 There are a number of reasons the MN might reject a notification such 653 as administrative in nature returning a GNAM with a code of 193, 654 similarly and provides the Code value 192 or 194 for the unspecified 655 reason and insufficient resources. 657 If the GNM was initiated from the HA to the MN ("MD" value is set to 658 0) and in the case of Co-located CoA, then MN-HA AE MUST be the last 659 extension in order to protect all other non-authentication extensions 660 as defined in section 3.5.2 of [RFC3344] 662 In the case of a FA-CoA, the source address is the MN's HoA address 663 and the destination address is the FA's address ("MD" value is set to 664 2), the ordering of the extension is: any non-authentication 665 Extensions used only by the HA, followed by the MN-HA AE defined in 666 section 3.5.2. of [RFC3344], followed by any non-authentication 667 Extensions used only by the FA, followed by the MN-FA AE defined in 668 section 3.5.3 of [RFC3344]. 670 4.4.3. Sending Generic Notification Messages 672 The MN may either send a GNM to notify the FA or HA. 674 If the message is sent to the FA, then the source address is the MN's 675 address, and the destination address is the FA's address 677 If the FA is the target of this notification message, then the "MD" 678 value is set to 3, MN-FA AE MUST be the last extension in order to 679 protect all other non-authentication extensions. Computing 680 Authentication Extension Value is the same as section 3.5.1 of 681 [RFC3344]. 683 If the FA is working only as a relay agent, then the "MD" value is 684 set to 2, and the ordering of the extension is: the notification 685 extension, followed by any non-authentication extension expected to 686 be used by HA, followed by MN-HA AE defined in section 3.5.2. of 687 [RFC3344], followed by any non-authentication Extensions used only by 688 the FA, followed by The MN-FA AE defined in section 3.5.3 of 689 [RFC3344]. Computing Authentication Extension Value is the same as 690 section 3.5.1 of [RFC3344]. 692 In the case of a Co-located CoA, the MN MAY send a notification 693 message directly to the HA if it needs to be notified. The "MD" 694 value is set to 2, and the ordering of the extension is: the 695 notification extension, followed by any non-authentication extension 696 expected to be used by HA, followed by MN-HA AE defined in section 697 3.5.2 of [RFC3344]. 699 The MN chooses the Identification field in accordance with the style 700 of replay protection it uses with its HA. This is part of the 701 mobility security association the MN shares with its HA. See Section 702 8.1 for the method by which the MN computes the Identification field. 704 4.4.4. Receiving Generic Notification Acknowledgement Messages 706 In the case of a FA-CoA, if the MN receives this message, and the 707 "MD" value is set to 0, it means that the GNAM came from HA 709 If the "MD" value is set to 4, then the MN-FA AE MUST be checked, and 710 the MN MUST check the Authenticator value in the Extension. If no 711 MN-FA AE is found, or if more than one MN-FA AE is found, or if the 712 Authenticator is invalid, then the MN MUST silently discard the GNAM. 714 In addition, the low-order 32 bits of the Identification field in the 715 GNAM MUST be compared to the low-order 32 bits of the Identification 716 field in the most recent GNM sent to the replying agent. If they do 717 not match, then the GNAM MUST be silently discarded. 719 If the "MD" value is set to 0, then the MN-HA AE MUST be checked, and 720 the MN MUST check the Authenticator value in the Extension. If no 721 MN-HA AE is found, or if more than one MN-HA AE is found, or if the 722 Authenticator is invalid, then the MN MUST silently discard the GNAM. 723 If the MN accepted this message, then the MN MAY also process it 724 based on the notification event. 726 In the case of a Co-located CoA, if the MN received this message, 727 then the MN-HA AE MUST be checked, and the MN MUST check the 728 Authenticator value in the Extension. If no MN-HA AE is found, or if 729 more than one MN-HA AE is found, or if the Authenticator is invalid, 730 then the MN MUST silently discard the Notification Acknowledgement 731 message. 733 4.5. Foreign Agent Consideration 735 The FA may initiate a GNM to the MN or the HA. Additionally, the FA 736 also relays GNM and GNAM messages between the MN and its HA as long 737 as there is an active binding for the MN at the FA. 739 4.5.1. Receiving Generic Notification Message 741 If the FA receives a GNM, and the "MD" value is set to 0, then it 742 means that the HA is asking the FA to relay the message to the MN. 743 If the "MD" value is set to 1, then it means that the target of the 744 notification is the FA. If the "MD" value is set to 2, then it means 745 that the MN is asking the FA to relay the message to the HA. If the 746 "MD" value is set to 3, then it means that the notification came from 747 the MN to the FA. 749 If the "MD" value is set to 0, then the FA MAY validate the FA-HA AE 750 if present. If the FA-HA AE is invalid, then all extensions between 751 the HA-MN AE and the HA-FA AE MUST be removed, FA SHOULD relay the 752 GNM to the MN's home address as specified in the Home Address field 753 of the GNM, MN will eventually validate the MN-HA AE to ensure that 754 all information sent to the MN is integrity protected. If the FA-HA 755 AE is valid, FA MUST relay the GNM to the MN's home address as 756 specified in the Home Address field of the GNM. The FA MUST NOT 757 modify any of the fields beginning with the fixed portion of the GNM 758 through the MN-HA AE or other authentication extension supplied by 759 the HA as an authorization-enabling extension for the MN. 761 Furthermore, the FA MUST process and remove any extensions following 762 the MN-HA AE. If the FA shares a mobility security association with 763 the MN, the FA MAY append any of its own non-authentication 764 extensions which of relevance to the MN. In this case, the FA MUST 765 append the MN-FA AE after these non-authentication extensions. 767 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 768 FA MUST check the Authenticator value in the Extension. If no FA-HA 769 AE is found, or if more than one FA-HA AE is found, or if the 770 Authenticator is invalid, the FA MUST reject the GNM and MAY send a 771 GNAM to the HA with Code 68, including an Identification field 772 computed in accordance with the rules specified in Section 8.1. The 773 FA MUST do no further processing with such a notification, though it 774 SHOULD log the error as a security exception. 776 The FA MUST check that the Identification field is correct using the 777 context selected by the SPI within mandatory FA-HA AE. See Section 778 8.1 for a description of how this is performed. If incorrect, the FA 779 MUST reject the GNM and MAY send a GNAM to the initiator with Code 780 69, including an Identification field computed in accordance with the 781 rules specified in Section 8.1. The FA MUST do no further processing 782 with such a notification, though it SHOULD log the error as a 783 security exception. 785 If FA accepts the HA's GNM, it will process it based on the specific 786 rules for that extension. The FA MAY then reply with a GNAM with 787 Code 0 back to the MN based on the "A" flag in the GNM. 789 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 790 received this message, and if the MN-FA AE is present, the MN-FA AE 791 MUST be checked, and the FA MUST check the Authenticator value in the 792 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 793 found, or if the Authenticator is invalid, the FA MUST silently 794 discard the GNM message. If MN-FA is valid, FA MUST relay the GNM to 795 the HA's address as specified in the Home Agent Address field of the 796 GNM, HA will eventually validate the MN-HA AE to ensure that all 797 information sent to the HA is integrity protected. The FA MUST NOT 798 modify any of the fields beginning with the fixed portion of the GNM 799 through the MN-HA AE or other authentication extension supplied by 800 the MN as an authorization-enabling extension for the HA. 802 Furthermore, the FA MUST process and remove any Extensions following 803 the MN-HA AE, and MAY append any of its own non-authentication 804 Extensions of relevance to the HA if applicable, and MUST append the 805 FA-HA AE, if the FA shares a mobility security association with the 806 HA. 808 If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the 809 FA MUST check the Authenticator value in the Extension which is the 810 same as the section 3.7.2.1 of RFC 3344. If no MN-FA AE is found, or 811 if more than one MN-FA AE is found, or if the Authenticator is 812 invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN 813 with Code 67, including an Identification field computed in 814 accordance with the rules specified in Section 8.1. The FA MUST do 815 no further processing with such a notification, though it SHOULD log 816 the error as a security exception. 818 The FA MUST check that the Identification field is correct using the 819 context selected by the SPI within mandatory MN-FA AE. See Section 820 8.1 for a description of how this is performed. If incorrect, the FA 821 MUST reject the GNM and MAY send a GNAM to the initiator with Code 822 69, including an Identification field computed in accordance with the 823 rules specified in Section 8.1. The FA MUST do no further processing 824 with such a notification, though it SHOULD log the error as a 825 security exception. 827 If FA accepts the MN's GNM, it will process it based on the specific 828 rules for that extension. The FA MAY then reply with a GNAM with 829 Code 0 back to the MN based on the "A" flag in the GNM. 831 4.5.2. Sending Generic Notification Acknowledgement Messages 833 The FA may need to either relay a GNAM message between the MN and the 834 HA or send one as a response to a GNM messsage that was sent to it. 835 In both cases, the GNAM message is defined as follows: 837 The source address is the FA address, the destination address is HA's 838 or MN's home address. 840 The Code field of the GNAM is chosen in accordance with the rules 841 specified in the section 4.2. When replying to an accepted 842 notification, a FA SHOULD respond with Code 0. 844 There are a number of reasons the FA might reject a notification such 845 as administrative in nature returning a GNAM with a code of 65, 846 similarly and provides the Code value 64 or 66 for the unspecified 847 reason and insufficient resources. 849 If the FA is only relaying this message to the HA, the FA MUST NOT 850 modify any of the fields beginning with the fixed portion of the GNAM 851 through the including the MN-HA AE or other authentication extension 852 supplied by the MN as an authorization-enabling extension for the MN. 853 Furthermore, the foreign agent MUST process and remove any Extensions 854 following the MN-HA AE. If the FA shares a mobility security 855 association with the HA, the FA MAY append any of its own non- 856 authentication extensions which of relevance to the HA, In this case 857 the FA MUST append the FA-HA AE after these non-authentication 858 extensions. 860 If the notification message is from the HA to the FA then the "MD" 861 value is set to 5 and the ordering of the extension is: any non- 862 authentication Extensions used only by the FA, followed by The FA-HA 863 AE defined in section 3.5.4 of [RFC3344]. 865 If the notification message is from the MN to the FA then the "MD" 866 value is set to 4 and the ordering of the extension is: any non- 867 authentication Extensions used only by the FA, followed by The MN-FA 868 AE defined in section 3.5.3 of [RFC3344]. 870 4.5.3. Sending Generic Notification Messages 872 If the FA is initiating a notification to the MN using the GNM, it 873 MAY also notify the HA as well. 875 In the message to the MN, the source address is the FA address, the 876 destination address is the MN's address, the "MD" value is set to 4, 877 and the ordering of the extension is: the notification extension, 878 followed by any non-authentication Extensions used only by the MN, 879 followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 880 Computing Authentication Extension Value is the same as section 3.5.1 881 of [RFC3344] except the payload is the notification other than 882 registration. 884 In the message to the HA, the source address is the FA's address, the 885 destination address is the HA's address (the "MD" value is set to 5), 886 and the ordering of the extension is: notification extension, 887 followed by any non-authentication Extensions used only by the HA, 888 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 889 Computing Authentication Extension Value is the same as section 3.5.1 890 of [RFC3344] except the payload is the notification other than 891 registration. 893 4.5.4. Receiving Generic Notification Acknowledgement Messages 895 In the case of a FA-CoA, if the FA receives this message, and the 896 "MD" value is set to 3, it means that the notification 897 acknowledgement message came from the MN, otherwise it came from the 898 HA. 900 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 901 FA MUST check the Authenticator value in the Extension. If no FA-HA 902 AE is found, or if more than one FA-HA AE is found, or if the 903 Authenticator is invalid, the FA MUST silently discard the 904 Notification Acknowledgement message. If the FA accepted this 905 message, the FA MAY also process it based on the notification event. 907 If the "MD" value is set to 3, if the MN-FA AE is present, it MUST be 908 checked, and the FA MUST check the Authenticator value in the 909 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 910 found, or if the Authenticator is invalid, the FA MUST silently 911 discard the GNAM message. If the FA accepted this message, the FA 912 MAY also process it based on the notification event. 914 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 915 received this message, and if the MN-FA AE is present, the MN-FA AE 916 MUST be checked, and the FA MUST check the Authenticator value in the 917 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 918 found, or if the Authenticator is invalid, the FA MUST silently 919 discard the GNAM message. If FA accepted the MN's GNAM message, it 920 MUST relay this message to the HA. The FA MUST NOT modify any of the 921 fields beginning with the fixed portion of the GNAM message through 922 the including the MN-HA AE or other authentication extension supplied 923 by the HA as an authorization-enabling extension for the MN. 924 Furthermore, the FA MUST process and remove any Extensions following 925 the MN-HA AE and MAY append any of its own non-authentication 926 Extensions of relevance to the HA, if applicable, and MUST append the 927 FA-HA AE, if the FA shares a mobility security association with the 928 HA. 930 4.6. Home Agent Consideration 932 The HA MAY initiate a GNM message to both the mobile node and FA, and 933 it also MAY receive a GNAM message from both the FA and MN. The HA 934 also MAY receive a GNM message from the FA, but only when there is a 935 binding for a MN. If the HA receives a GNM from a FA and there is no 936 corresponding MN registration, the HA SHOULD drop the GNM message. 938 4.6.1. Sending Generic Notification Messages 940 In the case of a FA-CoA, the HA may either send a GNM to notify the 941 FA, or have the FA relay the GNM to the MN if the MN needs to be 942 notified. 944 If the message is from the HA to the FA, the source address is the 945 HA's address, and the destination address is the FA's address 947 If the FA is working only as a relay agent, the "MD" value is set to 948 0, and the ordering of the extension is: the notification extension, 949 followed by any non-authentication extension expected to be used by 950 MN, followed by MN-HA AE defined in section 3.5.2. of [RFC3344], 951 followed by any non-authentication Extensions used only by the FA, 952 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 953 Computing Authentication Extension Value is the same as section 3.5.1 954 of [RFC3344]. 956 If the FA is the target of this notification message, then the "MD" 957 value is set to 1, and the ordering of the extension is: the 958 notification extension, followed by any non-authentication Extensions 959 used only by the FA, followed by The FA-HA AE defined in section 960 3.5.4 of [RFC3344]. Computing Authentication Extension Value is the 961 same as section 3.5.1 of [RFC3344]. 963 In the case of a Co-located CoA, the HA MAY send a notification 964 message directly to the MN if it needs to be notified. The "MD" 965 value is set to 0, and the ordering of the extension is: the 966 notification extension, followed by any non-authentication extension 967 expected to be used by MN, followed by MN-HA AE defined in section 968 3.5.2. of [RFC3344]. 970 4.6.2. Receiving Generic Notification Acknowledgement Messages 972 In the case of a FA-CoA, if the HA receives this message, and the 973 "MD" value is set to 2, it means that the GNAM message came from MN. 975 If the "MD" value is set to 5, and the HA accepted this message, the 976 HA MAY also process it based on the notification event. The FA-HA AE 977 MUST be checked, and the HA MUST check the Authenticator value in the 978 Extension. If no FA-HA AE is found, or if more than one FA-HA AE is 979 found, or if the Authenticator is invalid, the HA MUST silently 980 discard the GNAM message. 982 If the "MD" value is set to 2, in the case of a FA-CoA, and if FA-HA 983 AE is present, the FA-HA AE MUST be checked, and the HA MUST check 984 the Authenticator value in the Extension. If more than one FA-HA AE 985 is found, or if the Authenticator is invalid, the HA MUST silently 986 discard the GNAM message. Anyway, MN-HA AE MUST be checked, and the 987 HA MUST check the Authenticator value in the Extension. If no MN-HA 988 AE is found, or if more than one MN-HA AE is found, or if the 989 Authenticator is invalid, the HA MUST silently discard the GNAM. If 990 the HA accepted this message, the HA MAY also process it based on the 991 notification event. 993 If the "MD" value is set to 2, in the case of a Co-located CoA, MN-HA 994 AE MUST be checked, and the HA MUST check the Authenticator value in 995 the Extension. If no MN-HA AE is found, or if more than one MN-HA AE 996 is found, or if the Authenticator is invalid, the HA MUST silently 997 discard the GNAM. If the HA accepted this message, the HA MAY also 998 process it based on the notification event. 1000 4.6.3. Receiving Generic Notification Messages 1002 The HA MAY receive a GNM message sent from the FA. When the HA 1003 receives this message, if the the "MD" value is set to 5, this 1004 message came from FA. FA-HA AE MUST be checked, and the HA MUST 1005 check the Authenticator value in the Extension. If no FA-HA AE is 1006 found, or if more than one FA-HA AE is found, or if the Authenticator 1007 is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA 1008 with Code 132, including an Identification field computed in 1009 accordance with the rules specified in Section 8.1. The HA MUST do 1010 no further processing with such a notification, though it SHOULD log 1011 the error as a security exception. 1013 The HA MUST check that the Identification field is correct using the 1014 context selected by the SPI within mandatory authentication extension 1015 like MN-HA AE or FA-HA AE. See Section 8.1 for a description of how 1016 this is performed. If incorrect, the HA MUST reject the GNM and MAY 1017 send a GNAM to the initiator with Code 133, including an 1018 Identification field computed in accordance with the rules specified 1019 in Section 8.1. The HA MUST do no further processing with such a 1020 notification, though it SHOULD log the error as a security exception. 1021 If HA accepts the FA's GNM message, it will process it based on the 1022 notification extension. Furthermore, the HA MAY reply with a GNAM 1023 message with Code 0 back to the FA based on the "A" flag in the GNM 1024 message. 1026 If the the "MD" value is set to 2, this message come from MN, in the 1027 case of FA-COA, if FA-HA AE is present, it MUST be checked, and the 1028 HA MUST check the Authenticator value in the Extension. If more than 1029 one FA-HA AE Extension is found, or if the Authenticator is invalid, 1030 the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 1031 132, including an Identification field computed in accordance with 1032 the rules specified in Section 8.1. The HA MUST do no further 1033 processing with such a notification, though it SHOULD log the error 1034 as a security exception. And MN-HA AE MUST be checked, and the HA 1035 MUST check the Authenticator value in the Extension. If no MN-HA AE 1036 is found, or if more than one MN-HA AE is found, or if the 1037 Authenticator is invalid, the HA MUST reject the GNM and MAY send a 1038 GNAM to the MN with Code 131, including an Identification field 1039 computed in accordance with the rules specified in Section 8.1. The 1040 HA MUST do no further processing with such a notification, though it 1041 SHOULD log the error as a security exception. If HA accepts the MN's 1042 GNM message, it will process it based on the notification extension. 1043 Furthermore, the HA MAY reply with a GNAM message back to the MN with 1044 Code 0 based on the "A" flag in the GNM message. 1046 If the the "MD" value is set to 2, in the case of a Co-located CoA, 1047 the MN-HA AE MUST be checked, and the HA MUST check the Authenticator 1048 value in the Extension. If no MN-HA AE is found, or if more than one 1049 MN-HA AE is found, or if the Authenticator is invalid, the HA MUST 1050 reject the GNM and MAY send a GNAM to the MN with Code 131, including 1051 an Identification field computed in accordance with the rules 1052 specified in Section 8.1. The HA MUST do no further processing with 1053 such a notification, though it SHOULD log the error as a security 1054 exception. If HA accepts the MN's GNM message, it will process it 1055 based on the notification extension. Furthermore, the HA MAY reply 1056 with a GNAM message back to the MN with Code 0 based on the "A" flag 1057 in the GNM message. 1059 4.6.4. Sending Generic Notification Acknowledgement Messages 1061 If the GNM message came from the FA only, and if the "A" flag is set 1062 in the GNM message, then the HA MUST send a GNAM message. The 1063 message is as follows: The source address is HA's address, the 1064 destination address is the FA's address, the "MD" value is set to 1. 1065 The ordering of the extension is: any non-authentication Extensions 1066 used only by the FA, followed by The Foreign-Home Authentication 1067 extension defined in section 3.5.4 of [RFC3344]. 1069 The Code field of the GNAM is chosen in accordance with the rules 1070 specified in the section 4.2. When replying to an accepted GNM, a MN 1071 SHOULD respond with Code 0. 1073 If the GNM message came from the MN, and if the "A" flag is set in 1074 the GNM message, then the HA MUST send a GNAM message. The message 1075 is as follows: The source address is HA's address, the destination 1076 address is the FA's address, the "MD" value is set to 0. The 1077 ordering of the extension is: any non-authentication Extensions used 1078 only by the MN, followed by the MN-HA AE defined in section 3.5.2. of 1079 [RFC3344], optionly followed by any non-authentication Extensions 1080 used only by the FA, optionly followed by The MN-FA AE defined in 1081 section 3.5.3 of [RFC3344] 1083 5. Usage Example 1085 There are several applications that could use this GNM. For example, 1086 during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP 1087 resource of CDMA side have to be removed on the FA (PDSN) to avoid 1088 over-charging subscribers. Other applications such as HA switch 1089 over, NEMO prefix changes, service or billing related events, load 1090 balancing where the HA wants to move some of the registered mobile 1091 nodes to other HAs, service termination due to end of prepaid time, 1092 and service interruption due to system maintenance. 1094 Here we describe some possible event which could use the generic 1095 string extension [RFC4917] based on this notification mechanism. 1096 There is also the possibility that this notification message could 1097 carry many extensions at once. A new VSE extension could be defined 1098 to support this notification message. 1100 5.1. Generic String Extension 1102 In some case, the HA or FA needs to notify the mobile node about 1103 service termination due to the end of prepaid time, or service 1104 interruption due to system maintenance. This information could be 1105 defined based on a string [RFC4917] which is recognized by the MN 1106 easily. An example would be "Maintenance Downtime", "Prepaid 1107 Expiration". These string MUST be strictly defined so they could be 1108 easily understood by all of the network entities, and a suitable GNM 1109 Subtype number would have to be allocated. All such definitions are 1110 left for future specifications. 1112 6. IANA Considerations 1114 This document describes two new messages, the GNM in section 4.1 and 1115 the GNAM in section 4.2. These two messages SHOULD be allocated from 1116 the same address space used by the Registration Request and 1117 Registration Reply messages in [RFC3344]. The subtype of these two 1118 messages indicate what kind of information is carried and will be 1119 under assigned by IANA namespace. 1121 This document creates a new IANA registry for the Subtype field in 1122 the GNM and GNAM. New values MUST be allocated by Standards Actions 1123 or IETF Consensus. This document reserves three values for the 1124 Subtype field 1126 0 Reserved 1128 1 Information carried in Vendor specific extensions 1130 2 Information carried in Generic String Extension 1132 This GNAM message, specified in section section 4.2, has a Code 1133 field. The number space for the Code field values is also specified 1134 in section 4.2. The Code number space is strucutred according to 1135 whether the notification was successful, or whether the HA denied the 1136 notification, or whether FA denied the notification, or whether MN 1137 denied the notification, as follows 1139 0 Success Code 1140 64-69 Error Codes from the FA 1141 128-133 Error Codes from the HA 1142 192-197 Error Codes from the MN 1144 Approval of new Code values require expert review. 1146 7. Acknowledgments 1148 The author appreciate the efforts of Ahmad Muhanna for his detail 1149 reviewing of this document and his many contributions to the text of 1150 this document. The author also wants to thank Kent Leung, Peng Yang 1151 and Peter McCann et al. for their helping developing this document. 1152 Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E. 1153 Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu, 1154 Tim Polk, Amanda Baber, and Joseph Salowey's discussion and comments. 1155 Thanks to Jari Arkko for each step of this document. 1157 8. Security Considerations 1159 This specification operates in the security constraints and 1160 requirements of [RFC3344]. It require that when these message is 1161 transmitted between the MN and the HA, MN-HA AE is mandatory, when 1162 this message is transmitted between the MN and the FA, MN-FA AE is 1163 mandatory, when this message is transmitted between the FA and the 1164 HA, FA-HA AE is mandatory. It extends the operations of MN, HA and 1165 FA defined in [RFC3344] to notify each other about some events. The 1166 GNM message defined in the specification could carry information that 1167 modifies the mobility bindings. Therefore the message MUST be 1168 integrity protected. Replay protection MUST also be guaranteed. 1170 RFC 3344 provides replay protection only for registration requests 1171 sent by the MN. There is no mechanism for replay protection for 1172 messages initiated by a FA or a HA. The 64-bit Identification field 1173 specified in this document (Section 4.1 and 4.2) for the GNM message 1174 is used to provide replay protection for the notification messages 1175 initiated by the FA or HA. 1177 8.1. Replay Protection for GNM, GNAM messages 1179 The Identification field is used to let the receiving node verify 1180 that a GNM has been freshly generated by the sending node, not 1181 replayed by an attacker from some previous registration. Two methods 1182 are described in this section: timestamps (mandatory) and "nonces" 1183 (optional). All senders and receivers MUST implement timestamp-based 1184 replay protection. These nodes MAY also implement nonce-based replay 1185 protection 1187 The style of replay protection in effect between any two peer nodes 1188 among MN, FA and HA is part of the mobile security association. A 1189 sending node and its receiving node MUST agree on which method of 1190 replay protection will be used. The interpretation of the 1191 Identification field depends on the method of replay protection as 1192 described in the subsequent subsections. 1194 Whatever method is used, the low-order 32 bits of the Identification 1195 MUST be copied unchanged from the GNM to the GNMA. The receiver uses 1196 those bits (and the sender's source address) to match GNAM with 1197 corresponding replies. The receiver MUST verify that the low-order 1198 32 bits of any GNAM are identical to the bits it sent in the GNM. 1200 The Identification in a new GNM MUST NOT be the same as in an 1201 immediately preceding GNM, and SHOULD NOT repeat while the same 1202 security context is being used between the MN and the HA. 1204 8.1.1. Replay Protection using Timestamps 1206 The basic principle of timestamp replay protection is that the node 1207 generating a message inserts the current time of day, and the node 1208 receiving the message checks that this timestamp is sufficiently 1209 close to its own time of day. Unless specified differently in the 1210 security association between the nodes, a default value of 7 seconds 1211 MAY be used to limit the time difference. This value SHOULD be 1212 greater than 3 seconds. Obviously the two nodes must have adequately 1213 synchronized time-of-day clocks. As with any messages, time 1214 synchronization messages may be protected against tampering by an 1215 authentication mechanism determined by the security context between 1216 the two nodes. 1218 In this document, the timestamps are used, the sender MUST set the 1219 Identification field to a 64-bit value formatted as specified by the 1220 Network Time Protocol[RFC1305]. The low-order 32 bits of the NTP 1221 format represent fractional seconds . Note, however, that when using 1222 timestamps, the 64-bit Identification used in a GNM message from the 1223 sender MUST be greater than that used in any previous GNM message, as 1224 the receiver uses this field also as a sequence number. Without such 1225 a sequence number, it would be possible for a delayed duplicate of an 1226 earlier GNM message to arrive at the receiver (within the clock 1227 synchronization required by the receiver), and thus be applied out of 1228 order, mistakenly altering the sender's current status. 1230 Upon receipt of a GNM message with an authorization-enabling 1231 extension, the receiver MUST check the Identification field for 1232 validity. In order to be valid, the timestamp contained in the 1233 Identification field MUST be close enough to the receiver's time of 1234 day clock and the timestamp MUST be greater than all previously 1235 accepted timestamps for the requesting sender. Time tolerances and 1236 resynchronization details are specific to a particular mobility 1237 security association. 1239 If the timestamp is valid, the receiver copies the entire 1240 Identification field into the GNAM it returns the GNAM message to the 1241 sender. If the timestamp is not valid, the receiver copies only the 1242 low-order 32 bits into the GNAM, and supplies the high-order 32 bits 1243 from its own time of day. In this latter case, the receiver MUST 1244 reject the registration by returning Code 69/133/197 (identification 1245 mismatch) in the GNAM message. 1247 Furthermore, the receiver MUST verify that the low-order 32 bits of 1248 the Identification in the GNAM are identical to those in the rejected 1249 GNM attempt, before using the high-order bits for clock 1250 resynchronization. 1252 8.1.2. Replay Protection using Nonces 1254 The basic principle of nonce replay protection is that node A 1255 includes a new random number in every message to node B, and checks 1256 that node B returns that same number in its next message to node A. 1257 Both messages use an authentication code to protect against 1258 alteration by an attacker. At the same time node B can send its own 1259 nonces in all messages to node A (to be echoed by node A), so that it 1260 too can verify that it is receiving fresh messages. 1262 The receiver may be expected to have resources for computing pseudo- 1263 random numbers useful as nonces [RFC1750]. It inserts a new nonce as 1264 the high-order 32 bits of the identification field of every GNAM 1265 message. The receiver copies the low-order 32 bits of the 1266 Identification from the GNM message into the low-order 32 bits of the 1267 Identification in the GNAM message. When the sender receives an 1268 authenticated GNAM message from the receiver, it saves the high-order 1269 32 bits of the identification for use as the high-order 32 bits of 1270 its next GNM message. 1272 The sender is responsible for generating the low-order 32 bits of the 1273 Identification in each GNM message. Ideally it should generate its 1274 own random nonces. However it may use any expedient method, 1275 including duplication of the random value sent by the receiver. The 1276 method chosen is of concern only to the sender , because it is the 1277 node that checks for valid values in the GNAM message. The high- 1278 order and low-order 32 bits of the identification chosen SHOULD both 1279 differ from their previous values. The receiver uses a new high- 1280 order value and the sender uses a new low-order value for each 1281 registration message. 1283 If a GNM message is rejected because of an invalid nonce, the GNAM 1284 always provides the sender with a new nonce to be used in the next 1285 registration. Thus the nonce protocol is self- synchronizing. 1287 8.2. Non-authentication Extensions Handling in Foreign Agent 1289 When the FA is relaying the GNM message between the MN and the HA, 1290 and if the FA does not share a mobility security association with the 1291 MN or HA, all non-authentication extensions between MN and FA, or FA 1292 and HA are not protected; In this case, all non-authentication 1293 extensions should be silently discarded. 1295 9. Normative References 1297 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1298 Specification, Implementation", RFC 1305, March 1992. 1300 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1301 Recommendations for Security", RFC 1750, December 1994. 1303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1304 Requirement Levels", BCP 14, RFC 2119, March 1997. 1306 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ 1307 Organization-Specific Extensions", RFC 3115, April 2001. 1309 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1310 August 2002. 1312 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 1313 String Extension", RFC 4917, June 2007. 1315 Authors' Addresses 1317 Hui Deng 1318 China Mobile 1319 53A,Xibianmennei Ave., 1320 Xuanwu District, 1321 Beijing 100053 1322 China 1324 Email: denghui02@gmail.com 1326 Henrik Levkowetz 1327 Ericsson Research 1328 Torshamsgatan 23 1329 S-164 80, Stockholm 1330 SWEDEN 1332 Email: henrik@levkowetz.com 1334 Vijay Devarapalli 1335 WiChorus 1336 3590 North First St 1337 San Jose, CA 1338 USA 1340 Email: dvijay@gmail.com 1342 Sri Gundavelli 1343 Cisco Systems 1344 170 W.Tasman Drive 1345 San Jose, CA 95134 1346 USA 1348 Email: sgundave@cisco.com 1350 Brian Haley 1351 Hewlett-Packard Company 1352 110 Spitbrook Road 1353 Nashua, NH 03062 1354 USA 1356 Email: brian.haley@hp.com