Minutes for MPTCP at IETF-interim-2010-mptcp-1
minutes-interim-2010-mptcp-1-00

MPTCP interim meeting / 12.14.2010  16:00 - 17:50 GMT
-----------------------------------------------------

Chairs: Philip Eardley, Yoshifumi Nishida

Notetakes: Costin Raiciu, John Leslie 

--------------------------------------------------------------------
Slide P4: Scope

Mark Handely: 
    Perhaps we could solve on subsequent subfolws not as said on the slide

Alan Ford: 
    You're quite right, but not worth getting bogged down

Phil Eardely: 
    Any more comment on these high-level goals?

Olivier Bonaventure: 
    We should have precise definition of capabilities we assume.
    Otherwise, we won't understand what our system is secure against.
Alan: 
    this related to your email on thursday, relating to blind and listen + spoof attackers
    also time-shifted attacks within inject

Marcelo Bagnulo:
    we should also consider a post attack detection capability.
    this is where some solutions differ. It allows original parties to detect the 
    attack took place or not. maybe the attacker in the initial connection set 
    can introduce new locators that if the original parties can detectors. 
    this is another dimension worth considering.

Olivier: 
    detection is important. What do we need to detect? When? 

Marcelo: 
    suppose a mitm changes the crypto material. To remain undetected he must remain online 
    and change everything. if the original parties can talk directly they can easily realize 
    there was a problem.

Alan: 
    difference btw an attacker and a misdirected packet? where a shared address behind nat

MMarcelo: 
    suppose you want to attack by hash-change, if original parties talk privately, they can 
    detect hash-change

Marcelo: 
    attack a hash chain; need to replace the hash chain completely - 
    they can realize there was an attack. If you use a token only, you cannot tell 
    there was an attack. 

Mark: 
    if packets reach host unchanged, different from MITM... but also consider DoS blocking 
    real packets while injecting own packets

Marcelo: 
    we can protect against most things we can imagine, but at what complexity cost.
    is it worth the trouble?

Olivier: 
    IMHO must be secure against blind attackers, if we can do no more than that, 
    we need to say so clearly

Mark: 
    TLS on top. should be able to use in all environments where you'd use plain TCP, 
    otherwise you can't turn on by default

Mark: 
    what is the difference btw the passive + spoof attacker and the mitm?
    not so big with a dos you can prevent the source to receive. 

Olivier: 
    in practice there may be a difference

Marcelo: 
    not really, not convinced

Olivier: 
    mptcp must be secure against blind at least; not necesarily that need to do more.

Mark: 
   it's not reasonable to use tls on top. You should be able to use with high confidence 
   in the same environments you could use tcp. 

Olivier: 
   we don't have such a solution yet

--------------------------------------------------------------
Slide P10:  current (-02) proposal

Marcelo: 
   in the join in the -02 proposal you use 4 packets; mh proposed a way to reduce this 
   to three packets.

Alan: 
   it is possible, yes.

Marcelo: 
   it's desirable to have three-way handshake

Alan: 
   would have to consider option space, but it is feasible

--------------------------------------------------------------
Slide P11: First Question

Alan: 
   what does HMAC add anything? is this significant improvement? 
   we still have sequence-number gleaning issue.

Mark: 
   depends on your usage modes: if we postulate initial setup over 3G + many wifis, 
   it could add a lot

Marcelo: 
   significant reduction in window of vulnerability. also, quite cheap.

Andrew Macdonald:
   agree with marcelo it reduces time and space of vulnerability

Alan: 
   any other opinions? we agree this is adding something


-------------------------------
Slide P12: Hash Chains Proposal

Alan: 
   should mean we no longer have initial vulnerability, but introduces other issues

Marcelo: 
   don't understand, you can't solve MITH of initial setup only solves for passive attackers: 
   active attackers aren't solved

Alan: 
   this one protects against active attackers on subsequents. but of course MITM is still 
   impossible to protect

Alan: 
   non-reversible hash, sender declares previous value in chain, receiver can verify H[n] 
   is the successor of H[n-1]. meaningless to any passive listeners

----------------------------------------------
Slide P15: Hash Chains #2 

Marcelo: 
   not sure I agree... NAT-compatible requires ability to change address.
   protecting against address change breaks NAT compatibility... 
   an attacker will be able to put any address he wants...

Alan: 
   agree he could put whatever address he wants in SYN and/or SYN/ACK; 
   but the ACK has to get back

Marcelo: 
   you cannot prevent time-shifted attack by active listener

Alan: 
   he can pass the packets, but can't move the connection elsewhere; but he must remain on path

Marcelo: 
   suppose I'm on path and see new subflow

Alan: 
   yes, you can bounce packets somewhere else. but I don't believe we're trying to protect 
   against that. only thing you could do would require including HMAC? on all subsequent packets

Mark: 
   he can't move the connection elsewhere

Marcelo:
   he can change the source address

Mark:
   he needs to remain on path

Marcelo:
   only during the control info setup

Mark: 
   how can he leave

Marcelo:
   suppose i am on path. i change the source address of the new subflow being established. 

Costin Raiciu: 
   we're doing our best to protect control information, but data is still vulnerable. 
   no point in this much complexity unless we can add protection to data; HMAC does help us 
   in the wifi case; why wouldn't we use something like this to encrypt?

Marcelo: 
   hash-chain allows detection of attack; with HMAC he can replace hash-chain

Andrew: 
   that's rather limited

Alan: 
   it is impossible to tell the difference in practice - can we reliably detect an attack?

Marcelo: 
   significant additional complexity. cannot protect completely

Mark: 
   how do you handle other cases. can you re-use hash-chains

Marcelo: 
   what happens if you run out of hashes

Mark: 
   in case of race condition what does a receiver do with JOINS using same hash?

Andrew: 
   yes you only do one subflow at a time. 

Olivier: 
   christoph's proposal may be interesting to consider

Marcelo
   there are solutions that can give you additional security only in some scenarios. 
   For instance: use initial subflow to check subflow setup. 

Olivier: 
   we need a formal description of the attacker capabilities. 
   how do we deal with functional constraints?

Costin: 
   we need to also think about the constraints of mptcp and the attacker capabilities. 
   E.g. break before make & christoph's proposal, nats & active attackers

Mark: 
   in ipv6 we could increase security

Marcelo 
   in ipv6 solution space is completely different; much better solutions. e.g. CGAs

Mark: 
   can we do different solutions for v4 and v6? will the iesg allow that?

Marcelo: 
   it should. that's what mip does.

Mark: 
   we're at transport level, not IP layer... also we could see single TCP running 
   both v4 and v6 paths

Marcelo: 
   this should be acceptable to IESG as this is also what SCTP does. they also requested 
   that we can code keys for better security. but we are discussing here just the default 
   worst case

Yoshifumi Nishida: 
   I'm not in favor of using hash in SYN.

Alan: 
   at the moment hostB would have to calculate immediately at SYN. 
   This is an open issue how we might delay that.

------------------------------------------------------------
slide: P19 What other solutions are there?

Alan: 
   charter says "basic security". we don't want "perfect" solution, but should be 
   sufficiently agile to insert better solutions later

Mark: 
   attacker can race, on response can spoof a MP_VERIFY (after spoofing SYN/ACK)

Alan: 
   sounds plausible, if that is the case MP_VERIFY is no more secure, would mean 
   we don't have a solution

Mark: 
   what about the combined hmac + hash chains?

Andrew: 
   amount of information you have to carry on initial SYN/ACK

Alan: 
   a lot of complexity, a few holes remain

Costin: 
   what about diffie hellman? how much more do we get compared to hmac? 

Alan: 
   still vulnerable to race attack

Mark: 
   not vulnerable, but how to protect ?

Alan: 
   computationally expensive

Costin: 
   same security as HMAC except requires active attackers 

Alan: 
   let's phrase it differently, does HMAC meet our needs

Marcelo: 
   need to support alternatives (e.g. IPv6, encryption) as upgrades

Andrew: 
   there are other ways available, this gives basic working point.
   another benefit, SYN-cookie easier to imagine

Marcelo: 
   how much is left on other protocol issues?

Alan: 
   not much. we need to design-in algorithm-agility, rest is fairly solid.

Marcelo: 
   let's decide on something, not worth delaying protocol spec

Alan:
   security area not terribly impressed. but nobody said something was broken. 

Marcelo: 
   I don't see a problem with security area

Phil: 
   does anyone want to speak against "emerging consensus"

Alan: 
   this should be the baseline; agility is key for future extensions.

Marcelo: 
   completely agree with that. Ask IESG whether we should also work on an additional mechanism. 

Phil: 
   capture consensus, get it on the list, and make sure there is agreement on the list. 
   We should still be on track to finish by march. Will ask for extension to charter 
   to do stronger security, if deemed necessary.
   It'd be worth trying to summarize this in a page or two, why we arrived at this conclusion.

Marcelo: 
   The security director will review the threats ID. we will know before this hits the 
   security director. 

Phil: 
   it would be great if this document reached the security director and security working group.

Marcelo: 
   let me know if something is missing from threats draft

Olivier: 
   implementation issue: not reasonable to assume unlimited subflows.indication of limit 
   to number of subflows. should be part of protocol so that endpoint can simply reject 
   subflow requests

Costin: 
   what's the point instead of just refusing extra SYNs?

Olivier: 
   e.g. initial 3G, second SYN over wifi, then reject any others (unless something closes); 
   this would require attacker capable of listening on both media. option to signal the limit.

Costin: 
   if you assume unlimited subflows, vulnerabilities increase. who decides? 
   can simply drop the SYN unless there's a benefit from the other end knowing

Phil: that needs more discussion on the list