Authorizing Mobile IPv6 Binding Update with Cryptographically Generated Addresses
draft-laganier-mext-cga-00

Abstract

The standard RFC 3775 mechanism to secure Mobile IPv6 Binding Updates sent by a Mobile Node to its Home Agent relies on the use of a pair of unidirectional IPsec security associations between these two nodes. The standard mechanism to secure Mobile IPv6 Binding Updates sent by a Mobile Node to one of its Correspondent Nodes relies on the use of a return routability test that involves the Correspondent Node verifying reachability of the Mobile Node at both its Home Address and its Care-of Address. The mechanism also requires the correspondent node to send keying material to both of these addresses.

RFC 4866 specifies a standard track mecanism that allows a Mobile Node that has configured a Cryptographically Generated Address (RFC 3972) as its Home Address to secure Mobile IPv6 Binding Updates sent its Correspondent Nodes based on the properties of its Cryptographically Generated Addresses. Note that Cryptographically Generated Addresses have also been used to counter similar security issues in the context of SHIM6 (RFC 5533) and Secure Neighbor Discovery (RFC 3971.)

This memo proposes a mechanism that would let a Mobile Node use a similar mechanism to secure Mobile IPv6 Binding Updates its sent to its Home Agent with a similar technique based on the use of Cryptographically Generated Addresses.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on April 19, 2011.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 Simplified BSD License.

Table of Contents

1.  Introduction
2.  Disclaimer
3.  Requirement Levels Key Words
4.  Terminology
5.  Usage Scenario
6.  Mobile Node Operation
7.  Home Agent Operation
8.  IANA Considerations
9.  Security Considerations
10.  Acknowledgment
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Author's Address

1.  Introduction

The standard RFC 3775 (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) [RFC3775] mechanism to secure Mobile IPv6 Binding Updates sent by a Mobile Node to its Home Agent relies on the use of a pair of unidirectional IPsec security associations between these two nodes [RFC4877] (Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture,” April 2007.). The standard mechanism to secure Mobile IPv6 Binding Updates sent by a Mobile Node to one of its Correspondent Nodes relies on the use of a return routability test that involves the Correspondent Node verifying reachability of the Mobile Node at both its Home Address and its Care-of Address. The mechanism also requires the correspondent node to send keying material to both of these addresses.

RFC 4866 (Arkko, J., Vogt, C., and W. Haddad, “Enhanced Route Optimization for Mobile IPv6,” May 2007.) [RFC4866] specifies a standard track mecanism that allows a Mobile Node that has configured a Cryptographically Generated Address [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) as its Home Address to secure Mobile IPv6 Binding Updates sent its Correspondent Nodes based on the properties of its Cryptographically Generated Addresses. Note that Cryptographically Generated Addresses have also been used to counter similar security issues in the context of SHIM6 [RFC5533] (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” June 2009.) and Secure Neighbor Discovery [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.).

This memo proposes a mechanism that would let a Mobile Node use a similar mechanism to secure Mobile IPv6 Binding Updates its sent to its Home Agent with a similar technique based on the use of Cryptographically Generated Addresses.

2.  Disclaimer

This is Internet Draft is Work in Progress.

3.  Requirement Levels Key Words

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

4.  Terminology

Other terms used throughout this document are defined in the relevant documents: [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), [RFC4866] (Arkko, J., Vogt, C., and W. Haddad, “Enhanced Route Optimization for Mobile IPv6,” May 2007.), [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.).

5.  Usage Scenario

The mechanism described herein is useful in situations where there is a desire not to depend on IPsec for protection of the Mobile IPv6 signaling between the Mobile Node and the Home Agent.

6.  Mobile Node Operation

A Mobile Node creates and updates a Binding with its Home Agent by sending a Binding Update to its Home Agent. The Binding Update MUST include:

• a monotically increasing Sequence Number as per [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
• a CGA Parameters option for the Cryptographically Generated Home Address of the Mobile Node as per [RFC4866] (Arkko, J., Vogt, C., and W. Haddad, “Enhanced Route Optimization for Mobile IPv6,” May 2007.).
• a Timestamp option as per [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.).
• an Alternate Care-of Address option as per [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
• a Signature option as per [RFC4866] (Arkko, J., Vogt, C., and W. Haddad, “Enhanced Route Optimization for Mobile IPv6,” May 2007.).

7.  Home Agent Operation

A Home Agent MUST accept a Binding Update from a Mobile Node and maintain accordingly the corresponding Binding Cache Entry if the Binding Update includes all of the following:

• a valid Sequence Number [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.). That is, if there is no existing Binding Cache Entry and the Timestamp is valid, the Sequence Number is accepted and recorded in the Binding Cache Entry. If there exists a Binding Cache Entry, the Sequence Number MUST be greater than the value recorded in the Binding Cache Entry.
• a CGA Parameters option for the Cryptographically Generated Home Address of the Mobile Node as per [RFC4866] (Arkko, J., Vogt, C., and W. Haddad, “Enhanced Route Optimization for Mobile IPv6,” May 2007.).
• a valid Timestamp option [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.). That is, if there is no existing Binding Cache Entry, the time offset between the Timestamp and local Home Agent clock is recorded in the Binding Cache Entry. If there exists a Binding Cache Entry, the Timestamp MUST not differ from the local Home Agent clock for more than 1.5 times the time offset recorded in the Binding Cache Entry.
• an Alternate Care-of Address option as per [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
• a valid Signature option as per [RFC4866] (Arkko, J., Vogt, C., and W. Haddad, “Enhanced Route Optimization for Mobile IPv6,” May 2007.).

8.  IANA Considerations

There are no IANA considerations yet for this specification.

9.  Security Considerations

There are no security considerations yet for this document.

10.  Acknowledgment

The author acknowledge prior work in the area of Mobile IPv6 security based on Cryptographically Generated Addresses, Statistically Unique and Crypgraphically Verifiable Identifiers, and more.

11.  References

11.1. Normative References

11.2. Informative References

Author's Address