Internet DRAFT - draft-dupont-mobike-transport
draft-dupont-mobike-transport
Network Working Group F. Dupont
Internet-Draft CELAR
Expires: December 27, 2006 June 25, 2006
IPsec transport mode in Mobike environments
draft-dupont-mobike-transport-04.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 December 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies how to use transport mode IPsec security
associations in a Mobike environment, i.e., in an environment with
sequential (mobility) or parallel (multi-homing) addresses.
1. Introduction
The Mobike protocol [RFC4555] deals with "peer addresses" which are
the addresses IKE runs over and which are the addresses used as outer
Dupont Expires December 27, 2006 [Page 1]
Internet-Draft Transport mode and Mobike June 2006
or endpoint addresses by tunnel mode IPsec security associations
between security gateways [RFC4301]. Mobike specifies in IKEv2
[RFC4306] both 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 / endpoint addresses: current designs for Mobike do not
support their management, for instance updates of their addresses,
because the endpoint addresses are also traffic selectors.
But there are two ways to take benefit from Mobike in some cases: the
first one is to assume that the peer addresses are the addresses of
peers for authorization, the second is to update addresses which do
not select traffic.
2. Terms and Definitions
Terms like "peer addresses" are taken from the certificate profile
proposal [IKECERT].
This document uses the standard keywords [BCP14] to indicate
requirement levels.
3. Transport mode and addresses
The endpoint addresses of a transport mode IPsec 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.
The Mobike protocol provides peer address lists or sets so this rule
can be relaxed into: by default, any peer address MAY be used as an
endpoint address of a transport mode IPsec security association.
4. Reuses of address management
This section provides two examples of transport mode taking benefit
from the peer address set management provided by Mobike.
4.1. MIPv6 example
The first example is the IPv6 mobility [RFC3775] where a mobile node
uses two kinds of addresses:
Dupont Expires December 27, 2006 [Page 2]
Internet-Draft Transport mode and Mobike June 2006
- 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.
Using the Mobike peer address management, a mobile node MAY 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 some other IPsec security
associations which are in tunnel mode are updated in case of handoffs
by the mobility support itself, not by Mobike.
4.2. Multi-homing 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 the peer address management of Mobike, a multi-homed peer
SHOULD register its addresses as peer addresses. It is also
authorized to use them (i.e., it MAY use them) to build multiple
transport mode IPsec security associations using only one IKE
session, i.e., within the same IKE security association.
Without this authorization facility from Mobike, each pair of peer
addresses has to be managed 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. Reuses of endpoint updates
The Mobike protocol cannot directly update transport mode IPsec
security associations, in particular it cannot change their traffic
selectors. But when there are not addresses in traffic selectors
(i.e., address selectors are set to ANY) or when all the involved
addresses are in traffic selectors, this obstacle no more exists.
An exterior (to IPsec/IKE) mechanism has to handle both the decision
to change addresses and to update the endpoints of the transport mode
IPsec security associations. The role of Mobike is to update the IKE
security association and the house-keeping of the IPsec security
Dupont Expires December 27, 2006 [Page 3]
Internet-Draft Transport mode and Mobike June 2006
associations. One can compare this to the K flag mechanism of MIPv6
[RFC3776].
5.1. SCTP example
Again SCTP [RFC2960] is a good candidate, in this example the current
SCTP endpoint management is followed: when a path, i.e., a pair of a
soure and destination endpoint addresses, fails, another (backup)
path is selected and all the communications between the two endpoints
are switched over it.
When some of the SCTP communications are protected by IPsec, the
Mobike peer address update mechanism MAY be used to notify IKE of
peer address changes.
This case is limited:
- the whole list of possible peer addresses SHOULD be known in
advance, i.e., multi-homing is supported but not mobility.
- all involved addresses MUST be in traffic selectors.
5.2. IP-IP example
The last example is about some special transport mode IPsec security
associations over IP-IP tunnels [RFC3884]. The traffic selectors MAY
be reduced to the tunnel transport mechanism parameters, for instance
a protocol number, and the endpoint addresses hidden by the choice of
the security policy database attached to the tunnel interface.
With this special configuration there is no constraint on the use of
Mobike as soon as the tunnel and IPsec managements are implemented to
work together (i.e., all parameters are updated exactly once).
6. Acknowledgments
The Mobike Working Group agreed to put transport mode outside of its
immediate scope. But as transport mode can take indirect benefit
from Mobike mechanisms, an as short as possible document (this one)
was proposed. Mohan Parthasarathy provides a big part of the update
reuse cases, Joe Touch proposed for consideration the IP-IP one.
7. 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
Dupont Expires December 27, 2006 [Page 4]
Internet-Draft Transport mode and Mobike June 2006
endpoint addresses.
Rationale: "authenticated" means that one verified the address
belongs to the peer and may be trusted, "authorized" means that one
checks in its policy whether 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.
The peer address update of Mobike is only an optimization of re-
keying or re-establishing of a set of security associations so this
mechanism does not introduce new issues when it is performed in the
same conditions.
8. References
8.1. Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4555] Eronen, P., Ed., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
8.2. Informative References
[IKECERT] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX",
draft-ietf-pki4ipsec-ikecert-profile-10.txt (work in
progress), April 2006.
[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
Dupont Expires December 27, 2006 [Page 5]
Internet-Draft Transport mode and Mobike June 2006
Home Agents", RFC 3776, June 2004.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884,
September 2004.
Dupont Expires December 27, 2006 [Page 6]
Internet-Draft Transport mode and Mobike June 2006
Author's Address
Francis Dupont
CELAR
Email: Francis.Dupont@point6.net
Dupont Expires December 27, 2006 [Page 7]
Internet-Draft Transport mode and Mobike June 2006
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 (2006). 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 December 27, 2006 [Page 8]
