idnits 2.17.1 draft-ietf-mip4-generic-notification-message-14.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 (March 8, 2010) is 5156 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 1277, 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: September 9, 2010 Ericsson Research 6 V. Devarapalli 7 WiChorus 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 March 8, 2010 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-14.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 September 9, 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 . . . . . . . . . . . . . . . . 14 80 4.4. Mobile Node Consideration . . . . . . . . . . . . . . . . 14 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 . . . . . . . . 16 85 4.4.4. Receiving Generic Notification Acknowledgement 86 Messages . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . 20 92 4.5.4. Receiving Generic Notification Acknowledgement 93 Messages . . . . . . . . . . . . . . . . . . . . . . . 21 94 4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 22 95 4.6.1. Sending Generic Notification Messages . . . . . . . . 22 96 4.6.2. Receiving Generic Notification Acknowledgement 97 Messages . . . . . . . . . . . . . . . . . . . . . . . 23 98 4.6.3. Receiving Generic Notification Messages . . . . . . . 23 99 4.6.4. Sending Generic Notification Acknowledgement 100 Messages . . . . . . . . . . . . . . . . . . . . . . . 24 101 5. Future Extensibility . . . . . . . . . . . . . . . . . . . . . 26 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 104 7.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 28 105 7.1.1. Replay Protection using Timestamps . . . . . . . . . . 29 106 7.1.2. Replay Protection using Nonces . . . . . . . . . . . . 30 107 7.2. Non-authentication Extensions Handling in Foreign Agent . 30 108 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 109 9. Normative References . . . . . . . . . . . . . . . . . . . . . 32 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 112 1. Introduction 114 In some situations, there is a need for Mobile IPv4 entities, such as 115 the home agent(HA), foreign agent(FA) and mobile node(MN) to send and 116 receive asynchronous notification messages during a mobility session. 117 The base Mobile IP Specification [RFC3344] does not have a provision 118 for this. 120 This document defines a generic message and a notification model that 121 can be used by Mobile IPv4 entities to send various notifications. 122 It also defines a corresponding acknowledgement message to allow for 123 reliable delivery of notifications. The messages defined in this 124 document are capable of carrying the same extensions that have been 125 defined for the existing Mobile IPv4 messages. However, this 126 document requires for now that only the following extensions be 127 present in the new messages defined herein: 129 - MN-HA Authentication Extension 131 - MN-FA Authentication Extension 133 - FA-HA Authentication Extension 135 - Generic String Extension 137 For now, the semantics of receiving a generic notification message 138 are null; i.e., it has no effect on the state of a mobile node's 139 existing registration. See Section 5 for some prospective 140 application examples that motivate the new messages defined in this 141 document. Future documents may specify additional extension types 142 that may be used in a generic notification message and their 143 semantics. 145 2. Terminology 147 It is assumed that the reader is familiar with the terminology used 148 in [RFC4917], [RFC3344]. In addition, the following terms are 149 defined: 151 Notification Message 153 A message from a mobility agent to a MN or other mobility agent to 154 asynchronously notify it about an event that is relevant to the 155 mobility service it is currently providing. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119, [RFC2119]. 161 3. Notification message - Usage Scenario's 163 There are several scenarios where a mobility agent could initiate 164 notification events. Some of these are described in the following 165 sections. 167 3.1. Notification message between a Home Agent and a Mobile Node 169 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 171 In this case, the HA cannot directly notify the MN, but must send the 172 notification via the FA, vice versa. 174 +----+ notification +----+ notification +----+ 175 | MN |<================>| FA |<=============>| HA | 176 +----+ +----+ +----+ 178 Figure 1: HA notifies MN or MN notifies HA through FA 180 3.1.2. Mobile Registered using a Co-located Care-of Address 182 In this case, the MN has registered with the home agent directly, so 183 the notification message can go directly to the MN. 185 The notification mechanism as specified here does not support the 186 case of Co-located CoA mode with registration through a FA (due to 187 the 'R' bit being set in the FA's advertisement messages). 189 +----+ notification +----+ 190 | MN |<===================================>| HA | 191 +----+ +----+ 193 Figure 2: HA directly notifies MN or MN directly notifies HA 195 3.2. Notification message between a Foreign Agent and a Mobile Node 197 There are two cases where a FA may send notification messages to a 198 MN, one where it is relaying a message, the other where the 199 notification is triggered by a message from another network entity, 200 for example a AAA node(notification messages between a AAA entity and 201 the FA could be based on RADIUS or Diameter, but this is out of scope 202 for this document). If the notification is initiated by a FA, the FA 203 may need to also notify the HA about the event. 205 +----+ notification +----+ trigger +--------+ 206 | MN |<================>| FA |<=============| AAA | 207 +----+ +----+ +--------+ 208 || notification +----+ 209 ================>| HA | 210 +----+ 212 Figure 3: FA notifies MN 214 3.3. Notification message between a Home Agent and a Foreign Agent 216 The HA may also need to send a notification to the FA, but not to the 217 MN, The FA may also need to send a notification to the HA, as 218 illustrated below: 220 +----+ notification +----+ 221 | FA |<=============>| HA | 222 +----+ +----+ 224 Figure 4: HA notifies FA or FA notifies HA 226 4. Generic Notification Message and Considerations 228 This section describes in detail the Generic Notification Message 229 (GNM), Generic Notification Acknowledgement Message (GNAM), and some 230 considerations related to the handling of these messages in the MN, 231 FA and HA. 233 The MN and HA MUST maintain the following information, FA also needs 234 to maintain both the HA's and MN's direction the below information: 236 - the IP source address of the Registration Request/Reply 238 - the IP destination address of the Registration Request/Reply 240 - the UDP source port of the Registration Request/Reply 242 - the UDP destination port of the Registration Request/Reply 244 The sending node always sends the GNM message following the same 245 procedure for sending Registration Request as in section 3.3 of 246 [RFC3344] and the receiving node follows the same procedure for 247 Registration Reply as in section 3.4. of [RFC3344] when sending GNAM. 249 4.1. Generic Notification Message 251 A GNM is sent by a mobility agent to inform another mobility agent, 252 or a MN, of MIP-related information such as generic string 253 notification[RFC4917]. These messages MUST use the same IP and UDP 254 headers as any previous Registration Request(RRQ) or Reply (RRP) 255 message to the same entity. This would support NAT traversal and 256 ensure same security association used for GNM/GNAM and RRQ/RRP. The 257 GNM is defined as follows: 259 IP Fields: 261 Source Address Typically copied from the destination 262 address of the last Registration Reply/ 263 Request message that the agent received from 264 the agent to which it is sending the GNM. 266 Destination Address Copied from the source address of the last 267 Registration Reply/Request message that the 268 agent received from the agent to which it is 269 sending the GNM. 271 UDP Fields: 273 Source Port Typically copied from the destination port 274 of the last Registration Reply/Request 275 message that the agent received from the 276 agent to which it is sending the GNM. 278 Destination Port Copied from the source port of the last 279 Registration Reply/Request message that the 280 agent received from the agent to which it is 281 sending the GNM. 283 The UDP header is followed by the Mobile IP fields shown below: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type | MD |A| Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Home Address | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Home Agent Address | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Care-of Address | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 + Identification + 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Extensions... 301 +-+-+-+-+-+-+-+-+-+-+-+-+- 303 Type (To be assigned by IANA) 305 MD: Message Direction 307 This memo defines the semantics of the following MD field value: 309 0 -- Message sent by the HA to the MN 311 1 -- Message sent by the HA to the FA 313 2 -- Message sent by the MN to the HA 315 3 -- Message sent by the MN to the FA 317 4 -- Message sent by the FA to the MN 318 5 -- Message sent by the FA to the HA 320 A 322 This bit indicates whether the notification message MUST be 323 acknowledged by the recipient. If "A" bit has been set during the 324 message, but the sender doesn't receive any acknowledgement 325 message, then the sender will have to resend the notification 326 message again. 328 Set to "1" to indicate that acknowledgement is required. 330 Set to "0" to indicate that acknowledgement is optional. 332 Reserved 334 MUST be sent as 0, and ignored when received. 336 Home Address 338 The home IP address of the mobile node. 340 Home Agent Address 342 The IP address of the mobile node's HA. 344 Care-of Address 346 The mobile node's care-of address, either the Co-located Care-of 347 Address or the foreign agent care-of address. 349 Identification 351 A 64-bit number, constructed by the sender, used for matching GNM 352 with GNAM, and for protecting against replay attacks of 353 notification messages. See Sections 8.1.1 and 8.1.2. Timestamps 354 is mandatory and nonces is optional. 356 Extensions 358 The fixed portion of the GNM is followed by one or more extensions 359 which may be used with this message, and by one or more 360 authentication extensions (as defined in Section 3.5 of [RFC3344]. 361 This document mandates the MN-HA Authentication Extension (AE) 362 when this message is sent between the MN and the HA, MN-FA AE and 363 FA-HA AE are optional. This document also mandate the MN-FA AE 364 when this message is sent between the MN and the FA, MN-HA AE and 365 FA-HA AE are not needed. This document mandate the FA-HA AE when 366 this message is sent between the FA and the HA, MN-HA AE and MN-FA 367 AE are not needed. This could be judged based on "MD" value.). 368 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 369 order of these extensions as they appear in Mobile IPv4 RRQ and 370 RRP messages. The same rules are applicable to GNM and GNAM. 372 4.2. Generic Notification Acknowledgment Message 374 A GNAM is sent by mobility agents or MNs to indicate the successful 375 receipt of a GNM. 377 IP Fields: 379 Source Address Typically copied from the destination 380 address of the GNM to which the agent is 381 replying. 383 Destination Address Copied from the source address of the GNM to 384 which the agent is replying. 386 UDP Fields: 388 Source Port Copied from the destination port of the 389 corresponding GNM. 391 Destination Port Copied from the source port of the 392 corresponding GNM. 394 The UDP header is followed by the Mobile IP fields shown below: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | MD | code | Reserved | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Home Address | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Home Agent Address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Care-of Address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 + Identification + 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Extensions... 412 +-+-+-+-+-+-+-+-+-+-+-+-+- 413 Type (To be assgined by IANA) 415 MD: Message Direction 417 This memo defines the semantics of the following MD field value: 419 0 -- Message sent by the HA to the MN 421 1 -- Message sent by the HA to the FA 423 2 -- Message sent by the MN to the HA 425 3 -- Message sent by the MN to the FA 427 4 -- Message sent by the FA to the MN 429 5 -- Message sent by the FA to the HA 431 code 433 A value indicating the result of the GNM. See below for a list of 434 currently defined Code values. 436 Notification suceessful 438 0 -- notification accepted 440 Notification denied by the HA 442 128 -- reason unspecified 444 129 -- administratively prohibited 446 130 -- insufficient resources 448 131 -- mobile node failed authentication 450 132 -- foreign agent failed authentication 452 133 -- notification Identification mismatch 454 Notification denied by the FA 456 64 -- reason unspecified 458 65 -- administratively prohibited 459 66 -- insufficient resources 461 67 -- mobile node failed authentication 463 68 -- home agent failed authentication 465 69 -- notification Identification mismatch 467 Notification denied by the mobile node 469 192 -- reason unspecified 471 193 -- administratively prohibited 473 194 -- insufficient resources 475 195 -- foreign agent failed authentication 477 196 -- home agent failed authentication 479 197 -- notification Identification mismatch 481 Home Address 483 The home IP address of the mobile node. 485 Home Agent Address 487 The IP address of the sender's home agent. 489 Care-of Address 491 The mobile node's care-of address, either the Co-located Care-of 492 Address or the foreign agent care-of address. 494 Identification 496 A 64-bit number used for matching GNM message with GNAM mesage and 497 for protecting against replay attacks of registration messages. 498 See Sections 8.1.1 and 8.1.2. Timestamps is mandatory and nonces 499 is optional. The value is based on the Identification field from 500 the GNM message from the sender, and on the style of replay 501 protection used in the security context between the sender and its 502 receiver (defined by the mobility security association between 503 them, and SPI value in the authorization-enabling extension). 505 Extensions 506 The fixed portion of the GNAM is followed by one or more 507 extensions which may be used with this message, and by one or more 508 authentication extensions (as defined in Section 3.5 of [RFC3344]. 509 This document mandates the MN-HA Authentication Extension (AE) 510 when this message is sent between the MN and the HA, MN-FA AE and 511 FA-HA AE are optional. This document also mandate the MN-FA AE 512 when this message is sent between the MN and the FA, MN-HA AE and 513 FA-HA AE are not needed. This document mandate the FA-HA AE when 514 this message is sent between the FA and the HA, MN-HA AE and MN-FA 515 AE are not needed. This could be judged based on "MD" value.). 516 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 517 order of these extensions as they appear in Mobile IPv4 RRQ and 518 RRP messages. The same rules are applicable to GNM and GNAM. 520 4.3. Notification Retransmision 522 If "A" flag has been set during the GNM message, but the sender 523 doesn't receive any GNAM message within a reasonable time, then 524 another GNM will be retransmited. When timestamps are used, a new 525 registration Identification is chosen for each retransmision; Thus it 526 counts as a new GNM. When nonces are used, the unanswered GNM 527 message is retransmitted unchanged; thus the retransmission does not 528 count as a new GNM (Section 8.1). In this way a retransmission will 529 not require the receiver to resynchronize with the sender by issuing 530 another nonce in the case in which the original GNM message (rather 531 than its GNAM message) was lost by the network. 533 The maximum time until a new GNM message is sent SHOULD be no greater 534 than the requested Lifetime of the last GNM message. The minimum 535 value SHOULD be large enough to account for the size of the messages, 536 twice the round trip time for transmission to the receiver, and at 537 least an additional 100 milliseconds to allow for processing the 538 messages before responding. The round trip time for transmission to 539 the receiver will be at least as large as the time required to 540 transmit the messages at the link speed of the sender's current point 541 of attachment. Some circuits add another 200 milliseconds of 542 satellite delay in the total round trip time to the receiver. The 543 minimum time between GNM MUST NOT be less than 1 second. Each 544 successive retransmission timeout period SHOULD be at least twice the 545 previous period, as long as that is less than the maximum as 546 specified above. 548 4.4. Mobile Node Consideration 550 It is possible that the MN MAY receive a GNM from a FA or HA. Both 551 in the case of FA-CoA and Co-located CoA, the MN MAY reply with a 552 GNAM based on the "A" flag in the GNM message. 554 4.4.1. Receiving Generic Notification Messages 556 When the MN is using FA-CoA and receives a Notification message, if 557 the "MD" value is 0, it means that the notification message came from 558 the HA. If the "MD" value is 4, the notification came from the FA. 560 If this notification message came from a FA and the MN accepts the 561 FA's GNM, then it will process the notification extension according 562 to the specific rules for that extension. 564 The MN MUST check for the presence of an authorization-enabling 565 extension, and perform the indicated authentication. Exactly one 566 authorization-enabling extension MUST be present in the GNM, if this 567 message came from a FA, then MN-FA AE MUST be present. If no MN-FA 568 AE is found, or if more than one MN-FA AE is found, or if the 569 Authenticator is invalid, then the MN MUST reject the GNM and MAY 570 send a GNAM to the FA with Code 195, including an Identification 571 field computed in accordance with the rules specified in Section 8.1. 572 The MN MUST do no further processing with such a notification, though 573 it SHOULD log the error as a security exception. 575 The MN MUST check that the Identification field is correct using the 576 context selected by the SPI within mandatory authentication extension 577 like MN-FA AE or MN-HA AE. See Section 8.1 for a description of how 578 this is performed. If incorrect, the MN MUST reject the GNM and MAY 579 send a GNAM to the initiator with Code 197, including an 580 Identification field computed in accordance with the rules specified 581 in Section 8.1. The MN MUST do no further processing with such a 582 notification, though it SHOULD log the error as a security exception. 584 After that, the MN MAY reply GNAM back to the FA. If the "A" flag is 585 set in the GNM, then the MN MUST send the GNAM. 587 If this notification message came from the HA, relayed by the FA, or 588 is a Co-located CoA, then the MN-HA AE MUST be checked and the MN 589 MUST check the Authenticator value in the Extension. If no MN-HA AE 590 is found, or if more than one MN-HA AE is found, or if the 591 Authenticator is invalid, then the MN MUST reject the GNM and MAY 592 send a GNAM to the initiator with Code 196, including an 593 Identification field computed in accordance with the rules specified 594 in Section 8.1. The MN MUST do no further processing with such a 595 notification, though it SHOULD log the error as a security exception. 596 If the MN accepts the HA's GNM, then it will process it according to 597 the specific rules for that extension. After that, the MN MAY reply 598 with a GNAM with Code 0 back to the HA based on the "A" flag in the 599 GNM. 601 4.4.2. Sending Generic Notification Acknowledgement Message 603 Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply 604 with a GNAM based on the "A" flag in the GNM as follows: 606 If the GNM was initiated from the FA to the MN ("MD" value is set to 607 4), then MN-FA AE MUST be the last extension in order to protect all 608 other non-authentication extensions as defined in section 3.5.3 of 609 [RFC3344]. 611 In the case of a FA-CoA, the source address is the MN's address, the 612 destination address is the FA's address. 614 The Code field of the GNAM is chosen in accordance with the rules 615 specified in the section 4.2. When replying to an accepted 616 notification, a MN SHOULD respond with Code 0. 618 There are a number of reasons the MN might reject a notification such 619 as administrative in nature returning a GNAM with a code of 193, 620 similarly and provides the Code value 192 or 194 for the unspecified 621 reason and insufficient resources. 623 If the GNM was initiated from the HA to the MN ("MD" value is set to 624 0) and in the case of Co-located CoA, then MN-HA AE MUST be the last 625 extension in order to protect all other non-authentication extensions 626 as defined in section 3.5.2 of [RFC3344] 628 In the case of a FA-CoA, the source address is the MN's HoA address 629 and the destination address is the FA's address ("MD" value is set to 630 2), the ordering of the extension is: any non-authentication 631 Extensions used only by the HA, followed by the MN-HA AE defined in 632 section 3.5.2. of [RFC3344], followed by any non-authentication 633 Extensions used only by the FA, followed by the MN-FA AE defined in 634 section 3.5.3 of [RFC3344]. 636 4.4.3. Sending Generic Notification Messages 638 The MN may either send a GNM to notify the FA or HA. 640 If the message is sent to the FA, then the source address is the MN's 641 address, and the destination address is the FA's address 643 If the FA is the target of this notification message, then the "MD" 644 value is set to 3, MN-FA AE MUST be the last extension in order to 645 protect all other non-authentication extensions. Computing 646 Authentication Extension Value is the same as section 3.5.1 of 647 [RFC3344]. 649 If the FA is working only as a relay agent, then the "MD" value is 650 set to 2, and the ordering of the extension is: the notification 651 extension, followed by any non-authentication extension expected to 652 be used by HA, followed by MN-HA AE defined in section 3.5.2. of 653 [RFC3344], followed by any non-authentication Extensions used only by 654 the FA, followed by The MN-FA AE defined in section 3.5.3 of 655 [RFC3344]. Computing Authentication Extension Value is the same as 656 section 3.5.1 of [RFC3344]. 658 In the case of a Co-located CoA, the MN MAY send a notification 659 message directly to the HA if it needs to be notified. The "MD" 660 value is set to 2, and the ordering of the extension is: the 661 notification extension, followed by any non-authentication extension 662 expected to be used by HA, followed by MN-HA AE defined in section 663 3.5.2 of [RFC3344]. 665 The MN chooses the Identification field in accordance with the style 666 of replay protection it uses with its HA. This is part of the 667 mobility security association the MN shares with its HA. See Section 668 8.1 for the method by which the MN computes the Identification field. 670 4.4.4. Receiving Generic Notification Acknowledgement Messages 672 In the case of a FA-CoA, if the MN receives this message, and the 673 "MD" value is set to 0, it means that the GNAM came from HA 675 If the "MD" value is set to 4, then the MN-FA AE MUST be checked, and 676 the MN MUST check the Authenticator value in the Extension. If no 677 MN-FA AE is found, or if more than one MN-FA AE is found, or if the 678 Authenticator is invalid, then the MN MUST silently discard the GNAM. 680 In addition, the low-order 32 bits of the Identification field in the 681 GNAM MUST be compared to the low-order 32 bits of the Identification 682 field in the most recent GNM sent to the replying agent. If they do 683 not match, then the GNAM MUST be silently discarded. 685 If the "MD" value is set to 0, then the MN-HA AE MUST be checked, and 686 the MN MUST check the Authenticator value in the Extension. If no 687 MN-HA AE is found, or if more than one MN-HA AE is found, or if the 688 Authenticator is invalid, then the MN MUST silently discard the GNAM. 689 If the MN accepted this message, then the MN MAY also process it 690 based on the notification event. 692 In the case of a Co-located CoA, if the MN received this message, 693 then the MN-HA AE MUST be checked, and the MN MUST check the 694 Authenticator value in the Extension. If no MN-HA AE is found, or if 695 more than one MN-HA AE is found, or if the Authenticator is invalid, 696 then the MN MUST silently discard the Notification Acknowledgement 697 message. 699 4.5. Foreign Agent Consideration 701 The FA may initiate a GNM to the MN or the HA. Additionally, the FA 702 also relays GNM and GNAM messages between the MN and its HA as long 703 as there is an active binding for the MN at the FA. 705 4.5.1. Receiving Generic Notification Message 707 If the FA receives a GNM, and the "MD" value is set to 0, then it 708 means that the HA is asking the FA to relay the message to the MN. 709 If the "MD" value is set to 1, then it means that the target of the 710 notification is the FA. If the "MD" value is set to 2, then it means 711 that the MN is asking the FA to relay the message to the HA. If the 712 "MD" value is set to 3, then it means that the notification came from 713 the MN to the FA. 715 If the "MD" value is set to 0, then the FA MAY validate the FA-HA AE 716 if present. If the FA-HA AE is invalid, then all extensions between 717 the HA-MN AE and the HA-FA AE MUST be removed, FA SHOULD relay the 718 GNM to the MN's home address as specified in the Home Address field 719 of the GNM, MN will eventually validate the MN-HA AE to ensure that 720 all information sent to the MN is integrity protected. If the FA-HA 721 AE is valid, FA MUST relay the GNM to the MN's home address as 722 specified in the Home Address field of the GNM. The FA MUST NOT 723 modify any of the fields beginning with the fixed portion of the GNM 724 through the MN-HA AE or other authentication extension supplied by 725 the HA as an authorization-enabling extension for the MN. 727 Furthermore, the FA MUST process and remove any extensions following 728 the MN-HA AE. If the FA shares a mobility security association with 729 the MN, the FA MAY append any of its own non-authentication 730 extensions which of relevance to the MN. In this case, the FA MUST 731 append the MN-FA AE after these non-authentication extensions. 733 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 734 FA MUST check the Authenticator value in the Extension. If no FA-HA 735 AE is found, or if more than one FA-HA AE is found, or if the 736 Authenticator is invalid, the FA MUST reject the GNM and MAY send a 737 GNAM to the HA with Code 68, including an Identification field 738 computed in accordance with the rules specified in Section 8.1. The 739 FA MUST do no further processing with such a notification, though it 740 SHOULD log the error as a security exception. 742 The FA MUST check that the Identification field is correct using the 743 context selected by the SPI within mandatory FA-HA AE. See Section 744 8.1 for a description of how this is performed. If incorrect, the FA 745 MUST reject the GNM and MAY send a GNAM to the initiator with Code 746 69, including an Identification field computed in accordance with the 747 rules specified in Section 8.1. The FA MUST do no further processing 748 with such a notification, though it SHOULD log the error as a 749 security exception. 751 If FA accepts the HA's GNM, it will process it based on the specific 752 rules for that extension. The FA MAY then reply with a GNAM with 753 Code 0 back to the MN based on the "A" flag in the GNM. 755 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 756 received this message, and if the MN-FA AE is present, the MN-FA AE 757 MUST be checked, and the FA MUST check the Authenticator value in the 758 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 759 found, or if the Authenticator is invalid, the FA MUST silently 760 discard the GNM message. If MN-FA is valid, FA MUST relay the GNM to 761 the HA's address as specified in the Home Agent Address field of the 762 GNM, HA will eventually validate the MN-HA AE to ensure that all 763 information sent to the HA is integrity protected. The FA MUST NOT 764 modify any of the fields beginning with the fixed portion of the GNM 765 through the MN-HA AE or other authentication extension supplied by 766 the MN as an authorization-enabling extension for the HA. 768 Furthermore, the FA MUST process and remove any Extensions following 769 the MN-HA AE, and MAY append any of its own non-authentication 770 Extensions of relevance to the HA if applicable, and MUST append the 771 FA-HA AE, if the FA shares a mobility security association with the 772 HA. 774 If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the 775 FA MUST check the Authenticator value in the Extension which is the 776 same as the section 3.7.2.1 of RFC 3344. If no MN-FA AE is found, or 777 if more than one MN-FA AE is found, or if the Authenticator is 778 invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN 779 with Code 67, including an Identification field computed in 780 accordance with the rules specified in Section 8.1. The FA MUST do 781 no further processing with such a notification, though it SHOULD log 782 the error as a security exception. 784 The FA MUST check that the Identification field is correct using the 785 context selected by the SPI within mandatory MN-FA AE. See Section 786 8.1 for a description of how this is performed. If incorrect, the FA 787 MUST reject the GNM and MAY send a GNAM to the initiator with Code 788 69, including an Identification field computed in accordance with the 789 rules specified in Section 8.1. The FA MUST do no further processing 790 with such a notification, though it SHOULD log the error as a 791 security exception. 793 If FA accepts the MN's GNM, it will process it based on the specific 794 rules for that extension. The FA MAY then reply with a GNAM with 795 Code 0 back to the MN based on the "A" flag in the GNM. 797 4.5.2. Sending Generic Notification Acknowledgement Messages 799 The FA may need to either relay a GNAM message between the MN and the 800 HA or send one as a response to a GNM messsage that was sent to it. 801 In both cases, the GNAM message is defined as follows: 803 The source address is the FA address, the destination address is HA's 804 or MN's home address. 806 The Code field of the GNAM is chosen in accordance with the rules 807 specified in the section 4.2. When replying to an accepted 808 notification, a FA SHOULD respond with Code 0. 810 There are a number of reasons the FA might reject a notification such 811 as administrative in nature returning a GNAM with a code of 65, 812 similarly and provides the Code value 64 or 66 for the unspecified 813 reason and insufficient resources. 815 If the FA is only relaying this message to the HA, the FA MUST NOT 816 modify any of the fields beginning with the fixed portion of the GNAM 817 through the including the MN-HA AE or other authentication extension 818 supplied by the MN as an authorization-enabling extension for the MN. 819 Furthermore, the foreign agent MUST process and remove any Extensions 820 following the MN-HA AE. If the FA shares a mobility security 821 association with the HA, the FA MAY append any of its own non- 822 authentication extensions which of relevance to the HA, In this case 823 the FA MUST append the FA-HA AE after these non-authentication 824 extensions. 826 If the notification message is from the HA to the FA then the "MD" 827 value is set to 5 and the ordering of the extension is: any non- 828 authentication Extensions used only by the FA, followed by The FA-HA 829 AE defined in section 3.5.4 of [RFC3344]. 831 If the notification message is from the MN to the FA then the "MD" 832 value is set to 4 and the ordering of the extension is: any non- 833 authentication Extensions used only by the FA, followed by The MN-FA 834 AE defined in section 3.5.3 of [RFC3344]. 836 4.5.3. Sending Generic Notification Messages 838 If the FA is initiating a notification to the MN using the GNM, it 839 MAY also notify the HA as well. 841 In the message to the MN, the source address is the FA address, the 842 destination address is the MN's address, the "MD" value is set to 4, 843 and the ordering of the extension is: the notification extension, 844 followed by any non-authentication Extensions used only by the MN, 845 followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 846 Computing Authentication Extension Value is the same as section 3.5.1 847 of [RFC3344] except the payload is the notification other than 848 registration. 850 In the message to the HA, the source address is the FA's address, the 851 destination address is the HA's address (the "MD" value is set to 5), 852 and the ordering of the extension is: notification extension, 853 followed by any non-authentication Extensions used only by the HA, 854 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 855 Computing Authentication Extension Value is the same as section 3.5.1 856 of [RFC3344] except the payload is the notification other than 857 registration. 859 4.5.4. Receiving Generic Notification Acknowledgement Messages 861 In the case of a FA-CoA, if the FA receives this message, and the 862 "MD" value is set to 3, it means that the notification 863 acknowledgement message came from the MN, otherwise it came from the 864 HA. 866 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 867 FA MUST check the Authenticator value in the Extension. If no FA-HA 868 AE is found, or if more than one FA-HA AE is found, or if the 869 Authenticator is invalid, the FA MUST silently discard the 870 Notification Acknowledgement message. If the FA accepted this 871 message, the FA MAY also process it based on the notification event. 873 If the "MD" value is set to 3, if the MN-FA AE is present, it MUST be 874 checked, and the FA MUST check the Authenticator value in the 875 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 876 found, or if the Authenticator is invalid, the FA MUST silently 877 discard the GNAM message. If the FA accepted this message, the FA 878 MAY also process it based on the notification event. 880 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 881 received this message, and if the MN-FA AE is present, the MN-FA AE 882 MUST be checked, and the FA MUST check the Authenticator value in the 883 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 884 found, or if the Authenticator is invalid, the FA MUST silently 885 discard the GNAM message. If FA accepted the MN's GNAM message, it 886 MUST relay this message to the HA. The FA MUST NOT modify any of the 887 fields beginning with the fixed portion of the GNAM message through 888 the including the MN-HA AE or other authentication extension supplied 889 by the HA as an authorization-enabling extension for the MN. 890 Furthermore, the FA MUST process and remove any Extensions following 891 the MN-HA AE and MAY append any of its own non-authentication 892 Extensions of relevance to the HA, if applicable, and MUST append the 893 FA-HA AE, if the FA shares a mobility security association with the 894 HA. 896 4.6. Home Agent Consideration 898 The HA MAY initiate a GNM message to both the mobile node and FA, and 899 it also MAY receive a GNAM message from both the FA and MN. The HA 900 also MAY receive a GNM message from the FA, but only when there is a 901 binding for a MN. If the HA receives a GNM from a FA and there is no 902 corresponding MN registration, the HA SHOULD drop the GNM message. 904 4.6.1. Sending Generic Notification Messages 906 In the case of a FA-CoA, the HA may either send a GNM to notify the 907 FA, or have the FA relay the GNM to the MN if the MN needs to be 908 notified. 910 If the message is from the HA to the FA, the source address is the 911 HA's address, and the destination address is the FA's address 913 If the FA is working only as a relay agent, the "MD" value is set to 914 0, and the ordering of the extension is: the notification extension, 915 followed by any non-authentication extension expected to be used by 916 MN, followed by MN-HA AE defined in section 3.5.2. of [RFC3344], 917 followed by any non-authentication Extensions used only by the FA, 918 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 919 Computing Authentication Extension Value is the same as section 3.5.1 920 of [RFC3344]. 922 If the FA is the target of this notification message, then the "MD" 923 value is set to 1, and the ordering of the extension is: the 924 notification extension, followed by any non-authentication Extensions 925 used only by the FA, followed by The FA-HA AE defined in section 926 3.5.4 of [RFC3344]. Computing Authentication Extension Value is the 927 same as section 3.5.1 of [RFC3344]. 929 In the case of a Co-located CoA, the HA MAY send a notification 930 message directly to the MN if it needs to be notified. The "MD" 931 value is set to 0, and the ordering of the extension is: the 932 notification extension, followed by any non-authentication extension 933 expected to be used by MN, followed by MN-HA AE defined in section 934 3.5.2. of [RFC3344]. 936 4.6.2. Receiving Generic Notification Acknowledgement Messages 938 In the case of a FA-CoA, if the HA receives this message, and the 939 "MD" value is set to 2, it means that the GNAM message came from MN. 941 If the "MD" value is set to 5, and the HA accepted this message, the 942 HA MAY also process it based on the notification event. The FA-HA AE 943 MUST be checked, and the HA MUST check the Authenticator value in the 944 Extension. If no FA-HA AE is found, or if more than one FA-HA AE is 945 found, or if the Authenticator is invalid, the HA MUST silently 946 discard the GNAM message. 948 If the "MD" value is set to 2, in the case of a FA-CoA, and if FA-HA 949 AE is present, the FA-HA AE MUST be checked, and the HA MUST check 950 the Authenticator value in the Extension. If more than one FA-HA AE 951 is found, or if the Authenticator is invalid, the HA MUST silently 952 discard the GNAM message. Anyway, MN-HA AE MUST be checked, and the 953 HA MUST check the Authenticator value in the Extension. If no MN-HA 954 AE is found, or if more than one MN-HA AE is found, or if the 955 Authenticator is invalid, the HA MUST silently discard the GNAM. If 956 the HA accepted this message, the HA MAY also process it based on the 957 notification event. 959 If the "MD" value is set to 2, in the case of a Co-located CoA, MN-HA 960 AE MUST be checked, and the HA MUST check the Authenticator value in 961 the Extension. If no MN-HA AE is found, or if more than one MN-HA AE 962 is found, or if the Authenticator is invalid, the HA MUST silently 963 discard the GNAM. If the HA accepted this message, the HA MAY also 964 process it based on the notification event. 966 4.6.3. Receiving Generic Notification Messages 968 The HA MAY receive a GNM message sent from the FA. When the HA 969 receives this message, if the the "MD" value is set to 5, this 970 message came from FA. FA-HA AE MUST be checked, and the HA MUST 971 check the Authenticator value in the Extension. If no FA-HA AE is 972 found, or if more than one FA-HA AE is found, or if the Authenticator 973 is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA 974 with Code 132, including an Identification field computed in 975 accordance with the rules specified in Section 8.1. The HA MUST do 976 no further processing with such a notification, though it SHOULD log 977 the error as a security exception. 979 The HA MUST check that the Identification field is correct using the 980 context selected by the SPI within mandatory authentication extension 981 like MN-HA AE or FA-HA AE. See Section 8.1 for a description of how 982 this is performed. If incorrect, the HA MUST reject the GNM and MAY 983 send a GNAM to the initiator with Code 133, including an 984 Identification field computed in accordance with the rules specified 985 in Section 8.1. The HA MUST do no further processing with such a 986 notification, though it SHOULD log the error as a security exception. 987 If HA accepts the FA's GNM message, it will process it based on the 988 notification extension. Furthermore, the HA MAY reply with a GNAM 989 message with Code 0 back to the FA based on the "A" flag in the GNM 990 message. 992 If the the "MD" value is set to 2, this message come from MN, in the 993 case of FA-COA, if FA-HA AE is present, it MUST be checked, and the 994 HA MUST check the Authenticator value in the Extension. If more than 995 one FA-HA AE Extension is found, or if the Authenticator is invalid, 996 the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 997 132, including an Identification field computed in accordance with 998 the rules specified in Section 8.1. The HA MUST do no further 999 processing with such a notification, though it SHOULD log the error 1000 as a security exception. And MN-HA AE MUST be checked, and the HA 1001 MUST check the Authenticator value in the Extension. If no MN-HA AE 1002 is found, or if more than one MN-HA AE is found, or if the 1003 Authenticator is invalid, the HA MUST reject the GNM and MAY send a 1004 GNAM to the MN with Code 131, including an Identification field 1005 computed in accordance with the rules specified in Section 8.1. The 1006 HA MUST do no further processing with such a notification, though it 1007 SHOULD log the error as a security exception. If HA accepts the MN's 1008 GNM message, it will process it based on the notification extension. 1009 Furthermore, the HA MAY reply with a GNAM message back to the MN with 1010 Code 0 based on the "A" flag in the GNM message. 1012 If the the "MD" value is set to 2, in the case of a Co-located CoA, 1013 the MN-HA AE MUST be checked, and the HA MUST check the Authenticator 1014 value in the Extension. If no MN-HA AE is found, or if more than one 1015 MN-HA AE is found, or if the Authenticator is invalid, the HA MUST 1016 reject the GNM and MAY send a GNAM to the MN with Code 131, including 1017 an Identification field computed in accordance with the rules 1018 specified in Section 8.1. The HA MUST do no further processing with 1019 such a notification, though it SHOULD log the error as a security 1020 exception. If HA accepts the MN's GNM message, it will process it 1021 based on the notification extension. Furthermore, the HA MAY reply 1022 with a GNAM message back to the MN with Code 0 based on the "A" flag 1023 in the GNM message. 1025 4.6.4. Sending Generic Notification Acknowledgement Messages 1027 If the GNM message came from the FA only, and if the "A" flag is set 1028 in the GNM message, then the HA MUST send a GNAM message. The 1029 message is as follows: The source address is HA's address, the 1030 destination address is the FA's address, the "MD" value is set to 1. 1031 The ordering of the extension is: any non-authentication Extensions 1032 used only by the FA, followed by The Foreign-Home Authentication 1033 extension defined in section 3.5.4 of [RFC3344]. 1035 The Code field of the GNAM is chosen in accordance with the rules 1036 specified in the section 4.2. When replying to an accepted GNM, a MN 1037 SHOULD respond with Code 0. 1039 If the GNM message came from the MN, and if the "A" flag is set in 1040 the GNM message, then the HA MUST send a GNAM message. The message 1041 is as follows: The source address is HA's address, the destination 1042 address is the FA's address, the "MD" value is set to 0. The 1043 ordering of the extension is: any non-authentication Extensions used 1044 only by the MN, followed by the MN-HA AE defined in section 3.5.2. of 1045 [RFC3344], optionly followed by any non-authentication Extensions 1046 used only by the FA, optionly followed by The MN-FA AE defined in 1047 section 3.5.3 of [RFC3344] 1049 5. Future Extensibility 1051 The HA, FA, and MN SHOULD expose a list of the supported 1052 notifications to operators via some management interface, and there 1053 SHOULD be switches to enable / disable individual types of 1054 notifications and controllers to tune the retransmission timers for 1055 each type. 1057 There are several applications that could use this GNM. For example, 1058 during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP 1059 resource on the CDMA side has to be removed on the FA (PDSN) to avoid 1060 over-charging subscribers, anyway existing Registration Revocation 1061 RFC [RFC3543] is a one way to do this. Other applications such as HA 1062 switch over(before HA decide to go offline it would like to notify 1063 the MNs to register with another candidate HA), NEMO prefix 1064 changes(MN is notified by HA about NEMO prefix changes and service or 1065 billing related events, which is an operational requirement), Load 1066 balancing(HA wants to move some of the registered MNs to other HAs), 1067 Service Termination(due to end of prepaid time), and Service 1068 Interruption(due to system maintenance). 1070 This document describes how to use Generic String Extension [RFC4917] 1071 based on this notification mechanism. 1073 In some case, the HA or FA needs to notify the MN about service 1074 termination due to the end of prepaid time, or service interruption 1075 due to system maintenance. This information could be defined based 1076 on a string [RFC4917] which is easily recognized by the MN. An 1077 example would be "Maintenance Downtime", "Prepaid Expiration". On 1078 the other hand, the MN may need to notify the network about events 1079 related to a service such as a location change event, or a usage- 1080 preference change event. This information could be defined based on 1081 a string [RFC4917]. An example would be "Location Change" or 1082 "Service Event". These strings MUST be strictly defined so they 1083 could be easily understood by all of the network entities, and a 1084 suitable GNM Subtype number would have to be allocated. All such 1085 definitions are left for future specifications. 1087 For now, none of these above future semantics are supported except 1088 that the Generic String Extension is supported for informational 1089 purposes. There should be minimum requirements given here for adding 1090 additional extension types to the allowed set and defining their 1091 semantics. 1093 6. IANA Considerations 1095 This document describes two new messages, the GNM in section 4.1 and 1096 the GNAM in section 4.2. These two messages SHOULD be allocated from 1097 the same address space used by the Registration Request and 1098 Registration Reply messages in [RFC3344]. The subtype of these two 1099 messages indicate the information that GNM is carrying, and it will 1100 be under assigned by IANA namespace. 1102 This GNAM message, specified in section section 4.2, has a Code 1103 field. The number space for the Code field values is also specified 1104 in section 4.2. The Code number space is strucutred according to 1105 whether the notification was successful, or whether the HA denied the 1106 notification, or whether FA denied the notification, or whether MN 1107 denied the notification, as follows 1109 0 Success Code 1110 64-69 Error Codes from the FA 1111 128-133 Error Codes from the HA 1112 192-197 Error Codes from the MN 1114 Approval of new Code values require expert review. 1116 7. Security Considerations 1118 This specification operates in the security constraints and 1119 requirements of [RFC3344]. It require that when these message is 1120 transmitted between the MN and the HA, MN-HA AE is mandatory, when 1121 this message is transmitted between the MN and the FA, MN-FA AE is 1122 mandatory, when this message is transmitted between the FA and the 1123 HA, FA-HA AE is mandatory. It extends the operations of MN, HA and 1124 FA defined in [RFC3344] to notify each other about some events. The 1125 GNM message defined in the specification could carry information that 1126 modifies the mobility bindings. Therefore the message MUST be 1127 integrity protected. Replay protection MUST also be guaranteed. 1129 RFC 3344 provides replay protection only for registration requests 1130 sent by the MN. There is no mechanism for replay protection for 1131 messages initiated by a FA or a HA. The 64-bit Identification field 1132 specified in this document (Section 4.1 and 4.2) for the GNM message 1133 is used to provide replay protection for the notification messages 1134 initiated by the FA or HA. 1136 7.1. Replay Protection for GNM, GNAM messages 1138 The Identification field is used to let the receiving node verify 1139 that a GNM has been freshly generated by the sending node, not 1140 replayed by an attacker from some previous registration. Two methods 1141 are described in this section: timestamps (mandatory) and "nonces" 1142 (optional). All senders and receivers MUST implement timestamp-based 1143 replay protection. These nodes MAY also implement nonce-based replay 1144 protection 1146 The style of replay protection in effect between any two peer nodes 1147 among MN, FA and HA is part of the mobile security association. A 1148 sending node and its receiving node MUST agree on which method of 1149 replay protection will be used. The interpretation of the 1150 Identification field depends on the method of replay protection as 1151 described in the subsequent subsections. 1153 Whatever method is used, the low-order 32 bits of the Identification 1154 MUST be copied unchanged from the GNM to the GNMA. The receiver uses 1155 those bits (and the sender's source address) to match GNAM with 1156 corresponding replies. The receiver MUST verify that the low-order 1157 32 bits of any GNAM are identical to the bits it sent in the GNM. 1159 The Identification in a new GNM MUST NOT be the same as in an 1160 immediately preceding GNM, and SHOULD NOT repeat while the same 1161 security context is being used between the MN and the HA. 1163 7.1.1. Replay Protection using Timestamps 1165 The basic principle of timestamp replay protection is that the node 1166 generating a message inserts the current time of day, and the node 1167 receiving the message checks that this timestamp is sufficiently 1168 close to its own time of day. Unless specified differently in the 1169 security association between the nodes, a default value of 7 seconds 1170 MAY be used to limit the time difference. This value SHOULD be 1171 greater than 3 seconds. Obviously the two nodes must have adequately 1172 synchronized time-of-day clocks. As with any messages, time 1173 synchronization messages may be protected against tampering by an 1174 authentication mechanism determined by the security context between 1175 the two nodes. 1177 In this document, the timestamps are used, the sender MUST set the 1178 Identification field to a 64-bit value formatted as specified by the 1179 Network Time Protocol[RFC1305]. The low-order 32 bits of the NTP 1180 format represent fractional seconds . Note, however, that when using 1181 timestamps, the 64-bit Identification used in a GNM message from the 1182 sender MUST be greater than that used in any previous GNM message, as 1183 the receiver uses this field also as a sequence number. Without such 1184 a sequence number, it would be possible for a delayed duplicate of an 1185 earlier GNM message to arrive at the receiver (within the clock 1186 synchronization required by the receiver), and thus be applied out of 1187 order, mistakenly altering the sender's current status. 1189 Upon receipt of a GNM message with an authorization-enabling 1190 extension, the receiver MUST check the Identification field for 1191 validity. In order to be valid, the timestamp contained in the 1192 Identification field MUST be close enough to the receiver's time of 1193 day clock and the timestamp MUST be greater than all previously 1194 accepted timestamps for the requesting sender. Time tolerances and 1195 resynchronization details are specific to a particular mobility 1196 security association. 1198 If the timestamp is valid, the receiver copies the entire 1199 Identification field into the GNAM it returns the GNAM message to the 1200 sender. If the timestamp is not valid, the receiver copies only the 1201 low-order 32 bits into the GNAM, and supplies the high-order 32 bits 1202 from its own time of day. In this latter case, the receiver MUST 1203 reject the registration by returning Code 69/133/197 (identification 1204 mismatch) in the GNAM message. 1206 Furthermore, the receiver MUST verify that the low-order 32 bits of 1207 the Identification in the GNAM are identical to those in the rejected 1208 GNM attempt, before using the high-order bits for clock 1209 resynchronization. 1211 7.1.2. Replay Protection using Nonces 1213 The basic principle of nonce replay protection is that node A 1214 includes a new random number in every message to node B, and checks 1215 that node B returns that same number in its next message to node A. 1216 Both messages use an authentication code to protect against 1217 alteration by an attacker. At the same time node B can send its own 1218 nonces in all messages to node A (to be echoed by node A), so that it 1219 too can verify that it is receiving fresh messages. 1221 The receiver may be expected to have resources for computing pseudo- 1222 random numbers useful as nonces [RFC1750]. It inserts a new nonce as 1223 the high-order 32 bits of the identification field of every GNAM 1224 message. The receiver copies the low-order 32 bits of the 1225 Identification from the GNM message into the low-order 32 bits of the 1226 Identification in the GNAM message. When the sender receives an 1227 authenticated GNAM message from the receiver, it saves the high-order 1228 32 bits of the identification for use as the high-order 32 bits of 1229 its next GNM message. 1231 The sender is responsible for generating the low-order 32 bits of the 1232 Identification in each GNM message. Ideally it should generate its 1233 own random nonces. However it may use any expedient method, 1234 including duplication of the random value sent by the receiver. The 1235 method chosen is of concern only to the sender , because it is the 1236 node that checks for valid values in the GNAM message. The high- 1237 order and low-order 32 bits of the identification chosen SHOULD both 1238 differ from their previous values. The receiver uses a new high- 1239 order value and the sender uses a new low-order value for each 1240 registration message. 1242 If a GNM message is rejected because of an invalid nonce, the GNAM 1243 always provides the sender with a new nonce to be used in the next 1244 registration. Thus the nonce protocol is self- synchronizing. 1246 7.2. Non-authentication Extensions Handling in Foreign Agent 1248 When the FA is relaying the GNM message between the MN and the HA, 1249 and if the FA does not share a mobility security association with the 1250 MN or HA, all non-authentication extensions between MN and FA, or FA 1251 and HA are not protected; In this case, all non-authentication 1252 extensions should be silently discarded. 1254 8. Acknowledgments 1256 The author appreciate the efforts of Ahmad Muhanna for his detail 1257 reviewing of this document and his many contributions to the text of 1258 this document. The author also wants to thank Kent Leung, Peng Yang 1259 and Peter McCann et al. for their helping developing this document. 1260 Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E. 1261 Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu, 1262 Tim Polk, Amanda Baber, Sebastian Thalanany, and Joseph Salowey's 1263 discussion and comments. Thanks to Jari Arkko for each step of this 1264 document. 1266 9. Normative References 1268 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1269 Specification, Implementation", RFC 1305, March 1992. 1271 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1272 Recommendations for Security", RFC 1750, December 1994. 1274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1275 Requirement Levels", BCP 14, RFC 2119, March 1997. 1277 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ 1278 Organization-Specific Extensions", RFC 3115, April 2001. 1280 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1281 August 2002. 1283 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1284 Mobile IPv4", RFC 3543, August 2003. 1286 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 1287 String Extension", RFC 4917, June 2007. 1289 Authors' Addresses 1291 Hui Deng 1292 China Mobile 1293 53A,Xibianmennei Ave., 1294 Xuanwu District, 1295 Beijing 100053 1296 China 1298 Email: denghui02@gmail.com 1300 Henrik Levkowetz 1301 Ericsson Research 1302 Torshamsgatan 23 1303 S-164 80, Stockholm 1304 SWEDEN 1306 Email: henrik@levkowetz.com 1308 Vijay Devarapalli 1309 WiChorus 1310 3590 North First St 1311 San Jose, CA 1312 USA 1314 Email: dvijay@gmail.com 1316 Sri Gundavelli 1317 Cisco Systems 1318 170 W.Tasman Drive 1319 San Jose, CA 95134 1320 USA 1322 Email: sgundave@cisco.com 1324 Brian Haley 1325 Hewlett-Packard Company 1326 110 Spitbrook Road 1327 Nashua, NH 03062 1328 USA 1330 Email: brian.haley@hp.com