360 likes | 373 Views
Design of the MOBIKE Protocol. < draft-ietf-mobike-design-02.txt > Editors: T. Kivinen H. Tschofenig. Acknowledgements. This slide set was prepared by Jari Arkko Pasi Eronen Paul Hoffman Tero Kivinen Hannes Tschofenig
E N D
Design of the MOBIKE Protocol <draft-ietf-mobike-design-02.txt> Editors: T. Kivinen H. Tschofenig
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
Agenda • Terminology • Simple example (some NAT enhanced) • Some individual issues (#18, #6, #15, #11, #19, #20)
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).
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.
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
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)
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!
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.
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.
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)
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
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?
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>”
“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
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
“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
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 (-)
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
Issue # 20 - Conclusion • Proposal: • “Initiator decides” approach seems simple enough
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
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)
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)
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
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)
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.
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.
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
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)
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
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)
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.
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
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.