draft-ietf-mip6-auth-protocol-07.txt   rfc4285.txt 
Network Working Group A. Patel Network Working Group A. Patel
Internet-Draft K. Leung Request for Comments: 4285 K. Leung
Expires: March 23, 2006 Cisco Systems Category: Informational Cisco Systems
M. Khalil M. Khalil
H. Akhtar H. Akhtar
Nortel Networks Nortel Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
September 19, 2005 January 2006
Authentication Protocol for Mobile IPv6 Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This memo provides information for the Internet community. It does
applicable patent or other IPR claims of which he or she is aware not specify an Internet standard of any kind. Distribution of this
have been or will be disclosed, and any of which he or she becomes memo is unlimited.
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 Copyright Notice
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 Copyright (C) The Internet Society (2006).
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at IESG Note
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 23, 2006. This RFC is not a candidate for any level of Internet Standard. RFC
3775 and 3776 define Mobile IPv6 and its security mechanism. This
document presents an alternate security mechanism for Mobile IPv6
used in 3GPP2 networks.
Copyright Notice The security properties of this mechanism have not been reviewed in
the IETF. Conducting this review proved difficult because the
standards-track security mechanism for Mobile IPv6 is tightly
integrated into the protocol; extensions to Mobile IPv6 and the core
documents make assumptions about the properties of the security model
without explicitly stating what assumptions are being made. There is
no documented service model. Thus it is difficult to replace the
security mechanism and see if the current protocol and future
extensions meet appropriate security requirements both under the
original and new security mechanisms. If a service model for Mobile
IPv6 security is ever formally defined and reviewed, a mechanism
similar to this one could be produced and fully reviewed.
Copyright (C) The Internet Society (2005). Section 1.1 of this document provides an applicability statement for
this RFC. The IESG recommends against the usage of this
specification outside of environments that meet the conditions of
that applicability statement. In addition the IESG recommends those
considering deploying or implementing this specification conduct a
sufficient security review to meet the conditions of the environments
in which this RFC will be used.
Abstract Abstract
IPsec is specified as the means of securing signaling messages IPsec is specified as the means of securing signaling messages
between the Mobile Node and Home agent for Mobile IPv6 (MIPv6). between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).
MIPv6 signalling messages that are secured include the Binding MIPv6 signaling messages that are secured include the Binding Updates
Updates and Acknowledgement messages used for managing the bindings and Acknowledgement messages used for managing the bindings between a
between a Mobile Node and its Home Agent. This document proposes an Mobile Node and its Home Agent. This document proposes an alternate
alternate method for securing MIPv6 signaling messages between a method for securing MIPv6 signaling messages between Mobile Nodes and
Mobile Nodes and Home Agents. The alternate method defined here Home Agents. The alternate method defined here consists of a
conists of a MIPv6-specific authentication option that can be added MIPv6-specific mobility message authentication option that can be
to MIPv6 signalling messages. added to MIPv6 signaling messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 1.1. Applicability Statement ....................................3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview ........................................................4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology .....................................................5
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Terms ..............................................5
4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7 4. Operational Flow ................................................6
5. Mobility message authentication option . . . . . . . . . . . . 8 5. Mobility Message Authentication Option ..........................7
5.1. MN-HA authentication mobility option . . . . . . . . . . . 10 5.1. MN-HA Mobility Message Authentication Option ...............8
5.1.1. Processing Considerations . . . . . . . . . . . . . . 10 5.1.1. Processing Considerations ...........................9
5.2. MN-AAA authentication mobility option . . . . . . . . . . 11 5.2. MN-AAA Mobility Message Authentication Option ..............9
5.2.1. Processing Considerations . . . . . . . . . . . . . . 12 5.2.1. Processing Considerations ..........................10
5.3. Authentication Failure Detection at the Mobile Node . . . 12 5.3. Authentication Failure Detection at the Mobile Node .......11
6. Mobility message replay protection option . . . . . . . . . . 13 6. Mobility Message Replay Protection Option ......................11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations ........................................13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations ............................................14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements ...............................................15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References ....................................................15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References .....................................15
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References ...................................15
Appendix A. Rationale for mobility message replay protection Appendix A. Rationale for mobility message replay protection
option . . . . . . . . . . . . . . . . . . . . . . . 20 option ................................................16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
The base Mobile IPv6 specification [RFC3775] specifies the signaling The base Mobile IPv6 specification [RFC3775] specifies the signaling
messages, Binding Update (BU) and Binding Acknowledgement (BA), messages, Binding Update (BU) and Binding Acknowledgement (BA),
between the Mobile Node and Home agent to be secured by the IPsec between the Mobile Node (MN) and Home Agent (HA) to be secured by the
Security Associations (IPsec SAs) that are established between these IPsec Security Associations (IPsec SAs) that are established between
two entities. these two entities.
This document proposes a solution for securing the Binding Update and This document proposes a solution for securing the Binding Update and
Binding Acknowledgment messages between the Mobile Node and Home Binding Acknowledgment messages between the Mobile Node and Home
agent using an authentication option which is included in these Agent using a mobility message authentication option that is included
messages. Such a mechanism enables IPv6 mobility in a host without in these messages. Such a mechanism enables IPv6 mobility in a host
having to establish an IPsec SA with its Home Agent. A Mobile Node without having to establish an IPsec SA with its Home Agent. A
can implement Mobile IPv6 without having to integrate it with the Mobile Node can implement Mobile IPv6 without having to integrate it
IPsec module, in which case the Binding Update and Binding with the IPsec module, in which case the Binding Update and Binding
Acknowldegement messages (between MN-HA) are secured with the Acknowledgement messages (between MN-HA) are secured with the
authentication option. mobility message authentication option.
The authentication mechanism proposed here is similar to the The authentication mechanism proposed here is similar to the
authentication mechanism used in Mobile IPv4 [RFC3344]. authentication mechanism used in Mobile IPv4 [RFC3344].
1.1. Applicability Statement 1.1. Applicability Statement
The authentication option specified in Section 5 is applicable in The mobility message authentication option specified in Section 5 is
certain types of networks that have the following characteristics: applicable in certain types of networks that have the following
characteristics:
- Networks in which the authentication of the MN for network access - Networks in which the authentication of the MN for network access
is done by an authentication server in the home network via the home is done by an authentication server in the home network via the home
agent. The security association is established by the network agent. The security association is established by the network
operator (provisioning methods) between the MN and a backend operator (provisioning methods) between the MN and a backend
authentication server (eg. AAA home server). MIP6 as per RFC3775/ authentication server (e.g., Authentication, Authorization, and
3776 relies on the IPsec SA between the MN and an HA. In cases where Accounting (AAA) home server). MIPv6 as per RFCs 3775 and 3776
the assignment of the HA is dynamic and the only static or long term relies on the IPsec SA between the MN and an HA. In cases where the
SA is between the MN and a backend authentication server, the assignment of the HA is dynamic and the only static or long-term SA
authentication option is desirable. is between the MN and a backend authentication server, the mobility
message authentication option is desirable.
- In certain deployment environments, the mobile node needs dynamic - In certain deployment environments, the mobile node needs dynamic
assignment of a home agent and home address. The assignment of such assignment of a home agent and home address. The assignment of such
can be on a per session basis or on a per MN power-up basis. In such can be on a per-session basis or on a per-MN power-up basis. In such
scenarios, the MN relies on an identity such as an NAI [MN_Ident], scenarios, the MN relies on an identity such as a Network Access
and a security association with a AAA server to obtain such Identifier (NAI) [RFC4283], and a security association with a AAA
bootstrapping information. The security association is created via server to obtain such bootstrapping information. The security
an out-of-band mechanism or by non Mobile IPv6 signaling. The out- association is created via an out-of-band mechanism or by non Mobile
of-band mechanism can be specific to the deployment environment of a IPv6 signaling. The out-of-band mechanism can be specific to the
network operator. In cdma network deployments this information can deployment environment of a network operator. In Code Division
be obtained at the time of network access authentication via [3GPP2] Multiple Access (CDMA) network deployments, this information can be
obtained at the time of network access authentication via [3GPP2]
specific extensions to PPP or DHCPv6 on the access link and by AAA specific extensions to PPP or DHCPv6 on the access link and by AAA
extensions in the core. It should be noted that the out-of-band extensions in the core. It should be noted that the out-of-band
mechanism if not within the scope of the authentication option mechanism is not within the scope of the mobility message
Section 5 and hence not described therein. authentication option (Section 5) and hence is not described therein.
- Network deployments in which not all mobile nodes and home agents - Network deployments in which not all Mobile Nodes and Home Agents
have IKEv2 implementations and support for the integration of IKEv2 have IKEv2 implementations and support for the integration of IKEv2
with backend AAA infrastructures. IKEv2 as a technology has yet to with backend AAA infrastructures. IKEv2 as a technology has yet to
reach maturity status and widespread implementations needed for reach maturity status and widespread implementations needed for
commercial deployments on a large scale. At the time of this writing commercial deployments on a large scale. At the time of this
[IKEv2-REF] is yet to be published as an RFC. Hence from a practical writing, [RFC4306] is yet to be published as an RFC. Hence from a
perspective that operators face, IKEv2 is not yet capable of practical perspective that operators face, IKEv2 is not yet capable
addressing the immediate need for MIP6 deployment. of addressing the immediate need for MIPv6 deployment.
- Networks which expressly rely on the backend AAA infrastructure as - Networks that expressly rely on the backend AAA infrastructure as
the primary means for identifying and authentication/authorizing a the primary means for identifying and authentication/authorizing a
mobile user for MIP6 service. mobile user for MIPv6 service.
- Networks in which the establishment of the security association - Networks in which the establishment of the security association
between the mobile node and the authentication server (AAA Home) is between the Mobile Node and the authentication server (AAA Home) is
established using an out-of-band mechanism and not by any key established using an out-of-band mechanism and not by any key
exchange protocol. Such networks will also rely on out-of-band exchange protocol. Such networks will also rely on out-of-band
mechanisms to renew the security association (between MN and AAA mechanisms to renew the security association (between MN and AAA
Home) when needed. Home) when needed.
- Networks which are bandwidth constrained (such as cellular wireless - Networks that are bandwidth constrained (such as cellular wireless
networks) and there exists a strong desire to minimize the number of networks) and for which there exists a strong desire to minimize the
signaling messages sent over such interfaces. MIP6 signaling which number of signaling messages sent over such interfaces. MIPv6
relies on IKE as the primary means for setting up an SA between the signaling that relies on Internet Key Exchange (IKE) as the primary
MN and HA requires more signaling messages compared with the use of means for setting up an SA between the MN and HA requires more
an authentication option carried in the BU/BAck messages. signaling messages compared with the use of an mobility message
authentication option carried in the BU/BA messages.
One such example of networks that have such characteristics are cdma One such example of networks that have such characteristics are CDMA
networks as defined in [3GPP2]. networks as defined in [3GPP2].
2. Overview 2. Overview
This document presents a lightweight mechanism to authenticate the This document presents a lightweight mechanism to authenticate the
Mobile Node at the Home Agent or at the Authentication, Authorization Mobile Node at the Home Agent or at the Authentication,
and Accounting (AAA) server in Home network (AAAH) based on a shared- Authorization, and Accounting (AAA) server in Home network (AAAH)
key based mobility security association between the Mobile Node and based on a shared-key-based mobility security association between the
the respective authenticating entity. This shared-key based mobility Mobile Node and the respective authenticating entity. This shared-
security association (shared-key based mobility SA) may be statically key-based mobility security association (shared-key-based mobility
provisioned or dynamically created. The term "mobility security SA) may be statically provisioned or dynamically created. The term
association" referred to in this document is understood to be a "mobility security association" referred to in this document is
"shared-key based Mobile IPv6 authentication" security association. understood to be a "shared-key-based Mobile IPv6 authentication"
security association.
This document introduces new mobility options to aid in This document introduces new mobility options to aid in
authentication of the Mobile Node to the Home Agent or AAAH server. authentication of the Mobile Node to the Home Agent or AAAH server.
The confidentiality protection of Return Routability messages and The confidentiality protection of Return Routability messages and
authentication/integrity protection of Mobile Prefix Discovery (MPD) authentication/integrity protection of Mobile Prefix Discovery (MPD)
is not provided when these options are used for authentication of the is not provided when these options are used for authentication of the
Mobile Node to the Home Agent. Thus, unless the network can Mobile Node to the Home Agent. Thus, unless the network can
guarantee such protection (for instance, like in 3gpp2 networks), guarantee such protection (for instance, like in 3GPP2 networks),
Route Optimization and Mobile Prefix Discovery should not be used Route Optimization and Mobile Prefix Discovery should not be used
when using the authentication option. when using the mobility message authentication option.
3. Terminology 3. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
3.1. General Terms 3.1. General Terms
First (size, input) First (size, input)
Some formulas in this specification use a functional form "First Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that (size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used. only the first "size" bits remain to be used.
Shared-key based Mobility Security Association Shared-key-based Mobility Security Association
Security relation between Mobile Node and its Home Agent, used to Security relation between the Mobile Node and its Home Agent, used
authenticate the Mobile Node for mobility service. The shared-key to authenticate the Mobile Node for mobility service. The
based mobility security association between Mobile Node and Home shared-key-based mobility security association between Mobile Node
Agent consists of a mobility SPI, a shared-key, an authentication and Home Agent consists of a mobility Security Parameter Index
algorithm and the replay protection mechanism in use. (SPI), a shared key, an authentication algorithm, and the replay
protection mechanism in use.
Mobility SPI Mobility SPI
A number in the range [0-4294967296] used to index into the A number in the range [0-4294967296] used to index into the
shared-key based mobility security associations. shared-key-based mobility security associations.
4. Operational flow 4. Operational Flow
The figure below describes the sequence of messages sent and received The figure below describes the sequence of messages sent and received
between the MN and HA in the registration process. Binding Update between the MN and HA in the registration process. Binding Update
(BU) and Binding Acknowledgement (BA) messages are used in the (BU) and Binding Acknowledgement (BA) messages are used in the
registration process. registration process.
MN HA/AAAH MN HA/AAAH
| BU to HA | | BU to HA |
(a) |----------------------------------------------------->| (a) |----------------------------------------------------->|
| (including MN-ID option, | | (including MN-ID option, |
| Message ID option [optional], authentication option)| | mobility message replay protection option[optional],|
| | | mobility message authentication option) |
| | | |
| HA/AAAH authenticates MN | HA/AAAH authenticates MN
| | | |
| | | |
| BA to MN | | BA to MN |
(b) |<-----------------------------------------------------| (b) |<-----------------------------------------------------|
| (including MN-ID option, | | (including MN-ID option, |
| Message ID option [optional], authentication option)| | mobility message replay protection option[optional],|
| mobility message authentication option) |
| | | |
Figure 1: Home Registration with Authentication Protocol Figure 1: Home Registration with Authentication Protocol
The Mobile Node MUST use the Mobile Node Identifier Option, The Mobile Node MUST use the Mobile Node Identifier option,
specifically the MN-NAI mobility option as defined in [MN_Ident] to specifically the MN-NAI mobility option as defined in [RFC4283] to
identify itself while authenticating with the Home Agent. The mobile identify itself while authenticating with the Home Agent. The Mobile
node uses the Mobile Node Identifier option as defined in [MN_Ident] Node uses the Mobile Node Identifier option as defined in [RFC4283]
to identify itself as may be required for use with some existing AAA to identify itself as may be required for use with some existing AAA
infrastructure designs. infrastructure designs.
Mobile Node MAY use Message Identifier option as defined in Section 6 The Mobile Node MAY use the Message Identifier option as defined in
for additional replay protection. Section 6 for additional replay protection.
The authentication option described in Section 5 may be used by the The mobility message authentication option described in Section 5 may
mobile node to transfer authentication data when the mobile node and be used by the Mobile Node to transfer authentication data when the
the home agent are utilizing a mobility SPI (a number in the range Mobile Node and the Home Agent are utilizing a mobility SPI (a number
[0-4294967296] used to index into the shared-key based mobility in the range [0-4294967296] used to index into the shared-key-based
security associations). to index between multiple mobility security mobility security associations) to index between multiple mobility
associations. security associations.
5. Mobility message authentication option 5. Mobility Message Authentication Option
This section defines a message authentication mobility option that This section defines a mobility message authentication option that
may be used to secure Binding Update and Binding Acknowledgement may be used to secure Binding Update and Binding Acknowledgement
messages. This option can be used along with IPsec or preferably as messages. This option can be used along with IPsec or preferably as
an alternate mechanism to authenticate Binding Update and Binding an alternate mechanism to authenticate Binding Update and Binding
Acknowledgement messages in the absence of IPsec. Acknowledgement messages in the absence of IPsec.
This document also defines subtype numbers, which identify the mode This document also defines subtype numbers, which identify the mode
of authentication and the peer entity to authenticate the message. of authentication and the peer entity to authenticate the message.
Two subtype numbers are specified in this document. Other subtypes Two subtype numbers are specified in this document. Other subtypes
may be defined for use in the future. may be defined for use in the future.
Only one instance of an authentication option of a particular subtype Only one instance of a mobility message authentication option of a
can be present in the message. One message may contain multiple particular subtype can be present in the message. One message may
instances of authentication options with different subtype values. contain multiple instances of the mobility message authentication
If both MN-HA and MN-AAA authentication options are present, MN-HA option with different subtype values. If both MN-HA and MN-AAA
authentication option must be present before the MN-AAA authentication options are present, the MN-HA authentication option
authentication option (else, the HA MUST discard the message). must be present before the MN-AAA authentication option (else, the HA
MUST discard the message).
When a Binding Update or Binding Acknowledgement is received without When a Binding Update or Binding Acknowledgement is received without
an authentication option and the entity receiving it is configured to a mobility message authentication option and the entity receiving it
use authentication option or has the shared-key based mobility is configured to use the mobility message authentication option or
security association for authentication option, the entity should has the shared-key-based mobility security association for the
silently discard the received message. mobility message authentication option, the entity should silently
discard the received message.
0 1 2 3 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 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 | Subtype | | Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI | | Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data .... | Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2: Mobility Message Authentication Option
Option Type: Option Type:
AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of AUTH-OPTION-TYPE value 9 has been defined by IANA. An 8-bit
the type mobility option. identifier of the type mobility option.
Option Length: Option Length:
8-bit unsigned integer, representing the length in octets of 8-bit unsigned integer, representing the length in octets of
the Sub-type, mobility Security Parameter Index (SPI) and the Subtype, mobility Security Parameter Index (SPI) and
Authentication Data fields. Authentication Data fields.
Subtype: Subtype:
A number assigned to identify the entity and/or mechanism to be A number assigned to identify the entity and/or mechanism to be
used to authenticate the message. used to authenticate the message.
Mobility SPI: Mobility SPI:
Mobility Security Parameter Index Mobility Security Parameter Index
skipping to change at page 10, line 5 skipping to change at page 8, line 30
Authentication Data: Authentication Data:
This field has the information to authenticate the relevant This field has the information to authenticate the relevant
mobility entity. This protects the message beginning at the mobility entity. This protects the message beginning at the
Mobility Header upto and including the mobility SPI field. Mobility Header upto and including the mobility SPI field.
Alignment requirements : Alignment requirements :
The alignment requirement for this option is 4n + 1. The alignment requirement for this option is 4n + 1.
5.1. MN-HA authentication mobility option 5.1. MN-HA Mobility Message Authentication Option
The format of the MN-HA authentication mobility option is as defined The format of the MN-HA mobility message authentication option is as
in Figure 2. This option uses the subtype value of 1. The MN-HA defined in Figure 2. This option uses the subtype value of 1. The
authentication mobility option is used to authenticate the Binding MN-HA mobility message authentication option is used to authenticate
Update and Binding Acknowledgement messages based on the shared-key the Binding Update and Binding Acknowledgement messages based on the
based security association between the Mobile Node and the Home shared-key-based security association between the Mobile Node and the
Agent. Home Agent.
The shared-key based mobility security association between Mobile The shared-key-based mobility security association between Mobile
Node and Home Agent used within this specification consists of a Node and Home Agent used within this specification consists of a
mobility SPI, a key, an authentication algorithm and the replay mobility SPI, a key, an authentication algorithm, and the replay
protection mechanism in use. The mobility SPI is a number in range protection mechanism in use. The mobility SPI is a number in the
[0-4294967296], where the range [0-255] is reserved. The key range [0-4294967296], where the range [0-255] is reserved. The key
consists of an arbitrary value and is 16 octets in length. The consists of an arbitrary value and is 16 octets in length. The
authentication algorithm is HMAC_SHA1. The replay protection authentication algorithm is HMAC_SHA1. The replay protection
mechanism may use the Sequence number as specified in [RFC3775] or mechanism may use the Sequence number as specified in [RFC3775] or
the option as defined in Section 6. If the Timestamp option is used the Timestamp option as defined in Section 6. If the Timestamp
for replay protection as defined in Section 6, the mobility security option is used for replay protection, the mobility security
association includes a "close enough" field to account for clock association includes a "close enough" field to account for clock
drift. A default value of 7 seconds SHOULD be used. This value drift. A default value of 7 seconds SHOULD be used. This value
SHOULD be greater than 3 seconds. SHOULD be greater than 3 seconds.
This MUST be the last option in a message with mobility header if it The MN-HA mobility message authentication option MUST be the last
is the only authentication option in the message. option in a message with a mobility header if it is the only mobility
message authentication option in the message.
The authentication data is calculated on the message starting from The authentication data is calculated on the message starting from
the mobility header upto and including the mobility SPI value of this the mobility header up to and including the mobility SPI value of
option. this option.
Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility
Data)) Data))
Mobility Data = care-of address | home address | Mobility Header(MH) Mobility Data = care-of address | home address | Mobility Header(MH)
Data Data
MH Data is the content of the Mobility Header upto and including the MH Data is the content of the Mobility Header upto and including the
mobility SPI field of this option. The Checksum field in Mobility mobility SPI field of this option. The Checksum field in the
Header MUST be set to 0 to calculate the Mobility Data. Mobility Header MUST be set to 0 to calculate the Mobility Data.
The first 96 bits from the MAC result are used as the Authentication The first 96 bits from the Message Authentication Code (MAC) result
Data field. are used as the Authentication Data field.
5.1.1. Processing Considerations 5.1.1. Processing Considerations
The assumption is that Mobile Node has a shared-key based security The assumption is that the Mobile Node has a shared-key-based
association with the Home Agent. The Mobile Node MUST include this security association with the Home Agent. The Mobile Node MUST
option in a BU if it has a shared-key based mobility security include this option in a BU if it has a shared-key-based mobility
association with the Home Agent. The Home Agent MUST include this security association with the Home Agent. The Home Agent MUST
option in the BA if it received this option in the corresponding BU include this option in the BA if it received this option in the
and Home Agent has a shared-key based mobility security association corresponding BU and Home Agent has a shared-key-based mobility
with the Mobile Node. security association with the Mobile Node.
The Mobile Node or Home Agent receiving this option MUST verify the The Mobile Node or Home Agent receiving this option MUST verify the
authentication data in the option. If authentication fails, the Home authentication data in the option. If authentication fails, the Home
Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home
Agent does not have shared-key based mobility SA, Home Agent MUST Agent does not have shared-key-based mobility SA, Home Agent MUST
discard the BU. The Home Agent MAY log such events. discard the BU. The Home Agent MAY log such events.
5.2. MN-AAA authentication mobility option 5.2. MN-AAA Mobility Message Authentication Option
The format of the MN-AAA authentication mobility option is as defined The format of the MN-AAA mobility message authentication option is as
in Figure 2. This option uses the subtype value of 2. The MN-AAA defined in Figure 2. This option uses the subtype value of 2. The
authentication mobility option is used to authenticate the Binding MN-AAA authentication mobility option is used to authenticate the
Update message based on the shared mobility security association Binding Update message based on the shared mobility security
between Mobile Node and AAA server in Home network (AAAH). It is not association between the Mobile Node and AAA server in Home network
used in Binding Acknowledgement messages. The corresponding Binding (AAAH). It is not used in Binding Acknowledgement messages. The
Acknowledgement messages must be authenticated using the MN-HA corresponding Binding Acknowledgement messages must be authenticated
authentication option Section 5.1. using the MN-HA mobility message authentication option (Section 5.1).
This must be the last option in a message with mobility header. The The MN-AAA mobility message authentication option must be the last
corresponding response MUST include the Mobile-Home Authentication option in a message with a mobility header. The corresponding
option, and MUST NOT include the Mobile-AAA Authentication option. response MUST include the MN-HA mobility message authentication
option, and MUST NOT include the MN-AAA mobility message
authentication option.
The Mobile Node MAY use Mobile Node Identifier option [MN_Ident] to The Mobile Node MAY use the Mobile Node Identifier option [RFC4283]
enable the Home Agent to make use of available AAA infrastructure. to enable the Home Agent to make use of available AAA infrastructure.
The authentication data is calculated on the message starting from The authentication data is calculated on the message starting from
the mobility header upto and including the mobility SPI value of this the mobility header up to and including the mobility SPI value of
option. this option.
The authentication data shall be calculated as follows: The authentication data shall be calculated as follows:
Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)
hash_fn() is decided by the value of mobility SPI field in the hash_fn() is decided by the value of mobility SPI field in the MN-AAA
authentication option. mobility message authentication option.
SPI = HMAC_SHA1_SPI: SPI = HMAC_SHA1_SPI:
If mobility SPI has the well-known value HMAC_SHA1_SPI, then If mobility SPI has the well-known value HMAC_SHA1_SPI, then
hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is
authenticated by AAA using HMAC_SHA1 authentication. In that case, authenticated by AAA using HMAC_SHA1 authentication. In that case,
MAC_Mobility Data is calculated as follows: MAC_Mobility Data is calculated as follows:
MAC_Mobility Data = SHA1(care-of address | home address | MH Data) MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MH Data is the content of the Mobility Header upto and including the MH Data is the content of the Mobility Header upto and including the
mobility SPI field of this option. mobility SPI field of this option.
5.2.1. Processing Considerations 5.2.1. Processing Considerations
The use of the MN-AAA authentication option assumes that AAA entities The use of the MN-AAA mobility message authentication option assumes
at the home site communicate with the HA via an authenticated that AAA entities at the home site communicate with the HA via an
channel. Specifically, a BU with the MN-AAA authentication option is authenticated channel. Specifically, a BU with the MN-AAA mobility
authenticated via a home AAA server. The specific details of the message authentication option is authenticated via a home AAA server.
interaction between the HA and the AAA server is beyond the scope of The specific details of the interaction between the HA and the AAA
this document. server is beyond the scope of this document.
When the Home Agent receives a Binding Update with the Mobile-AAA When the Home Agent receives a Binding Update with the MN-AAA
authentication option, the Binding Update is authenticated by an mobility message authentication option, the Binding Update is
entity external to the Home Agent, typically a AAA server. authenticated by an entity external to the Home Agent, typically a
AAA server.
5.3. Authentication Failure Detection at the Mobile Node 5.3. Authentication Failure Detection at the Mobile Node
In case of authentication failure, the Home Agent MUST send a Binding In case of authentication failure, the Home Agent MUST send a Binding
Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node,
if a shared-key based mobility security association to be used if a shared-key-based mobility security association to be used
between Mobile Node and Home Agent for authentication exists. If between Mobile Node and Home Agent for authentication exists. If
there is no shared-key based mobility security association, HA drops there is no shared-key-based mobility security association, HA drops
the Binding Update. HA may log the message for administrative the Binding Update. HA may log the message for administrative
action. action.
Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH- Upon receiving a Binding Acknowledgement with status code MIPV6-
FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding Updates to
Home Agent. the Home Agent.
6. Mobility message replay protection option 6. Mobility Message Replay Protection Option
The Mobility message replay protection option MAY be used in Binding The Mobility message replay protection option MAY be used in Binding
Update/Binding Acknowledgement messages when authenticated using the Update/Binding Acknowledgement messages when authenticated using the
mobility message authentication option as described in Section 5. mobility message authentication option as described in Section 5.
The mobility message replay protection option is used to let the Home The mobility message replay protection option is used to let the Home
Agent verify that a Binding Update has been freshly generated by the Agent verify that a Binding Update has been freshly generated by the
Mobile Node and not replayed by an attacker from some previous Mobile Node and not replayed by an attacker from some previous
Binding Update. This is especially useful for cases where the Home Binding Update. This is especially useful for cases where the Home
Agent does not maintain stateful information about the Mobile Node Agent does not maintain stateful information about the Mobile Node
after the binding entry has been removed. The Home Agent does the after the binding entry has been removed. The Home Agent does the
replay protection check after the Binding Update has been replay protection check after the Binding Update has been
authenticated. The mobility message replay protection option when authenticated. The mobility message replay protection option when
included is used by the Mobile Node for matching BA with BU. 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 If this mode of replay protection is used, it needs to be part of the
shared-key based mobility security association. shared-key-based mobility security association.
If the policy at Home Agent mandates replay protection using this If the policy at Home Agent mandates replay protection using this
option (as opposed to the sequence number in Mobility Header in option (as opposed to the sequence number in the Mobility Header in
Binding Update) and the Binding Update from Mobile Node does not Binding Update) and the Binding Update from the Mobile Node does not
include this option, Home Agent discards the BU and sets the Status include this option, the Home Agent discards the BU and sets the
Code in BA to MIPV6-MESG-ID-REQD. Status Code in BA to MIPV6-MESG-ID-REQD.
When the Home Agent receives the mobility message replay protection When the Home Agent receives the mobility message replay protection
option in Binding Update, it MUST include the mobility message replay option in Binding Update, it MUST include the mobility message replay
protection option in Binding Acknowledgement. Appendix A provides protection option in Binding Acknowledgement. Appendix A provides
details regarding why the mobility message replay protection option details regarding why the mobility message replay protection option
MAY be used when using the authentication option. MAY be used when using the authentication option.
0 1 2 3 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 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 | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp ... | | Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Figure 3: Mobility Message Replay Protection Option
Option Type: Option Type:
MESG-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier MESG-ID-OPTION-TYPE value 10 has been defined by IANA. An
of the type mobility option. 8-bit identifier of the type mobility option.
Option Length: Option Length:
8-bit unsigned integer, representing the length in octets of 8-bit unsigned integer, representing the length in octets of
the Timestamp field. the Timestamp field.
Timestamp: Timestamp:
This field carries the 64 bit timestamp. This field carries the 64 bit timestamp.
Alignment requirements : Alignment requirements :
The alignment requirement for this option is 8n + 2. The alignment requirement for this option is 8n + 2.
The basic principle of timestamp replay protection is that the node The basic principle of timestamp replay protection is that the node
generating a message inserts the current time of day, and the node generating a message inserts the current time of day, and the node
receiving the message checks that this timestamp is sufficiently receiving the message checks that this timestamp is sufficiently
close to its own time of day. Unless specified differently in the close to its own time of day. Unless specified differently in the
shared-key based mobility security association between the nodes, a shared-key-based mobility security association between the nodes, a
default value of 7 seconds MAY be used to limit the time difference. 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 This value SHOULD be greater than 3 seconds. The two nodes must have
adequately synchronized time-of-day clocks. adequately synchronized time-of-day clocks.
The Mobile Node MUST set the Timestamp field to a 64-bit value The Mobile Node MUST set the Timestamp field to a 64-bit value
formatted as specified by the Network Time Protocol [RFC1305]. The formatted as specified by the Network Time Protocol (NTP) [RFC1305].
low-order 32 bits of the NTP format represent fractional seconds, and The low-order 32 bits of the NTP format represent fractional seconds,
those bits which are not available from a time source SHOULD be and those bits that are not available from a time source SHOULD be
generated from a good source of randomness. Note, however, that when generated from a good source of randomness. Note, however, that when
using timestamps, the 64-bit Timestamp used in a Binding Update from using timestamps, the 64-bit timestamp used in a Binding Update from
the Mobile Node MUST be greater than that used in any previous the Mobile Node MUST be greater than that used in any previous
successful Binding Update. successful Binding Update.
After successful authentication of Binding Update (either locally at After successful authentication of Binding Update (either locally at
the Home Agent or when a success indication is received from the AAA the Home Agent or when a success indication is received from the AAA
server), the Home Agent MUST check the Timestamp field for validity. server), the Home Agent MUST check the Timestamp field for validity.
In order to be valid, the timestamp contained in the Timestamp field 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 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 timestamp MUST be greater than all previously accepted timestamps for
the requesting Mobile Node. the requesting Mobile Node.
If the timestamp is valid, the Home Agent copies the entire Timestamp 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 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 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 low-order 32 bits into the BA, and supplies the high-order 32 bits
from its own time of day. from its own time of day.
If the timestamp field is not valid but the authentication of the BU If the Timestamp field is not valid but the authentication of the BU
succeeds, Home Agent MUST send a Binding Acknowledgement with status succeeds, the Home Agent MUST send a Binding Acknowledgement with
code MIPV6-ID-MISMATCH. The Home Agent does not create a binding status code MIPV6-ID-MISMATCH. The Home Agent does not create a
cache entry if the timestamp check fails. binding cache entry if the timestamp check fails.
If the Mobile Node receives a Binding Acknowledgement with the code If the Mobile Node receives a Binding Acknowledgement with the code
MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by
processing the MN-HA authentication mobility option. processing the MN-HA authentication mobility option.
If authentication succeeds, the Mobile Node MUST adjust its timestamp If authentication succeeds, the Mobile Node MUST adjust its timestamp
and send subsequent Binding Update using the updated value. and send subsequent Binding Update using the updated value.
Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH
status code, the Mobile Node MUST compare the Timestamp value in the 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 BA to the Timestamp value it sent in the corresponding BU. If the
values match, the Mobile Node proceeds to process the MN-HA values match, the Mobile Node proceeds to process the MN-HA
authentication data in the BA. If the values do not match, the authentication data in the BA. If the values do not match, the
Mobile Node silently discards the BA. Mobile Node silently discards the BA.
7. Security Considerations 7. Security Considerations
This document proposes new authentication options to authenticate the This document proposes new mobility message authentication options to
control message between Mobile Node, Home Agent and/or home AAA (as authenticate the control message between Mobile Node, Home Agent,
an alternative to IPsec). The new options provide for authentication and/or home AAA (as an alternative to IPsec). The new options
of Binding Update and Binding Acknowledgement messages. The MN-AAA provide for authentication of Binding Update and Binding
authentication options provides for authentication with AAA Acknowledgement messages. The MN-AAA mobility message authentication
infrastructure. option provide for authentication with AAA infrastructure.
This specification also introduces an optional replay protection This specification also introduces an optional replay protection
mechanism in Section 6, to prevent replay attacks. The sequence mechanism in Section 6, to prevent replay attacks. The sequence
number field in the Binding Update is not used if this mechanism is 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 used. This memo defines the timestamp option to be used for mobility
message replay protection. message replay protection.
8. IANA Considerations 8. IANA Considerations
IANA services are required for this specification. The values for IANA services are required for this specification. The values for
new mobility options and status codes must be assigned from the new mobility options and status codes must be assigned from the
Mobile IPv6 [RFC3775] numbering space. Mobile IPv6 [RFC3775] numbering space.
The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID- The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID-
OPTION-TYPE, as defined in Section 5 and Section 6 need to be OPTION-TYPE, as defined in Section 5 and Section 6, have been
assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9 assigned. The values are 9 for the AUTH-OPTION-TYPE and 10 for the
for the MESG-ID-OPTION-TYPE Mobility Option. 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, Section 6 and Section 5.3
also need to be assigned. The suggested values are 144 for MIPV6-ID-
MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
IANA should record values for these new Mobility Options and the new The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL, and
Status Codes. 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 A new section for enumerating algorithms identified by specific
mobility SPIs within the range 0-255 is to be added to mobility SPIs within the range 0-255 has to be added to
http://www.isi.edu/in-notes/iana/assignments/mobility-parameters http://www.iana.org/assignments/mobility-parameters
The currently defined values are as follows: The currently defined values are as follows:
The value 0 should not be assigned. The value 0 should not be assigned.
The value 3 is suggested for HMAC_SHA1_SPI as defined in Section 5.2. The value 3 is reserved for HMAC_SHA1_SPI as defined in Section 5.2.
The value 5 is reserved for use by 3GPP2. The value 5 is reserved for use by 3GPP2.
New values for this namespace can be allocated using IETF Consensus. New values for this namespace can be allocated using IETF Consensus.
[RFC2434]. [RFC2434].
In addition, IANA needs to create a new namespace for the subtype In addition, IANA has created a new namespace for the Subtype field
field of the MN-HA and MN-AAA authentication mobility options under of the MN-HA and MN-AAA mobility message authentication options under
http://www.isi.edu/in-notes/iana/assignments/mobility-parameters http://www.iana.org/assignments/mobility-parameters
The currently allocated values are as follows: The currently allocated values are as follows:
1 MN-HA authentication mobility option Section 5.1 1 MN-HA mobility message authentication option Section 5.1
2 MN-AAA authentication mobility option Section 5.2 2 MN-AAA mobility message authentication option Section 5.2
New values for this namespace can be allocated using IETF Consensus. New values for this namespace can be allocated using IETF Consensus.
[RFC2434]. [RFC2434].
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Basavaraj Patil, Charlie Perkins The authors would like to thank Basavaraj Patil, Charlie Perkins,
Vijay Devarapalli, Jari Arkko and Gopal Dommety for their thorough Vijay Devarapalli, Jari Arkko, and Gopal Dommety, and Avi Lior for
review and suggestions on the document. The authors would like to their thorough review and suggestions on the document. The authors
acknowledge the fact that a similar authentication method was would like to acknowledge the fact that a similar authentication
considered in base protocol [RFC3775] at one time. method was considered in base protocol [RFC3775] at one time.
10. References 10. References
10.1. Normative References 10.1. Normative References
[MN_Ident] [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Patel et. al., A., "Mobile Node Identifier Option for Chowdhury, "Mobile Node Identifier Option for Mobile
Mobile IPv6", draft-ietf-mip6-mn-ident-option-03.txt (work IPv6", RFC 4283, November 2005.
in progress), December 2004.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
10.2. Informative References 10.2. Informative References
[3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D, [3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D,
September 2005. September 2005.
[IKEv2-REF] [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Kaufman, et. al, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
Protocol", draft-ietf-ipsec-ikev2-17.txt (work in
progress).
[whyauth] Patil et. al., B., "Why Authentication Data suboption is
needed for MIP6",
draft-patil-mip6-whyauthdataoption-01.txt (work in
progress), September 2005.
Appendix A. Rationale for mobility message replay protection option Appendix A. Rationale for Mobility Message Replay Protection Option
Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility
header to prevent replay attacks. There are two aspects that stand header to prevent replay attacks. There are two aspects that stand
out in regards to using the Sequence Number to prevent replay out in regards to using the Sequence Number to prevent replay
attacks. attacks.
Firstly, the specification states that Home Agent should accept a BU First, the specification states that the Home Agent should accept a
with a Sequence Number greater than the Sequence Number from previous BU with a Sequence Number greater than the Sequence Number from the
Binding Update. This implicitly assumes that the Home Agent has some previous Binding Update. This implicitly assumes that the Home Agent
information regarding the Sequence Number from previous BU (even when has some information regarding the Sequence Number from the previous
the binding cache entry is not present). Secondly, the specification BU (even when the binding cache entry is not present). Second, the
states that if the Home Agent has no binding cache entry for the specification states that if the Home Agent has no binding cache
indicated home address, it MUST accept any Sequence Number value in a entry for the indicated home address, it MUST accept any Sequence
received Binding Update from this Mobile Node. Number value in a received Binding Update from this Mobile Node.
With the mechanism defined in this draft, it is possible for the With the mechanism defined in this document, it is possible for the
Mobile Node to register with a different Home Agent during each Mobile Node to register with a different Home Agent during each
mobility session. Thus, it is unreasonable to expect each Home Agent mobility session. Thus, it is unreasonable to expect each Home Agent
in the network to maintain state about the Mobile Node. Also, if the in the network to maintain state about the Mobile Node. Also, if the
Home Agent does not cache information regarding sequence number, as Home Agent does not cache information regarding sequence number, as
per the second point above, a replayed BU can cause a Home Agent to 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 create a binding cache entry for the Mobile Node. Thus, when
authentication option is used, Sequence Number does not provide authentication option is used, Sequence Number does not provide
protection against replay attack. protection against replay attack.
One solution to this problem (when Home Agent does not save state 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 information for every Mobile Node) would be for the Home Agent to
reject the first BU and assign a (randomly generated) starting reject the first BU and assign a (randomly generated) starting
sequence number for the session and force the Mobile Node to send a sequence number for the session and force the Mobile Node to send a
fresh BU with the suggested sequence number. While this would work fresh BU with the suggested sequence number. While this would work
in most cases, it would require an additional round trip and this in most cases, it would require an additional round trip, and this
extra signalling and latency is not acceptable in certain deployments extra signaling and latency is not acceptable in certain deployments
[3GPP2]. Also, this rejection and using sequence number as a nonce [3GPP2]. Also, this rejection and using sequence number as a nonce
in rejection is a new behavior that is not specified in [RFC3775]. in rejection is a new behavior that is not specified in [RFC3775].
Thus, this specification uses the mobility message replay protection Thus, this specification uses the mobility message replay protection
option to prevent replay attacks. Specifically, timestamps are used option to prevent replay attacks. Specifically, timestamps are used
to prevent replay attacks as described in Section 6. to prevent replay attacks as described in Section 6.
It is important to note that as per Mobile IPv6 [RFC3775] this It is important to note that as per Mobile IPv6 [RFC3775] this
problem with sequence number exists. Since the base specification problem with sequence number exists. Since the base specification
mandates the use of IPsec (and naturally that goes with IKE in most 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 cases), the real replay protection is provided by IPsec/IKE. In case
of BU/BA between Mobile Node and CN, the liveness proof is provided of BU/BA between Mobile Node and Client Node (CN), the liveness proof
by the use of nonces which the CN generates. is provided by the use of nonces that the CN generates.
Authors' Addresses Authors' Addresses
Alpesh Patel Alpesh Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408-853-9580 Phone: +1 408-853-9580
Email: alpesh@cisco.com EMail: alpesh@cisco.com
Kent Leung Kent Leung
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408-526-5030 Phone: +1 408-526-5030
Email: kleung@cisco.com EMail: kleung@cisco.com
Mohamed Khalil Mohamed Khalil
Nortel Networks Nortel Networks
2221 Lakeside Blvd. 2221 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
US US
Phone: +1 972-685-0574 Phone: +1 972-685-0574
Email: mkhalil@nortel.com EMail: mkhalil@nortel.com
Haseeb Akhtar Haseeb Akhtar
Nortel Networks Nortel Networks
2221 Lakeside Blvd. 2221 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
US US
Phone: +1 972-684-4732 Phone: +1 972-684-4732
Email: haseebak@nortel.com EMail: haseebak@nortel.com
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Starent Networks
30 International Place 30 International Place
Tewksbury, MA 01876 Tewksbury, MA 01876
US US
Phone: +1 214 550 1416 Phone: +1 214 550 1416
Email: kchowdury@starentnetworks.com EMail: kchowdhury@starentnetworks.com
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 23, line 29 skipping to change at page 19, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 106 change blocks. 
305 lines changed or deleted 316 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/