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

Reminder: Scope of the MOBIKE work

B

A

Mobility control

Policy

SEND

NUD

MOBIKE IKEv2

R1

GPRSphone

SGSN

BSS

GGSNR2

BT IrDA

AP1

AP2

PPPIPv4

IPv6TCP

ESP

DNA 802.3

802.11

802.21

MOBIKE

playground

7

ExampleInitialize

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

ExampleStarting 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

ExampleExchanging 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

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

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

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

ExampleInterface 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

Individual issues… Starting with Issue #20

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

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

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)

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

ExampleConnectivity 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

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: B2Dst IP: A1Src Port: XDst Port: Y

B2

A1

B1NAT Binding:Map <NAT-IP,port Y,B1,port X> To <A1,port Z,B1,port X>

NAT

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., <A1,B2>)

– 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 <A1,B1> broken

Node ANode B

• 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)

InitiatorResponder

RA1B1

A2B2

DPD failure

35

ExampleNode A detects a problem in the networkPath <A1,B1> broken

Node ANode B

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

InitiatorResponder

RA1

B1

A2B2

Connectivity Test <A2,B2>

Peer Address Set (A)Preferred Address (A2)

DPD failure

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-NATSuggestion: 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.