Design of the MOBIKE Protocol

1. Design of the MOBIKE Protocol <draft-ietf-mobike-design-02.txt> 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. GPRSphone AP2 AP1 R2 GGSN BSS SGSN R1 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 TCP BT IrDA 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 • Peer’s addresses • My preferences • Some limited information about thepeer’s preferences • Connectivity information • “combining IPv4/IPv6 does not work” • “DPD seems to be failing with <A1,B3>”

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 don’t 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 # 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 > 1? • We cannot live with window size 1: • Enhance window size • Use a new message exchange (that allows a larger window to be used)

27. 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.

28. Backup Slides (on additional NAT handling issues)

29. 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.

30. 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

31. Example Interface goes down (B1)Node B detects it B1 NAT Binding: Map <NAT-IP,port Y,B1,port X> To <A1,port Z,B1,port X> 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)

32. 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., <A1,B2>) • Binding will exist in order to allow packets from Node B at other addresses to reach Node A

33. ExampleNode A detects a problem in the networkPath <A1,B1> broken Responder Initiator DPD failure B1 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 <A2,B2>, <A1,B2>, <A1,B2>? c) Switch to another address pair • Previous resolution: ad a+b) policy issues ad c)

34. ExampleNode A detects a problem in the networkPath <A1,B1> broken Responder Initiator DPD failure B1 R A1 B2 A2 Connectivity Test <A2,B2> Node B Node A Peer Address Set (A) Preferred Address (A2) • Recovery attempt: • Node A tries connectivity test with <A2,B2>. • 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.

35. 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

36. 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.