© 2004 SafeNet, Inc. All rights reserved. Mobike Protocol Design draft-ietf-mobike-design-00.txt Tero Kivinen [email protected]

© 2004 SafeNet, Inc. All rights reserved.

Mobike Protocol Designdraft-ietf-mobike-design-00.txt

Tero [email protected]


Scenarios

• The design draft lists to basic scenarios, where the protocols should work

o Roaming laptop scenarioo 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


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


Multihoming SGW Scenario

• We have the corporate SGW with multiple internet connections (from different ISPs)

o Interfaces are fixedo 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)


Basic Scenario

SGW/B

D

E

NAT

A

A

A

Internet

WLAN

Corporatenetwork


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 issueso Simultaneous movementso IPv4/IPv6


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 Co Do we care if A is the attacker


3rd Party Bombing (cont)

A

B

C

M1A/M3 M2


NATs and MOBIKE

• Related to 3rd party bombing issueo if we want to have full protection against 3rd

party bombings, we cannot work with NATso If we only want to use limited or partial

protection then we can work through NATso 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


NAT and MOBIKE (cont)

• Problems with multihoming and NATo 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.


NAT-T and MOBIKE Options

• 1: Always use NAT-To No multihoming in servero No protection against 3rd party bombing

• 2: NAT-T and MOBIKE are separateo If you move to NAT-T, just create new IKE SA

which uses NAT-To Mobike will have the active attack detector,

which notices that there is NAT between.

• 3: NAT-T and MOBIKE are combinedo Modify NAT-T and/or create combination using

NAT-T and MOBIKE.


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 bombingo 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


Recovery from Problems

• Which problems we try to recovero 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


Recovery from Problems (cont)

• Minor issues related to thiso Testing of all possible paths between hosts?o Which end starts recovery?o Do we need to know all addresses from other

end?


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.


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.


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.


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-addresseso Disallow NATs on SGW side, but allow them on

other end


Simplifications (cont)

• Client side (roaming laptop side)o Allow NAT-T only when not using multihomingo 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).

• Recoveryo If the initiator is behind NAT it takes care of

recoveryo Initiator takes all care of recovery alwayso Note Initiator == Client side (roaming laptop) in

most of the cases


Summary

• There are some questions we need to answer before we can really even start designing the protocol.

o 3rd Party Bombing Protectiono Recovery model

• Answers to those will then give answer to some of the other questions

Documents

© 2004 SafeNet, Inc. All rights reserved. Mobike Protocol Design draft-ietf-mobike-design-00.txt Tero Kivinen [email protected]