1 / 20

Mobike Protocol Design draft-ietf-mobike-design-00.txt Tero Kivinen kivinen@safenet-inc

Mobike Protocol Design draft-ietf-mobike-design-00.txt Tero Kivinen kivinen@safenet-inc.com. Scenarios. The design draft lists to basic scenarios, where the protocols should work Roaming laptop scenario Multihoming SGW scenario

zuzana
Download Presentation

Mobike Protocol Design draft-ietf-mobike-design-00.txt Tero Kivinen kivinen@safenet-inc

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Scenarios • The design draft lists to basic scenarios, where the protocols should work • 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

  3. Roaming Laptop Scenario • We have a roaming laptop with multiple connections to internet • 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. Multihoming SGW Scenario • We have the corporate SGW with multiple internet connections (from different ISPs) • 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)

  5. Internet Basic Scenario WLAN A D A SGW/B E NAT Corporate network A

  6. 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 • Simultaneous movements • IPv4/IPv6

  7. 3rd Party Bombing • How much protection we offer against 3rd party bombing • 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 IP-addresses, 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 • Do we care if A is the attacker

  8. 3rd Party Bombing (cont) C A M2 M1 A/M3 B

  9. NATs and MOBIKE • Related to 3rd party bombing issue • 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

  10. NAT and MOBIKE (cont) • Problems with multihoming and NAT • 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 • 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. NAT-T and MOBIKE Options • 1: Always use NAT-T • No multihoming in server • No protection against 3rd party bombing • 2: NAT-T and MOBIKE are separate • 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 • Modify NAT-T and/or create combination using NAT-T and MOBIKE.

  12. Combined NAT-T and MOBIKE • With combined NAT-T and MOBIKE protocol we have some more questions: • Do we only allow NAT to appear only when IP-address 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 • 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

  13. Recovery from Problems • Which problems we try to recover • 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

  14. Recovery from Problems (cont) • Minor issues related to this • Testing of all possible paths between hosts? • Which end starts recovery? • Do we need to know all addresses from other end?

  15. 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. • Those IKE SAs can be created at the same time, perhaps using the same authentication information.

  16. 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). • The SGW will have fixed quite static set of IP-addresses, thus roaming host can know the IP-addresses of that SGW.

  17. 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. Simplifications • SGW side: • 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 • Disallow NATs on SGW side, but allow them on other end

  19. Simplifications (cont) • Client side (roaming laptop side) • 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 • 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

  20. Summary • There are some questions we need to answer before we can really even start designing the protocol. • 3rd Party Bombing Protection • Recovery model • Answers to those will then give answer to some of the other questions

More Related