Mobike Protocol Design draft-kivinen-mobike-design-00.txt Tero Kivinen kivinen@safenet-inc

1. Mobike Protocol Design draft-kivinen-mobike-design-00.txt Tero Kivinen kivinen@safenet-inc.com

2. Introduction • Want to change the IP-addresses of the IKE and IPsec SAs without rekey • 2 Basic scenarios • Roaming laptop • Multiple network connections • IP-addresses change • Prefers some interfaces over some others • Multihoming SGW • Multiple network connections • Static IP-addresses • Some links might be down

3. 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. 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. 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. 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 • Other end start using different source IP-address • ICMP message is received • Routing information changes • No traffic from the other end for awhile • Do not directly act on such indication

7. 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 • Can cause troubles, as other end might only answer to one request

8. 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. Basic Address Update Format • Basic format of address update protocol • IKEv2 exchanges • Informational exchange? • Own MOBIKE exchange? • One or multiple payloads • Payload types • Notify payload? • Own MOBIKE payload? • Ordered list of addresses or preference number for each address

10. Exchange • Informational exchange • Already defined in the IKEv2 • All implemenations 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

11. Number of Payloads • One payload containing everything • More compressed format • More complicated format (needs extensions, list of both IPv4 and IPv6 addresses etc) • 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 (limits the number of IP-addresses)

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

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

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

15. 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. Return Routability Checks • When to do them • Every time we change address? • Extra overhead • Only when we start to use new address not used before? • Needs to keep track of used addresses • Never? • Not protecting third parties against flooding attacks • If other end has fixed authenticated list of IP-address, we can leave checks out

17. 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