Update/Binding Acknowledgement messages when authenticated using the
mobility message authentication option as described in Section 5.
The mobility message replay protection option is used to let the Home
Agent verify that a Binding Update has been freshly generated by the
Mobile Node and not replayed by an attacker from some previous
Binding Update. This is especially useful for cases where the Home
Agent does not maintain stateful information about the Mobile Node
after the binding entry has been removed. The Home Agent does the
replay protection check after the Binding Update has been
authenticated. The mobility message replay protection option when
included is used by the Mobile Node for matching BA with BU.
If this mode of replay protection is used, it needs to be part of the
shared-key-based mobility security association.
If the policy at Home Agent mandates replay protection using this
option (as opposed to the sequence number in the Mobility Header in
Binding Update) and the Binding Update from the Mobile Node does not
include this option, the Home Agent discards the BU and sets the
Status Code in BA to MIPV6-MESG-ID-REQD.
When the Home Agent receives the mobility message replay protection
option in Binding Update, it MUST include the mobility message replay
protection option in Binding Acknowledgement. Appendix A provides
details regarding why the mobility message replay protection option
MAY be used when using the authentication option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Mobility Message Replay Protection Option
Option Type:
MESG-ID-OPTION-TYPE value 10 has been defined by IANA. An
8-bit identifier of the type mobility option.
Option Length:
8-bit unsigned integer, representing the length in octets of
the Timestamp field.
Timestamp:
This field carries the 64 bit timestamp.
Alignment requirements :
The alignment requirement for this option is 8n + 2.
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
shared-key-based mobility 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. The two nodes must have
adequately synchronized time-of-day clocks.
The Mobile Node MUST set the Timestamp field to a 64-bit value
formatted as specified by the Network Time Protocol (NTP) [RFC1305].
The low-order 32 bits of the NTP format represent fractional seconds,
and those bits that 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 timestamp used in a Binding Update from
the Mobile Node MUST be greater than that used in any previous
successful Binding Update.
After successful authentication of Binding Update (either locally at
the Home Agent or when a success indication is received from the AAA
server), the Home Agent MUST check the Timestamp field for validity.
In order to be valid, the timestamp contained in the Timestamp field
MUST be close enough to the Home Agent’s time-of-day clock and the
timestamp MUST be greater than all previously accepted timestamps for
the requesting Mobile Node.
If the timestamp is valid, the Home Agent copies the entire Timestamp
field into the Timestamp field in the BA it returns to the Mobile
Node. If the timestamp is not valid, the Home Agent copies only the
low-order 32 bits into the BA, and supplies the high-order 32 bits
from its own time of day.
If the Timestamp field is not valid but the authentication of the BU
succeeds, the Home Agent MUST send a Binding Acknowledgement with
status code MIPV6-ID-MISMATCH. The Home Agent does not create a
binding cache entry if the timestamp check fails.
If the Mobile Node receives a Binding Acknowledgement with the code
MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by
processing the MN-HA authentication mobility option.
If authentication succeeds, the Mobile Node MUST adjust its timestamp
and send subsequent Binding Update using the updated value.
Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH
status code, the Mobile Node MUST compare the Timestamp value in the
BA to the Timestamp value it sent in the corresponding BU. If the
values match, the Mobile Node proceeds to process the MN-HA
authentication data in the BA. If the values do not match, the
Mobile Node silently discards the BA.
7. Security Considerations
This document proposes new mobility message authentication options to
authenticate the control message between Mobile Node, Home Agent,
and/or home AAA (as an alternative to IPsec). The new options
provide for authentication of Binding Update and Binding
Acknowledgement messages. The MN-AAA mobility message authentication
option provide for authentication with AAA infrastructure.
This specification also introduces an optional replay protection
mechanism in Section 6, to prevent replay attacks. The sequence
number field in the Binding Update is not used if this mechanism is
used. This memo defines the timestamp option to be used for mobility
message replay protection.
8. IANA Considerations
IANA services are required for this specification. The values for
new mobility options and status codes must be assigned from the
Mobile IPv6 [RFC3775] numbering space.
The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID-
OPTION-TYPE, as defined in Section 5 and Section 6, have been
assigned. The values are 9 for the AUTH-OPTION-TYPE and 10 for the
MESG-ID-OPTION-TYPE Mobility Option.
The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL, and
MIPV6-MESG-ID-REQD, as defined in Section 6 and Section 5.3, have
been assigned. The values are 144 for MIPV6-ID-MISMATCH 145 for
MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
A new section for enumerating algorithms identified by specific
mobility SPIs within the range 0-255 has to be added to
http://www.iana.org/assignments/mobility-parameters
The currently defined values are as follows:
The value 0 should not be assigned.
The value 3 is reserved for HMAC_SHA1_SPI as defined in Section 5.2.
The value 5 is reserved for use by 3GPP2.
New values for this namespace can be allocated using IETF Consensus.
[RFC2434].
In addition, IANA has created a new namespace for the Subtype field
of the MN-HA and MN-AAA mobility message authentication options under
http://www.iana.org/assignments/mobility-parameters
The currently allocated values are as follows:
1 MN-HA mobility message authentication option Section 5.1
2 MN-AAA mobility message authentication option Section 5.2
New values for this namespace can be allocated using IETF Consensus.
[RFC2434].
9. Acknowledgements
The authors would like to thank Basavaraj Patil, Charlie Perkins,
Vijay Devarapalli, Jari Arkko, and Gopal Dommety, and Avi Lior for
their thorough review and suggestions on the document. The authors
would like to acknowledge the fact that a similar authentication
method was considered in base protocol [RFC3775] at one time.
10. References
10.1. Normative References
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile
IPv6", RFC 4283, November 2005.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
10.2. Informative References
[3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D,
September 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
Appendix A. Rationale for Mobility Message Replay Protection Option
Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility
header to prevent replay attacks. There are two aspects that stand
out in regards to using the Sequence Number to prevent replay
attacks.
First, the specification states that the Home Agent should accept a
BU with a Sequence Number greater than the Sequence Number from the
previous Binding Update. This implicitly assumes that the Home Agent
has some information regarding the Sequence Number from the previous
BU (even when the binding cache entry is not present). Second, the
specification states that if the Home Agent has no binding cache
entry for the indicated home address, it MUST accept any Sequence
Number value in a received Binding Update from this Mobile Node.
With the mechanism defined in this document, it is possible for the
Mobile Node to register with a different Home Agent during each
mobility session. Thus, it is unreasonable to expect each Home Agent
in the network to maintain state about the Mobile Node. Also, if the
Home Agent does not cache information regarding sequence number, as
per the second point above, a replayed BU can cause a Home Agent to
create a binding cache entry for the Mobile Node. Thus, when
authentication option is used, Sequence Number does not provide
protection against replay attack.
One solution to this problem (when the Home Agent does not save state
information for every Mobile Node) would be for the Home Agent to
reject the first BU and assign a (randomly generated) starting
sequence number for the session and force the Mobile Node to send a
fresh BU with the suggested sequence number. While this would work
in most cases, it would require an additional round trip, and this
extra signaling and latency is not acceptable in certain deployments
[3GPP2]. Also, this rejection and using sequence number as a nonce
in rejection is a new behavior that is not specified in [RFC3775].
Thus, this specification uses the mobility message replay protection
option to prevent replay attacks. Specifically, timestamps are used
to prevent replay attacks as described in Section 6.
It is important to note that as per Mobile IPv6 [RFC3775] this
problem with sequence number exists. Since the base specification
mandates the use of IPsec (and naturally that goes with IKE in most
cases), the real replay protection is provided by IPsec/IKE. In case
of BU/BA between Mobile Node and Client Node (CN), the liveness proof
is provided by the use of nonces that the CN generates.
Authors’ Addresses
Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-685-0574
EMail: mkhalil@nortel.com
Haseeb Akhtar
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-684-4732
EMail: haseebak@nortel.com
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 214 550 1416
EMail: kchowdhury@starentnetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).