Design of the MOBIKE Protocol

1
Design of the MOBIKE Protocol

• ltdraft-ietf-mobike-design-02.txtgt
• Editors
• T. Kivinen
• H. Tschofenig

2
Acknowledgements

• This slide set was prepared by
• Jari Arkko
• Pasi Eronen
• Paul Hoffman
• Tero Kivinen
• Hannes Tschofenig
• based on the discussions on the mailing list and
  the issues captured in the issue list.
• The MOBIKE issue list can be found at
• http//www.vpnc.org/ietf-mobike/issues.html

3
Agenda

• Terminology
• Simple example (some NAT enhanced)
• Some individual issues
• (18, 6, 15, 11, 19, 20)

4
Terminology (1/2)

• Peer Address Set
• A peer address set is a subset of locally
  operational addresses of a peer. A policy
  available at peer A indicates which addresses to
  include in the peer address set. Such a policy
  might be impacted by manual configuration or by
  interaction with other protocols that indicate
  new available addresses.
• Preferred Address
• An address on which a peer prefers to receive
  MOBIKE messages and IPsec protected data traffic.
  
• A given peer has only one active preferred
  address at a given point in time (ignoring the
  small time period where it needs to switch from
  the old preferred address to a new preferred
  address).

5
Terminology (2/2)

• Primary Path
• The primary path is the destination and
  source address that will be put into a packet
  outbound to the peer by default.
• Path
• The route taken by the MOBIKE and/or IPsec
  packets sent via the IP address of one peer to a
  specific destination address of the other peer.
• These two terms have to be seen as the path
  taken by packets through the network by the
  choice of a certain address pair.

6
Reminder Scope of the MOBIKE work
A
MOBIKE
IKEv2
Mobility control
Policy
802.21
B
SEND
802.11
NUD
DNA
802.3
IPv4
ESP
PPP
BT
IrDA
TCP
IPv6
MOBIKE playground
7
ExampleInitialize
Node B
Node A

• Node A and Node B have two interfaces.
• Local configuration at the MOBIKE daemon
  indicates that both addresses may be used (peer
  address set)

8
ExampleStarting the exchange
Responder
IKEv2 Exchange
Initiator
Node B
Node A

• Node A discovers node B somehow.
• Initial message exchange with IKEv2 already
  performs connectivity test.
• Node B returns message where it came from!

9
ExampleExchanging Peer Address Set (and
Preferred Address)
Responder
Peer Address Set (A) Peer Address Set
(B) Preferred Address (A1) Preferred Address (B1)
Initiator
Node B
Node A

• The preferred address will in this initial
  exchange be equal to the currently used address.
• Preferred address of Node A and Node B is already
  in use with the IKEv2 messages.

10
Example Node A switches interface (1/2)
Responder
Initiator
Peer Address Set (A) Preferred Address (A2)
Node B
Node A

• MOBIKE messages should use A2 instead of A1 as
  preferred address.
• Node A needs to tell Node B that the preferred
  address has changed.

11
Example Node A switches interface (2/2)

• Peer address set is still the same.
• Communicated information might be diff-list or
  full list.
• Actions
• Authorize new address (if not done already)
• Connectivity check (if not done already)

12
ExampleInterface goes down (A2)Node A detects it
Responder
B1
Initiator
Peer Address Set (A) Preferred Address (A1)
A1
Node B
Node A

• MOBIKE messages should use A1 instead of A2 as
  preferred address.
• Break-before-make scenario
• See previous slide

13
ExampleInterface goes down (B1)Node B detects it
B1
Responder
B2
Initiator
Change my preferred address to B2 Peer Address
Set (B)
A1
Node B
Node A

• Node A should address MOBIKE messages to B2
  instead of B1.
• How to recover
• a) Should Node B send a message to Node A?
• b) Should Node A determine the problem?

14
Individual issues Starting with Issue 20
15
Selecting addresses for IPsec SAs inputs

• My addresses
• Peers addresses
• My preferences
• Some limited information about thepeers
  preferences
• Connectivity information
• combining IPv4/IPv6 does not work
• DPD seems to be failing with ltA1,B3gt

16
Option 1 Independent decisions

• We send our addresses to the peer (and vice
  versa)
• Limited amount of preferences implied by the
  order of the list
• Both parties can have connectivity information
• Both parties make the decision independently

17
Option 1 pros and cons

• Works ()
• Handling partial connectivity and failures in the
  middle is clear ()
• Address lists dont change, both parties
  determine connectivity on their own and move
  traffic
• Both parties are equally complex (-)
• No guarantee that upstream and downstream
  traffic uses same addresses (-)
• The only way Host A can move all traffic to some
  interface is to delete all other addresses

18
Option 3 Initiator decides

• The responder sends its addresses to the
  initiator
• Again, preferences implied by the order
• Initiator handles partial connectivity and
  failures in the middle
• Initiator selects which addresses are used and
  tells the responder
• Responder simply reverses src/dst

19
Option 3 pros and cons

• Making decisions in the client sensible for
  mobility cases ()
• Simple for VPN gateway ()
• If the initiator wants, same address pair used in
  both directions this makes it possible to work
  with stateful filters and NATs ()
• Less elegant perhaps (-)

20
Other options

• Other options seem to
• Have most of the cons from 1
• Or have big difficulties in taking connectivity
  information into account (option 2)
• Or both (option 4)
• Both options 2 and 4 have big missing pieces that
  need to be defined

21
Issue 20 - Conclusion

• Proposal
• Initiator decides approach seems simple enough

22
Return Routability Tests (6, 15, 18)

• Goal protect against 3rd party bombing attacks
• Outsiders cause our IPsec stream to be directed
  towards a victim
• Unreliable peer (virus etc) directs the stream
• Note Bad nodes can always send packets to
  victims, the only question is how much
  amplification we give to them
• Primary defense is probing (testing) an address
• Also known as return routability test
• The main issue is when and how

23
Issues 18 6 15 -- The Dimensions

• Do any tests at all? (18) -- open
• When to do tests? (6) -- open
• What kind of tests? (15) -- decided (cookie
  based)

24
Issue 18 -- Do any tests at all?

• Alternatives
• Never
• Mandatory
• Configuration and/or situation
• Proposal -- party that is being tested
• MUST always respond
• Proposal -- party that is doing the test
• IF new address is in certificate, no test needed
• OTHERWISE do it if configuration tells you to.
  Default is on. (Could also be done if attack is
  suspected, but hard to define this)

25
Issue 6 -- When to do tests?

• Alternatives
• Before starting to use the new addresses
• After starting to use the new addresses
• Tradeoffs relate to level of protection about
  redirection attacks vs. latency
• Does not affect latency if old address is still
  operational
• Research schemes exist to decrease latency
• Proposal Test before starting to use the address
• Can be done if suspect a problem, as in DPD

26
Issue 15 -- What kind of tests?

• A regular DPD-like exchange
• Legitimate, but compromised peer can predict
  request and respond even if not at that address
• DPD-like exchange cookie
• Does not have the above problem
• Authentication of addresses
• Can detected an en-route modification of an
  address ( NAT or attacker)
• Already decided Use cookies (and NAT-T payloads
  to detect NATs)

27
Issue 11 Window Size Problem

• IKEv2 has a window size of 1 before starting a
  new exchange you need to finish an exchange in
  progress.
• Example
• Performing multiple DPD exchanges for multiple
  address pairs would
• Should MOBIKE support a window size gt 1?
• We cannot live with window size 1
• Enhance window size
• Use a new message exchange (that allows a larger
  window to be used)

28
Issue 19 Same or different addresses for IPsec
SA pairs

• Should the IPsec traffic in both directions
  should use the same pair of addresses?
• Discussion
• With the initiator decides approach the
  initiator can decide to use different pairs of
  addresses.
• In most cases the same address pair will be used.
• Problems with NATs and stateful packet filter
  firewalls
• Proposal
• Always the same pair of addresses
• Future extension can change it.

29
Backup Slides (on additional NAT handling issues)
30
Example (NAT enhanced)Exchanging Peer Address
Set (and Preferred Address)
Responder
Initiator
NAT
Node B
Node A

• Communicating a peer address set is meaningless
  with a NAT.
• Each address needs to be communicated
  independently and packet header information will
  be used.

31
ExampleConnectivity Tests
Responder
Continued connectivity test
Initiator
Node B
NAT
Still ok!
Node A

• Purpose of connectivity test
• Determine whether a given address pair offers
  bi-directional connectivity
• IKEv2 provides support via the Dead Peer
  Detection (DPD) mechanism

32
Example Interface goes down (B1)Node B detects
it
B1
NAT Binding Map ltNAT-IP,port Y,B1,port Xgt To
ltA1,port Z,B1,port Xgt
Responder
B2
Initiator
NAT
Src IP B2 Dst IP A1 Src Port X Dst Port Y
A1
Node B
Node A

• Node B would use a new source address (B2) for
  the packet sent to Node A at A1 or A2.
• Packet will be blocked at the NAT (for certain
  NAT types and for stateful packet filtering
  firewalls)

33
Example Interface goes down (B1)Node B detects
it

• It is not possible for a responder that moves
  (and is behind a restrictive NAT)
• Conditions to make it work
• Node A performs connectivity tests on the other
  paths (e.g., ltA1,B2gt)
• Binding will exist in order to allow packets from
  Node B at other addresses to reach Node A

34
ExampleNode A detects a problem in the
networkPath ltA1,B1gt broken
Responder
Initiator
B1
DPD failure
R
A1
B2
A2
Node B
Node A

• What should Node A do?
• a) Wait for routers or peer to recover?
• b) Perform connectivity test on ltA2,B2gt, ltA1,B2gt,
  ltA1,B2gt?
• c) Switch to another address pair
• Previous resolution
• ad ab) policy issues
• ad c)

35
ExampleNode A detects a problem in the
networkPath ltA1,B1gt broken
Responder
Initiator
B1
DPD failure
R
A1
B2
A2
Connectivity Test ltA2,B2gt
Node B
Node A
Peer Address Set (A) Preferred Address (A2)

• Recovery attempt
• Node A tries connectivity test with ltA2,B2gt.
• Node B replies.
• Node A and Node B might test connectivity of
  other paths as well.
• Node A decides that switching the preferred
  address to A2 is useful.

36
NAT Issues (1/2)

• NAT support is needed for MOBIKE - Details are
  missing
• Should we have a NAT-prevention feature?
• Suggestion Yes.
• Enabling UDP encapsulation should be policy
• Enabling NAT-T depends on interface, the
  scenario, situation and some other policy
  decisions
• Support for NAT detection over each address pair

37
NAT Issues (2/2)

• Send keepalives on every alternative path or just
  on the primary path (implications if only on the
  current path, only the node that is behind a NAT
  can recover from problems)
• Should we support these scenarios
• Initiator movement from a not-NAT to a NAT and
• Initiator movement from a NAT to a non-NAT
• Suggestion Support them.
• Do we allow Responders to be behind NATs (not
  NAPT)?
• Suggestion Follow approach of IKEv2 an allow
  Responder to be behind a NAT.