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

© 2004 SafeNet, Inc. All rights reserved.

Mobike Protocoldraft-kivinen-mobike-protocol-00.txt

Tero [email protected]


Basic Design

• Tries to use as much of IKEv2 as possible• Notify payloads for address updates

o Multiple notify payloads, each having one address

o 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


Multihoming Rules

• Use preferred address as long as it workso If it fails, takes the next one, mark it as

currently in use addresso Try the most preferred address only after

some event

• Do return routability checks once per new address

• Concentrates on the usability


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


Indirect Indication of Change

• Peer receives some indirect indication that address might not work

o Do not directly act based on such indication, but start dead-peer-detection to verify if the current address works

• Rate limit those checks tooo 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


Dead-Peer-Detection

• IKEv2 dead-peer-detection used for return routability checks and to verify addresses

o If indirect notification, start with currently in use address

o If direct notification start with most preferred address

o Send some DPD packets, if no reply move to next address

o Keep same IKEv2 message ido Every time new address is tried the retranmission

timers are reseto If no response the IKE SA is dead => delete


Dead-peer-detection example

T+0 Notify IP1, IP2

t+9.1 Ack packet

t+1 DPD packet to IP1





t+9.2 Start using IP2

Unreachable

Unreachable

Unreachable

Lost


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)

o Must not send address notifications in ack-packets


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 ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Scope of SA Changes

• Every time IKE SA addresses are updated, all IPsec SAs follow it

o If separate SA list is needed per IPsec SA, then use separate IKE SAs to negotiate them


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 timeo 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?


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

Documents

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