< 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
	This section discusses aspects affecting the design of the MOBIKE		This section discusses aspects affecting the design of the MOBIKE
	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.
	47 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/