PPT Version

advertisement
Mobike Protocol Design
draft-ietf-mobike-design-00.txt
Tero Kivinen
kivinen@safenet-inc.com
© 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.
Download