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

2. © 2004 SafeNet, Inc. All rights reserved. Scenarios The design draft lists to basic scenarios, where the protocols should work o Roaming laptop scenario o Multihoming SGW scenario Those two scenarios can be combined, meaning that we have the roaming laptop on the other end and multihoming SGW on the other end

3. © 2004 SafeNet, Inc. All rights reserved. Roaming Laptop Scenario We have a roaming laptop with multiple connections to internet o Fixed ethernet, WLAN, GPRS etc Changes are either change of the interface, or change of the IP because of movement Connection is to the corporate SGW or similar Connection between two laptops is out of scope

4. © 2004 SafeNet, Inc. All rights reserved. Multihoming SGW Scenario We have the corporate SGW with multiple internet connections (from different ISPs) o Interfaces are fixed o IP addresses are mostly static Changes are because of change of used interface when one ISP used stops working The other end might be roaming laptop or similar SGW (site to site connection)

5. © 2004 SafeNet, Inc. All rights reserved. Basic Scenario SGW/B D E NAT A A A Internet WLAN Corporate network

6. © 2004 SafeNet, Inc. All rights reserved. Major Open Issues 3rd party bombing protection level Level of NAT-T and MOBIKE interaction Do we need to recover from problems that we did not hear about directly Scope of SA changes Other issues o Simultaneous movements o IPv4/IPv6

7. © 2004 SafeNet, Inc. All rights reserved. 3rd Party Bombing How much protection we offer against 3rd party bombing o almost none, [A-B] (IKEv2 NAT-T) o limited, [A-B and (B-C or A)] (return routability without cookies) o partial [A-B and B-C] (return routability with cookies) o Full [A inside path B-C] (authenticate outer IP- addresses, incompatible with NATs) o Terms A, B = MOBIKE hosts, C = host attacked A-B = along path between A and B B-C = along path between B and C o Do we care if A is the attacker

8. © 2004 SafeNet, Inc. All rights reserved. 3rd Party Bombing (cont) A B C M1 A/M3 M2

9. © 2004 SafeNet, Inc. All rights reserved. NATs and MOBIKE Related to 3rd party bombing issue o if we want to have full protection against 3rd party bombings, we cannot work with NATs o If we only want to use limited or partial protection then we can work through NATs o If we allow full protection to be downgraded, then attacker might force the protection to be downgraded before starting the attack => we didn't have full protection at all. Does the limited or partial protection offer that much compared to the normal IKEv2 NAT-T? Should we upgrade the protection offered by IKEv2 NAT-T to partial/limited Implicit address update is not mandated in IKEv2, it is only SHOULD

10. © 2004 SafeNet, Inc. All rights reserved. NAT and MOBIKE (cont) Problems with multihoming and NAT o Case 1: the host behind NAT is not multihoming and the other end is multihoming Option 1: Recovery is limited and done only by the host behind NAT. Option 2: The host behind NAT must send keepalives to all possible path combinations, and keep the mappings in NAT active all the time o Case 2: The host behind NAT is multihoming, with some of the interfaces using NAT and some not. Same problems with interfaces using NAT No problems with interfaces not using NAT, can use normal MOBIKE methods.

11. © 2004 SafeNet, Inc. All rights reserved. NAT-T and MOBIKE Options 1: Always use NAT-T o No multihoming in server o No protection against 3rd party bombing 2: NAT-T and MOBIKE are separate o If you move to NAT-T, just create new IKE SA which uses NAT-T o Mobike will have the active attack detector, which notices that there is NAT between. 3: NAT-T and MOBIKE are combined o Modify NAT-T and/or create combination using NAT- T and MOBIKE.

12. © 2004 SafeNet, Inc. All rights reserved. Combined NAT-T and MOBIKE With combined NAT-T and MOBIKE protocol we have some more questions: o Do we only allow NAT to appear only when IP- address or link status changes? o Do we want to switch back from the NAT-T to MOBIKE Save bandwidth (no UDP encapsulation) Better protection against 3rd party bombing o Attacker can force as to use NAT-T before attacking o We need to define our own NAT-T (or modify IKEv2), as IKEv2 NAT-T isn't enough for us Can only be enabled in the beginning Implicit address update is not mandatory Return routability checks not mandatory No detection of NAT disappearing

13. © 2004 SafeNet, Inc. All rights reserved. Recovery from Problems Which problems we try to recover o Only local problems (IP-address changes by dhcp, link goes down, network card is removed) o Also problems in the network (link breaking down somewhere along the path, routing infrastructure problems etc) o Do we need to act on information that no packets are received from other end? o Relates to the NAT-T issue, as there only initiator can fix things, thus it needs to detect problems

14. © 2004 SafeNet, Inc. All rights reserved. Recovery from Problems (cont) Minor issues related to this o Testing of all possible paths between hosts? o Which end starts recovery? o Do we need to know all addresses from other end?

15. © 2004 SafeNet, Inc. All rights reserved. Scope of SA Changes Do all IPsec SAs move along the IKE SA, or do we want to be able to set IP-addresses for each IPsec SA separately We can always simulate the moving them separately by creating multiple IKE SAs. o Those IKE SAs can be created at the same time, perhaps using the same authentication information.

16. © 2004 SafeNet, Inc. All rights reserved. Simultaneous Movements Real simultaneous movement where rendezvous server is needed are outside of the scope of MOBIKE. If we want recover from situations where link goes down along the path, we will see virtual simultaneous movements, i.e. both ends IP- addresses change at the same time (but to already known addresses). o The SGW will have fixed quite static set of IP- addresses, thus roaming host can know the IP- addresses of that SGW.

17. © 2004 SafeNet, Inc. All rights reserved. IPv4 vs IPv6 If we use tunnel mode and tunnel endpoint addresses (outer addresses) change from IPv4 to IPv6 or other way around, everything should still work. We are not discussing of changing the traffic selectors here.

18. © 2004 SafeNet, Inc. All rights reserved. Simplifications SGW side: o Number of IP-address and their type: Has one static global IP-address Has multiple static global IP-addresses Has one mostly static global IP-address (can be changed, but only when the link is still working) Has multiple mostly static global IP-addresses o Disallow NATs on SGW side, but allow them on other end

19. © 2004 SafeNet, Inc. All rights reserved. Simplifications (cont) Client side (roaming laptop side) o Allow NAT-T only when not using multihoming o Only allow one interface at time if NAT-T is used (no multiple NAT-T interfaces or non NAT-T interface at same time) (i.e. ignore other interfaces if the current one uses NAT). Recovery o If the initiator is behind NAT it takes care of recovery o Initiator takes all care of recovery always o Note Initiator == Client side (roaming laptop) in most of the cases

20. © 2004 SafeNet, Inc. All rights reserved. Summary There are some questions we need to answer before we can really even start designing the protocol. o 3rd Party Bombing Protection o Recovery model Answers to those will then give answer to some of the other questions