draft-ietf-mobike-design-07.txt   draft-ietf-mobike-design-08.txt 
IKEv2 Mobility and Multihoming T. Kivinen IKEv2 Mobility and Multihoming T. Kivinen
(mobike) Safenet, Inc. (mobike) Safenet, Inc.
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Expires: July 31, 2006 Siemens Expires: September 4, 2006 Siemens
January 27, 2006 March 3, 2006
Design of the MOBIKE Protocol Design of the MOBIKE Protocol
draft-ietf-mobike-design-07.txt draft-ietf-mobike-design-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2006. This Internet-Draft will expire on September 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the
Internet Key Exchange Protocol version 2 (IKEv2). These extensions Internet Key Exchange Protocol version 2 (IKEv2). These extensions
should enable an efficient management of IKE and IPsec Security should enable an efficient management of IKE and IPsec Security
skipping to change at page 11, line 52 skipping to change at page 11, line 52
MOBIKE peers. MOBIKE interacts with the packet processing module of MOBIKE peers. MOBIKE interacts with the packet processing module of
the IPsec implementation using an internal API (such as those based the IPsec implementation using an internal API (such as those based
on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create
entries in the Security Association (SAD) and Security Policy entries in the Security Association (SAD) and Security Policy
Databases (SPD). The packet processing module of the IPsec Databases (SPD). The packet processing module of the IPsec
implementation may also interact with IKEv2 and MOBIKE module using implementation may also interact with IKEv2 and MOBIKE module using
this API. The content of the Security Policy and Security this API. The content of the Security Policy and Security
Association Databases determines what traffic is protected with IPsec Association Databases determines what traffic is protected with IPsec
in which fashion. MOBIKE, on the other hand, receives information in which fashion. MOBIKE, on the other hand, receives information
from a number of sources that may run both in kernel-mode and in from a number of sources that may run both in kernel-mode and in
user-mode. Information relevant for MOBIKE might be stored in a user-mode. These sources form the basis on which MOBIKE make
database. The content of such a database, along with the occurrence decisions regarding the set of available addresses, the peer address
of events of which the MOBIKE process is notified, form the basis on set, and the preferred address. Policies may also affect the
which MOBIKE make decisions regarding the set of available addresses, selection process.
the peer address set, and the preferred address. Policies may also
affect the selection process.
The peer address set and the preferred address needs to be made The peer address set and the preferred address needs to be made
available to the other peer. In order to address certain failure available to the other peer. In order to address certain failure
cases, MOBIKE should perform connectivity tests between the peers cases, MOBIKE should perform connectivity tests between the peers
(potentially over a number of different paths). Although a number of (potentially over a number of different paths). Although a number of
address pairs may be available for such tests, the most important is address pairs may be available for such tests, the most important is
the pair (source address, destination address) of the current path. the pair (source address, destination address) of the current path.
This is because this pair is selected for sending and receiving This is because this pair is selected for sending and receiving
MOBIKE signaling and IPsec traffic. If a problem along this current MOBIKE signaling and IPsec traffic. If a problem along this current
path is detected (e.g., due to a router failure) it is necessary to path is detected (e.g., due to a router failure) it is necessary to
switch to a new current path. In order to be able to do so quickly, switch to a new current path. In order to be able to do so quickly,
it may be helpful to perform connectivity tests of other paths it may be helpful to perform connectivity tests of other paths
periodically. Such a technique would also help in identifying periodically. Such a technique would also help in identifying
previously disconnected paths that become operational again. previously disconnected paths that become operational again.
+-------------+ +---------+ +---------------------+ +----------------+
|User-space | | MOBIKE | | User-space | | |
|Protocols | +-->>| Module | | Protocols and | | MOBIKE and |
|relevant for | | | | | Functions Relevant |<---------->| IKEv2 Module |
|MOBIKE | | +---------+ | MOBIKE (e.g., DHCP, | | |
+-------------+ | ^ | policies) | +----------------+
User Space ^ | ^ +---------------------+ ^
++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ ^ |
Kernel Space v | v | | User space
_______ | v ++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
+-------------+ / \ | +--------------+ | | Kernel space
|Routing | / Trigger \ | | IPsec | | v
|Protocols |<<-->>| Database |<<-+ +>+ Engine | | +----------------+
| | \ / | | (+Databases) | v | |
+-----+---+---+ \_______/ | +------+-------+ +---------------------+ | IPsec engine |
^ ^ ^ | ^ | Kernel-space |<---------->| (and databases)|
| +---------------+-------------+--------+-----+ | Protocols | | |
| v | | | | Relevant for | +----------------+
| +-------------+ | | | | MOBIKE (e.g., ND, | ^
I | |Kernel-space | | | | I | DNA, L2) |<---------------+ |
n | +-------->+Protocols +<----+-----+ | | n +---------------------+ v v
t v v |relevant for | | v v v t || +----------------+
e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e \/ | |
r | Input | +-------------+ | | Outgoing | r Inter- =====================>| IP forwarding, |
f | Packet +<--------------------------+ | Interface | f faces <=====================|input and output|
==a>|Processing|===============================| Processing |=a> | |
c | | | | c +----------------+
e +----------+ +------------+ e
s s
===> = IP packets arriving/leaving a MOBIKE node ===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations <-> = control and configuration operations
Figure 3: Framework Figure 3: Framework
Please note that Figure 3 illustrates an example of how a MOBIKE Please note that Figure 3 illustrates an example of how a MOBIKE
implementation could work. Hence, it serves illustrative purposes implementation could work. Hence, it serves illustrative purposes
only. only.
5. Design Considerations 5. Design Considerations
skipping to change at page 33, line 19 skipping to change at page 33, line 19
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mobike-protocol] [I-D.ietf-mobike-protocol]
Eronen, P., "IKEv2 Mobility and Multihoming Protocol Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", draft-ietf-mobike-protocol-07 (work in (MOBIKE)", draft-ietf-mobike-protocol-08 (work in
progress), December 2005. progress), February 2006.
[I-D.ietf-shim6-failure-detection] [I-D.ietf-shim6-failure-detection]
Arkko, J. and I. Beijnum, "Failure Detection and Locator Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming", Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-03 (work in progress), draft-ietf-shim6-failure-detection-03 (work in progress),
December 2005. December 2005.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the Nikander, P., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-02 (work in Host Identity Protocol", draft-ietf-hip-mm-03 (work in
progress), July 2005. progress), March 2006.
[I-D.crocker-celp] [I-D.crocker-celp]
Crocker, D., "Framework for Common Endpoint Locator Crocker, D., "Framework for Common Endpoint Locator
Pools", draft-crocker-celp-00 (work in progress), Pools", draft-crocker-celp-00 (work in progress),
February 2004. February 2004.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
skipping to change at page 35, line 7 skipping to change at page 35, line 7
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002. framework", RFC 3303, August 2002.
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-08 (work in Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in
progress), October 2005. progress), February 2006.
[Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet [Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Location Management", In Proc. 18th Annual Computer Location Management", In Proc. 18th Annual Computer
Security Applications Conference, pages 78-87, Las Vegas, Security Applications Conference, pages 78-87, Las Vegas,
NV USA, December 2002. NV USA, December 2002.
Authors' Addresses Authors' Addresses
Tero Kivinen Tero Kivinen
Safenet, Inc. Safenet, Inc.
 End of changes. 8 change blocks. 
45 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/