1. © 2004 SafeNet, Inc. All rights reserved. Mobike Protocol Design draft-kivinen-mobike-design-00.txt Tero Kivinen kivinen@safenet-inc.com

2. © 2004 SafeNet, Inc. All rights reserved. Introduction Want to change the IP-addresses of the IKE and IPsec SAs without rekey 2 Basic scenarios o Roaming laptop Multiple network connections IP-addresses change Prefers some interfaces over some others o Multihoming SGW Multiple network connections Static IP-addresses Some links might be down

3. © 2004 SafeNet, Inc. All rights reserved. Protocol Notifying the other end of IP-address list changes Update the IKE SA endpoint address based on the notifications Automatically swithing to use new IP-address if old one does not work anymore Updating the tunnel mode IPsec SA tunnel endpoint addresses Return routability checks of new addresses if needed

4. © 2004 SafeNet, Inc. All rights reserved. Multihoming Support Multihoming support consist of rules how to use IP-address lists When to move to new address? How to verify whether the address works or if any addresses works? When to do return routability checks?

5. © 2004 SafeNet, Inc. All rights reserved. Direct Indication of Address Change Directly from the other end Authenticated List of addressed in most preferred order Is there max size of that list?

6. © 2004 SafeNet, Inc. All rights reserved. Indirect Indication of Address Change Indirect indication, i.e. The local end notices something that causes it to belive something along the path has changed Not authenticated All kind of things o Other end start using different source IP-address o ICMP message is received o Routing information changes o No traffic from the other end for awhile Do not directly act on such indication

7. © 2004 SafeNet, Inc. All rights reserved. Dead-Peer-Detection Verify that the other end is still alive In MOBIKE context verify that the IP- address(es) still work(s) Should have much longer timeouts, should try to all possible IP-addresses before marking peer dead Can be done simultaneously for each IP- addresses o Can cause troubles, as other end might only answer to one request

8. © 2004 SafeNet, Inc. All rights reserved. Return Routability Checks Try to verify that the other peer can be reached using the IP-address given Protection against the flooding attacks against third party Can be using similar protocol than dead-peer- detection

9. © 2004 SafeNet, Inc. All rights reserved. Basic Address Update Format Basic format of address update protocol IKEv2 exchanges o Informational exchange? o Own MOBIKE exchange? One or multiple payloads Payload types o Notify payload? o Own MOBIKE payload? Ordered list of addresses or preference number for each address

10. © 2004 SafeNet, Inc. All rights reserved. Exchange Informational exchange o Already defined in the IKEv2 o All implemenations have code to generate and parse them Own MOBIKE specific exchange o Not restricted to 2 packets o Might be able to combine RR with address update

11. © 2004 SafeNet, Inc. All rights reserved. Number of Payloads One payload containing everything o More compressed format o More complicated format (needs extensions, list of both IPv4 and IPv6 addresses etc) Multiple payloads o Easier to parse (can use IKEv2 code to parse the list) o Easier to add extension data o Some implementations might have limit of max number of payloads (limits the number of IP- addresses)

12. © 2004 SafeNet, Inc. All rights reserved. Payloads Notify payloads o Already defined in the IKEv2 o All implemenations should already have code to generate and parse them o Some extra overhead MOBIKE specific payload o Can use more compressed format o If using one big payload, then having separate payload for the complex format is better

13. © 2004 SafeNet, Inc. All rights reserved. Full List or Incremental Updates When sending IP-address update notifications Full list of IP-addresses o Easier to handle, as all IP-address arrives at same time o No syncronization problems o Restricts the number of IP-addresses because of the packet size restrictions Incremental changes o Strict ordering restrictions (must be processed in order) o More complicated

14. © 2004 SafeNet, Inc. All rights reserved. Scope of SA Changes How to update the IPsec SA IP-address when IKE SA IP-address change Automatic o Fast, easy, simple o Everything moves, no way to move only some SAs Manual o Needs separate protocol, payloads etc o Allows moving only parts of the traffic to new IP- addresses o Needs per IPsec SA IP-address list

15. © 2004 SafeNet, Inc. All rights reserved. Zero Address Set Sending zero IP-addresses, meaning that other end is going to be disconnected from the net Is this needed? What happens to the TCP/IP connections while other end is disconnected Local policy can disallow this Helps Monday morning problems as users can keep the SAs up over the weekends :-)

16. © 2004 SafeNet, Inc. All rights reserved. Return Routability Checks When to do them Every time we change address? o Extra overhead Only when we start to use new address not used before? o Needs to keep track of used addresses Never? o Not protecting third parties against flooding attacks o If other end has fixed authenticated list of IP-address, we can leave checks out

17. © 2004 SafeNet, Inc. All rights reserved. Summary Lots of questions 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