Mobile IPv6 Binding Update: Return Routability Procedure

Mobile IPv6 Binding Update: Return Routability Procedure

Andre Encarnacao and Greg BayerStanford University

CS 259Winter 2008

Andre Encarnacao, Greg Bayer

Outline

Overview of Return Routability Procedure (RRP) Security Properties

Attacks Murphi Invariants

Rational Reconstruction in Murphi Five incremental versions Notable attacks within each version

Attacks Found against the final version of RRP Description of attacks Consequences of attacks

Possible solutions to attacks Security Tradeoffs


Indirect/Triangular Routing Direct Routing (Route Optimization)

Mobile IPv6 Binding Update

Mobile IPv4 didn’t specify the direct routing optimization Direct routing requires a binding update over a non-secure

channel Need a method to protect the authenticity and integrity of the

binding update sent from Mobile node to Correspondent node Return Routability procedure/protocol


Return Routability Procedure

Authentication without Public Key infrastructure or pre-shared keys Two tokens, two paths: must have both to complete update Difficult for attacker to intercept both tokens & generate valid MAC MAC also protects integrity of plaintext message

Goal: Should be as secure as regular IPv4 (without mobility) Unusual / limited intruder model

CN ↔ Mobile via Home1a: Home Test Init2a: Home Test (token1)CN ↔ Mobile1b: Care-of Test Init2b: Care-of Test (token2)

Kbm = SHA(token1|token2)

3: Binding Update (MACKbm)4: Binding ACK (MACKbm)Source: Ahmed, et al, 2007

Correspondent Node (CN)

Home

Mobile


RRP Security Properties Return Routability Procedure (RRP) - Overview

Ensure authenticity and integrity of Binding Update Authentication without PKI or pre-shared keys Two tokens, two paths: must have both to complete update Difficult for attacker to intercept both tokens & gen valid MAC Goal: Should be as secure as regular IPv4 Unusual / limited intruder model

What if we don’t authenticate binding update? (no RRP) Could be worse than IPv4 Attacks:

Redirection/hijack Bombing Amplification and Reflection

Security properties of RRP are based on preventing these attacks and ensuring the authenticity and integrity of BU


Redirection/hijack attack Attacker C redirects traffic B was sending to A Ex. care-of address = Attacker (B), home address = Target (A) Attacker and Target could be anywhere

Source: Aura 2002


Bombing Attack Bomb an innocent node with unwanted traffic (DoS / DDoS) Attacker requests traffic from B and then redirects it to A Home address is valid. CoA not validated: could be anywhere

Source: Aura 2002


Additional AttacksAmplification Amplify packet flood attack to Mobile Node by factor of two

Reflection Packet source now correspondent and not attacker

State Exhaustion DoS attack against the Correspondent

Replay Attack Replay of Binding Update


Source: Aura 2002

Our Approach We are using Murphi as our analysis tool

Scenarios Considered 1. All nodes are honest - there is an outside attacker 2. Mobile node is dishonest - MN is the attacker

Scenarios Excluded to limit scope 3. Home agent is dishonest 4. Correspondent node is dishonest

Attacker model Remember: Full control of network does not apply due to

assumptions of protocol - ideally, successful attacker must intercept on two paths

Can attacker succeed without intercepting anything? Can attacker succeed by intercepting on one path?

Correspondent Node <--> Mobile Node Correspondent Node <--> Home Agent Home Agent <--> Mobile Node (assumed to be secure)


Security Property #1

invariant “Legitimacy of the final binding known to the CN”forall i: CorrespondentId do

cn[i].state = C_COMMIT ->

cn[i].home = cn[i].coa -- hoa and coa both refer to same node end;


Ensures the legitimacy of the final binding This check is only performed when the correspondent node is in a

COMMIT state, meaning that it has accepted the binding (verified the HMAC).

Once a binding update has completed, the home address and care-of address in the final binding known to the correspondent node must refer to the same node.

Security Property #2


invariant "Intruder does not have access to both keygen tokens, and hence the key of HMAC" forall i: CorrespondentId do

!( ismember(cn[i].coa,IntruderId) & ismember(cn[i].home,IntruderId) ) ->

forall j: IntruderId do int[j].tokens0[i] = false | int[j].tokens1[i] = falseend

end;

If the intruder does so, then the intruder has enough information to figure out the key of the HMAC used in the binding update message. Key of HMAC: Kbm = SHA1 (home token | care-of token)

An intruder may never obtain access to both the care-of and home keygen tokens unless the intruder is acting as an honest mobile node.

Additional Security Properties


Authenticity of MN from CN’s point of view Whenever a CN i completes a session (apparently with some

MN j), then it must be that j has completed a session with i 2 invariants: home address and care-of address of MN

Authenticity of CN from MN’s point of view Whenever a MN i completes a session (apparently with some

CN j), then it must be that j has completed a session with i

Authenticity of home agent (HA) - not checked We assume the HA is honest relative to the MN HA and MN are abstracted as one entity

Other security properties based on possible attacks Amplification and reflection attacks State exhaustion attack Replay attack

Rational Reconstruction - Version #1

Attack: bombing attack without access to any path Found in Murphi: violates legitimacy of binding update, and

authenticity of mobile node’s care-of address invariants

Idea: need to verify that the mobile node is reachable at the specified care-of address


Three messages: Care-of init (with

home address) Home test Binding update

Only one keygen token is conveyed to the mobile node (the home token)


Attacks: bombing or redirection with access to one path Refer to next 2 slides Attacks will still be possible even in the final version!

Attack: reflection and amplification against the mobile node

Idea: use an additional message to prevent reflection/amplification Andre Encarnacao, Greg Bayer

Addition: care-of test message containing the care-of keygen token

Now we have 2 tokens

Added to prevent the notable attack in version #1

Bombing Attack Found


Violates 3 invariants: legitimacy of binding update, secrecy and authenticity of mobile node’s care-of address.

Assumption: intruder can sniff packets in the route between the Correspondent and Target nodes.

Key of HMAC: Kbm = SHA1 (home token | care-of token)

Care-of init uses address of target node and conveys home address of intruder

Home test contains home token

Care-of test contains care-of token

Redirection Attack Found


Violates 3 invariants: legitimacy of binding update, secrecy and authenticity of mobile node’s home address.

Assumption: intruder can sniff packets in the route between the Correspondent node and Home agent.

Key of HMAC: Kbm = SHA1 (home token | care-of token)

Care-of init uses address of intruder and conveys home address of target node

Home test contains home token

Care-of test contains care-of token


Attacks: bombing or redirection with access to one path Same attack as in version #2!

Attack: state exhaustion of correspondent node State = relation between keygen token and address

Idea: correspondent needs to be able generate (and not save) stateAndre Encarnacao, Greg Bayer

Addition: home init message

Now the MN sends 2 messages to the CN

Added to prevent the amplification and reflection attacks in version #2



Addition: Keygen tokens are a function of the corresponding address and an additional nonce used by the CN CN no longer has to save any token-related state and can

use the nonce and address to re-generate token Added to prevent the state exhaustion attack in version #3

Attacks: bombing or redirection with access to one path Same attack as in version #2!

Attack: replay of final binding update message Attack: binding update prevention

Done by spoofing care-of test and/or home test reply messages (without access to any path)

Found in Murphi: violates authenticity of correspondent node invariant

Idea: need to uniquely identify messages to prevent spoofing

Rational Reconstruction - Final Version


Addition #1: Sequence numbers in final binding update message Added to prevent binding update replay attack

Addition #2: Mobile node uses cookies (essentially nonces) to uniquely relate its own init messages to received test messages Added to prevent the binding update prevention DOS attack in

version #4

The attacks that still exist: Bombing or redirection with access to one path

Same attack from version #2 Other binding update prevention attacks still possible

Need access to one or more paths Intercept init message (with cookie) and generated valid

test reply Modify nonce in test messages Prevent final binding update message from going through

Assessment of Attacks #1 Bombing attack

Assumes CN-Target access, which is not noted by protocol (RFC)

Easier to perform (choice of CN)

Damage: Packet flood

DoS DDos

Duration 5 minutes

Greg Bayer, Andre Encarnacao

Assessment of Attacks #2 Redirection / hijack attack

Assumes CN-HA access, which the protocol notes is not safe

Harder to perform Must know of existing MN-CN connection No choice of CN

Other Attacks: Preventing

binding update Fallback to

indirect routing (via HA)


Possible Solution #1 Solution to Bombing Attack

Verification message (with a nonce) to detect DoS attacks

Network congestion blocks message Intruder cannot intercept


Possible Solution #2

Use CGAs & signatures to make spoofing harder CGA contains hash of public key Message includes public key (verified by

comparing with CGA) Message signed with private key Benefits of public-key signatures without

infrastructure Makes redirection/hijack attack more difficult

IPv6 Cryptographically Generated Address (CGA)


Subnet Prefix Interface Id

Hash(public key)

Source: Tuomas Aura, 2003

Security vs. Efficiency

Additional fields and/or messages increase complexity Earlier solution idea – Prof. Mitchell & Arnab Roy 2005

Fix bombing attack by having HA verify CoA Response from primary RRP designer

HA is a router - Extra processing Would always have to check for mobility header Is reduced efficiency acceptable?

Our proposed solutions First idea: Additional messages after existing RRP Second idea: Additional fields and processing

Public Key Infrastructure Limits applicability to where PKI exists


Conclusions Rational reconstruction

Helped us to understand protocol Found two major attacks & other minor attacks

Major Attacks in final protocol Bombing Redirection / hijack

Fix ideas Binding update verification message to

minimize DoS damage CGA to help prevent message spoofing

Security tradeoffs Efficiency concerns / implementation costs Relying on infrastructure too restrictiveGreg Bayer, Andre Encarnacao

Mobile IPv6 Binding Update: Return Routability Procedure

Documents

Transcript of Mobile IPv6 Binding Update: Return Routability Procedure