1. 1 Design of the MOBIKE Protocol Editors: T. Kivinen H. Tschofenig

2. 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. 3 Agenda Terminology Simple example (some NAT enhanced) Some individual issues (#18, #6, #15, #11, #19, #20)

4. 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. 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. 6 Reminder: Scope of the MOBIKE work B A Mobility control Policy SEND NUD MOBIKEIKEv2 R1 GPRS phone SGSN BSS GGSN R2 BTIrDA AP1 AP2 PPP IPv4 IPv6 TCP ESP DNA 802.3 802.11 802.21 MOBIKE playground

7. 7 Example Initialize 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) Node B

8. 8 Example Starting the exchange Node A Node B Node A discovers node B somehow. Initial message exchange with IKEv2 already performs connectivity test. Node B returns message where it came from! Initiator Responder IKEv2 Exchange

9. 9 Example Exchanging Peer Address Set (and Preferred Address) Node A Node B 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. Initiator Responder Peer Address Set (A) Peer Address Set (B) Preferred Address (A1) Preferred Address (B1)

10. 10 Example: Node A switches interface (1/2) Node A Node B MOBIKE messages should use A2 instead of A1 as preferred address. Node A needs to tell Node B that the preferred address has changed. Initiator Responder Peer Address Set (A) Preferred Address (A2)

11. 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. 12 Example Interface goes down (A2) Node A detects it Node A Node B MOBIKE messages should use A1 instead of A2 as preferred address. Break-before-make scenario See previous slide Initiator Responder Peer Address Set (A) Preferred Address (A1) B1 A1

13. 13 Example Interface goes down (B1) Node B detects it Node A Node B 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? Initiator Responder Change my preferred address to B2 Peer Address Set (B) B2 A1 B1

14. 14 Individual issues… Starting with Issue #20

15. 15 Selecting addresses for IPsec SAs: inputs My addresses Peer’s addresses My preferences Some limited information about the peer’s preferences Connectivity information –“combining IPv4/IPv6 does not work” –“DPD seems to be failing with ”

16. 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. 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. 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. 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. 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. 21 Issue # 20 - Conclusion Proposal: –“Initiator decides” approach seems simple enough

22. 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. 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. 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. 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. 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. 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 > 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. 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. 29 Backup Slides (on additional NAT handling issues)

30. 30 Example (NAT enhanced) Exchanging Peer Address Set (and Preferred Address) Node A Node B Communicating a peer address set is meaningless with a NAT. Each address needs to be communicated independently and packet header information will be used. Initiator Responder NAT

31. 31 Example Connectivity Tests Node A Node B Purpose of connectivity test: –Determine whether a given address pair offers bi-directional connectivity IKEv2 provides support via the Dead Peer Detection (DPD) mechanism Initiator Responder Continued connectivity test Still ok! NAT

32. 32 Example Interface goes down (B1) Node B detects it Node A Node B 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) Initiator Responder Src IP: B2 Dst IP: A1 Src Port: X Dst Port: Y B2 A1 B1 NAT Binding: Map To NAT

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

34. 34 Example Node A detects a problem in the network Path broken Node A Node B What should Node A do? a) Wait for routers or peer to recover? b) Perform connectivity test on,, ? c) Switch to another address pair Previous resolution: ad a+b) policy issues ad c) Initiator Responder R A1 B1 A2 B2 DPD failure

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

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