250 likes | 383 Views
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
E N D
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 • 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
Mobile IPv6 Binding Update Indirect/Triangular Routing Direct Routing (Route Optimization) • 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 CN ↔Mobile via Home 1a: Home Test Init 2a: Home Test (token1) CN ↔Mobile 1b: Care-of Test Init 2b: Care-of Test (token2) Kbm = SHA(token1|token2) 3: Binding Update (MACKbm) 4: Binding ACK (MACKbm) Correspondent Node (CN) Home Mobile Source: Ahmed, et al, 2007 • 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 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 Attacks Amplification • 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 Andre Encarnacao, Greg Bayer
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 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. • 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). 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
Security Property #2 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. • 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) 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] = false end end; Andre Encarnacao, Greg Bayer
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 Andre Encarnacao, Greg Bayer
Rational Reconstruction - Version #1 • 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) • 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
Rational Reconstruction - Version #2 • 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 • 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
Bombing Attack Found • 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 • 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) Andre Encarnacao, Greg Bayer
Redirection Attack Found • 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 • 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) Andre Encarnacao, Greg Bayer
Rational Reconstruction - Version #3 • Addition: home init message • Now the MN sends 2 messages to the CN • Added to prevent the amplification and reflection attacks in version #2 • 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) state Andre Encarnacao, Greg Bayer
Rational Reconstruction - Version #4 • 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 Andre Encarnacao, Greg Bayer
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 Andre Encarnacao, Greg Bayer
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) Hash(public key) Subnet Prefix Interface Id Source: Tuomas Aura, 2003 Greg Bayer, Andre Encarnacao
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 restrictive Greg Bayer, Andre Encarnacao