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

Differences from draft-dupont-mobike-transport-01.txt

Network Working Group                                          F. Dupont
Internet-Draft                                                    Point6
Expires: October 27, 2005                                 April 25, 2005


              IPsec transport mode in Mobike environments
                  draft-dupont-mobike-transport-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   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
   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 October 27, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Dupont                  Expires October 27, 2005                [Page 1]

Internet-Draft          Transport mode and Mobike             April 2005


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

   But transport mode IPsec security associations are end-to-end and
   have no outer addresses: current designs for Mobike do not support
   their management, for instance updates of their addresses.  But there
   is an indirect way to take benefits from Mobike: assume that the peer
   addresses are the addresses of peers.

2.  Terms and Definitions

   Terms like "peer addresses" are taken from the address management
   proposal [ADDRMGT].

   This document uses the standard keywords [BCP14] to indicate
   requirement levels.

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

4.  Two examples

   This section provides two examples of transport mode taking benefits
   of Mobike mechanisms.

4.1  MIPv6 example

   The first example is the IPv6 mobility [RFC3775] 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 [RFC3776] a transport mode IPsec
   security association pair is established using the home address.




Dupont                  Expires October 27, 2005                [Page 2]

Internet-Draft          Transport mode and Mobike             April 2005


   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.

4.2  SCTP example

   The second example is multi-homing using SCTP [RFC2960], (itself or
   what we call the SCTP model of multi-homing) between two hosts.
   "Using Mobike, a multi-homed peer can register its addresses as peer
   addresses.  It is also authorized to use them to build multiple
   transport mode IPsec security associations using only one IKE
   session, i.e., within the same IKE security association.

   Without Mobike, each pair of peer addresses has to be management by
   an independent IKE session, wasting resources and making a higher
   layer of management for handling peer events (in place of address
   events) necessary.

   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.

5.  Acknowledgments

   The Mobike Working Group agreed at the 60th IETF meeting in San Diego
   to put transport mode outside 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.  Note it does not
   try to justify the decision in details (decision which can be
   reversed if an interesting direct application of Mobike mechanisms to
   transport mode is found).

   Some special transport mode IPsec security associations over IP-IP
   tunnels [RFC3884] 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.

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



Dupont                  Expires October 27, 2005                [Page 3]

Internet-Draft          Transport mode and Mobike             April 2005


   safely be used for transport mode IPsec security associations as
   endpoint addresses.

   Rationale: "authenticated" means that one verified the address
   belongs to the peer and must be trusted, "authorized" means that one
   checks in its policy the peer is authorized to use this address.  The
   mechanisms to provide the authentication and authorization are
   outside the scope of this document which only assumes they exist and
   are enforced.

7.  References

7.1  Normative References

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

7.2  Informative References

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

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

   [MOBIKE]   Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
              protocol", draft-ietf-mobike-design-02.txt (work in
              progress), February 2005.

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

   [RFC2960]  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.

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

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




Dupont                  Expires October 27, 2005                [Page 4]

Internet-Draft          Transport mode and Mobike             April 2005


   [RFC3884]  Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
              Transport Mode for Dynamic Routing", RFC 3884,
              September 2004.


Author's Address

   Francis Dupont
   Point6
   c/o 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 October 27, 2005                [Page 5]

Internet-Draft          Transport mode and Mobike             April 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   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
   Internet Society.




Dupont                  Expires October 27, 2005                [Page 6]