MIP4 Working Group H. Deng Internet-Draft China Mobile Intended status: Standards Track H. Levkowetz Expires: May 7, 2009 Ericsson Research V. Devarapalli WiChorus S. Gundavelli Cisco Systems B. Haley Hewlett-Packard Company November 3, 2008 Generic Notification Message for Mobile IPv4 draft-ietf-mip4-generic-notification-message-07.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 May 7, 2009. Deng, et al. Expires May 7, 2009 [Page 1] Internet-Draft MIP4 Generic Notification Message November 2008 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Notification message - Usage Scenario's . . . . . . . . . . . 6 3.1. Notification message between a Home Agent and a Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Mobile Registered using a Foreign Agent Care-of Address . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Mobile Registered using a Co-located Care-of Address . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Notification message between a Foreign Agent and a Mobile Node . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Notification message between a Home Agent and a Foreign Agent . . . . . . . . . . . . . . . . . . . . . . 7 4. Generic Notification Message and Considerations . . . . . . . 8 4.1. Generic Notification Message . . . . . . . . . . . . . . . 8 4.2. Generic Notification Acknowledgment Message . . . . . . . 11 4.3. Mobile Node Consideration . . . . . . . . . . . . . . . . 14 4.3.1. Receiving Generic Notification Messages . . . . . . . 15 4.3.2. Sending Generic Notification Acknowledgement Message . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.3. Sending Generic Notification Messages . . . . . . . . 16 4.3.4. Receiving Generic Notification Acknowledgement Messages . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Foreign Agent Consideration . . . . . . . . . . . . . . . 18 4.4.1. Receiving Generic Notification Message . . . . . . . . 18 4.4.2. Sending Generic Notification Acknowledgement Messages . . . . . . . . . . . . . . . . . . . . . . . 19 4.4.3. Sending Generic Notification Messages . . . . . . . . 20 4.4.4. Receiving Generic Notification Acknowledgement Messages . . . . . . . . . . . . . . . . . . . . . . . 21 4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 21 4.5.1. Sending Generic Notification Messages . . . . . . . . 22 4.5.2. Receiving Generic Notification Acknowledgement Messages . . . . . . . . . . . . . . . . . . . . . . . 22 4.5.3. Receiving Generic Notification Messages . . . . . . . 23 4.5.4. Sending Generic Notification Acknowledgement Messages . . . . . . . . . . . . . . . . . . . . . . . 24 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Generic String Extension . . . . . . . . . . . . . . . . . 25 Deng, et al. Expires May 7, 2009 [Page 2] Internet-Draft MIP4 Generic Notification Message November 2008 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 27 7.1.1. Replay Protection using Timestamps . . . . . . . . . . 27 8. Normative References . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Deng, et al. Expires May 7, 2009 [Page 3] Internet-Draft MIP4 Generic Notification Message November 2008 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 May 7, 2009 [Page 4] Internet-Draft MIP4 Generic Notification Message November 2008 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 keywords "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 May 7, 2009 [Page 5] Internet-Draft MIP4 Generic Notification Message November 2008 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 May 7, 2009 [Page 6] Internet-Draft MIP4 Generic Notification Message November 2008 +----+ 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 May 7, 2009 [Page 7] Internet-Draft MIP4 Generic Notification Message November 2008 4. Generic Notification Message and Considerations This section describes in detail the generic notification message, generic notification acknowledgement message, and some considerations related to the handling of these messages in the MN, foreign agent and HA. 4.1. Generic Notification Message A generic notification message 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 or Reply message to the same entity. This would support NAT traversal and ensure same security association used for GNM/GNAM and RRQ/RRP. The generic notification message is defined as follows: IP Fields: Source Address Same as the last Registration Reply/Request message received. Destination Address Same as the last Registration Reply/Request message. UDP Fields: Source Port Same as the last Registration Reply/Request message. Destination Port Same as the last Registration Reply/Request message. The UDP header is followed by the Mobile IP fields shown below: Deng, et al. Expires May 7, 2009 [Page 8] Internet-Draft MIP4 Generic Notification Message November 2008 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 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 May 7, 2009 [Page 9] Internet-Draft MIP4 Generic Notification Message November 2008 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 A 64-bit number, constructed by the sender, used for matching Generic Notification with Generic Notification Acknowledgement, 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 and nonces is optional. Extensions Deng, et al. Expires May 7, 2009 [Page 10] Internet-Draft MIP4 Generic Notification Message November 2008 The fixed portion of the Generic Notification Message 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 mandate the MN-HA 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 information on the relative order in which different extensions, when present, must be placed in a Generic Notification Message. 4.2. Generic Notification Acknowledgment Message A generic notification acknowledgement message is sent by mobility agents or MNs to indicate the successful receipt of a generic notification message. IP Fields: Source Address Typically copied from the destination address of the Generic Notification to which the agent is replying. Destination Address Copied from the source address of the Generic Notification to which the agent is replying. UDP Fields: Source Port Copied from the source port of the corresponding Generic Notification. Destination Port Copied from the source port of the corresponding Generic Notification. The UDP header is followed by the Mobile IP fields shown below: Deng, et al. Expires May 7, 2009 [Page 11] Internet-Draft MIP4 Generic Notification Message November 2008 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 May 7, 2009 [Page 12] Internet-Draft MIP4 Generic Notification Message November 2008 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 Generic Notification Message. 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 May 7, 2009 [Page 13] Internet-Draft MIP4 Generic Notification Message November 2008 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 A 64-bit number, constructed by the sender, used for matching Generic Notification with Generic Notification Acknowledgement, 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 generic notification acknowledgement message 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 information on the relative order in which different extensions, when present, MUST be placed in a Generic Notification message. 4.3. Mobile Node Consideration It is possible that the MN MAY receive a generic notification message(GNM) from a FA or HA. Both in the case of FA-CoA and Co- located CoA, the MN MAY reply with a generic notification acknowledgement message (GNAM) based on the "A" flag in the GNM Deng, et al. Expires May 7, 2009 [Page 14] Internet-Draft MIP4 Generic Notification Message November 2008 message. 4.3.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. 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 acknowledgement with Code 0. 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 Registration Request, 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 SHOULD send a GNAM to the FA with Code 195, including an Identification field computed in accordance with the rules specified in Section 7.1.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 Identfication field is correct using the context selected by the SPI within mandatory authentication extension like MN-FA AE or MN-HA AE. See Section 7.1.1 for a description of how this is performed. If incorrect, the MN MUST reject the GNM and SHOULD send a GNAM to the initiator with Code 197, including an Identification field computed in accordance with the rules specified in Section 7.1.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. 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 SHOULD send a GNAM to the initiator with Code 196, including an Identification field computed in accordance with the rules specified in Section 7.1.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. Deng, et al. Expires May 7, 2009 [Page 15] Internet-Draft MIP4 Generic Notification Message November 2008 4.3.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), 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]. 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 insufficent 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, 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] In the case of a FA-CoA, the source address is the MN's HoA address 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.3.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, and the ordering of the extension is: the notification extension, 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]. Deng, et al. Expires May 7, 2009 [Page 16] Internet-Draft MIP4 Generic Notification Message November 2008 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 FA or HA. This is part of the mobility security association the MN shares with its FA or HA. See Section 7.1.1 for the method by which the MN computes the Identification field. 4.3.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 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 GNA 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 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 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 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 Deng, et al. Expires May 7, 2009 [Page 17] Internet-Draft MIP4 Generic Notification Message November 2008 silently discard the Notification Acknowledgement message. 4.4. Foreign Agent Consideration The FA can not only relay generic notification message between the HA and MN, but it can also initiate a GNM to the MN or HA, and it will depends on whether there is a binding for the MN. 4.4.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 check the FA-HA AE and Authenticator value in the Extension. If the FA validates the HA's GNM, it 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 and 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 MN if applicable, and MUST append the MN-FA AE, if the FA shares a mobility security association with the MN. 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 SHOULD send a GNAM to the HA with Code 68, including an Identification field computed in accordance with the rules specified in Section 7.1.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 Identfication field is correct using the context selected by the SPI within mandatory FA-HA AE. See Section 7.1.1 for a description of how this is performed. If incorrect, the FA MUST reject the GNM and SHOULD send a GNAM to the initiator with Code 69, including an Identification field computed in accordance with the rules specified in Section 7.1.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. Deng, et al. Expires May 7, 2009 [Page 18] Internet-Draft MIP4 Generic Notification Message November 2008 If FA accepts the HA's generic notification message, 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. if the "MD" value is set to 2, the FA MAY check the MN-FA AE and Authenticator value in the Extension. If the FA validates the MN's GNM, it MUST relay the GNM to the HA's address as specified in the Home Agent Address field of the GNM. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNM through and 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 MN if applicable, and MUST append the MN-FA AE, if the FA shares a mobility security association with the MN. If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the 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 SHOULD send a GNAM to the HA with Code 67, including an Identification field computed in accordance with the rules specified in Section 7.1.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 Identfication field is correct using the context selected by the SPI within mandatory MN-FA AE. See Section 7.1.1 for a description of how this is performed. If incorrect, the FA MUST reject the GNM and SHOULD send a GNAM to the initiator with Code 69, including an Identification field computed in accordance with the rules specified in Section 7.1.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.4.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: Deng, et al. Expires May 7, 2009 [Page 19] Internet-Draft MIP4 Generic Notification Message November 2008 The source address is the FA address, the destination address is HA's or 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 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 insufficent resources. If the FA is only relaying this message to the HA, the FA it MUST NOT modify any of the fields beginning with the fixed portion of the Generic Notification Acknowledgement through and including the MN-HA AE or other authentication extension supplied by the HA as an authorization-enabling extension for the MN. Furthermore, the foreign agent 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. It MUST also append the FA-HA AE, if the FA shares a mobility security association with the HA. 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 HA, 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 HA, followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 4.4.3. Sending Generic Notification Messages If the FA is initiating a notification to the MN using the generic notification message, 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), Deng, et al. Expires May 7, 2009 [Page 20] Internet-Draft MIP4 Generic Notification Message November 2008 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.4.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 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 presented, 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, 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 and 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.5. 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 Deng, et al. Expires May 7, 2009 [Page 21] Internet-Draft MIP4 Generic Notification Message November 2008 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.5.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]. 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.5.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, MN-HA AE MUST be checked, and the HA Deng, et al. Expires May 7, 2009 [Page 22] Internet-Draft MIP4 Generic Notification Message November 2008 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 Notification Acknowledgement message. If the HA accepted this message, the HA MAY also process it based on the notification event. In the case of a Co-located CoA, if the HA received this message, the 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 message. 4.5.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 SHOULD send a GNAM to the FA with Code 132, including an Identification field computed in accordance with the rules specified in Section 7.1.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 Identfication field is correct using the context selected by the SPI within mandatory authentication extension like MN-HA AE or FA-HA AE. See Section 7.1.1 for a description of how this is performed. If incorrect, the HA MUST reject the GNM and SHOULD send a GNAM to the initiator with Code 133, including an Identification field computed in accordance with the rules specified in Section 7.1.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, if FA-HA AE is presented, 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 SHOULD send a GNAM to the FA with Code 132, including an Identification field computed in accordance with the rules specified in Section 7.1.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 Deng, et al. Expires May 7, 2009 [Page 23] Internet-Draft MIP4 Generic Notification Message November 2008 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 SHOULD send a GNAM to the MN with Code 131, including an Identification field computed in accordance with the rules specified in Section 7.1.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.5.4. Sending Generic Notification Acknowledgement Messages If the GNM message came from the FA only, the HA MAY reply with a GNAM message to the FA 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 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 May 7, 2009 [Page 24] Internet-Draft MIP4 Generic Notification Message November 2008 5. Usage Example There are several applications that could use this generic notification message. 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 Stopping", "Prepaid Expire". These string MUST be strictly defined so they could be easily understood by all of the network entities. "Subtype" number would need to be decided by the working group. Deng, et al. Expires May 7, 2009 [Page 25] Internet-Draft MIP4 Generic Notification Message November 2008 6. IANA Considerations This document describes two new messages, the Generic Notification message, section 4.1 and the Generic Notification Acknowledgement message, 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 Generic Notification and Generic Notification Acknowledgement messages. New values should be allocated by Standards Actions or IETF Consensus. This document reserves four values for the Subtype field 0 Reserved 1 Information carried in Vendor specific extensions 2 Information carried in Generic String Extension Deng, et al. Expires May 7, 2009 [Page 26] Internet-Draft MIP4 Generic Notification Message November 2008 7. 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. 7.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 documents 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 HNM to the HNMA. The receiver uses those bits (and the sender's source address) to match HNAM with corresponding replies. The receiver MUST verify that the low-order 32 bits of any HNAM 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. 7.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 May 7, 2009 [Page 27] Internet-Draft MIP4 Generic Notification Message November 2008 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 May 7, 2009 [Page 28] Internet-Draft MIP4 Generic Notification Message November 2008 8. 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. [RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004. [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message String Extension", RFC 4917, June 2007. Deng, et al. Expires May 7, 2009 [Page 29] Internet-Draft MIP4 Generic Notification Message November 2008 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 May 7, 2009 [Page 30] Internet-Draft MIP4 Generic Notification Message November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Deng, et al. Expires May 7, 2009 [Page 31]