[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                         Francis Dupont
INTERNET DRAFT                                           ENST Bretagne
Expires in August 2001                               February 22. 2001

                Mobility-aware IPsec ESP tunnels

                 <draft-dupont-movesptun-00.txt>

Status of this Memo

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

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

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

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

   Distribution of this memo is unlimited.

Abstract

   A common usage of IPsec is bidirectional ESP tunnels (secure
   Virtual Private Networks): the original packet is encapsulated in
   a new IP header and protected (ESP can provide confidentiality,
   authentication, integrity and anti-replay) by IPsec ESP (in tunnel
   mode).

   This conflicts with all mobility devices [ID1, ID2] which are based
   on addresses for no good reasons when some of these mobility devices
   should be able to use the four addresses in the two headers.

   This document tries to solve this conflict in order to make secure
   and mobile supports colaborating, ie. to pay for the two features
   only once.



draft-dupont-movesptun-00.txt                                   [Page 1]


INTERNET-DRAFT       Mobility-aware IPsec ESP tunnels      February 2001


1. Introduction

   IPsec [RFC 2401] defines Encapsulation Security Payload (ESP)
   [RFC 2406] tunnel mode as an encapsulation of an original/inner
   IP packet in an outer IP packet:

   +--------------------+-------------------------------------------+
   |                    |                +------------------------+ |
   |      IP header     |  ESP header    |   original IP packet   | |
   |                    |                +------------------------+ |
   +--------------------+-------------------------------------------+


   Address based mobility protocols use two addresses for a mobile node:
     - the home address which is static but virtual
     - a care-of address which is temporary but denotes the current
       position of the mobile node.
   These protocols can use options (source routing header and home
   address destination option) for the optimized version or a tunnel
   for the unoptimized version. Both versions apply the same rules:
     - the mobile node should send packets with a care-of address as
       the outer source and the home address as the inner source.
     - a correspondent node should send packets with a care-of address
       as the outer destination and the home address as the inner
       destination.

   If an ESP tunnel is already used we want to add no option or new
   encapsulation.  If security and mobility protocols can colaborate
   we shall get mobility support without overhead. This document
   describes how this colaboration can be archieved: packets are
   transported as for ESP tunnels, IPsec and mobility signaling
   control together outer addresses.


2. IPsec issues


   IPsec specifications [RFC 2401] do not mandate any check of the
   outer source address in incoming processing but many implementations
   do this kind of check. They are (still) compliant but they cannot
   interoperate if the source address can change, ie. with an address
   based mobility device or a Network Address Translator.


draft-dupont-movesptun-00.txt                                   [Page 2]


INTERNET-DRAFT       Mobility-aware IPsec ESP tunnels      February 2001


   There is no real issue with Internet Key Exchange [RFC 2409]
   but the phase one is done with a care-of address then:
    - the lifetime of ISAKMP Security Association built by the
      phase one should be in the same order than the lifetime of
      the care-of address.
    - the care-of address should not be used in an Identity payload
      (ie. user_FQDN Identity payload is recommended for phase one).
    - in some case the care-of address of the peer is not known then
      the initiator should be the mobile node.
   In phase two the home-address should be used in the Identity payload,
   the policy should tie the phase one identity with the home-address in
   order to authorize the setup and update of proper IPsec SAs.

   The PF_KEY API [RFC 2367] defines identities and addresses (three
   kind of addresses, source, destination and proxy) for SAs.
   For a mobile node the care-of address is the source and
   the home address the proxy according to section 5.2 example.
   The current specifications need to be updated in order to
   provide a way to update the source or the destination address.

   There is not yet a PF_POLICY document but the requirements are
   exactly the same than for PF_KEY: the source or the destination
   address of the outer headers must be updatable.


3. Signaling


   Address based mobility protocols manage a care-of/home address
   pair on both ends of a mobility session. In the case covered
   by the document this pair is the outer/inner source address pair
   on the mobile node, the outer/inner destination address pair
   on the correspondent node.

   The signaling function provides a way to update the care-of address
   in this pair on correspondent nodes when the mobile node has moved,
   ie. has acquired a new care-of address.

   If the signaling is done inline, ie. signaling protocol elements
   are transported through the ESP tunnel from the mobile node to
   a correspondent, then ESP must provide authentication, integrity
   check and anti-replay protection.

   The signaling responder on correspondents MUST interoperate with
   IPsec management, for instance using standard extended APIs like
   PF_KEY as decribed before.


draft-dupont-movesptun-00.txt                                   [Page 3]


INTERNET-DRAFT       Mobility-aware IPsec ESP tunnels      February 2001


4. Extensions

   Most of this document was written with bidirectional tunnels in mind
   but it can be applied in the unidirectional case where previous
   issues are less critical but still exist.

   AH in tunnel mode is not commonly used but this document applies
   to it too. The only difference is that AH protects the whole outer
   header, including the outer source address.

5. Security Considerations

   Signaling devices have some security requirements which can be
   provided by ESP.

   The correspondent policy have to authorize both the setup of SAs
   negociated by an initiator using a (a priori random) care-of address
   and the update of the mobile node outer address in these SAs.

6. Acknowledgements

   I would like to thank Richard Draves (Microsoft Research) to point
   to that the interaction between mobile IPv6 and IPsec is near a
   complete disaster and something must be done.

7. References


   [ID1] D. Johnson, C. Perkins, "Mobility Support in IPv6",
         draft-ietf-mobileip-ipv6-13.tx, work in progress,
         November 2000.

   [ID2] F. Dupont, "IPv6 over IPv4 tunnels for home to Internet
         access", draft-ietf-ngtrans-hometun-01.txt, work in progress,
         November 2000.

   [RFC 2401] S. Kent, R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC 2406] S. Kent, R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

   [RFC 2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
              RFC 2409, November 1998.

   [RFC 2367] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management
              API, Version 2", RFC 2367, July 1998.


draft-dupont-movesptun-00.txt                                   [Page 4]

INTERNET-DRAFT       Mobility-aware IPsec ESP tunnels      February 2001


8. Author's Address

   Francis Dupont
   ENST Bretagne
   Campus de Rennes
   2 rue de la Chataigneraie
   BP 78
   35512 Cesson-Sevigne Cedex
   FRANCE
   Fax: +33 2 99 12 70 30
   EMail: Francis.Dupont@enst-bretagne.fr


Expire in 6 months (August 22, 2001)


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/