170 likes | 185 Views
This protocol draft outlines a method for changing IP addresses of IKE and IPsec SAs without rekeying, catering to multihoming scenarios and enabling direct and indirect indication of address changes. It includes support for return routability checks, dead-peer detection, and basic address update formats. The protocol also covers the scope of SA changes and considerations for zero address sets.
E N D
Mobike Protocol Design draft-kivinen-mobike-design-00.txt Tero Kivinen kivinen@safenet-inc.com
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
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
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?
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?
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
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
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
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
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
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)
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
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
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
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 :-)
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
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