MIP4 Working Group H. Deng
Internet-Draft China Mobile
Intended status: Standards Track H. Levkowetz
Expires: August 6, 2010 Ericsson Research
V. Devarapalli
WiChorus
S. Gundavelli
Cisco Systems
B. Haley
Hewlett-Packard Company
February 2, 2010
Generic Notification Message for Mobile IPv4
draft-ietf-mip4-generic-notification-message-13.txt
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 6, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Deng, et al. Expires August 6, 2010 [Page 1]
Internet-Draft MIP4 Generic Notification Message February 2010
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Deng, et al. Expires August 6, 2010 [Page 2]
Internet-Draft MIP4 Generic Notification Message February 2010
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. Notification Retransmision . . . . . . . . . . . . . . . . 15
4.4. Mobile Node Consideration . . . . . . . . . . . . . . . . 15
4.4.1. Receiving Generic Notification Messages . . . . . . . 15
4.4.2. Sending Generic Notification Acknowledgement
Message . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.3. Sending Generic Notification Messages . . . . . . . . 17
4.4.4. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Foreign Agent Consideration . . . . . . . . . . . . . . . 18
4.5.1. Receiving Generic Notification Message . . . . . . . . 18
4.5.2. Sending Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.3. Sending Generic Notification Messages . . . . . . . . 21
4.5.4. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 22
4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 22
4.6.1. Sending Generic Notification Messages . . . . . . . . 23
4.6.2. Receiving Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.3. Receiving Generic Notification Messages . . . . . . . 24
4.6.4. Sending Generic Notification Acknowledgement
Messages . . . . . . . . . . . . . . . . . . . . . . . 25
5. Future Extensibility . . . . . . . . . . . . . . . . . . . . . 26
5.1. Generic String Extension . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 28
7.1.1. Replay Protection using Timestamps . . . . . . . . . . 29
7.1.2. Replay Protection using Nonces . . . . . . . . . . . . 30
7.2. Non-authentication Extensions Handling in Foreign Agent . 30
Deng, et al. Expires August 6, 2010 [Page 3]
Internet-Draft MIP4 Generic Notification Message February 2010
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. Normative References . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Deng, et al. Expires August 6, 2010 [Page 4]
Internet-Draft MIP4 Generic Notification Message February 2010
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.
It also defines a corresponding acknowledgement message to allow for
reliable delivery of notifications. The messages defined in this
document are capable of carrying the same extensions that have been
defined for the existing Mobile IPv4 messages. However, this
document requires for now that only the following extensions be
present in the new messages defined herein:
- MN-HA Authentication Extension
- MN-FA Authentication Extension
- FA-HA Authentication Extension
- Generic String Extension
For now, the semantics of receiving a generic notification message
are null; i.e., it has no effect on the state of a mobile node's
existing registration. See Section 5 for some prospective
application examples that motivate the new messages defined in this
document. Future documents may specify additional extension types
that may be used in a generic notification message and their
semantics.
Deng, et al. Expires August 6, 2010 [Page 5]
Internet-Draft MIP4 Generic Notification Message February 2010
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 August 6, 2010 [Page 6]
Internet-Draft MIP4 Generic Notification Message February 2010
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 August 6, 2010 [Page 7]
Internet-Draft MIP4 Generic Notification Message February 2010
+----+ 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 August 6, 2010 [Page 8]
Internet-Draft MIP4 Generic Notification Message February 2010
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, FA also needs
to maintain both the 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 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 Typically copied from the destination
address of the last Registration Reply/
Request message that the agent received from
the agent to which it is sending the GNM.
Destination Address Copied from the source address of the last
Registration Reply/Request message that the
agent received from the agent to which it is
sending the GNM.
UDP Fields:
Deng, et al. Expires August 6, 2010 [Page 9]
Internet-Draft MIP4 Generic Notification Message February 2010
Source Port Typically copied from the destination port
of the last Registration Reply/Request
message that the agent received from the
agent to which it is sending the GNM.
Destination Port Copied from the source port of the last
Registration Reply/Request message that the
agent received from the agent to which it is
sending the GNM.
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 (To be assigned by IANA)
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 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 generic string
extensions. Other values are reserved for future extensions.
Deng, et al. Expires August 6, 2010 [Page 10]
Internet-Draft MIP4 Generic Notification Message February 2010
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, then 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 August 6, 2010 [Page 11]
Internet-Draft MIP4 Generic Notification Message February 2010
A 64-bit number, constructed by the sender, used for matching GNM
with GNAM, and for protecting against replay attacks of
notification messages. See Sections 8.1.1 and 8.1.2. Timestamps
is mandatory and nonces is optional.
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, MN-FA AE and
FA-HA AE are optional. This document also mandate the MN-FA AE
when this message is sent between the MN and the FA, MN-HA AE and
FA-HA AE are not needed. This document mandate the FA-HA AE when
this message is sent between the FA and the HA, MN-HA AE and MN-FA
AE are not needed. 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 August 6, 2010 [Page 12]
Internet-Draft MIP4 Generic Notification Message February 2010
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 (To be assgined by IANA)
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 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 Generic String
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
2 -- Message sent by the MN to the HA
3 -- Message sent by the MN to the FA
Deng, et al. Expires August 6, 2010 [Page 13]
Internet-Draft MIP4 Generic Notification Message February 2010
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
192 -- reason unspecified
193 -- administratively prohibited
Deng, et al. Expires August 6, 2010 [Page 14]
Internet-Draft MIP4 Generic Notification Message February 2010
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 used for matching GNM message with GNAM mesage and
for protecting against replay attacks of registration messages.
See Sections 8.1.1 and 8.1.2. Timestamps is mandatory and nonces
is optional. The value is based on the Identification field from
the GNM message from the sender, and on the style of replay
protection used in the security context between the sender and its
receiver (defined by the mobility security association between
them, and SPI value in the authorization-enabling extension).
Extensions
The fixed portion of the GNAM 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, MN-FA AE and
FA-HA AE are optional. This document also mandate the MN-FA AE
when this message is sent between the MN and the FA, MN-HA AE and
FA-HA AE are not needed. This document mandate the FA-HA AE when
this message is sent between the FA and the HA, MN-HA AE and MN-FA
AE are not needed. 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.
Deng, et al. Expires August 6, 2010 [Page 15]
Internet-Draft MIP4 Generic Notification Message February 2010
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, then
another GNM will be retransmited. When timestamps are used, a new
registration Identification is chosen for each retransmision; Thus it
counts as a new GNM. When nonces are used, the unanswered GNM
message is retransmitted unchanged; thus the retransmission does not
count as a new GNM (Section 8.1). In this way a retransmission will
not require the receiver to resynchronize with the sender by issuing
another nonce in the case in which the original GNM message (rather
than its GNAM message) was lost by the network.
The maximum time until a new GNM message is sent SHOULD be no greater
than the requested Lifetime of the last GNM message. 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 sender'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, then 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, then MN-FA AE MUST be present. If no MN-FA
Deng, et al. Expires August 6, 2010 [Page 16]
Internet-Draft MIP4 Generic Notification Message February 2010
AE is found, or if more than one MN-FA AE is found, or if the
Authenticator is invalid, then 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
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, then 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, then 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, then 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), then 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
Deng, et al. Expires August 6, 2010 [Page 17]
Internet-Draft MIP4 Generic Notification Message February 2010
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, then 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
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, then 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, then 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].
Deng, et al. Expires August 6, 2010 [Page 18]
Internet-Draft MIP4 Generic Notification Message February 2010
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, then 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, then 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, then the GNAM MUST be silently discarded.
If the "MD" value is set to 0, then 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, then the MN MUST silently discard the GNAM.
If the MN accepted this message, then 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,
then 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,
then 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, then it
means that the HA is asking the FA to relay the message to the MN.
If the "MD" value is set to 1, then it means that the target of the
notification is the FA. If the "MD" value is set to 2, then it means
that the MN is asking the FA to relay the message to the HA. If the
"MD" value is set to 3, then it means that the notification came from
Deng, et al. Expires August 6, 2010 [Page 19]
Internet-Draft MIP4 Generic Notification Message February 2010
the MN to the FA.
If the "MD" value is set to 0, then the FA MAY validate the FA-HA AE
if present. If the FA-HA AE is invalid, then 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.
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
Deng, et al. Expires August 6, 2010 [Page 20]
Internet-Draft MIP4 Generic Notification Message February 2010
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
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.
Deng, et al. Expires August 6, 2010 [Page 21]
Internet-Draft MIP4 Generic Notification Message February 2010
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
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.
Deng, et al. Expires August 6, 2010 [Page 22]
Internet-Draft MIP4 Generic Notification Message February 2010
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
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.
Deng, et al. Expires August 6, 2010 [Page 23]
Internet-Draft MIP4 Generic Notification Message February 2010
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].
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
Deng, et al. Expires August 6, 2010 [Page 24]
Internet-Draft MIP4 Generic Notification Message February 2010
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.
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
Deng, et al. Expires August 6, 2010 [Page 25]
Internet-Draft MIP4 Generic Notification Message February 2010
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
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, 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 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 August 6, 2010 [Page 26]
Internet-Draft MIP4 Generic Notification Message February 2010
5. Future Extensibility
The HA, FA, and MN SHOULD expose a list of the supported
notifications to operators via some management interface, and there
SHOULD be switches to enable / disable individual types of
notifications and to tune the retransmission timers for each type.
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, anyway existing Registration Revocation
RFC [RFC3543] is a one way to do this. Other applications such as HA
switch over when HA decide to go offline and would like to scheduled
notify the MN to register to the other candidate HAs , NEMO prefix
changes when MN is notified by HA about NEMO prefix changes , service
or billing related events which is more operational requirement, 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.
For now, none of these future semantics are supported and only the
Generic String Extension is supported for informational purposes.
There should be minimum requirements given here for adding additional
extension types to the allowed set and defining their semantics; It
would better follow the way of the specification required.
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 August 6, 2010 [Page 27]
Internet-Draft MIP4 Generic Notification Message February 2010
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 two values for the Subtype
field
0 Reserved
1 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 August 6, 2010 [Page 28]
Internet-Draft MIP4 Generic Notification Message February 2010
7. Security Considerations
This specification operates in the security constraints and
requirements of [RFC3344]. It require that when these 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. Two methods
are described in this section: timestamps (mandatory) and "nonces"
(optional). All senders and receivers MUST implement timestamp-based
replay protection. These nodes MAY also implement nonce-based replay
protection
The style of replay protection in effect between any two peer nodes
among MN, FA and HA is part of the mobile security association. 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.
Whatever method is used, 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.
Deng, et al. Expires August 6, 2010 [Page 29]
Internet-Draft MIP4 Generic Notification Message February 2010
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
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 . 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 August 6, 2010 [Page 30]
Internet-Draft MIP4 Generic Notification Message February 2010
7.1.2. Replay Protection using Nonces
The basic principle of nonce replay protection is that node A
includes a new random number in every message to node B, and checks
that node B returns that same number in its next message to node A.
Both messages use an authentication code to protect against
alteration by an attacker. At the same time node B can send its own
nonces in all messages to node A (to be echoed by node A), so that it
too can verify that it is receiving fresh messages.
The receiver may be expected to have resources for computing pseudo-
random numbers useful as nonces [RFC1750]. It inserts a new nonce as
the high-order 32 bits of the identification field of every GNAM
message. The receiver copies the low-order 32 bits of the
Identification from the GNM message into the low-order 32 bits of the
Identification in the GNAM message. When the sender receives an
authenticated GNAM message from the receiver, it saves the high-order
32 bits of the identification for use as the high-order 32 bits of
its next GNM message.
The sender is responsible for generating the low-order 32 bits of the
Identification in each GNM message. Ideally it should generate its
own random nonces. However it may use any expedient method,
including duplication of the random value sent by the receiver. The
method chosen is of concern only to the sender , because it is the
node that checks for valid values in the GNAM message. The high-
order and low-order 32 bits of the identification chosen SHOULD both
differ from their previous values. The receiver uses a new high-
order value and the sender uses a new low-order value for each
registration message.
If a GNM message is rejected because of an invalid nonce, the GNAM
always provides the sender with a new nonce to be used in the next
registration. Thus the nonce protocol is self- synchronizing.
7.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; In this case, all non-authentication
extensions should be silently discarded.
Deng, et al. Expires August 6, 2010 [Page 31]
Internet-Draft MIP4 Generic Notification Message February 2010
8. Acknowledgments
The author appreciate the efforts of Ahmad Muhanna for his detail
reviewing of this document and his many contributions to the text of
this document. The author also wants to thank Kent Leung, Peng Yang
and Peter McCann et al. for their helping developing this document.
Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E.
Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu,
Tim Polk, Amanda Baber, and Joseph Salowey's discussion and comments.
Thanks to Jari Arkko for each step of this document.
Deng, et al. Expires August 6, 2010 [Page 32]
Internet-Draft MIP4 Generic Notification Message February 2010
9. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[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.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003.
[RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message
String Extension", RFC 4917, June 2007.
Deng, et al. Expires August 6, 2010 [Page 33]
Internet-Draft MIP4 Generic Notification Message February 2010
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 August 6, 2010 [Page 34]
