One document matched: draft-soliman-mobileip-routeopt-mipv6-00.txt

Mobile IP Working Group                         Hesham Soliman, Ericsson
INTERNET-DRAFT                                   Karim ElMalki, Ericsson
Expires: Feruary 2001                      Tomas Goldbeck-Lowe, Ericsson
                                                            August, 2000





              Security Association establishment for route
                         optimisation in MIPv6
             <draft-soliman-mobileip-routeopt-mipv6-00.txt>


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is an individual submission to the IETF. Comments
   should be directed to the authors.


Abstract

   This draft introduces a simple mechanism that allows an MN to
   establish a security association with a CN to enable it to send
   Binding Updates in a secure manner as required by MIPv6. The proposed
   mechanism is only inteneded for securing network signalling data (eg.
   BUs from MN) but not necessarily payload information.








Soliman, El-Malki, Goldbeck-Lowe                                [Page 1]

INTERNET-DRAFT        SA establishment using AAAv6          August, 2000


TABLE OF CONTENTS

   1.  Introduction..................................................3

   2.  Establishing SAs..............................................3

   3.  Acknowledgements..............................................6

   4.  References....................................................6

   5.  Intellectual Property Statement...............................6

   6.  Author's Address..............................................6








































Soliman, El-Malki, Goldbeck-Lowe                                [Page 2]

INTERNET-DRAFT        SA establishment using AAAv6          August, 2000





1. Introduction

   MIPv6 provides a powerful and flexible way of optimising a route
   between a MN and a CN based on an end-to-end approach. Route
   optimisation is required to reduce the delays in packet arrivals
   between a CN and a MN. Such delays may be significant, depending on
   the number of hops between a MN and its HA and the level of
   congestion in such path. Route optimisation is achieved when an MN
   sends a Binding Update (BU) to a CN. According to [MIPv6], BUs MUST
   be secured by at least an Authentication Header [AH]. Security
   association establishment between a MN and a CN requires that the MN
   has some security credentials (key) that can be trusted by the CN and
   a mechanism to exchange such keys. One possible key exchange
   mechanism is explained in [IKE].

   The aim of this draft is to introduce a simple mechanism based on the
   AAA infrastructure that allows key generation and distribution for
   securing BUs between a MN and a CN. The proposed mechanism relies on
   the existing trust models within a AAA infrastructure, hence
   resulting in less messages required to exchange keys between an MN
   and a CN. This will reduce connection setup latencies as well as the
   overhead (ie. number of messages) required for security association
   establishment. Such enhancements are especially relevant to real time
   services and wireless networks where radio links have strict
   requirements on  Bandwidth efficiency. Furthermore, since the
   proposed mechanism assumes an existing level of trust within the AAA
   infrastructure, the required protocol would be relatively simple to
   implement.

   It should be noted that the proposed mechanism is not intended to
   replace current key exchange mechanisms (eg. IKE). When using the
   proposed mechanism in this draft, the local AAA servers for both the
   CN and the MN will be aware of the keys exchanged between the MN and
   the CN. Hence this method may not necessarily be secure enough for
   certain applications. However, the proposed mechanism may be
   sufficient for securing BUs between a MN and a CN.

2. Establishing Security Associations

2.1  Initial assumptions and limitations

   Since no AAA protocol has been decided upon yet to authenticate an
   IPv6 user to the network, some assumptions are made about the
   services that will be provided by the AAAv6 protocol. These
   assumptions may be used by developers as requirements on AAAv6.





Soliman, El-Malki, Goldbeck-Lowe                                [Page 3]

INTERNET-DRAFT        SA establishment using AAAv6          August, 2000


   It is assumed in this memo that AAAv6 will allow the generation of an
   MN-AAAL security association of limited lifetime. This key may be
   used by the MN to communicate with AAAL in a secure mannner. It
   should be noted that AAAL in this context may mean AAAH if the MN
   happened to be at its home domain.

   In this memo, the communication between the MN and AAAL is not
   assumed to use the same protocol as the AAA-AAA servers communication
   protocol. This allows for some flexibility for the MN-AAA protocol
   choice.

   It is implicitly assumed in this memo that AAAH for a MN will cache
   the MN's location information (ie. it's AAAL) when authenticating the
   MN to a foreign domain. AAAL information is assumed to be transferred
   to AAAH while transferring the MN's security credentials to be
   authenticated by its AAAH.

   Since no method currently exists to allow route optimisation between
   IPv6 and IPv4 hosts. IPv6 MNs will not be able to use this method
   when communicating with IPv4 hosts.

2.2 Operational overview

   The model proposed for establishing a Security Association is
   illustrated below in Fig. 1. The communication between the MN and the
   CN is divided into two separate protocols: the IPv6 host-AAA server
   protocol and the AAA-AAA server protocol. Messages received from IPv6
   hosts by the AAA server are translated and forwarded to the other
   host's AAA server. It should be noted that the model shown below need
   not be limited to security associations between IPv6 hosts. The same
   model can be used to establish security associations between IPv6
   hosts and IPv6 routers, provided routers have pre-established
   security associations with their local domain's AAA servers.

                                     2
           +---------+  --------------------> +--------------+
           |AAAH/L MN| <----------------------|AAAH/L CN     |
           +---------+         3              +--------------+
             |   /\                              |  /\  |   /\
             |   |                               |  |   |   |
             |   |                            2a |  |   |   |
             |   | 1                             |  | 2b| 3 | 4
             |   |                               |  |   |   |
             |   |                               |  |   |   |
             \/  |                               \/ |   \/  |
           +------+                              +-----------+
           |  MN  |                              |  CN       |
           +------+                              +-----------+

   A MN may request another entity, with which it has a pre-established



Soliman, El-Malki, Goldbeck-Lowe                                [Page 4]

INTERNET-DRAFT        SA establishment using AAAv6          August, 2000


   trust (eg. AAAL), to set up a security association between the MN and
   another CN for securing BU messages. The request can be sent to the
   AAAL which in turn relays it to AAAH for the MN. Alternatively the MN
   can send the request directly to AAAH-MN. The first alternative (MN-
   AAAL) is preferred as it would limit the use of the permanent MN-AAAH
   security keys, providing a more secure method of communication. This
   is due to minimising the use of the pre-established MN-AAAH security
   association.

   The information passed from the MN to the AAAL server (message 1
   above) should contain the following:

   - Message authentication based on MN-AAAL Security Association.
   - MN's Home Address.
   - IPv6 address or NAI for the CN.
   - Security algorithms supported by the MN.
   - Lifetime requested for the generated association.

   The request is forwarded from AAAL to AAAH (in case the MN is in a
   foreign domain). The request MUST be secured by using the AAAL-AAAH
   security association.

   Upon reception of the request from the MN, AAAH needs to locate the
   AAAH-CN. The request is then translated to the appropriate server-
   server AAA protocol and forwarded to the AAAH-CN. This is shown as
   step 2 in the figure above.

   Upon reception of the request by the AAAH-CN, a decision is made as
   to whether a key is generated immediately or after consulting the CN.
   The decision is based on the AAA server's knowledge of the CN. For
   example, a CN may have a certain profile in the AAA server that
   allows it to make such decision based on the CN's security
   preferences. Otherwise the CN is consulted first as shown in Fig. 1
   by sending message 2a. The message contains all the information given
   by the MN. The contents of the message should be validated by the CN
   and result in sending a reply message 2b.

   If the CN agrees to set up a security association it should include a
   supported algorithm and a lifetime value for the security
   association. Otherwise a rejection is sent with the appropriate error
   code. It should be noted that the key generated may not have the same
   lifetime value as the one requested by the MN.

   Upon reception of an acceptance from the CN, the AAAH-CN should
   generate the key and send it to the CN (message 3) and the AAAH-MN.
   The CN should reply to the AAAH-CN with an acknowledgement.

   It should be noted that the communication between AAAH-CN and the CN
   is done via AAAL while the CN is outside the AAAH-CN domain. This is
   to eliminate the use of the CN-AAAH pre-established security



Soliman, El-Malki, Goldbeck-Lowe                                [Page 5]

INTERNET-DRAFT        SA establishment using AAAv6          August, 2000


   association. AAAH-CN should have knowledge of the CN's current AAAL.
   This knowledge can be stored while authenticating the CN to the
   foreign domain.

   Finally, the reply is relayed by the AAAH-MN to the MN via AAAL.

   In the case where the MN is located in the AAAH-MN domain, the MN
   should send the request directly to AAAH-MN. The MN should use its
   MN-AAAH session key for communicating with AAAH.

3. Acknowledgements

   The basic concepts behind this draft were discussed between the
   authors, Annika Jonsson and Martin Korling. We would like to thank
   them for their input.

4. References

   [MIPv6]  D. Johnson and C. Perkins, "Mobility Support in IPv6",
            draft-ietf-mobileip-ipv6-12.txt, February 2000.

   [IKE]    D. Harkell and D. Carrel, _The Internet Key Exchange_,
            RFC 2409.

   [AH]     S. Kent and R. Atkinson, _IP Authentication Header_,
            RFC 2402.

5. Intellectual Property statement

   see http://www.ietf.org/ietf/IPR/ERICSSON-General


6.Authors' addresses

   Hesham Soliman
   Ericsson Australia
   61 Rigall St., Broadmeadows
   Melbourne, Victoria 3047
   AUSTRALIA

   Phone:  +61 3 93012049
   Fax:    +61 3 93014280
   E-mail: Hesham.Soliman@ericsson.com.au


   Karim El Malki
   Ericsson Radio Systems AB
   Access Networks Research
   SE-164 80 Stockholm
   SWEDEN



Soliman, El-Malki, Goldbeck-Lowe                                [Page 6]

INTERNET-DRAFT        SA establishment using AAAv6          August, 2000



   Phone:  +46 8 7573561
   Fax:    +46 8 7575720
   E-mail: Karim.El-Malki@era.ericsson.se

   Tomas Goldbeck-Lowe
   Ericsson Radio Systems AB
   Networks and Systems Research
   SE-164 80 Stockholm
   SWEDEN

   Phone:  +46 8 764 1467
   Fax:    +46 8 404 7020
   E-mail: Tomas.Goldbeck-Lowe@era.ericsson.se







































Soliman, El-Malki, Goldbeck-Lowe                                [Page 7]