Mobike Protocol Design draft-ietf-mobike-design-00.txt Tero Kivinen firstname.lastname@example.org © 2004 SafeNet, Inc. All rights reserved. Scenarios • The design draft lists to basic scenarios, where the protocols should work o o Roaming laptop scenario 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 © 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 © 2004 SafeNet, Inc. All rights reserved. Multihoming SGW Scenario • We have the corporate SGW with multiple internet connections (from different ISPs) o o Interfaces are fixed 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) © 2004 SafeNet, Inc. All rights reserved. Basic Scenario WLAN A D A Internet SGW/B E NAT A © 2004 SafeNet, Inc. All rights reserved. Corporate network 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 o Simultaneous movements IPv4/IPv6 © 2004 SafeNet, Inc. All rights reserved. 3rd Party Bombing • How much protection we offer against 3rd party bombing o o o o o almost none, [A-B] (IKEv2 NAT-T) limited, [A-B and (B-C or A)] (return routability without cookies) partial [A-B and B-C] (return routability with cookies) Full [A inside path B-C] (authenticate outer IPaddresses, incompatible with NATs) 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 © 2004 SafeNet, Inc. All rights reserved. 3rd Party Bombing (cont) C A/M3 A M2 B © 2004 SafeNet, Inc. All rights reserved. M1 NATs and MOBIKE • Related to 3rd party bombing issue o o o if we want to have full protection against 3rd party bombings, we cannot work with NATs If we only want to use limited or partial protection then we can work through NATs 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 © 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 • o 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 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. © 2004 SafeNet, Inc. All rights reserved. NAT-T and MOBIKE Options • 1: Always use NAT-T o o No multihoming in server No protection against 3rd party bombing • 2: NAT-T and MOBIKE are separate o o If you move to NAT-T, just create new IKE SA which uses NAT-T 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. © 2004 SafeNet, Inc. All rights reserved. Combined NAT-T and MOBIKE • With combined NAT-T and MOBIKE protocol we have some more questions: o o Do we only allow NAT to appear only when IPaddress or link status changes? Do we want to switch back from the NAT-T to MOBIKE • Save bandwidth (no UDP encapsulation) • Better protection against 3rd party bombing o o Attacker can force as to use NAT-T before attacking 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 © 2004 SafeNet, Inc. All rights reserved. Recovery from Problems • Which problems we try to recover o o o o Only local problems (IP-address changes by dhcp, link goes down, network card is removed) Also problems in the network (link breaking down somewhere along the path, routing infrastructure problems etc) Do we need to act on information that no packets are received from other end? Relates to the NAT-T issue, as there only initiator can fix things, thus it needs to detect problems © 2004 SafeNet, Inc. All rights reserved. Recovery from Problems (cont) • Minor issues related to this o o o Testing of all possible paths between hosts? Which end starts recovery? Do we need to know all addresses from other end? © 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. © 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 IPaddresses change at the same time (but to already known addresses). o The SGW will have fixed quite static set of IPaddresses, thus roaming host can know the IPaddresses of that SGW. © 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. © 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 • o changed, but only when the link is still working) Has multiple mostly static global IP-addresses Disallow NATs on SGW side, but allow them on other end © 2004 SafeNet, Inc. All rights reserved. Simplifications (cont) • Client side (roaming laptop side) o o Allow NAT-T only when not using multihoming 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 o o If the initiator is behind NAT it takes care of recovery Initiator takes all care of recovery always Note Initiator == Client side (roaming laptop) in most of the cases © 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 o 3rd Party Bombing Protection Recovery model • Answers to those will then give answer to some of the other questions © 2004 SafeNet, Inc. All rights reserved.