idnits 2.17.1 draft-ietf-mip4-generic-notification-message-10.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 5, 2009) is 5346 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 3344 (Obsoleted by RFC 5944) Summary: 3 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: March 9, 2010 Ericsson Research 6 V. Devarapalli 7 WiChorus 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 September 5, 2009 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-10.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 9, 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 . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . 18 93 4.5. Foreign Agent Consideration . . . . . . . . . . . . . . . 19 94 4.5.1. Receiving Generic Notification Message . . . . . . . . 19 95 4.5.2. Sending Generic Notification Acknowledgement 96 Messages . . . . . . . . . . . . . . . . . . . . . . . 21 97 4.5.3. Sending Generic Notification Messages . . . . . . . . 22 98 4.5.4. Receiving Generic Notification Acknowledgement 99 Messages . . . . . . . . . . . . . . . . . . . . . . . 22 100 4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 23 101 4.6.1. Sending Generic Notification Messages . . . . . . . . 23 102 4.6.2. Receiving Generic Notification Acknowledgement 103 Messages . . . . . . . . . . . . . . . . . . . . . . . 24 104 4.6.3. Receiving Generic Notification Messages . . . . . . . 25 105 4.6.4. Sending Generic Notification Acknowledgement 106 Messages . . . . . . . . . . . . . . . . . . . . . . . 26 107 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 27 108 5.1. Generic String Extension . . . . . . . . . . . . . . . . . 27 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 110 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 111 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 112 8.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 30 113 8.1.1. Replay Protection using Timestamps . . . . . . . . . . 30 114 8.2. Non-authentication Extensions Handling in Foreign Agent . 32 115 9. Normative References . . . . . . . . . . . . . . . . . . . . . 33 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 118 1. Introduction 120 In some situations, there is a need for Mobile IPv4 entities, such as 121 the home agent(HA), foreign agent(FA) and mobile node(MN) to send and 122 receive asynchronous notification messages during a mobility session. 123 The base Mobile IP Specification [RFC3344] does not have a provision 124 for this. 126 This document defines a generic message and a notification model that 127 can be used by Mobile IPv4 entities to send various notifications. 128 However, this specification does not define any specific notification 129 message or the actions that the receiving entity is required to 130 perform on receiving that message. Specific extensions and the 131 corresponding handler actions are outside the scope of this document. 133 2. Terminology 135 It is assumed that the reader is familiar with the terminology used 136 in [RFC4917], [RFC3344]. In addition, the following terms are 137 defined: 139 Notification Message 141 A message from a mobility agent to a MN or other mobility agent to 142 asynchronously notify it about an event that is relevant to the 143 mobility service it is currently providing. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119, [RFC2119]. 149 3. Notification message - Usage Scenario's 151 There are several scenarios where a mobility agent could initiate 152 notification events. Some of these are described in the following 153 sections. 155 3.1. Notification message between a Home Agent and a Mobile Node 157 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 159 In this case, the HA cannot directly notify the MN, but must send the 160 notification via the FA, vice versa. 162 +----+ notification +----+ notification +----+ 163 | MN |<================>| FA |<=============>| HA | 164 +----+ +----+ +----+ 166 Figure 1: HA notifies MN or MN notifies HA through FA 168 3.1.2. Mobile Registered using a Co-located Care-of Address 170 In this case, the MN has registered with the home agent directly, so 171 the notification message can go directly to the MN. 173 The notification mechanism as specified here does not support the 174 case of Co-located CoA mode with registration through a FA (due to 175 the 'R' bit being set in the FA's advertisement messages). 177 +----+ notification +----+ 178 | MN |<===================================>| HA | 179 +----+ +----+ 181 Figure 2: HA directly notifies MN or MN directly notifies HA 183 3.2. Notification message between a Foreign Agent and a Mobile Node 185 There are two cases where a FA may send notification messages to a 186 MN, one where it is relaying a message, the other where the 187 notification is triggered by a message from another network entity, 188 for example a AAA node(notification messages between a AAA entity and 189 the FA could be based on RADIUS or Diameter, but this is out of scope 190 for this document). If the notification is initiated by a FA, the FA 191 may need to also notify the HA about the event. 193 +----+ notification +----+ trigger +--------+ 194 | MN |<================>| FA |<=============| AAA | 195 +----+ +----+ +--------+ 196 || notification +----+ 197 ================>| HA | 198 +----+ 200 Figure 3: FA notifies MN 202 3.3. Notification message between a Home Agent and a Foreign Agent 204 The HA may also need to send a notification to the FA, but not to the 205 MN, The FA may also need to send a notification to the HA, as 206 illustrated below: 208 +----+ notification +----+ 209 | FA |<=============>| HA | 210 +----+ +----+ 212 Figure 4: HA notifies FA or FA notifies HA 214 4. Generic Notification Message and Considerations 216 This section describes in detail the Generic Notification Message 217 (GNM), Generic Notification Acknowledgement Message (GNAM), and some 218 considerations related to the handling of these messages in the MN, 219 FA and HA. 221 The MN and HA MUST maintain the following information, the FA also 222 need maintain both HA's and MN's direction the below information: 224 - the IP source address of the Registration Request/Reply 226 - the IP destination address of the Registration Request/Reply 228 - the UDP source port of the Registration Request/Reply 230 - the UDP destination port of the Registration Request/Reply 232 The sending node always sends the GNM message following the same 233 procedure for sending Registration Request as in section 3.3 of 234 [RFC3344] and the receiving node follows the same procedure for 235 Registration Reply as in section 3.4. of [RFC3344] when sending GNAM. 237 4.1. Generic Notification Message 239 A GNM is sent by a mobility agent to inform another mobility agent, 240 or a MN, of MIP-related information such as vendor specific 241 extensions[RFC3115] and generic string notification[RFC4917]. These 242 messages MUST use the same IP and UDP headers as any previous 243 Registration Request(RRQ) or Reply (RRP) message to the same entity. 244 This would support NAT traversal and ensure same security association 245 used for GNM/GNAM and RRQ/RRP. The GNM is defined as follows: 247 IP Fields: 249 Source Address Copied from the source address field of the 250 last Registration Reply/Request message 251 sent. 253 Destination Address Copied from the source address field of the 254 last Registration Reply/Request message 255 sent. 257 UDP Fields: 259 Source Port Copied from the source address field of the 260 last Registration Reply/Request message 261 sent. 263 Destination Port Copied from the source address field of the 264 last Registration Reply/Request message 265 sent. 267 The UDP header is followed by the Mobile IP fields shown below: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Subtype | MD |A| Reserved | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Home Address | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Home Agent Address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Care-of Address | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 + Identification + 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Extensions... 285 +-+-+-+-+-+-+-+-+-+-+-+-+- 287 Type (TBD) 289 Subtype 291 This field describes the particular type of notification which is 292 carried in the notification message. The following values are 293 reserved in this document. 295 0 Reserved 297 1 Information carried in Vendor specific extensions which is 298 specified in [RFC3115]. 300 2 Information carried in Generic String extensions which is 301 specified in [RFC4917]. 303 The value 0 is reserved and SHOULD NOT be used. The value 1 304 indicates that the actual information is carried in vendor 305 specific extensions. Other values are reserved for future 306 extensions. 308 MD: Message Direction 310 This memo defines the semantics of the following MD field value: 312 0 -- Message sent by the HA to the MN 314 1 -- Message sent by the HA to the FA 316 2 -- Message sent by the MN to the HA 318 3 -- Message sent by the MN to the FA 320 4 -- Message sent by the FA to the MN 322 5 -- Message sent by the FA to the HA 324 A 326 This bit indicates whether the notification message MUST be 327 acknowledged by the recipient. If "A" bit has been set during the 328 message, but the sender doesn't receive any acknowledgement 329 message, the sender will have to resend the notification message 330 again. 332 Set to "1" to indicate that acknowledgement is required. 334 Set to "0" to indicate that acknowledgement is optional. 336 Reserved 338 MUST be sent as 0, and ignored when received. 340 Home Address 342 The home IP address of the mobile node. 344 Home Agent Address 346 The IP address of the mobile node's HA. 348 Care-of Address 350 The mobile node's care-of address, either the Co-located Care-of 351 Address or the foreign agent care-of address. 353 Identification 354 A 64-bit number, constructed by the sender, used for matching GNM 355 with GNAM, and for protecting against replay attacks of 356 notification messages. Here is the same as Sections 5.4 and 5.7 357 of [RFC3344]. Timestamps is mandatory. 359 Extensions 361 The fixed portion of the GNM is followed by one or more extensions 362 which may be used with this message, and by one or more 363 authentication extensions (as defined in Section 3.5 of [RFC3344]. 364 This document mandates the MN-HA Authentication Extension (AE) 365 when this message is sent between the MN and the HA, others are 366 optional. This document also mandate the MN-FA AE when this 367 message is sent between the MN and the FA, others are optional. 368 This document mandate the FA-HA AE when this message is sent 369 between the FA and the HA, others are optional. This could be 370 judged based on "MD" value.). See Sections 3.6.1.3 and 3.7.2.2 of 371 [RFC3344] for the rules on the order of these extensions as they 372 appear in Mobile IPv4 RRQ and RRP messages. The same rules are 373 applicable to GNM and GNAM. 375 4.2. Generic Notification Acknowledgment Message 377 A GNAM is sent by mobility agents or MNs to indicate the successful 378 receipt of a GNM. 380 IP Fields: 382 Source Address Typically copied from the destination 383 address of the GNM to which the agent is 384 replying. 386 Destination Address Copied from the source address of the GNM to 387 which the agent is replying. 389 UDP Fields: 391 Source Port Copied from the destination port of the 392 corresponding GNM. 394 Destination Port Copied from the source port of the 395 corresponding GNM. 397 The UDP header is followed by the Mobile IP fields shown below: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Subtype | MD | code | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Home Address | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Home Agent Address | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Care-of Address | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 411 + Identification + 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Extensions... 415 +-+-+-+-+-+-+-+-+-+-+-+-+- 417 Type (TBD) 419 Subtype 421 This field specifies the particular type of notification 422 acknowledgement message. The following values are reserved in 423 this document. 425 0 Reserved 427 1 Information carried in Vendor specific extensions which is 428 specified in [RFC3115]. 430 2 Information carried in Generic String extensions which is 431 specified in [RFC4917]. 433 The value 0 is reserved and SHOULD NOT be used. The value 1 434 indicates that the actual information is carried in vendor 435 specific extensions. Other values are reserved for future 436 extensions. 438 MD: Message Direction 440 This memo defines the semantics of the following MD field value: 442 0 -- Message sent by the HA to the MN 444 1 -- Message sent by the HA to the FA 445 2 -- Message sent by the MN to the HA 447 3 -- Message sent by the MN to the FA 449 4 -- Message sent by the FA to the MN 451 5 -- Message sent by the FA to the HA 453 code 455 A value indicating the result of the GNM. See below for a list of 456 currently defined Code values. 458 Notification suceessful 460 0 -- notification accepted 462 Notification denied by the HA 464 128 -- reason unspecified 466 129 -- administratively prohibited 468 130 -- insufficient resources 470 131 -- mobile node failed authentication 472 132 -- foreign agent failed authentication 474 133 -- notification Identification mismatch 476 Notification denied by the FA 478 64 -- reason unspecified 480 65 -- administratively prohibited 482 66 -- insufficient resources 484 67 -- mobile node failed authentication 486 68 -- home agent failed authentication 488 69 -- notification Identification mismatch 490 Notification denied by the mobile node 491 192 -- reason unspecified 493 193 -- administratively prohibited 495 194 -- insufficient resources 497 195 -- foreign agent failed authentication 499 196 -- home agent failed authentication 501 197 -- notification Identification mismatch 503 Home Address 505 The home IP address of the mobile node. 507 Home Agent Address 509 The IP address of the sender's home agent. 511 Care-of Address 513 The mobile node's care-of address, either the Co-located Care-of 514 Address or the foreign agent care-of address. 516 Identification 518 If the timestamp of the GNM is valid, the receiver copies the 519 entire Identification field into the GNAM it returns the GNAM 520 message to the sender. If the timestamp of the GNM is not valid, 521 the receiver copies only the low-order 32 bits into the GNAM, and 522 supplies the high-order 32 bits from its own time of day. Both 523 GNM and GNAM mandate Timestamps. 525 Extensions 527 The fixed portion of the GNAM is followed by one or more of the 528 Extensions listed in Section 3.5 of [RFC3344]. See Sections 529 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the order of 530 these extensions as they appear in Mobile IPv4 RRQ and RRP 531 messages. The same rules are applicable to GNM and GNAM. 533 4.3. Notification Retransmision 535 If "A" flag has been set during the GNM message, but the sender 536 doesn't receive any GNAM message within a reasonable time, another 537 GNM will be retransmited. When timestamps are used, a new 538 registration Identification is chosen for each retransmision; Thus it 539 counts as a new GNM. 541 The maximum time until a new GNM is sent SHOULD be no greater than 542 the requested Lifetime of the last Registration Request. The minimum 543 value SHOULD be large enough to account for the size of the messages, 544 twice the round trip time for transmission to the receiver, and at 545 least an additional 100 milliseconds to allow for processing the 546 messages before responding. The round trip time for transmission to 547 the receiver will be at least as large as the time required to 548 transmit the messages at the link speed of the MN's current point of 549 attachment. Some circuits add another 200 milliseconds of satellite 550 delay in the total round trip time to the receiver. The minimum time 551 between GNM MUST NOT be less than 1 second. Each successive 552 retransmission timeout period SHOULD be at least twice the previous 553 period, as long as that is less than the maximum as specified above. 555 4.4. Mobile Node Consideration 557 It is possible that the MN MAY receive a GNM from a FA or HA. Both 558 in the case of FA-CoA and Co-located CoA, the MN MAY reply with a 559 GNAM based on the "A" flag in the GNM message. 561 4.4.1. Receiving Generic Notification Messages 563 When the MN is using FA-CoA and receives a Notification message, if 564 the "MD" value is 0, it means that the notification message came from 565 the HA. If the "MD" value is 4, the notification came from the FA. 567 If this notification message came from a FA and the MN accepts the 568 FA's GNM, it will process the notification extension according to the 569 specific rules for that extension. 571 The MN MUST check for the presence of an authorization-enabling 572 extension, and perform the indicated authentication. Exactly one 573 authorization-enabling extension MUST be present in the GNM, if this 574 message came from a FA, MN-FA AE MUST be present, If no MN-FA AE is 575 found, or if more than one MN-FA AE is found, or if the Authenticator 576 is invalid, the MN MUST reject the GNM and MAY send a GNAM to the FA 577 with Code 195, including an Identification field computed in 578 accordance with the rules specified in Section 8.1. The MN MUST do 579 no further processing with such a notification, though it SHOULD log 580 the error as a security exception. 582 The MN MUST check that the Identification field is correct using the 583 context selected by the SPI within mandatory authentication extension 584 like MN-FA AE or MN-HA AE. See Section 8.1 for a description of how 585 this is performed. If incorrect, the MN MUST reject the GNM and MAY 586 send a GNAM to the initiator with Code 197, including an 587 Identification field computed in accordance with the rules specified 588 in Section 8.1. The MN MUST do no further processing with such a 589 notification, though it SHOULD log the error as a security exception. 591 After that, the MN MAY reply GNAM back to the FA. If the "A" flag is 592 set in the GNM, then the MN MUST send the GNAM. 594 If this notification message came from the HA, relayed by the FA, or 595 is a Co-located CoA, the MN-HA AE MUST be checked and the MN MUST 596 check the Authenticator value in the Extension. If no MN-HA AE is 597 found, or if more than one MN-HA AE is found, or if the Authenticator 598 is invalid, the MN MUST reject the GNM and MAY send a GNAM to the 599 initiator with Code 196, including an Identification field computed 600 in accordance with the rules specified in Section 8.1. The MN MUST 601 do no further processing with such a notification, though it SHOULD 602 log the error as a security exception. If the MN accepts the HA's 603 GNM, it will process it according to the specific rules for that 604 extension. After that, the MN MAY reply with a GNAM with Code 0 back 605 to the HA based on the "A" flag in the GNM. 607 4.4.2. Sending Generic Notification Acknowledgement Message 609 Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply 610 with a GNAM based on the "A" flag in the GNM as follows: 612 If the GNM was initiated from the FA to the MN ("MD" value is set to 613 4), MN-FA AE MUST be the last extension in order to protect all other 614 non-authentication extensions as defined in section 3.5.3 of 615 [RFC3344]. 617 In the case of a FA-CoA, the source address is the MN's address, the 618 destination address is the FA's address. 620 The Code field of the GNAM is chosen in accordance with the rules 621 specified in the section 4.2. When replying to an accepted 622 notification, a MN SHOULD respond with Code 0. 624 There are a number of reasons the MN might reject a notification such 625 as administrative in nature returning a GNAM with a code of 193, 626 similarly and provides the Code value 192 or 194 for the unspecified 627 reason and insufficient resources. 629 If the GNM was initiated from the HA to the MN ("MD" value is set to 630 0) and in the case of Co-located CoA, MN-HA AE MUST be the last 631 extension in order to protect all other non-authentication extensions 632 as defined in section 3.5.2 of [RFC3344] 634 In the case of a FA-CoA, the source address is the MN's HoA address 635 and the destination address is the FA's address ("MD" value is set to 636 2), the ordering of the extension is: any non-authentication 637 Extensions used only by the HA, followed by the MN-HA AE defined in 638 section 3.5.2. of [RFC3344], followed by any non-authentication 639 Extensions used only by the FA, followed by The MN-FA AE defined in 640 section 3.5.3 of [RFC3344]. 642 4.4.3. Sending Generic Notification Messages 644 The MN may either send a GNM to notify the FA or HA. 646 If the message is sent to the FA, the source address is the MN's 647 address, and the destination address is the FA's address 649 If the FA is the target of this notification message, then the "MD" 650 value is set to 3, MN-FA AE MUST be the last extension in order to 651 protect all other non-authentication extensions. Computing 652 Authentication Extension Value is the same as section 3.5.1 of 653 [RFC3344]. 655 If the FA is working only as a relay agent, the "MD" value is set to 656 2, and the ordering of the extension is: the notification extension, 657 followed by any non-authentication extension expected to be used by 658 HA, followed by MN-HA AE defined in section 3.5.2. of [RFC3344], 659 followed by any non-authentication Extensions used only by the FA, 660 followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 661 Computing Authentication Extension Value is the same as section 3.5.1 662 of [RFC3344]. 664 In the case of a Co-located CoA, the MN MAY send a notification 665 message directly to the HA if it needs to be notified. The "MD" 666 value is set to 2, and the ordering of the extension is: the 667 notification extension, followed by any non-authentication extension 668 expected to be used by HA, followed by MN-HA AE defined in section 669 3.5.2 of [RFC3344]. 671 The MN chooses the Identification field in accordance with the style 672 of replay protection it uses with its HA. This is part of the 673 mobility security association the MN shares with its HA. See Section 674 8.1 for the method by which the MN computes the Identification field. 676 4.4.4. Receiving Generic Notification Acknowledgement Messages 678 In the case of a FA-CoA, if the MN receives this message, and the 679 "MD" value is set to 0, it means that the GNAM came from HA 681 If the "MD" value is set to 4, the MN-FA AE MUST be checked, and the 682 MN MUST check the Authenticator value in the Extension. If no MN-FA 683 AE is found, or if more than one MN-FA AE is found, or if the 684 Authenticator is invalid, the MN MUST silently discard the GNAM. 686 In addition, the low-order 32 bits of the Identification field in the 687 GNAM MUST be compared to the low-order 32 bits of the Identification 688 field in the most recent GNM sent to the replying agent. If they do 689 not match, the GNAM MUST be silently discarded. 691 If the "MD" value is set to 0, the MN-HA AE MUST be checked, and the 692 MN MUST check the Authenticator value in the Extension. If no MN-HA 693 AE is found, or if more than one MN-HA AE is found, or if the 694 Authenticator is invalid, the MN MUST silently discard the GNAM. If 695 the MN accepted this message, the MN MAY also process it based on the 696 notification event. 698 In the case of a Co-located CoA, if the MN received this message, the 699 MN-HA AE MUST be checked, and the MN MUST check the Authenticator 700 value in the Extension. If no MN-HA AE is found, or if more than one 701 MN-HA AE is found, or if the Authenticator is invalid, the MN MUST 702 silently discard the Notification Acknowledgement message. 704 4.5. Foreign Agent Consideration 706 The FA may initiate a GNM to the MN or the HA. Additionally, the FA 707 also relays GNM and GNAM messages between the MN and its HA as long 708 as there is an active binding for the MN at the FA. 710 4.5.1. Receiving Generic Notification Message 712 If the FA receives a GNM, and the "MD" value is set to 0, it means 713 that the HA is asking the FA to relay the message to the MN. If the 714 "MD" value is set to 1, it means that the target of the notification 715 is the FA. If the "MD" value is set to 2, it means that the MN is 716 asking the FA to relay the message to the HA. If the "MD" value is 717 set to 3, it means that the notification came from the MN to the FA. 719 If the "MD" value is set to 0, the FA MAY validate the FA-HA AE if 720 present. If the FA-HA AE is invalid, all extensions between the 721 HA-MN AE and the HA-FA AE MUST be removed, FA SHOULD relay the GNM to 722 the MN's home address as specified in the Home Address field of the 723 GNM, MN will eventually validate the MN-HA AE to ensure that all 724 information sent to the MN is integrity protected. If the FA-HA AE 725 is valid, FA MUST relay the GNM to the MN's home address as specified 726 in the Home Address field of the GNM. The FA MUST NOT modify any of 727 the fields beginning with the fixed portion of the GNM through the 728 MN-HA AE or other authentication extension supplied by the HA as an 729 authorization-enabling extension for the MN. 731 Furthermore, the FA MUST process and remove any extensions following 732 the MN-HA AE. If the FA shares a mobility security association with 733 the MN, the FA MAY append any of its own non-authentication 734 extensions which of relevance to the MN. In this case, the FA MUST 735 append the MN-FA AE after these non-authentication extensions. 737 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 738 FA MUST check the Authenticator value in the Extension. If no FA-HA 739 AE is found, or if more than one FA-HA AE is found, or if the 740 Authenticator is invalid, the FA MUST reject the GNM and MAY send a 741 GNAM to the HA with Code 68, including an Identification field 742 computed in accordance with the rules specified in Section 8.1. The 743 FA MUST do no further processing with such a notification, though it 744 SHOULD log the error as a security exception. 746 The FA MUST check that the Identification field is correct using the 747 context selected by the SPI within mandatory FA-HA AE. See Section 748 8.1 for a description of how this is performed. If incorrect, the FA 749 MUST reject the GNM and MAY send a GNAM to the initiator with Code 750 69, including an Identification field computed in accordance with the 751 rules specified in Section 8.1. The FA MUST do no further processing 752 with such a notification, though it SHOULD log the error as a 753 security exception. 755 If FA accepts the HA's GNM, it will process it based on the specific 756 rules for that extension. The FA MAY then reply with a GNAM with 757 Code 0 back to the MN based on the "A" flag in the GNM. 759 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 760 received this message, and if the MN-FA AE is present, the MN-FA AE 761 MUST be checked, and the FA MUST check the Authenticator value in the 762 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 763 found, or if the Authenticator is invalid, the FA MUST silently 764 discard the GNM message. If MN-FA is valid, FA MUST relay the GNM to 765 the HA's address as specified in the Home Agent Address field of the 766 GNM, HA will eventually validate the MN-HA AE to ensure that all 767 information sent to the HA is integrity protected. The FA MUST NOT 768 modify any of the fields beginning with the fixed portion of the GNM 769 through the MN-HA AE or other authentication extension supplied by 770 the MN as an authorization-enabling extension for the HA. 772 Furthermore, the FA MUST process and remove any Extensions following 773 the MN-HA AE, and MAY append any of its own non-authentication 774 Extensions of relevance to the HA if applicable, and MUST append the 775 FA-HA AE, if the FA shares a mobility security association with the 776 HA. 778 If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the 779 FA MUST check the Authenticator value in the Extension which is the 780 same as the section 3.7.2.1 of RFC 3344. If no MN-FA AE is found, or 781 if more than one MN-FA AE is found, or if the Authenticator is 782 invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN 783 with Code 67, including an Identification field computed in 784 accordance with the rules specified in Section 8.1. The FA MUST do 785 no further processing with such a notification, though it SHOULD log 786 the error as a security exception. 788 The FA MUST check that the Identification field is correct using the 789 context selected by the SPI within mandatory MN-FA AE. See Section 790 8.1 for a description of how this is performed. If incorrect, the FA 791 MUST reject the GNM and MAY send a GNAM to the initiator with Code 792 69, including an Identification field computed in accordance with the 793 rules specified in Section 8.1. The FA MUST do no further processing 794 with such a notification, though it SHOULD log the error as a 795 security exception. 797 If FA accepts the MN's GNM, it will process it based on the specific 798 rules for that extension. The FA MAY then reply with a GNAM with 799 Code 0 back to the MN based on the "A" flag in the GNM. 801 4.5.2. Sending Generic Notification Acknowledgement Messages 803 The FA may need to either relay a GNAM message between the MN and the 804 HA or send one as a response to a GNM messsage that was sent to it. 805 In both cases, the GNAM message is defined as follows: 807 The source address is the FA address, the destination address is HA's 808 or MN's home address. 810 The Code field of the GNAM is chosen in accordance with the rules 811 specified in the section 4.2. When replying to an accepted 812 notification, a FA SHOULD respond with Code 0. 814 There are a number of reasons the FA might reject a notification such 815 as administrative in nature returning a GNAM with a code of 65, 816 similarly and provides the Code value 64 or 66 for the unspecified 817 reason and insufficient resources. 819 If the FA is only relaying this message to the HA, the FA MUST NOT 820 modify any of the fields beginning with the fixed portion of the GNAM 821 through the including the MN-HA AE or other authentication extension 822 supplied by the MN as an authorization-enabling extension for the MN. 823 Furthermore, the foreign agent MUST process and remove any Extensions 824 following the MN-HA AE. If the FA shares a mobility security 825 association with the HA, the FA MAY append any of its own non- 826 authentication extensions which of relevance to the HA, In this case 827 the FA MUST append the FA-HA AE after these non-authentication 828 extensions. 830 If the notification message is from the HA to the FA then the "MD" 831 value is set to 5 and the ordering of the extension is: any non- 832 authentication Extensions used only by the FA, followed by The FA-HA 833 AE defined in section 3.5.4 of [RFC3344]. 835 If the notification message is from the MN to the FA then the "MD" 836 value is set to 4 and the ordering of the extension is: any non- 837 authentication Extensions used only by the FA, followed by The MN-FA 838 AE defined in section 3.5.3 of [RFC3344]. 840 4.5.3. Sending Generic Notification Messages 842 If the FA is initiating a notification to the MN using the GNM, it 843 MAY also notify the HA as well. 845 In the message to the MN, the source address is the FA address, the 846 destination address is the MN's address, the "MD" value is set to 4, 847 and the ordering of the extension is: the notification extension, 848 followed by any non-authentication Extensions used only by the MN, 849 followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 850 Computing Authentication Extension Value is the same as section 3.5.1 851 of [RFC3344] except the payload is the notification other than 852 registration. 854 In the message to the HA, the source address is the FA's address, the 855 destination address is the HA's address (the "MD" value is set to 5), 856 and the ordering of the extension is: notification extension, 857 followed by any non-authentication Extensions used only by the HA, 858 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 859 Computing Authentication Extension Value is the same as section 3.5.1 860 of [RFC3344] except the payload is the notification other than 861 registration. 863 4.5.4. Receiving Generic Notification Acknowledgement Messages 865 In the case of a FA-CoA, if the FA receives this message, and the 866 "MD" value is set to 3, it means that the notification 867 acknowledgement message came from the MN, otherwise it came from the 868 HA. 870 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 871 FA MUST check the Authenticator value in the Extension. If no FA-HA 872 AE is found, or if more than one FA-HA AE is found, or if the 873 Authenticator is invalid, the FA MUST silently discard the 874 Notification Acknowledgement message. If the FA accepted this 875 message, the FA MAY also process it based on the notification event. 877 If the "MD" value is set to 3, if the MN-FA AE is present, it MUST be 878 checked, and the FA MUST check the Authenticator value in the 879 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 880 found, or if the Authenticator is invalid, the FA MUST silently 881 discard the GNAM message. If the FA accepted this message, the FA 882 MAY also process it based on the notification event. 884 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 885 received this message, and if the MN-FA AE is present, the MN-FA AE 886 MUST be checked, and the FA MUST check the Authenticator value in the 887 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 888 found, or if the Authenticator is invalid, the FA MUST silently 889 discard the GNAM message. If FA accepted the MN's GNAM message, it 890 MUST relay this message to the HA. The FA MUST NOT modify any of the 891 fields beginning with the fixed portion of the GNAM message through 892 the including the MN-HA AE or other authentication extension supplied 893 by the HA as an authorization-enabling extension for the MN. 894 Furthermore, the FA MUST process and remove any Extensions following 895 the MN-HA AE and MAY append any of its own non-authentication 896 Extensions of relevance to the HA, if applicable, and MUST append the 897 FA-HA AE, if the FA shares a mobility security association with the 898 HA. 900 4.6. Home Agent Consideration 902 The HA MAY initiate a GNM message to both the mobile node and FA, and 903 it also MAY receive a GNAM message from both the FA and MN. The HA 904 also MAY receive a GNM message from the FA, but only when there is a 905 binding for a MN. If the HA receives a GNM from a FA and there is no 906 corresponding MN registration, the HA SHOULD drop the GNM message. 908 4.6.1. Sending Generic Notification Messages 910 In the case of a FA-CoA, the HA may either send a GNM to notify the 911 FA, or have the FA relay the GNM to the MN if the MN needs to be 912 notified. 914 If the message is from the HA to the FA, the source address is the 915 HA's address, and the destination address is the FA's address 917 If the FA is working only as a relay agent, the "MD" value is set to 918 0, and the ordering of the extension is: the notification extension, 919 followed by any non-authentication extension expected to be used by 920 MN, followed by MN-HA AE defined in section 3.5.2. of [RFC3344], 921 followed by any non-authentication Extensions used only by the FA, 922 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 924 Computing Authentication Extension Value is the same as section 3.5.1 925 of [RFC3344]. 927 If the FA is the target of this notification message, then the "MD" 928 value is set to 1, and the ordering of the extension is: the 929 notification extension, followed by any non-authentication Extensions 930 used only by the FA, followed by The FA-HA AE defined in section 931 3.5.4 of [RFC3344]. Computing Authentication Extension Value is the 932 same as section 3.5.1 of [RFC3344]. 934 In the case of a Co-located CoA, the HA MAY send a notification 935 message directly to the MN if it needs to be notified. The "MD" 936 value is set to 0, and the ordering of the extension is: the 937 notification extension, followed by any non-authentication extension 938 expected to be used by MN, followed by MN-HA AE defined in section 939 3.5.2. of [RFC3344]. 941 4.6.2. Receiving Generic Notification Acknowledgement Messages 943 In the case of a FA-CoA, if the HA receives this message, and the 944 "MD" value is set to 2, it means that the GNAM message came from MN. 946 If the "MD" value is set to 5, and the HA accepted this message, the 947 HA MAY also process it based on the notification event. The FA-HA AE 948 MUST be checked, and the HA MUST check the Authenticator value in the 949 Extension. If no FA-HA AE is found, or if more than one FA-HA AE is 950 found, or if the Authenticator is invalid, the HA MUST silently 951 discard the GNAM message. 953 If the "MD" value is set to 2, in the case of a FA-CoA, and if FA-HA 954 AE is present, the FA-HA AE MUST be checked, and the HA MUST check 955 the Authenticator value in the Extension. If more than one FA-HA AE 956 is found, or if the Authenticator is invalid, the HA MUST silently 957 discard the GNAM message. Anyway, MN-HA AE MUST be checked, and the 958 HA MUST check the Authenticator value in the Extension. If no MN-HA 959 AE is found, or if more than one MN-HA AE is found, or if the 960 Authenticator is invalid, the HA MUST silently discard the GNAM. If 961 the HA accepted this message, the HA MAY also process it based on the 962 notification event. 964 If the "MD" value is set to 2, in the case of a Co-located CoA, MN-HA 965 AE MUST be checked, and the HA MUST check the Authenticator value in 966 the Extension. If no MN-HA AE is found, or if more than one MN-HA AE 967 is found, or if the Authenticator is invalid, the HA MUST silently 968 discard the GNAM. If the HA accepted this message, the HA MAY also 969 process it based on the notification event. 971 4.6.3. Receiving Generic Notification Messages 973 The HA MAY receive a GNM message sent from the FA. When the HA 974 receives this message, if the the "MD" value is set to 5, this 975 message came from FA. FA-HA AE MUST be checked, and the HA MUST 976 check the Authenticator value in the Extension. If no FA-HA AE is 977 found, or if more than one FA-HA AE is found, or if the Authenticator 978 is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA 979 with Code 132, including an Identification field computed in 980 accordance with the rules specified in Section 8.1. The HA MUST do 981 no further processing with such a notification, though it SHOULD log 982 the error as a security exception. 984 The HA MUST check that the Identification field is correct using the 985 context selected by the SPI within mandatory authentication extension 986 like MN-HA AE or FA-HA AE. See Section 8.1 for a description of how 987 this is performed. If incorrect, the HA MUST reject the GNM and MAY 988 send a GNAM to the initiator with Code 133, including an 989 Identification field computed in accordance with the rules specified 990 in Section 8.1. The HA MUST do no further processing with such a 991 notification, though it SHOULD log the error as a security exception. 992 If HA accepts the FA's GNM message, it will process it based on the 993 notification extension. Furthermore, the HA MAY reply with a GNAM 994 message with Code 0 back to the FA based on the "A" flag in the GNM 995 message. 997 If the the "MD" value is set to 2, this message come from MN, in the 998 case of FA-COA, if FA-HA AE is present, it MUST be checked, and the 999 HA MUST check the Authenticator value in the Extension. If more than 1000 one FA-HA AE Extension is found, or if the Authenticator is invalid, 1001 the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 1002 132, including an Identification field computed in accordance with 1003 the rules specified in Section 8.1. The HA MUST do no further 1004 processing with such a notification, though it SHOULD log the error 1005 as a security exception. And MN-HA AE MUST be checked, and the HA 1006 MUST check the Authenticator value in the Extension. If no MN-HA AE 1007 is found, or if more than one MN-HA AE is found, or if the 1008 Authenticator is invalid, the HA MUST reject the GNM and MAY send a 1009 GNAM to the MN with Code 131, including an Identification field 1010 computed in accordance with the rules specified in Section 8.1. The 1011 HA MUST do no further processing with such a notification, though it 1012 SHOULD log the error as a security exception. If HA accepts the MN's 1013 GNM message, it will process it based on the notification extension. 1014 Furthermore, the HA MAY reply with a GNAM message back to the MN with 1015 Code 0 based on the "A" flag in the GNM message. 1017 If the the "MD" value is set to 2, in the case of a Co-located CoA, 1018 the MN-HA AE MUST be checked, and the HA MUST check the Authenticator 1019 value in the Extension. If no MN-HA AE is found, or if more than one 1020 MN-HA AE is found, or if the Authenticator is invalid, the HA MUST 1021 reject the GNM and MAY send a GNAM to the MN with Code 131, including 1022 an Identification field computed in accordance with the rules 1023 specified in Section 8.1. The HA MUST do no further processing with 1024 such a notification, though it SHOULD log the error as a security 1025 exception. If HA accepts the MN's GNM message, it will process it 1026 based on the notification extension. Furthermore, the HA MAY reply 1027 with a GNAM message back to the MN with Code 0 based on the "A" flag 1028 in the GNM message. 1030 4.6.4. Sending Generic Notification Acknowledgement Messages 1032 If the GNM message came from the FA only, and if the "A" flag is set 1033 in the GNM message, then the HA MUST send a GNAM message. The 1034 message is as follows: The source address is HA's address, the 1035 destination address is the FA's address, the "MD" value is set to 1. 1036 The ordering of the extension is: any non-authentication Extensions 1037 used only by the FA, followed by The Foreign-Home Authentication 1038 extension defined in section 3.5.4 of [RFC3344]. 1040 The Code field of the GNAM is chosen in accordance with the rules 1041 specified in the section 4.2. When replying to an accepted GNM, a MN 1042 SHOULD respond with Code 0. 1044 If the GNM message came from the MN, the HA MAY reply with a GNAM 1045 message to the MN based on the "A" flag in the GNM message. If the 1046 "A" flag is set in the GNM message, then the HA MUST send a GNAM 1047 message. The message is as follows: The source address is HA's 1048 address, the destination address is the FA's address, the "MD" value 1049 is set to 0. The ordering of the extension is: any non- 1050 authentication Extensions used only by the MN, followed by the MN-HA 1051 AE defined in section 3.5.2. of [RFC3344], optionly followed by any 1052 non-authentication Extensions used only by the FA, optionly followed 1053 by The MN-FA AE defined in section 3.5.3 of [RFC3344] 1055 5. Usage Example 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 of CDMA side have to be removed on the FA (PDSN) to avoid 1060 over-charging subscribers. Other applications such as HA switch 1061 over, NEMO prefix changes, service or billing related events, load 1062 balancing where the HA wants to move some of the registered mobile 1063 nodes to other HAs, service termination due to end of prepaid time, 1064 and service interruption due to system maintenance. 1066 Here we describe some possible event which could use the generic 1067 string extension [RFC4917] based on this notification mechanism also. 1068 There is also the possibility that this notification message could 1069 carry many extensions at once. A new VSE extension could be defined 1070 to support this notification message. 1072 5.1. Generic String Extension 1074 In some case, the HA or FA needs to notify the mobile node about 1075 service termination due to the end of prepaid time, or service 1076 interruption due to system maintenance. This information could be 1077 defined based on a string [RFC4917] which is recognized by the MN 1078 easily. An example would be "Maintenance Downtime", "Prepaid 1079 Expiration". These string MUST be strictly defined so they could be 1080 easily understood by all of the network entities, and a suitable GNM 1081 Subtype number would have to be allocated. All such definitions are 1082 left for future specifications. 1084 6. IANA Considerations 1086 This document describes two new messages, the GNM in section 4.1 and 1087 the GNAM in section 4.2. These two messages SHOULD be allocated from 1088 the same address space used by the Registration Request and 1089 Registration Reply messages in [RFC3344]. The subtype of these two 1090 messages indicate what kind of information is carried and will be 1091 under assigned by IANA namespace. 1093 This document creates a new IANA registry for the Subtype field in 1094 the GNM and GNAM. New values MUST be allocated by Standards Actions 1095 or IETF Consensus. This document reserves three values for the 1096 Subtype field 1098 0 Reserved 1100 1 Information carried in Vendor specific extensions 1102 2 Information carried in Generic String Extension 1104 This GNAM message, specified in section section 4.2, has a Code 1105 field. The number space for the Code field values is also specified 1106 in section 4.2. The Code number space is strucutred according to 1107 whether the notification was successful, or whether the HA denied the 1108 notification, or whether FA denied the notification, or whether MN 1109 denied the notification, as follows 1111 0 Success Code 1112 64-69 Error Codes from the FA 1113 128-133 Error Codes from the HA 1114 192-197 Error Codes from the MN 1116 Approval of new Code values require expert review. 1118 7. Acknowledgments 1120 The author appreciate the efforts of Ahmad Muhanna in detail 1121 reviewing of this document, lots of text have been contributed by his 1122 suggestions. The author thank the discussion from Kent Leung, Peng 1123 Yang and Peter McCann et al. in the development of this document. 1124 Thanks to Alexey Melnikov's discussion and comments. Thanks to Jari 1125 Arkko for each step of this document. 1127 8. Security Considerations 1129 This specification operates in the security constraints and 1130 requirements of [RFC3344]. It require that when this message is 1131 transmitted between the MN and the HA, MN-HA AE is mandatory, when 1132 this message is transmitted between the MN and the FA, MN-FA AE is 1133 mandatory, when this message is transmitted between the FA and the 1134 HA, FA-HA AE is mandatory. It extends the operations of MN, HA and 1135 FA defined in [RFC3344] to notify each other about some events. The 1136 GNM message defined in the specification could carry information that 1137 modifies the mobility bindings. Therefore the message MUST be 1138 integrity protected. Replay protection MUST also be guaranteed. 1140 RFC 3344 provides replay protection only for registration requests 1141 sent by the MN. There is no mechanism for replay protection for 1142 messages initiated by a FA or a HA. The 64-bit Identification field 1143 specified in this document (Section 4.1 and 4.2) for the GNM message 1144 is used to provide replay protection for the notification messages 1145 initiated by the FA or HA. 1147 8.1. Replay Protection for GNM, GNAM messages 1149 The Identification field is used to let the receiving node verify 1150 that a GNM has been freshly generated by the sending node, not 1151 replayed by an attacker from some previous registration. This 1152 document require that all MNs, FAs and HAs MUST implement timestamp- 1153 based replay protection. 1155 The style of replay protection in effect between any two peer node 1156 among MN, FA and HA. A sending node and its receiving node MUST 1157 agree on which method of replay protection will be used. The 1158 interpretation of the Identification field depends on the method of 1159 replay protection as described in the subsequent subsections. 1161 The low-order 32 bits of the Identification MUST be copied unchanged 1162 from the GNM to the GNMA. The receiver uses those bits (and the 1163 sender's source address) to match GNAM with corresponding replies. 1164 The receiver MUST verify that the low-order 32 bits of any GNAM are 1165 identical to the bits it sent in the GNM. 1167 The Identification in a new GNM MUST NOT be the same as in an 1168 immediately preceding GNM, and SHOULD NOT repeat while the same 1169 security context is being used between the MN and the HA. 1171 8.1.1. Replay Protection using Timestamps 1173 The basic principle of timestamp replay protection is that the node 1174 generating a message inserts the current time of day, and the node 1175 receiving the message checks that this timestamp is sufficiently 1176 close to its own time of day. Unless specified differently in the 1177 security association between the nodes, a default value of 7 seconds 1178 MAY be used to limit the time difference. This value SHOULD be 1179 greater than 3 seconds. Obviously the two nodes must have adequately 1180 synchronized time-of-day clocks. As with any messages, time 1181 synchronization messages may be protected against tampering by an 1182 authentication mechanism determined by the security context between 1183 the two nodes. 1185 In this document, the timestamps are used, the sender MUST set the 1186 Identification field to a 64-bit value formatted as specified by the 1187 Network Time Protocol[RFC1305]. The low-order 32 bits of the NTP 1188 format represent fractional seconds, and those bits which are not 1189 available from a time source SHOULD be generated from a good source 1190 of randomness. Note, however, that when using timestamps, the 64-bit 1191 Identification used in a GNM message from the sender MUST be greater 1192 than that used in any previous GNM message, as the receiver uses this 1193 field also as a sequence number. Without such a sequence number, it 1194 would be possible for a delayed duplicate of an earlier GNM message 1195 to arrive at the receiver (within the clock synchronization required 1196 by the receiver), and thus be applied out of order, mistakenly 1197 altering the sender's current status. 1199 Upon receipt of a GNM message with an authorization-enabling 1200 extension, the receiver MUST check the Identification field for 1201 validity. In order to be valid, the timestamp contained in the 1202 Identification field MUST be close enough to the receiver's time of 1203 day clock and the timestamp MUST be greater than all previously 1204 accepted timestamps for the requesting sender. Time tolerances and 1205 resynchronization details are specific to a particular mobility 1206 security association. 1208 If the timestamp is valid, the receiver copies the entire 1209 Identification field into the GNAM it returns the GNAM message to the 1210 sender. If the timestamp is not valid, the receiver copies only the 1211 low-order 32 bits into the GNAM, and supplies the high-order 32 bits 1212 from its own time of day. In this latter case, the receiver MUST 1213 reject the registration by returning Code 69/133/197 (identification 1214 mismatch) in the GNAM message. 1216 Furthermore, the receiver MUST verify that the low-order 32 bits of 1217 the Identification in the GNAM are identical to those in the rejected 1218 GNM attempt, before using the high-order bits for clock 1219 resynchronization. 1221 8.2. Non-authentication Extensions Handling in Foreign Agent 1223 When the FA is relaying the GNM message between the MN and the HA, 1224 and if the FA does not share a mobility security association with the 1225 MN or HA, all non-authentication extensions between MN and FA, or FA 1226 and HA are not protected. 1228 9. Normative References 1230 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1231 Specification, Implementation", RFC 1305, March 1992. 1233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1234 Requirement Levels", BCP 14, RFC 2119, March 1997. 1236 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ 1237 Organization-Specific Extensions", RFC 3115, April 2001. 1239 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1240 August 2002. 1242 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 1243 String Extension", RFC 4917, June 2007. 1245 Authors' Addresses 1247 Hui Deng 1248 China Mobile 1249 53A,Xibianmennei Ave., 1250 Xuanwu District, 1251 Beijing 100053 1252 China 1254 Email: denghui02@gmail.com 1256 Henrik Levkowetz 1257 Ericsson Research 1258 Torshamsgatan 23 1259 S-164 80, Stockholm 1260 SWEDEN 1262 Email: henrik@levkowetz.com 1264 Vijay Devarapalli 1265 WiChorus 1266 3590 North First St 1267 San Jose, CA 1268 USA 1270 Email: dvijay@gmail.com 1272 Sri Gundavelli 1273 Cisco Systems 1274 170 W.Tasman Drive 1275 San Jose, CA 95134 1276 USA 1278 Email: sgundave@cisco.com 1280 Brian Haley 1281 Hewlett-Packard Company 1282 110 Spitbrook Road 1283 Nashua, NH 03062 1284 USA 1286 Email: brian.haley@hp.com