MIP4 Working Group                                               H. Deng
Internet-Draft                                              China Mobile
Intended status: Standards Track                            H. Levkowetz
Expires: March 9, 2010                                 Ericsson Research
                                                          V. Devarapalli
                                                                WiChorus
                                                           S. Gundavelli
                                                           Cisco Systems
                                                                B. Haley
                                                 Hewlett-Packard Company
                                                       September 5, 2009


              Generic Notification Message for Mobile IPv4
          draft-ietf-mip4-generic-notification-message-10.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 9, 2010.



Deng, et al.              Expires March 9, 2010                 [Page 1]


Internet-Draft      MIP4 Generic Notification Message     September 2009


Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









































Deng, et al.              Expires March 9, 2010                 [Page 2]


Internet-Draft      MIP4 Generic Notification Message     September 2009


Abstract

   This document specifies protocol enhancements that allow Mobile IPv4
   entities to send and receive explicit notification messages using a
   new Mobile IPv4 message type designed for this purpose.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Notification message - Usage Scenario's  . . . . . . . . . . .  7
     3.1.  Notification message between a Home Agent and a Mobile
           Node . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Mobile Registered using a Foreign Agent Care-of
               Address  . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  Mobile Registered using a Co-located Care-of
               Address  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Notification message between a Foreign Agent and a
           Mobile Node  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Notification message between a Home Agent and a
           Foreign Agent  . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Generic Notification Message and Considerations  . . . . . . .  9
     4.1.  Generic Notification Message . . . . . . . . . . . . . . .  9
     4.2.  Generic Notification Acknowledgment Message  . . . . . . . 12
     4.3.  Notification Retransmision . . . . . . . . . . . . . . . . 15
     4.4.  Mobile Node Consideration  . . . . . . . . . . . . . . . . 16
       4.4.1.  Receiving Generic Notification Messages  . . . . . . . 16
       4.4.2.  Sending Generic Notification Acknowledgement
               Message  . . . . . . . . . . . . . . . . . . . . . . . 17
       4.4.3.  Sending Generic Notification Messages  . . . . . . . . 18
       4.4.4.  Receiving Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 18
     4.5.  Foreign Agent Consideration  . . . . . . . . . . . . . . . 19
       4.5.1.  Receiving Generic Notification Message . . . . . . . . 19
       4.5.2.  Sending Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 21
       4.5.3.  Sending Generic Notification Messages  . . . . . . . . 22
       4.5.4.  Receiving Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 22
     4.6.  Home Agent Consideration . . . . . . . . . . . . . . . . . 23
       4.6.1.  Sending Generic Notification Messages  . . . . . . . . 23
       4.6.2.  Receiving Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 24
       4.6.3.  Receiving Generic Notification Messages  . . . . . . . 25
       4.6.4.  Sending Generic Notification Acknowledgement
               Messages . . . . . . . . . . . . . . . . . . . . . . . 26
   5.  Usage Example  . . . . . . . . . . . . . . . . . . . . . . . . 27



Deng, et al.              Expires March 9, 2010                 [Page 3]


Internet-Draft      MIP4 Generic Notification Message     September 2009


     5.1.  Generic String Extension . . . . . . . . . . . . . . . . . 27
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 29
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
     8.1.  Replay Protection for GNM, GNAM messages . . . . . . . . . 30
       8.1.1.  Replay Protection using Timestamps . . . . . . . . . . 30
     8.2.  Non-authentication Extensions Handling in Foreign Agent  . 32
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34










































Deng, et al.              Expires March 9, 2010                 [Page 4]


Internet-Draft      MIP4 Generic Notification Message     September 2009


1.  Introduction

   In some situations, there is a need for Mobile IPv4 entities, such as
   the home agent(HA), foreign agent(FA) and mobile node(MN) to send and
   receive asynchronous notification messages during a mobility session.
   The base Mobile IP Specification [RFC3344] does not have a provision
   for this.

   This document defines a generic message and a notification model that
   can be used by Mobile IPv4 entities to send various notifications.
   However, this specification does not define any specific notification
   message or the actions that the receiving entity is required to
   perform on receiving that message.  Specific extensions and the
   corresponding handler actions are outside the scope of this document.





































Deng, et al.              Expires March 9, 2010                 [Page 5]


Internet-Draft      MIP4 Generic Notification Message     September 2009


2.  Terminology

   It is assumed that the reader is familiar with the terminology used
   in [RFC4917], [RFC3344].  In addition, the following terms are
   defined:

   Notification Message

      A message from a mobility agent to a MN or other mobility agent to
      asynchronously notify it about an event that is relevant to the
      mobility service it is currently providing.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119, [RFC2119].




































Deng, et al.              Expires March 9, 2010                 [Page 6]


Internet-Draft      MIP4 Generic Notification Message     September 2009


3.  Notification message - Usage Scenario's

   There are several scenarios where a mobility agent could initiate
   notification events.  Some of these are described in the following
   sections.

3.1.  Notification message between a Home Agent and a Mobile Node

3.1.1.  Mobile Registered using a Foreign Agent Care-of Address

   In this case, the HA cannot directly notify the MN, but must send the
   notification via the FA, vice versa.

           +----+    notification  +----+ notification  +----+
           | MN |<================>| FA |<=============>| HA |
           +----+                  +----+               +----+


           Figure 1: HA notifies MN or MN notifies HA through FA

3.1.2.  Mobile Registered using a Co-located Care-of Address

   In this case, the MN has registered with the home agent directly, so
   the notification message can go directly to the MN.

   The notification mechanism as specified here does not support the
   case of Co-located CoA mode with registration through a FA (due to
   the 'R' bit being set in the FA's advertisement messages).

           +----+               notification          +----+
           | MN |<===================================>| HA |
           +----+                                     +----+


       Figure 2: HA directly notifies MN or MN directly notifies HA

3.2.  Notification message between a Foreign Agent and a Mobile Node

   There are two cases where a FA may send notification messages to a
   MN, one where it is relaying a message, the other where the
   notification is triggered by a message from another network entity,
   for example a AAA node(notification messages between a AAA entity and
   the FA could be based on RADIUS or Diameter, but this is out of scope
   for this document).  If the notification is initiated by a FA, the FA
   may need to also notify the HA about the event.






Deng, et al.              Expires March 9, 2010                 [Page 7]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   +----+    notification  +----+    trigger   +--------+
   | MN |<================>| FA |<=============|   AAA  |
   +----+                  +----+              +--------+
                             ||   notification +----+
                              ================>| HA |
                                               +----+


                         Figure 3: FA notifies MN

3.3.  Notification message between a Home Agent and a Foreign Agent

   The HA may also need to send a notification to the FA, but not to the
   MN, The FA may also need to send a notification to the HA, as
   illustrated below:

                       +----+ notification  +----+
                       | FA |<=============>| HA |
                       +----+               +----+


                Figure 4: HA notifies FA or FA notifies HA





























Deng, et al.              Expires March 9, 2010                 [Page 8]


Internet-Draft      MIP4 Generic Notification Message     September 2009


4.  Generic Notification Message and Considerations

   This section describes in detail the Generic Notification Message
   (GNM), Generic Notification Acknowledgement Message (GNAM), and some
   considerations related to the handling of these messages in the MN,
   FA and HA.

   The MN and HA MUST maintain the following information, the FA also
   need maintain both HA's and MN's direction the below information:

      - the IP source address of the Registration Request/Reply

      - the IP destination address of the Registration Request/Reply

      - the UDP source port of the Registration Request/Reply

      - the UDP destination port of the Registration Request/Reply

   The sending node always sends the GNM message following the same
   procedure for sending Registration Request as in section 3.3 of
   [RFC3344] and the receiving node follows the same procedure for
   Registration Reply as in section 3.4. of [RFC3344] when sending GNAM.

4.1.  Generic Notification Message

   A GNM is sent by a mobility agent to inform another mobility agent,
   or a MN, of MIP-related information such as vendor specific
   extensions[RFC3115] and generic string notification[RFC4917].  These
   messages MUST use the same IP and UDP headers as any previous
   Registration Request(RRQ) or Reply (RRP) message to the same entity.
   This would support NAT traversal and ensure same security association
   used for GNM/GNAM and RRQ/RRP.  The GNM is defined as follows:

   IP Fields:

     Source Address         Copied from the source address field of the
                            last Registration Reply/Request message
                            sent.

     Destination Address    Copied from the source address field of the
                            last Registration Reply/Request message
                            sent.

   UDP Fields:







Deng, et al.              Expires March 9, 2010                 [Page 9]


Internet-Draft      MIP4 Generic Notification Message     September 2009


     Source Port            Copied from the source address field of the
                            last Registration Reply/Request message
                            sent.

     Destination Port       Copied from the source address field of the
                            last Registration Reply/Request message
                            sent.

   The UDP header is followed by the Mobile IP fields shown below:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Subtype     |      MD       |A|  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Home Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Home Agent Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Care-of Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Identification                          +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Extensions...
      +-+-+-+-+-+-+-+-+-+-+-+-+-


   Type (TBD)

   Subtype

      This field describes the particular type of notification which is
      carried in the notification message.  The following values are
      reserved in this document.

      0 Reserved

      1 Information carried in Vendor specific extensions which is
      specified in [RFC3115].

      2 Information carried in Generic String extensions which is
      specified in [RFC4917].

      The value 0 is reserved and SHOULD NOT be used.  The value 1
      indicates that the actual information is carried in vendor
      specific extensions.  Other values are reserved for future



Deng, et al.              Expires March 9, 2010                [Page 10]


Internet-Draft      MIP4 Generic Notification Message     September 2009


      extensions.

   MD: Message Direction

      This memo defines the semantics of the following MD field value:

      0 -- Message sent by the HA to the MN

      1 -- Message sent by the HA to the FA

      2 -- Message sent by the MN to the HA

      3 -- Message sent by the MN to the FA

      4 -- Message sent by the FA to the MN

      5 -- Message sent by the FA to the HA

   A

      This bit indicates whether the notification message MUST be
      acknowledged by the recipient.  If "A" bit has been set during the
      message, but the sender doesn't receive any acknowledgement
      message, the sender will have to resend the notification message
      again.

      Set to "1" to indicate that acknowledgement is required.

      Set to "0" to indicate that acknowledgement is optional.

   Reserved

      MUST be sent as 0, and ignored when received.

   Home Address

      The home IP address of the mobile node.

   Home Agent Address

      The IP address of the mobile node's HA.

   Care-of Address

      The mobile node's care-of address, either the Co-located Care-of
      Address or the foreign agent care-of address.

   Identification



Deng, et al.              Expires March 9, 2010                [Page 11]


Internet-Draft      MIP4 Generic Notification Message     September 2009


      A 64-bit number, constructed by the sender, used for matching GNM
      with GNAM, and for protecting against replay attacks of
      notification messages.  Here is the same as Sections 5.4 and 5.7
      of [RFC3344].  Timestamps is mandatory.

   Extensions

      The fixed portion of the GNM is followed by one or more extensions
      which may be used with this message, and by one or more
      authentication extensions (as defined in Section 3.5 of [RFC3344].
      This document mandates the MN-HA Authentication Extension (AE)
      when this message is sent between the MN and the HA, others are
      optional.  This document also mandate the MN-FA AE when this
      message is sent between the MN and the FA, others are optional.
      This document mandate the FA-HA AE when this message is sent
      between the FA and the HA, others are optional.  This could be
      judged based on "MD" value.).  See Sections 3.6.1.3 and 3.7.2.2 of
      [RFC3344] for the rules on the order of these extensions as they
      appear in Mobile IPv4 RRQ and RRP messages.  The same rules are
      applicable to GNM and GNAM.

4.2.  Generic Notification Acknowledgment Message

   A GNAM is sent by mobility agents or MNs to indicate the successful
   receipt of a GNM.

   IP Fields:

     Source Address         Typically copied from the destination
                            address of the GNM to which the agent is
                            replying.

     Destination Address    Copied from the source address of the GNM to
                            which the agent is replying.

   UDP Fields:

     Source Port            Copied from the destination port of the
                            corresponding GNM.

     Destination Port       Copied from the source port of the
                            corresponding GNM.

   The UDP header is followed by the Mobile IP fields shown below:







Deng, et al.              Expires March 9, 2010                [Page 12]


Internet-Draft      MIP4 Generic Notification Message     September 2009


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Subtype     |      MD       |     code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home Agent Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Care-of Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Identification                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions...
   +-+-+-+-+-+-+-+-+-+-+-+-+-


   Type (TBD)

   Subtype

      This field specifies the particular type of notification
      acknowledgement message.  The following values are reserved in
      this document.

      0 Reserved

      1 Information carried in Vendor specific extensions which is
      specified in [RFC3115].

      2 Information carried in Generic String extensions which is
      specified in [RFC4917].

      The value 0 is reserved and SHOULD NOT be used.  The value 1
      indicates that the actual information is carried in vendor
      specific extensions.  Other values are reserved for future
      extensions.

   MD: Message Direction

      This memo defines the semantics of the following MD field value:

      0 -- Message sent by the HA to the MN

      1 -- Message sent by the HA to the FA




Deng, et al.              Expires March 9, 2010                [Page 13]


Internet-Draft      MIP4 Generic Notification Message     September 2009


      2 -- Message sent by the MN to the HA

      3 -- Message sent by the MN to the FA

      4 -- Message sent by the FA to the MN

      5 -- Message sent by the FA to the HA

   code

      A value indicating the result of the GNM.  See below for a list of
      currently defined Code values.

   Notification suceessful

      0 -- notification accepted

   Notification denied by the HA

      128 -- reason unspecified

      129 -- administratively prohibited

      130 -- insufficient resources

      131 -- mobile node failed authentication

      132 -- foreign agent failed authentication

      133 -- notification Identification mismatch

   Notification denied by the FA

      64 -- reason unspecified

      65 -- administratively prohibited

      66 -- insufficient resources

      67 -- mobile node failed authentication

      68 -- home agent failed authentication

      69 -- notification Identification mismatch

   Notification denied by the mobile node





Deng, et al.              Expires March 9, 2010                [Page 14]


Internet-Draft      MIP4 Generic Notification Message     September 2009


      192 -- reason unspecified

      193 -- administratively prohibited

      194 -- insufficient resources

      195 -- foreign agent failed authentication

      196 -- home agent failed authentication

      197 -- notification Identification mismatch

   Home Address

      The home IP address of the mobile node.

   Home Agent Address

      The IP address of the sender's home agent.

   Care-of Address

      The mobile node's care-of address, either the Co-located Care-of
      Address or the foreign agent care-of address.

   Identification

      If the timestamp of the GNM is valid, the receiver copies the
      entire Identification field into the GNAM it returns the GNAM
      message to the sender.  If the timestamp of the GNM is not valid,
      the receiver copies only the low-order 32 bits into the GNAM, and
      supplies the high-order 32 bits from its own time of day.  Both
      GNM and GNAM mandate Timestamps.

   Extensions

      The fixed portion of the GNAM is followed by one or more of the
      Extensions listed in Section 3.5 of [RFC3344].  See Sections
      3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the order of
      these extensions as they appear in Mobile IPv4 RRQ and RRP
      messages.  The same rules are applicable to GNM and GNAM.

4.3.  Notification Retransmision

   If "A" flag has been set during the GNM message, but the sender
   doesn't receive any GNAM message within a reasonable time, another
   GNM will be retransmited.  When timestamps are used, a new
   registration Identification is chosen for each retransmision; Thus it



Deng, et al.              Expires March 9, 2010                [Page 15]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   counts as a new GNM.

   The maximum time until a new GNM is sent SHOULD be no greater than
   the requested Lifetime of the last Registration Request.  The minimum
   value SHOULD be large enough to account for the size of the messages,
   twice the round trip time for transmission to the receiver, and at
   least an additional 100 milliseconds to allow for processing the
   messages before responding.  The round trip time for transmission to
   the receiver will be at least as large as the time required to
   transmit the messages at the link speed of the MN's current point of
   attachment.  Some circuits add another 200 milliseconds of satellite
   delay in the total round trip time to the receiver.  The minimum time
   between GNM MUST NOT be less than 1 second.  Each successive
   retransmission timeout period SHOULD be at least twice the previous
   period, as long as that is less than the maximum as specified above.

4.4.  Mobile Node Consideration

   It is possible that the MN MAY receive a GNM from a FA or HA.  Both
   in the case of FA-CoA and Co-located CoA, the MN MAY reply with a
   GNAM based on the "A" flag in the GNM message.

4.4.1.  Receiving Generic Notification Messages

   When the MN is using FA-CoA and receives a Notification message, if
   the "MD" value is 0, it means that the notification message came from
   the HA.  If the "MD" value is 4, the notification came from the FA.

   If this notification message came from a FA and the MN accepts the
   FA's GNM, it will process the notification extension according to the
   specific rules for that extension.

   The MN MUST check for the presence of an authorization-enabling
   extension, and perform the indicated authentication.  Exactly one
   authorization-enabling extension MUST be present in the GNM, if this
   message came from a FA, MN-FA AE MUST be present, If no MN-FA AE is
   found, or if more than one MN-FA AE is found, or if the Authenticator
   is invalid, the MN MUST reject the GNM and MAY send a GNAM to the FA
   with Code 195, including an Identification field computed in
   accordance with the rules specified in Section 8.1.  The MN MUST do
   no further processing with such a notification, though it SHOULD log
   the error as a security exception.

   The MN MUST check that the Identification field is correct using the
   context selected by the SPI within mandatory authentication extension
   like MN-FA AE or MN-HA AE.  See Section 8.1 for a description of how
   this is performed.  If incorrect, the MN MUST reject the GNM and MAY
   send a GNAM to the initiator with Code 197, including an



Deng, et al.              Expires March 9, 2010                [Page 16]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   Identification field computed in accordance with the rules specified
   in Section 8.1.  The MN MUST do no further processing with such a
   notification, though it SHOULD log the error as a security exception.

   After that, the MN MAY reply GNAM back to the FA.  If the "A" flag is
   set in the GNM, then the MN MUST send the GNAM.

   If this notification message came from the HA, relayed by the FA, or
   is a Co-located CoA, the MN-HA AE MUST be checked and the MN MUST
   check the Authenticator value in the Extension.  If no MN-HA AE is
   found, or if more than one MN-HA AE is found, or if the Authenticator
   is invalid, the MN MUST reject the GNM and MAY send a GNAM to the
   initiator with Code 196, including an Identification field computed
   in accordance with the rules specified in Section 8.1.  The MN MUST
   do no further processing with such a notification, though it SHOULD
   log the error as a security exception.  If the MN accepts the HA's
   GNM, it will process it according to the specific rules for that
   extension.  After that, the MN MAY reply with a GNAM with Code 0 back
   to the HA based on the "A" flag in the GNM.

4.4.2.  Sending Generic Notification Acknowledgement Message

   Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply
   with a GNAM based on the "A" flag in the GNM as follows:

   If the GNM was initiated from the FA to the MN ("MD" value is set to
   4), MN-FA AE MUST be the last extension in order to protect all other
   non-authentication extensions as defined in section 3.5.3 of
   [RFC3344].

   In the case of a FA-CoA, the source address is the MN's address, the
   destination address is the FA's address.

   The Code field of the GNAM is chosen in accordance with the rules
   specified in the section 4.2.  When replying to an accepted
   notification, a MN SHOULD respond with Code 0.

   There are a number of reasons the MN might reject a notification such
   as administrative in nature returning a GNAM with a code of 193,
   similarly and provides the Code value 192 or 194 for the unspecified
   reason and insufficient resources.

   If the GNM was initiated from the HA to the MN ("MD" value is set to
   0) and in the case of Co-located CoA, MN-HA AE MUST be the last
   extension in order to protect all other non-authentication extensions
   as defined in section 3.5.2 of [RFC3344]

   In the case of a FA-CoA, the source address is the MN's HoA address



Deng, et al.              Expires March 9, 2010                [Page 17]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   and the destination address is the FA's address ("MD" value is set to
   2), the ordering of the extension is: any non-authentication
   Extensions used only by the HA, followed by the MN-HA AE defined in
   section 3.5.2. of [RFC3344], followed by any non-authentication
   Extensions used only by the FA, followed by The MN-FA AE defined in
   section 3.5.3 of [RFC3344].

4.4.3.  Sending Generic Notification Messages

   The MN may either send a GNM to notify the FA or HA.

   If the message is sent to the FA, the source address is the MN's
   address, and the destination address is the FA's address

   If the FA is the target of this notification message, then the "MD"
   value is set to 3, MN-FA AE MUST be the last extension in order to
   protect all other non-authentication extensions.  Computing
   Authentication Extension Value is the same as section 3.5.1 of
   [RFC3344].

   If the FA is working only as a relay agent, the "MD" value is set to
   2, and the ordering of the extension is: the notification extension,
   followed by any non-authentication extension expected to be used by
   HA, followed by MN-HA AE defined in section 3.5.2. of [RFC3344],
   followed by any non-authentication Extensions used only by the FA,
   followed by The MN-FA AE defined in section 3.5.3 of [RFC3344].
   Computing Authentication Extension Value is the same as section 3.5.1
   of [RFC3344].

   In the case of a Co-located CoA, the MN MAY send a notification
   message directly to the HA if it needs to be notified.  The "MD"
   value is set to 2, and the ordering of the extension is: the
   notification extension, followed by any non-authentication extension
   expected to be used by HA, followed by MN-HA AE defined in section
   3.5.2 of [RFC3344].

   The MN chooses the Identification field in accordance with the style
   of replay protection it uses with its HA.  This is part of the
   mobility security association the MN shares with its HA.  See Section
   8.1 for the method by which the MN computes the Identification field.

4.4.4.  Receiving Generic Notification Acknowledgement Messages

   In the case of a FA-CoA, if the MN receives this message, and the
   "MD" value is set to 0, it means that the GNAM came from HA

   If the "MD" value is set to 4, the MN-FA AE MUST be checked, and the
   MN MUST check the Authenticator value in the Extension.  If no MN-FA



Deng, et al.              Expires March 9, 2010                [Page 18]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   AE is found, or if more than one MN-FA AE is found, or if the
   Authenticator is invalid, the MN MUST silently discard the GNAM.

   In addition, the low-order 32 bits of the Identification field in the
   GNAM MUST be compared to the low-order 32 bits of the Identification
   field in the most recent GNM sent to the replying agent.  If they do
   not match, the GNAM MUST be silently discarded.

   If the "MD" value is set to 0, the MN-HA AE MUST be checked, and the
   MN MUST check the Authenticator value in the Extension.  If no MN-HA
   AE is found, or if more than one MN-HA AE is found, or if the
   Authenticator is invalid, the MN MUST silently discard the GNAM.  If
   the MN accepted this message, the MN MAY also process it based on the
   notification event.

   In the case of a Co-located CoA, if the MN received this message, the
   MN-HA AE MUST be checked, and the MN MUST check the Authenticator
   value in the Extension.  If no MN-HA AE is found, or if more than one
   MN-HA AE is found, or if the Authenticator is invalid, the MN MUST
   silently discard the Notification Acknowledgement message.

4.5.  Foreign Agent Consideration

   The FA may initiate a GNM to the MN or the HA.  Additionally, the FA
   also relays GNM and GNAM messages between the MN and its HA as long
   as there is an active binding for the MN at the FA.

4.5.1.  Receiving Generic Notification Message

   If the FA receives a GNM, and the "MD" value is set to 0, it means
   that the HA is asking the FA to relay the message to the MN.  If the
   "MD" value is set to 1, it means that the target of the notification
   is the FA.  If the "MD" value is set to 2, it means that the MN is
   asking the FA to relay the message to the HA.  If the "MD" value is
   set to 3, it means that the notification came from the MN to the FA.

   If the "MD" value is set to 0, the FA MAY validate the FA-HA AE if
   present.  If the FA-HA AE is invalid, all extensions between the
   HA-MN AE and the HA-FA AE MUST be removed, FA SHOULD relay the GNM to
   the MN's home address as specified in the Home Address field of the
   GNM, MN will eventually validate the MN-HA AE to ensure that all
   information sent to the MN is integrity protected.  If the FA-HA AE
   is valid, FA MUST relay the GNM to the MN's home address as specified
   in the Home Address field of the GNM.  The FA MUST NOT modify any of
   the fields beginning with the fixed portion of the GNM through the
   MN-HA AE or other authentication extension supplied by the HA as an
   authorization-enabling extension for the MN.




Deng, et al.              Expires March 9, 2010                [Page 19]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   Furthermore, the FA MUST process and remove any extensions following
   the MN-HA AE.  If the FA shares a mobility security association with
   the MN, the FA MAY append any of its own non-authentication
   extensions which of relevance to the MN.  In this case, the FA MUST
   append the MN-FA AE after these non-authentication extensions.

   If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the
   FA MUST check the Authenticator value in the Extension.  If no FA-HA
   AE is found, or if more than one FA-HA AE is found, or if the
   Authenticator is invalid, the FA MUST reject the GNM and MAY send a
   GNAM to the HA with Code 68, including an Identification field
   computed in accordance with the rules specified in Section 8.1.  The
   FA MUST do no further processing with such a notification, though it
   SHOULD log the error as a security exception.

   The FA MUST check that the Identification field is correct using the
   context selected by the SPI within mandatory FA-HA AE.  See Section
   8.1 for a description of how this is performed.  If incorrect, the FA
   MUST reject the GNM and MAY send a GNAM to the initiator with Code
   69, including an Identification field computed in accordance with the
   rules specified in Section 8.1.  The FA MUST do no further processing
   with such a notification, though it SHOULD log the error as a
   security exception.

   If FA accepts the HA's GNM, it will process it based on the specific
   rules for that extension.  The FA MAY then reply with a GNAM with
   Code 0 back to the MN based on the "A" flag in the GNM.

   In the case of a FA-CoA and if the "MD" value is set to 2, if the FA
   received this message, and if the MN-FA AE is present, the MN-FA AE
   MUST be checked, and the FA MUST check the Authenticator value in the
   Extension.  If no MN-FA AE is found, or if more than one MN-FA AE is
   found, or if the Authenticator is invalid, the FA MUST silently
   discard the GNM message.  If MN-FA is valid, FA MUST relay the GNM to
   the HA's address as specified in the Home Agent Address field of the
   GNM, HA will eventually validate the MN-HA AE to ensure that all
   information sent to the HA is integrity protected.  The FA MUST NOT
   modify any of the fields beginning with the fixed portion of the GNM
   through the MN-HA AE or other authentication extension supplied by
   the MN as an authorization-enabling extension for the HA.

   Furthermore, the FA MUST process and remove any Extensions following
   the MN-HA AE, and MAY append any of its own non-authentication
   Extensions of relevance to the HA if applicable, and MUST append the
   FA-HA AE, if the FA shares a mobility security association with the
   HA.

   If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the



Deng, et al.              Expires March 9, 2010                [Page 20]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   FA MUST check the Authenticator value in the Extension which is the
   same as the section 3.7.2.1 of RFC 3344.  If no MN-FA AE is found, or
   if more than one MN-FA AE is found, or if the Authenticator is
   invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN
   with Code 67, including an Identification field computed in
   accordance with the rules specified in Section 8.1.  The FA MUST do
   no further processing with such a notification, though it SHOULD log
   the error as a security exception.

   The FA MUST check that the Identification field is correct using the
   context selected by the SPI within mandatory MN-FA AE.  See Section
   8.1 for a description of how this is performed.  If incorrect, the FA
   MUST reject the GNM and MAY send a GNAM to the initiator with Code
   69, including an Identification field computed in accordance with the
   rules specified in Section 8.1.  The FA MUST do no further processing
   with such a notification, though it SHOULD log the error as a
   security exception.

   If FA accepts the MN's GNM, it will process it based on the specific
   rules for that extension.  The FA MAY then reply with a GNAM with
   Code 0 back to the MN based on the "A" flag in the GNM.

4.5.2.  Sending Generic Notification Acknowledgement Messages

   The FA may need to either relay a GNAM message between the MN and the
   HA or send one as a response to a GNM messsage that was sent to it.
   In both cases, the GNAM message is defined as follows:

   The source address is the FA address, the destination address is HA's
   or MN's home address.

   The Code field of the GNAM is chosen in accordance with the rules
   specified in the section 4.2.  When replying to an accepted
   notification, a FA SHOULD respond with Code 0.

   There are a number of reasons the FA might reject a notification such
   as administrative in nature returning a GNAM with a code of 65,
   similarly and provides the Code value 64 or 66 for the unspecified
   reason and insufficient resources.

   If the FA is only relaying this message to the HA, the FA MUST NOT
   modify any of the fields beginning with the fixed portion of the GNAM
   through the including the MN-HA AE or other authentication extension
   supplied by the MN as an authorization-enabling extension for the MN.
   Furthermore, the foreign agent MUST process and remove any Extensions
   following the MN-HA AE.  If the FA shares a mobility security
   association with the HA, the FA MAY append any of its own non-
   authentication extensions which of relevance to the HA, In this case



Deng, et al.              Expires March 9, 2010                [Page 21]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   the FA MUST append the FA-HA AE after these non-authentication
   extensions.

   If the notification message is from the HA to the FA then the "MD"
   value is set to 5 and the ordering of the extension is: any non-
   authentication Extensions used only by the FA, followed by The FA-HA
   AE defined in section 3.5.4 of [RFC3344].

   If the notification message is from the MN to the FA then the "MD"
   value is set to 4 and the ordering of the extension is: any non-
   authentication Extensions used only by the FA, followed by The MN-FA
   AE defined in section 3.5.3 of [RFC3344].

4.5.3.  Sending Generic Notification Messages

   If the FA is initiating a notification to the MN using the GNM, it
   MAY also notify the HA as well.

   In the message to the MN, the source address is the FA address, the
   destination address is the MN's address, the "MD" value is set to 4,
   and the ordering of the extension is: the notification extension,
   followed by any non-authentication Extensions used only by the MN,
   followed by The MN-FA AE defined in section 3.5.3 of [RFC3344].
   Computing Authentication Extension Value is the same as section 3.5.1
   of [RFC3344] except the payload is the notification other than
   registration.

   In the message to the HA, the source address is the FA's address, the
   destination address is the HA's address (the "MD" value is set to 5),
   and the ordering of the extension is: notification extension,
   followed by any non-authentication Extensions used only by the HA,
   followed by The FA-HA AE defined in section 3.5.4 of [RFC3344].
   Computing Authentication Extension Value is the same as section 3.5.1
   of [RFC3344] except the payload is the notification other than
   registration.

4.5.4.  Receiving Generic Notification Acknowledgement Messages

   In the case of a FA-CoA, if the FA receives this message, and the
   "MD" value is set to 3, it means that the notification
   acknowledgement message came from the MN, otherwise it came from the
   HA.

   If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the
   FA MUST check the Authenticator value in the Extension.  If no FA-HA
   AE is found, or if more than one FA-HA AE is found, or if the
   Authenticator is invalid, the FA MUST silently discard the
   Notification Acknowledgement message.  If the FA accepted this



Deng, et al.              Expires March 9, 2010                [Page 22]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   message, the FA MAY also process it based on the notification event.

   If the "MD" value is set to 3, if the MN-FA AE is present, it MUST be
   checked, and the FA MUST check the Authenticator value in the
   Extension.  If no MN-FA AE is found, or if more than one MN-FA AE is
   found, or if the Authenticator is invalid, the FA MUST silently
   discard the GNAM message.  If the FA accepted this message, the FA
   MAY also process it based on the notification event.

   In the case of a FA-CoA and if the "MD" value is set to 2, if the FA
   received this message, and if the MN-FA AE is present, the MN-FA AE
   MUST be checked, and the FA MUST check the Authenticator value in the
   Extension.  If no MN-FA AE is found, or if more than one MN-FA AE is
   found, or if the Authenticator is invalid, the FA MUST silently
   discard the GNAM message.  If FA accepted the MN's GNAM message, it
   MUST relay this message to the HA.  The FA MUST NOT modify any of the
   fields beginning with the fixed portion of the GNAM message through
   the including the MN-HA AE or other authentication extension supplied
   by the HA as an authorization-enabling extension for the MN.
   Furthermore, the FA MUST process and remove any Extensions following
   the MN-HA AE and MAY append any of its own non-authentication
   Extensions of relevance to the HA, if applicable, and MUST append the
   FA-HA AE, if the FA shares a mobility security association with the
   HA.

4.6.  Home Agent Consideration

   The HA MAY initiate a GNM message to both the mobile node and FA, and
   it also MAY receive a GNAM message from both the FA and MN.  The HA
   also MAY receive a GNM message from the FA, but only when there is a
   binding for a MN.  If the HA receives a GNM from a FA and there is no
   corresponding MN registration, the HA SHOULD drop the GNM message.

4.6.1.  Sending Generic Notification Messages

   In the case of a FA-CoA, the HA may either send a GNM to notify the
   FA, or have the FA relay the GNM to the MN if the MN needs to be
   notified.

   If the message is from the HA to the FA, the source address is the
   HA's address, and the destination address is the FA's address

   If the FA is working only as a relay agent, the "MD" value is set to
   0, and the ordering of the extension is: the notification extension,
   followed by any non-authentication extension expected to be used by
   MN, followed by MN-HA AE defined in section 3.5.2. of [RFC3344],
   followed by any non-authentication Extensions used only by the FA,
   followed by The FA-HA AE defined in section 3.5.4 of [RFC3344].



Deng, et al.              Expires March 9, 2010                [Page 23]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   Computing Authentication Extension Value is the same as section 3.5.1
   of [RFC3344].

   If the FA is the target of this notification message, then the "MD"
   value is set to 1, and the ordering of the extension is: the
   notification extension, followed by any non-authentication Extensions
   used only by the FA, followed by The FA-HA AE defined in section
   3.5.4 of [RFC3344].  Computing Authentication Extension Value is the
   same as section 3.5.1 of [RFC3344].

   In the case of a Co-located CoA, the HA MAY send a notification
   message directly to the MN if it needs to be notified.  The "MD"
   value is set to 0, and the ordering of the extension is: the
   notification extension, followed by any non-authentication extension
   expected to be used by MN, followed by MN-HA AE defined in section
   3.5.2. of [RFC3344].

4.6.2.  Receiving Generic Notification Acknowledgement Messages

   In the case of a FA-CoA, if the HA receives this message, and the
   "MD" value is set to 2, it means that the GNAM message came from MN.

   If the "MD" value is set to 5, and the HA accepted this message, the
   HA MAY also process it based on the notification event.  The FA-HA AE
   MUST be checked, and the HA MUST check the Authenticator value in the
   Extension.  If no FA-HA AE is found, or if more than one FA-HA AE is
   found, or if the Authenticator is invalid, the HA MUST silently
   discard the GNAM message.

   If the "MD" value is set to 2, in the case of a FA-CoA, and if FA-HA
   AE is present, the FA-HA AE MUST be checked, and the HA MUST check
   the Authenticator value in the Extension.  If more than one FA-HA AE
   is found, or if the Authenticator is invalid, the HA MUST silently
   discard the GNAM message.  Anyway, MN-HA AE MUST be checked, and the
   HA MUST check the Authenticator value in the Extension.  If no MN-HA
   AE is found, or if more than one MN-HA AE is found, or if the
   Authenticator is invalid, the HA MUST silently discard the GNAM.  If
   the HA accepted this message, the HA MAY also process it based on the
   notification event.

   If the "MD" value is set to 2, in the case of a Co-located CoA, MN-HA
   AE MUST be checked, and the HA MUST check the Authenticator value in
   the Extension.  If no MN-HA AE is found, or if more than one MN-HA AE
   is found, or if the Authenticator is invalid, the HA MUST silently
   discard the GNAM.  If the HA accepted this message, the HA MAY also
   process it based on the notification event.





Deng, et al.              Expires March 9, 2010                [Page 24]


Internet-Draft      MIP4 Generic Notification Message     September 2009


4.6.3.  Receiving Generic Notification Messages

   The HA MAY receive a GNM message sent from the FA.  When the HA
   receives this message, if the the "MD" value is set to 5, this
   message came from FA.  FA-HA AE MUST be checked, and the HA MUST
   check the Authenticator value in the Extension.  If no FA-HA AE is
   found, or if more than one FA-HA AE is found, or if the Authenticator
   is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA
   with Code 132, including an Identification field computed in
   accordance with the rules specified in Section 8.1.  The HA MUST do
   no further processing with such a notification, though it SHOULD log
   the error as a security exception.

   The HA MUST check that the Identification field is correct using the
   context selected by the SPI within mandatory authentication extension
   like MN-HA AE or FA-HA AE.  See Section 8.1 for a description of how
   this is performed.  If incorrect, the HA MUST reject the GNM and MAY
   send a GNAM to the initiator with Code 133, including an
   Identification field computed in accordance with the rules specified
   in Section 8.1.  The HA MUST do no further processing with such a
   notification, though it SHOULD log the error as a security exception.
   If HA accepts the FA's GNM message, it will process it based on the
   notification extension.  Furthermore, the HA MAY reply with a GNAM
   message with Code 0 back to the FA based on the "A" flag in the GNM
   message.

   If the the "MD" value is set to 2, this message come from MN, in the
   case of FA-COA, if FA-HA AE is present, it MUST be checked, and the
   HA MUST check the Authenticator value in the Extension.  If more than
   one FA-HA AE Extension is found, or if the Authenticator is invalid,
   the HA MUST reject the GNM and MAY send a GNAM to the FA with Code
   132, including an Identification field computed in accordance with
   the rules specified in Section 8.1.  The HA MUST do no further
   processing with such a notification, though it SHOULD log the error
   as a security exception.  And MN-HA AE MUST be checked, and the HA
   MUST check the Authenticator value in the Extension.  If no MN-HA AE
   is found, or if more than one MN-HA AE is found, or if the
   Authenticator is invalid, the HA MUST reject the GNM and MAY send a
   GNAM to the MN with Code 131, including an Identification field
   computed in accordance with the rules specified in Section 8.1.  The
   HA MUST do no further processing with such a notification, though it
   SHOULD log the error as a security exception.  If HA accepts the MN's
   GNM message, it will process it based on the notification extension.
   Furthermore, the HA MAY reply with a GNAM message back to the MN with
   Code 0 based on the "A" flag in the GNM message.

   If the the "MD" value is set to 2, in the case of a Co-located CoA,
   the MN-HA AE MUST be checked, and the HA MUST check the Authenticator



Deng, et al.              Expires March 9, 2010                [Page 25]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   value in the Extension.  If no MN-HA AE is found, or if more than one
   MN-HA AE is found, or if the Authenticator is invalid, the HA MUST
   reject the GNM and MAY send a GNAM to the MN with Code 131, including
   an Identification field computed in accordance with the rules
   specified in Section 8.1.  The HA MUST do no further processing with
   such a notification, though it SHOULD log the error as a security
   exception.  If HA accepts the MN's GNM message, it will process it
   based on the notification extension.  Furthermore, the HA MAY reply
   with a GNAM message back to the MN with Code 0 based on the "A" flag
   in the GNM message.

4.6.4.  Sending Generic Notification Acknowledgement Messages

   If the GNM message came from the FA only, and if the "A" flag is set
   in the GNM message, then the HA MUST send a GNAM message.  The
   message is as follows: The source address is HA's address, the
   destination address is the FA's address, the "MD" value is set to 1.
   The ordering of the extension is: any non-authentication Extensions
   used only by the FA, followed by The Foreign-Home Authentication
   extension defined in section 3.5.4 of [RFC3344].

   The Code field of the GNAM is chosen in accordance with the rules
   specified in the section 4.2.  When replying to an accepted GNM, a MN
   SHOULD respond with Code 0.

   If the GNM message came from the MN, the HA MAY reply with a GNAM
   message to the MN based on the "A" flag in the GNM message.  If the
   "A" flag is set in the GNM message, then the HA MUST send a GNAM
   message.  The message is as follows: The source address is HA's
   address, the destination address is the FA's address, the "MD" value
   is set to 0.  The ordering of the extension is: any non-
   authentication Extensions used only by the MN, followed by the MN-HA
   AE defined in section 3.5.2. of [RFC3344], optionly followed by any
   non-authentication Extensions used only by the FA, optionly followed
   by The MN-FA AE defined in section 3.5.3 of [RFC3344]
















Deng, et al.              Expires March 9, 2010                [Page 26]


Internet-Draft      MIP4 Generic Notification Message     September 2009


5.  Usage Example

   There are several applications that could use this GNM. for example,
   during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP
   resource of CDMA side have to be removed on the FA (PDSN) to avoid
   over-charging subscribers.  Other applications such as HA switch
   over, NEMO prefix changes, service or billing related events, load
   balancing where the HA wants to move some of the registered mobile
   nodes to other HAs, service termination due to end of prepaid time,
   and service interruption due to system maintenance.

   Here we describe some possible event which could use the generic
   string extension [RFC4917] based on this notification mechanism also.
   There is also the possibility that this notification message could
   carry many extensions at once.  A new VSE extension could be defined
   to support this notification message.

5.1.  Generic String Extension

   In some case, the HA or FA needs to notify the mobile node about
   service termination due to the end of prepaid time, or service
   interruption due to system maintenance.  This information could be
   defined based on a string [RFC4917] which is recognized by the MN
   easily.  An example would be "Maintenance Downtime", "Prepaid
   Expiration".  These string MUST be strictly defined so they could be
   easily understood by all of the network entities, and a suitable GNM
   Subtype number would have to be allocated.  All such definitions are
   left for future specifications.























Deng, et al.              Expires March 9, 2010                [Page 27]


Internet-Draft      MIP4 Generic Notification Message     September 2009


6.  IANA Considerations

   This document describes two new messages, the GNM in section 4.1 and
   the GNAM in section 4.2.  These two messages SHOULD be allocated from
   the same address space used by the Registration Request and
   Registration Reply messages in [RFC3344].  The subtype of these two
   messages indicate what kind of information is carried and will be
   under assigned by IANA namespace.

   This document creates a new IANA registry for the Subtype field in
   the GNM and GNAM.  New values MUST be allocated by Standards Actions
   or IETF Consensus.  This document reserves three values for the
   Subtype field

   0 Reserved

   1 Information carried in Vendor specific extensions

   2 Information carried in Generic String Extension

   This GNAM message, specified in section section 4.2, has a Code
   field.  The number space for the Code field values is also specified
   in section 4.2.  The Code number space is strucutred according to
   whether the notification was successful, or whether the HA denied the
   notification, or whether FA denied the notification, or whether MN
   denied the notification, as follows

           0       Success Code
           64-69   Error Codes from the FA
           128-133 Error Codes from the HA
           192-197 Error Codes from the MN

   Approval of new Code values require expert review.


















Deng, et al.              Expires March 9, 2010                [Page 28]


Internet-Draft      MIP4 Generic Notification Message     September 2009


7.  Acknowledgments

   The author appreciate the efforts of Ahmad Muhanna in detail
   reviewing of this document, lots of text have been contributed by his
   suggestions.  The author thank the discussion from Kent Leung, Peng
   Yang and Peter McCann et al. in the development of this document.
   Thanks to Alexey Melnikov's discussion and comments.  Thanks to Jari
   Arkko for each step of this document.











































Deng, et al.              Expires March 9, 2010                [Page 29]


Internet-Draft      MIP4 Generic Notification Message     September 2009


8.  Security Considerations

   This specification operates in the security constraints and
   requirements of [RFC3344].  It require that when this message is
   transmitted between the MN and the HA, MN-HA AE is mandatory, when
   this message is transmitted between the MN and the FA, MN-FA AE is
   mandatory, when this message is transmitted between the FA and the
   HA, FA-HA AE is mandatory.  It extends the operations of MN, HA and
   FA defined in [RFC3344] to notify each other about some events.  The
   GNM message defined in the specification could carry information that
   modifies the mobility bindings.  Therefore the message MUST be
   integrity protected.  Replay protection MUST also be guaranteed.

   RFC 3344 provides replay protection only for registration requests
   sent by the MN.  There is no mechanism for replay protection for
   messages initiated by a FA or a HA.  The 64-bit Identification field
   specified in this document (Section 4.1 and 4.2) for the GNM message
   is used to provide replay protection for the notification messages
   initiated by the FA or HA.

8.1.  Replay Protection for GNM, GNAM messages

   The Identification field is used to let the receiving node verify
   that a GNM has been freshly generated by the sending node, not
   replayed by an attacker from some previous registration.  This
   document require that all MNs, FAs and HAs MUST implement timestamp-
   based replay protection.

   The style of replay protection in effect between any two peer node
   among MN, FA and HA.  A sending node and its receiving node MUST
   agree on which method of replay protection will be used.  The
   interpretation of the Identification field depends on the method of
   replay protection as described in the subsequent subsections.

   The low-order 32 bits of the Identification MUST be copied unchanged
   from the GNM to the GNMA.  The receiver uses those bits (and the
   sender's source address) to match GNAM with corresponding replies.
   The receiver MUST verify that the low-order 32 bits of any GNAM are
   identical to the bits it sent in the GNM.

   The Identification in a new GNM MUST NOT be the same as in an
   immediately preceding GNM, and SHOULD NOT repeat while the same
   security context is being used between the MN and the HA.

8.1.1.  Replay Protection using Timestamps

   The basic principle of timestamp replay protection is that the node
   generating a message inserts the current time of day, and the node



Deng, et al.              Expires March 9, 2010                [Page 30]


Internet-Draft      MIP4 Generic Notification Message     September 2009


   receiving the message checks that this timestamp is sufficiently
   close to its own time of day.  Unless specified differently in the
   security association between the nodes, a default value of 7 seconds
   MAY be used to limit the time difference.  This value SHOULD be
   greater than 3 seconds.  Obviously the two nodes must have adequately
   synchronized time-of-day clocks.  As with any messages, time
   synchronization messages may be protected against tampering by an
   authentication mechanism determined by the security context between
   the two nodes.

   In this document, the timestamps are used, the sender MUST set the
   Identification field to a 64-bit value formatted as specified by the
   Network Time Protocol[RFC1305].  The low-order 32 bits of the NTP
   format represent fractional seconds, and those bits which are not
   available from a time source SHOULD be generated from a good source
   of randomness.  Note, however, that when using timestamps, the 64-bit
   Identification used in a GNM message from the sender MUST be greater
   than that used in any previous GNM message, as the receiver uses this
   field also as a sequence number.  Without such a sequence number, it
   would be possible for a delayed duplicate of an earlier GNM message
   to arrive at the receiver (within the clock synchronization required
   by the receiver), and thus be applied out of order, mistakenly
   altering the sender's current status.

   Upon receipt of a GNM message with an authorization-enabling
   extension, the receiver MUST check the Identification field for
   validity.  In order to be valid, the timestamp contained in the
   Identification field MUST be close enough to the receiver's time of
   day clock and the timestamp MUST be greater than all previously
   accepted timestamps for the requesting sender.  Time tolerances and
   resynchronization details are specific to a particular mobility
   security association.

   If the timestamp is valid, the receiver copies the entire
   Identification field into the GNAM it returns the GNAM message to the
   sender.  If the timestamp is not valid, the receiver copies only the
   low-order 32 bits into the GNAM, and supplies the high-order 32 bits
   from its own time of day.  In this latter case, the receiver MUST
   reject the registration by returning Code 69/133/197 (identification
   mismatch) in the GNAM message.

   Furthermore, the receiver MUST verify that the low-order 32 bits of
   the Identification in the GNAM are identical to those in the rejected
   GNM attempt, before using the high-order bits for clock
   resynchronization.






Deng, et al.              Expires March 9, 2010                [Page 31]


Internet-Draft      MIP4 Generic Notification Message     September 2009


8.2.  Non-authentication Extensions Handling in Foreign Agent

   When the FA is relaying the GNM message between the MN and the HA,
   and if the FA does not share a mobility security association with the
   MN or HA, all non-authentication extensions between MN and FA, or FA
   and HA are not protected.













































Deng, et al.              Expires March 9, 2010                [Page 32]


Internet-Draft      MIP4 Generic Notification Message     September 2009


9.  Normative References

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3115]  Dommety, G. and K. Leung, "Mobile IP Vendor/
              Organization-Specific Extensions", RFC 3115, April 2001.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC4917]  Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message
              String Extension", RFC 4917, June 2007.



































Deng, et al.              Expires March 9, 2010                [Page 33]


Internet-Draft      MIP4 Generic Notification Message     September 2009


Authors' Addresses

   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: denghui02@gmail.com


   Henrik Levkowetz
   Ericsson Research
   Torshamsgatan 23
   S-164 80, Stockholm
   SWEDEN

   Email: henrik@levkowetz.com


   Vijay Devarapalli
   WiChorus
   3590 North First St
   San Jose, CA
   USA

   Email: dvijay@gmail.com


   Sri Gundavelli
   Cisco Systems
   170 W.Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com


   Brian Haley
   Hewlett-Packard Company
   110 Spitbrook Road
   Nashua, NH  03062
   USA

   Email: brian.haley@hp.com





Deng, et al.              Expires March 9, 2010                [Page 34]