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

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

2. Basic Design • Tries to use as much of IKEv2 as possible • Notify payloads for address updates • Multiple notify payloads, each having one address • Separte notify message type for IPv4 and IPv6 • IKEv2 dead-peer-detection for return routability checks • Tie IKE SA and IPsec SA address movements together

3. Multihoming Rules • Use preferred address as long as it works • If it fails, takes the next one, mark it as currently in use address • Try the most preferred address only after some event • Do return routability checks once per new address • Concentrates on the usability

4. Direct Indication of Change • Other end sends address update notification • Authenticated • 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

5. Indirect Indication of Change • Peer receives some indirect indication that address might not work • Do not directly act based on such indication, but start dead-peer-detection to verify if the current address works • Rate limit those checks too • Indirect indication might be • ICMP (host unreachable etc) • Other end start using different address than before (indicates something changed along path, perhaps routing etc). • No packets from the other end

6. 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 • Every time new address is tried the retranmission timers are reset • If no response the IKE SA is dead => delete

7. Dead-peer-detection example T+0 Notify IP1, IP2 t+9.1 Ack packet t+1 DPD packet to IP1 t+2 DPD packet to IP1 t+4 DPD packet to IP1 t+8 DPD packet to IP2 t+9 DPD packet to IP2 t+9.2 Start using IP2 Unreachable Unreachable Unreachable Lost

8. Address Notify Protocol • IKEv2 informational exchange • Ordered list of IKEv2 notify payloads • Separate notify message type for IPv4 and IPv6 • Full list of IP-addresses • Message id used to sort the request (process only the one having largest message id) • Must not send address notifications in ack-packets

9. Packet Format 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID=0 ! SPI Size=0 ! Notify Message Type = 42004/6 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data = IPv4 or IPv6 address ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10. Scope of SA Changes • Every time IKE SA addresses are updated, all IPsec SAs follow it • If separate SA list is needed per IPsec SA, then use separate IKE SAs to negotiate them

11. Zero Address Set • Optional feature, which might be taken in • Could be one informational exchange having disconnected notify payload • Will indicate that the host is unreachable for some time • Can also give indication how long if known • DHCP leas time expiring, no new yet => few minutes • Suspending => few hours • Hibernating => 12 hours • Is this feature needed?

12. Summary • Simple protocol, no new payloads, no new exchanges, uses IKEv2 features • Use IKEv2 dpd for return routability checks and for verifying that address works