One document matched: draft-dupont-mobike-transport-00.txt

Network Working Group                                          F. Dupont
Internet-Draft                                         GET/ENST Bretagne
Expires: February 10, 2005                               August 12, 2004


              IPsec transport mode in Mobike environments
                  draft-dupont-mobike-transport-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 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.

   This Internet-Draft will expire on February 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document specifies how to use IPsec transport mode security
   associations in a Mobike environment, i.e., in an environment with
   sequential (mobility) or parallel (multi-homing) addresses.

1.  Introduction

   Mobike deals with "peer addresses" which are the addresses IKE runs
   over and which are the addresses used as outer addresses by tunnel
   mode IPsec security associations between security gateways
   [RFC2401bis].  Mobike both specifies in IKEv2 [IKEv2] a way to define
   alternate peer addresses and a way to update security associations,
   when one or both parties are mobile or multi-homed.



Dupont                 Expires February 10, 2005                [Page 1]

Internet-Draft         Transport mode and Mobike             August 2004


   But transport mode IPsec security associations are end-to-end and
   have no outer addresses: they cannot be managed by Mobike, for
   instance, they cannot be updated.  But there is an indirect way to
   take benefits from Mobike: assume that the peer addresses are the
   addresses of peers.  This document uses the standard keywords
   [keywords] to indicate requirement levels.

2.  Transport mode and addresses

   The endpoint addresses of an IPsec transport mode security
   association are usually addresses of the peers but are taken from the
   traffic selectors, not from the peer addresses.  When they are not
   the same than the peer addresses, they MUST be authorized by the
   local policy.

   When a Mobike mechanism provides peer address lists or sets as
   described in section 3.1 of the Mobike design document [MOBIKE], this
   rule can be relaxed into: by default, any peer address MAY be used as
   an endpoint address of an IPsec transport mode security association.

3.  Two examples

   The first example is the IPv6 mobility [MIPv6] where a mobile node
   uses two addresses:
      the fixed home address in the remote/home network;
      transient care-of addresses assigned in the local/visited network.
   In communications with its home agent, a mobile node uses a care-of
   address (because its home address is not usable until the home
   registration) so its peer address is a care-of address.  But to
   protect the mobility signaling [MN-HA] a transport mode IPsec
   security association pair is established using the home address.

   Using a Mobike peer address management (as in [ADDRMGT]) a mobile
   node can add its home address as an alternate peer address and be
   authorized to use it in its traffic selector for the mandatory
   transport mode IPsec security association pair.  Note the other IPsec
   security associations, in tunnel mode, are updated in case of
   handoffs by the mobility support itself, not by Mobike.

   The second example is multi-homing using SCTP [SCTP], itself or what
   we call the SCTP model of multi-homing, between two hosts.  A
   multi-homed peer can register using a Mobike mechanism its addresses
   as peer addresses and is authorized to use them to build transport
   mode IPsec security associations using only one IKE session, aka IKE
   security association.  Note this document does not address the
   question of using multiple simultaneous addresses in IPsec security
   associations in the outgoing side, even if the main implementation
   issue, the address selection, does not exist for transport mode.



Dupont                 Expires February 10, 2005                [Page 2]

Internet-Draft         Transport mode and Mobike             August 2004


4.  Acknowledgments

   The MOBIKE Working Group agreed at the 60th IETF meeting in San Diego
   to put transport mode ouside of its immediate scope.  But as
   transport mode can take indirect benefits of Mobike mechanisms, an as
   short as possible document (this one) was proposed.

   Some special transport mode IPsec security associations over IP-IP
   tunnels [VPN] were proposed for consideration by Joe Touch but in
   fact they are another example of security associations which are
   updated by an external (to IPsec) mechanism, i.e., as in the IPv6
   mobility case, Mobike mechanisms can only help to easily solve
   authorization issues.

5.  Security Considerations

   IKEv2 and Mobike mechanisms do verify that the primary peer address
   (for IKEv2) and further alternate peer address (for Mobike
   mechanisms) are correctly authenticated and authorized, so they MAY
   safely be used for transport mode IPsec security associations as
   endpoint addresses.

6.  References

6.1  Normative References

   [keywords]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

6.2  Informative References

   [ADDRMGT]  Dupont, F., "Address Management for IKE version 2",
              draft-dupont-ikev2-addrmgmt-05.txt (work in progress),
              June 2004.

   [IKEv2]    Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
              Protocol", draft-ietf-ipsec-ikev2-14.txt (work in
              progress), May 2004.

   [MIPv6]    Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [MN-HA]    Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

   [MOBIKE]   Kivinen, T., "Design of the MOBIKE protocol",



Dupont                 Expires February 10, 2005                [Page 3]

Internet-Draft         Transport mode and Mobike             August 2004


              draft-ietf-mobike-design-00.txt (work in progress), June
              2004.

   [RFC2401bis]
              Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", draft-ietf-ipsec-rfc2401bis-02.txt
              (work in progress), April 2004.

   [SCTP]     Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L. and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [VPN]      Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport
              Mode for Dynamic Routing", draft-touch-ipsec-vpn-07.txt
              (work in progress), February 2004.


Author's Address

   Francis Dupont
   GET/ENST Bretagne
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Fax:   +33 2 99 12 70 30
   EMail: Francis.Dupont@enst-bretagne.fr






















Dupont                 Expires February 10, 2005                [Page 4]

Internet-Draft         Transport mode and Mobike             August 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Dupont                 Expires February 10, 2005                [Page 5]

Internet-Draft         Transport mode and Mobike             August 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Dupont                 Expires February 10, 2005                [Page 6]