mobile ipv6 binding update: return routability procedure
DESCRIPTION
Mobile IPv6 Binding Update: Return Routability Procedure. Andre Encarnacao and Greg Bayer Stanford University CS 259 Winter 2008. Andre Encarnacao, Greg Bayer. Outline. Overview of Return Routability Procedure (RRP) Security Properties Attacks Murphi Invariants - PowerPoint PPT PresentationTRANSCRIPT
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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)
Andre Encarnacao, Greg Bayer
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;
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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)
Rational Reconstruction - Version #2
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
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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
Rational Reconstruction - Version #3
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
Rational Reconstruction - Version #4
Andre Encarnacao, Greg Bayer
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
Andre Encarnacao, Greg Bayer
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)
Greg Bayer, Andre Encarnacao
Possible Solution #1 Solution to Bombing Attack
Verification message (with a nonce) to detect DoS attacks
Network congestion blocks message Intruder cannot intercept
Greg Bayer, Andre Encarnacao
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)
Greg Bayer, Andre Encarnacao
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
Greg Bayer, Andre Encarnacao
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