2.6.10 IKEv2 Mobility and Multihoming (mobike)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MOBIKE Web Page

Last Modified: 2005-06-27

Chair(s):

Paul Hoffman <paul.hoffman@vpnc.org>
Jari Arkko <Jari.Arkko@piuha.net>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ Housley <housley@vigilsec.com>

Secretary(ies):

Pasi Eronen <pasi.eronen@nokia.com>

Mailing Lists:

General Discussion: mobike@machshav.com
To Subscribe: https://www.machshav.com/mailman/listinfo.cgi/mobike
Archive: https://www.machshav.com/pipermail/mobike/

Description of Working Group:

The IKE Mobility working group will focus on the extensions to the
IKEv2 protocol required to enable its use in the context where there
are multiple IP addresses per host (multihoming, SCTP) or where the IP
addresses changes in the control of the IPsec host (mobility and
roaming).

The main scenario is making it possible for a VPN user to move from
one address to another without re-establishing all security
associations, or to use multiple interfaces simultaenously, such as
where WLAN and GPRS are used simultaneously. It is also intended that
the extensions produced by the WG would address specific needs related
to other work in IETF, such as modification of SCTP end points without
renegotiation of the security associations or the movement of
IKEv2-based secure connections to enable Mobile IP signaling to take
place.

An explicit non-goal is the construction of a fully fledged mobility
protocol. In particular, the WG shall NOT develop mechanisms for the
following functions:

o Hiding of mobility from transport layer protocols or applications
  (beyond what already exists through the use of the tunnel mode). In
  this respect MOBIKE is different from Mobile IP, HIP, and other
  mobility protocols.

o IP address changes done by third parties (NATs, firewalls etc). In
  particular, MOBIKE shall not replace or modify IKEv2 NAT traversal
  function. MOBIKE handles IP address changes initiated by one of the
  endpoints of the security associations. NAT traversal handles other
  address changes. MOBIKE should not be tightly coupled with the NAT
  traversal function, but it is necessary to specify in which cases
  (if any) they can be used together, and how they interact.

o Opportunistic authentication or other tools for the reduction of
  configuration effort. The mechanisms specified in this WG are to be
  designed for the traditional VPN use case only.

o Any optimization of packet routing paths due to mobility.

o Load balancing. Multihoming is supported only in the sense of
  failing over to another interface; sending traffic over multiple
  addresses using the same SA is not supported.

o Use of IKEv1.

Work Items

The goals of the MOBIKE working group are to address the
following issues:

(1) IKEv2 mobile IP support for IKE SAs. Support for changing and
    authenticating the IKE SA endpoints IP addresses as requested by
    the host.

(2) Updating IPsec SA gateway addresses. Support for changing the IP
    address associated to the tunnel mode IPsec SAs already in
    place, so that further traffic is sent to the new gateway
    address.

(3) Multihoming support for IKEv2. Support for multiple IP addresses
    for IKEv2 SAs, and IPsec SAs created by the IKEv2. This should
    also include support for the multiple IP address for SCTP
    transport. This should also work together with the first two
    items, i.e those addresses should be able to be updated too.

(4) Verification of changed or added IP addresses. Provide way to
    verify IP address either using static information, information
    from certificates, or through the use of a return routability
    mechanism.

(5) Reduction of header overhead involved with mobility-related
    tunnels. This is a performance requirement in wireless
    environments.

(6) Specification of PFKEY extensions to support the IPsec SA
    movements and tunnel overhead reduction.

Goals and Milestones:

Jun 05  Publish first draft on 'IKEv2 Address Update', covering issues 1 to 4 from the above list
Sep 05  Submit IKEv2 Address Update document to IESG for Proposed Standard RFC
Jan 06  Submit Reduced Tunnel Overhead Mode for IPsec to IESG forInformational RFC
Jan 06  Publish first draft on 'PFKEY Extension for Address Updates' (issue 6 above)
May 06  Publish first draft on 'Reduced Tunnel Overhead Mode for IPsec' (issue 5 above)
May 06  Submit PFKEY Extension for Address Updates document to IESG for Informational RFC

Internet-Drafts:

  • draft-ietf-mobike-design-03.txt
  • draft-ietf-mobike-protocol-01.txt

    No Request For Comments

    Current Meeting Report

    MOBIKE WG meeting
    Wednesday August 3, 2005, Paris
    Notes taken by Lakshminath Dondeti and Maureen Stillman,
       combined by Paul Hoffman
    
    Introductory talk
    
    	Jari A: In May we resolved design issues. Pasi wrote a protocol
    	draft according to decisions made; it was reviewed and revised
    	version has been submitted.
    
    	Related documents are here FYI:
    
    	* devarapalli-mip4-mobike-connectivity -- MIPv4 approved WG (not
    	MOBIKE) item. Discussed in 3GPP, especially in relation to 3GPP-WLAN
    	interconnection May need liaison planning. Good to review in MOBIKE
    	also.
    
    	Paul H: we should coordinate with MIPv4 list. Pasi E: There is a
    	discussion underway in that group.
    
    	* dupont-mobike-transport Paul H: Please review, and we'll discuss
    	within a reasonable time
    
    	Paul H: It's fine to talk about non-WG documents as long as they
    	don't block WG doc progress. There are several other drafts like the
    	above two.  Please see the agenda slides.
    
    Pasi E on MOBIKE-Protocol-01:
    
    	(see the slides)
    
    MOBIKE easy issues (Pasi Eronen):
    
    	21, 25, 29 are Editorial
    	
    	26 Window size and latest update counter
    	
    	Word "path" now used only in senses that include the route
    	
    	23 : Separate payload types
    	
    	30 : Protocol ID in notifications (to be in sync with the
    	ikev2-clarifications document)
    	
    	24 NAT prevention needs clarification and a better name
    	
    		Jari A.: Let's make some progress here by coming with some
    		decisions and we can get those confirmed on the list.
    	
    		Francis D: dependency on 22
    	  
    	35, Version number (Skip the complexity now!)
    	
    	37: Move MOBIKE supported notification from IKEv2_SA_INIT to AUTH
    	exchange
    	
    		Allows per user policy about whether MOBIKE is allowed
    	
    		Hannes: less fragmentation risk if added to AUTH
    	
    		Jari A: Clarification req: 
    	
    		Tero:  Can't fragment the first packet, because can't do
    		stateless IKEv2 exchange.  Let's keep IKEv2_SA_INIT packet very
    		small and allow the stateless feature to be continued to be
    		supported. NAT-T may make the notification even larger.
    	
    		Seems like there is consensus on this.
    	
    	36: Unacceptable addresses.
    	
    		Receiver might not know which address set was acceptable
    	
    		Jari A: I had different thoughts on the list, but it is
    		clarified now and I am ok with this.
    	
    		Pasi: This is a corner case anyway
    	
    	27: Security and path testing
    	
    		Sec considerations section needs text on path testing
    	
    		Dependent on issue 34
    	
    	Consensus calls: 35, 37 (Lakshminath: add comments from Tero as
    	text) and 36 mostly yes and no hands on oppose. All will be repeated
    	on the list.
    	
    	22: close the issue, misunderstanding (Hannes)
    
    MOBIKE issue 34 (Pasi Eronen):
    
    	(see the slides!) Discussion in the room:
    	
    	Current protocol just does what IKEv2 NAT traversal does
    	
    	This is another place where we upgrade a MAY to a MUST in IKE v2
    	
    	Terminals that are totally idle sending keep alives consumes energy
    	
    	Should we ask the BEHAVE WG anything? (Paul H says no, emphatically)
    
    	Only 2 people in the room have done an implementation with this
    
    	Suggestion: never time out; wait until you are under attack
    	
    	When added to IKEv2, it was a corner case
    	if you care about it you implement the SHOULD
    	if you don't care then you don't implement the SHOULD
    	
    	Path test is valuable independent of this issue. It is clear we need
    	this path testing feature regardless of this issue.
    	
    	Relationship to Path test
    	
    		with approach 1
    			there are more of these time periods ->
    			more need of separate exchange
    			if you want to do NAT detection in path testing ->
    			need separate exchange
    		
    		with approach 3
    			fewer of these time periods
    	
    	summary:
    		approach 1 and 3 both work
    		both have pros and cons
    	
    	Tero agreed to write the summary to the list and send them 
    	
    	Want to see more discussion on the list;
    	security considerations for the path test exchange
    	
    	Sense of how we support this corner case; do we want to drop it?
    	We know it will happen if the NAT rebooted or change mapping for
    	some reason
    	
    	Ask on the list about implentations IKEv1 or IKEv2
    	
    Next steps (Jari A)
    
    	get rough consensus on technical issues
    	fix security considerations
    	clarify role of multihoming
    
    	3GPP2 has sent a liaison statement; we need to respond to it
    
    Design document (Hannes)
    
    	mobike design 03
    	
    	document update for this IETF
    	changed lots of text and organization
    	
    	Difficult to follow the whole story; moved text to make it easier
    	to understand
    	
    	missing pieces
    	
    	selecting address (issue #20)
    
    	more details in the security consideration section
    	
    	add design rationale for some issues that arise
    	
    	readability - better structure for the doc -- new outline
    	
    	Paul H: this tracks the IKEv2 clarifications document and can get
    	to the IESG after the protocol document (not by long)
    	People seem to like that
    	
    Way forward (Jari A and Paul H)
    
    	Close all open issues on the protocol document
    	We want to finish for real by September 15
    	
    	Then have WG last call
    	
    	At the same time as WG last call for the protocol finish the design
    	document
    	
    	Read the docs now; don't wait.
    

    Slides

    Agenda
    Protocol overview
    MOBIKE issues
    Design of the MOBIKE Protocol