230 likes | 327 Views
MPTCP threat analysis: an update. marcelo bagnulo IETF77 – MPTCP WG. Scope: Types of attackers. On-path vs. Off-path On-path attackers Full time on the path Passive (man on the side) Active: Blocking packets Changing packets. Scenario. IDB LB1,…, LBn. IDA LA1,…, LAn. IDX
E N D
MPTCP threat analysis:an update marcelo bagnulo IETF77 – MPTCP WG
Scope: Types of attackers • On-path vs. Off-path • On-path attackers • Full time on the path • Passive (man on the side) • Active: • Blocking packets • Changing packets
Scenario IDB LB1,…, LBn IDA LA1,…, LAn IDX LX1,…, LXn
Scenario IDB LB1,…, LBn IDA LA1,…, LAn IDA LA1,…, LAn IDB LB1,…, LBn IDX LX1,…, LXn
Redirection attacks IDB LB1,…, LBn IDA LA1,…, LAn IDA LA1,…, LAn IDB LB1,…, LBn IDX LX1,…, LXn
Flooding IDX LX1,…, LXn IDA LA1,…, LAn IDX LX1,…, LXn
Flooding IDX LX1,…LAi,…, LXn IDA LA1,…, LAn IDX LX1,…, LXn
Flooding IDX LX1,…LAi,…, LXn IDA LA1,…, LAn IDX LX1,…, LXn
Flooding and MPTCP • If MPTCP performs a 3-wayhandshakepernewflowandtheyidentifytheconnection • Thisprovidesthereachability check requiredtopreventfloodingattacks • Itisveryimportantto NOT send data without a prior reachability check
Connection Hijacking IDB LB1,…, LBn IDA LA1,…, LAn IDA LA1,…,…, LAn IDB LB1,…, LBn IDX LX1,…, LXn
Connection Hijacking IDB LB1,…, LBn IDA LA1,…, LAn IDA LA1,…,LXi,…, LAn IDB LB1,…, LBn IDX LX1,…, LXn
Connection Hijacking IDB LB1,…, LBn IDA LA1,…, LAn IDA LA1,…,LXi,…, LAn IDX LX1,…, LXn
Additional Threat • In current TCP, an on-path attacker can launch a hijacking attack, but an off-path attacker can’t. • So, MPTCP security must prevent off path atackers to perform hijacking attacks
Hijacking and MPTCP with cookie based security • MPTCP can use a combination of seq# and cookie for security. (as in draft-ford-mptcp-multiaddressed) • By Seq# i refer to the data seq# (not the one per flow, but the one of the data) • They are both exchanged in the first 3 way exchange, when the ULID pair is defined for the connection. • So what residual hijacking attacks can be performed with this protection?
Time-shifted/future attacks • A time-shiftedattackisanattackwhere: • Theattackerison-pathduring a periodof time andobtainsinformation (e.g. The cookie andtheseq#) or even installsstateifneeded. • Thentheattackerleavestheonpathlocation • Theattakcscontinues even aftertheattackerlefttheonpathposition • Current TCP isnot vulnerable to time-shiftedattacks • i.e. Whentheattackerleavestheposition, it no longerreceivesthepacketsofthe TCP connection
Time shifted attack in MPTCP IDB LB1,…, LBn IDA LA1,…, LAn Attacker on path learns cookie and seq# IDA LA1,…, LAn IDB LB1,…, LBn Any side initiates the connection
Time shifted attack in MPTCP Attacker leaves the location to a more comfortable one and adds new flow IDB LB1,…, LBn IDA LA1,…, LAn IDA LA1,…,LXi,…, LAn IDB LB1,…, LBn IDX LX1,…, LXn
Taxonomy of time shofted attacks • Type of attacker: Passive vs. Active • Vulnerability window to take over: • Only the initial handshake • Every subflow addition handshake • Integrity attacks • Replay attacks • Detectable vs. Undetactable attacks
Cookie based solution • Type of attacker: Passive • Vulnerability window to take over: both the initial and the every next subflow • Vulnerable to Integrity attacks • Vulnerable to Replay attacks • Undetactable attacks
Plain text key exchange + keyed HMAC • Type of attacker: Passive • Vulnerability window to take over: Only the initial handshake • Vulnerable to Integrity attacks • Vulnerable to Replay attacks • Undetactable attacks
Leap of faith/ssh type of security • Type of attacker: Active • Vulnerability window to take over: Only the initial handshake • Vulnerable to Integrity attacks • Replay attacks: possible to protect • Detectable attacks
NAT considerations • NAT compatibility implies that the endpoints do not know the IP address pair, which is exactly what we need to protect • Implies that integrity protection is very hard to achieve
Next steps • It would be possible to craft a solution with different pieces that mitigates most of the threats?