Last Modified: 2004-02-13
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.
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.
|Feb 04||Publish first draft on|
|Jun 04||Submit IKEv2 Address Update document to IESG for Proposed Standard RFC|
|Jun 04||Publish first draft on|
|Sep 04||Submit Reduced Tunnel Overhead Mode for IPsec to IESG for Informational RFC|
|Sep 04||Publish first draft on|
|Dec 04||Submit PFKEY Extension for Address Updates document to IESG for Informational RFC|
IKEv2 Mobility and Multihoming WGIETF 59, 2004-03-01 09:00-
Emerald Room, Lotte Hotel, Seoul, South Korea
Chairs: Jari Arkko & Paul Hoffman
Secretaries: Pasi Eronen & Lauri Tarkkala
1. Agenda bashing by chairsJari bashed the agenda.
2. WG Status by chairs- WG just approved, this is the first meeting.
- Pasi Eronen is the secretary. Will take minutes and track issues.
- Internal and external document reviewers recruited.
- Document editor(s) will be chosen when we have documents to edit.
- xml2rfc used as the tool for documents.
- No WG documents yet. Three individual submissions. Some missed the draft submission deadline, available from WG website.
- Expect one WG document for protocol. This is to become a standard track for RFC. Decide later what to do with design documents (possibly appendix in protocol document), but it is very important to discuss the design issues.
- Finish first work item before starting others.
- New WG gets to decide how to do things; we do some things differently that other WGs, but chairs are open to suggestions. This is not IPSEC WG part 2 or any mobility WG part 2.
- We want to make sure we get this right, so we need coordinating with others; but we want to finish this some day.
3. IKEv2 Address Management by Francis DupontGoals:
- New transports (SCTP, ...)
- Security, flexibility, simplicity
- NAT traversal
- Peer addresses as IKE SA parameters
- Special handling/clarification of transport mode
- Peer address sets
- Explicit peer address update
- No 3rd party bombing
- Change in transit
- Return routability check
- Binding with certificates
- Initiated in second exchange, can be changed at any time
- Validated against authentication
- Ordering can carry some meaning, but probably is not very useful and only adds complexity
- When traffic selector (TS) doesn't match the peer address, follow the TS
- Security issue: proper authz is needed
- Proposal: accept it when the TS is in the address set
- Transport mode SAs are not concerned when peer address changes?
- This "proxy mode" is a required feature for Mobile IPv6 support (to do transport mode SA for home address when peer address is CoA)
Peer address update:
- Change the endpoint addresses of IPSec or IKE SAs
- List of SAs to update, or an 'all SAs' flag
- Possible return routability check
- New payload similar to DELETE
- Mechanisms (managing peer address sets and updating SAs)
- Policies (what kind of verification you need for addresses, i.e. RR or certificates or something else)
- Nothing about header compression
- BTW, Jan Vilhuber has a draft about header compression in IPsec (draft-vilhuber-hcoesp-00)
Paul: Header compression is in the charter, but far down the line, and it is not work that the WG will be looking at any time soon.
4. MOBIKE Protocol by Tero KivinenQuickly written as starting point for discussion, will be submitted after I-D editor accepts submissions again
- Tries to use as much of IKEv2 as possible
- Notify payloads for address updates
- IKEv2 dead-peer-detection for return routability checks
- Tie IKE SA and IPSec SA address movements together
- Use preferred address as long as it works
- If it fails, take next one; try the most preferred address again after some event
- Do return routability check once per new address
- concentrates on the usability
Direct Indication of Change:
- Other end sends address update notification
- If new preferred address is known and working, move traffic immediately
- If new preferred address is unknown, move traffic immediately, and start return routability checks (some might want to delay moving).
- If new address is known and was not working last time, delay moving of traffic and move it only after verifying that address works now.
Indirect indication of change
- Peer receives some indirect indication that address might not work, this might be ICMP, or other end starts using different address than before, or no packets from other end.
- Do not act directly, but start DPD
Dead Peer Detection:
- IKEv2 dead-peer-detection used for return routability checks and to verify addresses
- If indirect notification, start with currently in use address
- If direct notification start with most preferred address
- Send some DPD packets, if no reply move to next address
- Keep same IKEv2 message id (because of window size)
- Every time new address is tried the retransmission timers are reset
- If no response, we have to delete IKE SA because we might be out of sync for message IDs--but we can retransmit many times and wait quite long
Address Notify Protocol
- Informational exchange, notify payloads
- Message id used to order the request
- Must not send address notifications in ACK packets, must send them in separate exchange
- When IKE SA is updated, all IPsec SAs follow it
- If you want separately move them, create two IKE SAs
Zero Address Set:
- Optional feature, which might be taken in
- Basically a disconnect message
- Simple protocol, no new payloads, no new exchanges, uses IKEv2 features
- Use IKEv2 DPD for return routability checks and for verifying that address works.
5. MOBIKE Design by Tero Kivinen
Paul: Please have open mind and forget the details of these protocols. The protocol we end up with might not look like either of these.Introduction:
- Want to change IP-address of the IKE and IPSec SAs without rekey
- 2 basic scenarios: roaming laptop, multihomed SGW
- We are trying to fix problems that occur locally (e.g. local network connection breaks), not route around problems in core network
- One end is static, not trying to solve two simultaneously moving laptops moving together
- Notifying the other end of IP-address list changes
- Update the IKE SA endpoint address based on the notifications
- Automatically switching to use new IP address if old one does not work anymore
- Updating the tunnel mode IPSec SA selectors.
- RR checks of new addresses if needed
- Multihoming support consist of rules how to use IP address lists
- When to move to new address?
- When to do return routability checks?
Direct indication of address change:
- Directly from the other end
- List of addressed in most preferred order
- Is there maximum size of that list
Indirect Indication of Address Change:
- Indirect indication. The local end notices something that causes it to believe that causes it to believe something along the path has changed.
- Not needed if moving point always notifies
- In MOBIKE context verify which IPs still work
- Should have much longer timeouts, should try to all possible IP addresses before marking peer dead.
- Can be done simultaneously for each IP-addresses, but could cause problems (some IKE implementations retransmit only once for a burst of packets)
Return Routability Checks:
- Try to verify that the other peer can be reached using the IP-address given.
- Can use same messages as DPD
- Informational Exchange: Already defined in IKEv2, All implementations have code to generate and parse them
- Own MOBIKE specific exchange: Not restricted to 2 packets, Might be able to combine RR with address update.
Number of payloads:
- One payload containing everything: More compressed format, More complicated format
- Multiple payloads: Easier to parse (can use IKEv2 code to parse the list), easier to add extension data, some implementations might have limit of max number of payloads
- Notify payloads
- MOBIKE specific payload
Full list of incremental updates:
- When sending IP-address update notifications
- Full list of IP-addresses:
- Easier to handle
- No synch problems
- Restricts the number of IP-addresses
- Incremental changes
- Strict ordering restrictions
- More complicated
Scope of SA Changes:
- How to update the IPSec SA IP-address when IKE SA IP-address change:
- Fast, easy, simple
- Everything moves
- Need separate protocol, payloads etc
- Allows moving only parts of the traffic to new IP-addresses
- Needs per IPSec SA IP-address list
Tero continued about "Zero address set"
Return Routability Checks:
- When to do them?
- Everytime we change address?
- Only when we start to use new address not used before?
- We need to decide on some of those issues before we can really describe the protocol
- Different scenarios and usage types affects some of the choices.
- Lots of decisions, e.g. do we need to support laptops/gws having hundreds of addresses?
6. Way forward- Read design document, read protocols. Submit design issues to mailing list.
- Design issues will be tracked on website. Hopefully design draft will be updated.
- At least one more round of individual submissions; Tero should submit his when submissions open.
- Then close discussion and arrive at a WG document (timeframe ~ 1 month).
- Get the Address Update protocol done before taking up other work items.