Multipath TCP (MPTCP)
          
Date : Thursday October 3, 2013, 15:00-17:00 GMT
Note Taker: John Ronan
Attendees:
  Alan Ford, Ed Lopez, Marcelo Bagnulo, Mark Handley, Olivier Bonaventure, Yoshifumi Nishida, John Leslie, 
  John Ronan, Costin Raiciu, Christoph Paasch, Gregory Detal, Benjamin Hesmans, Philip Eardley

-------------------------------------------------------------------------------------------------------------------
Phil: 
   introduced meeting. 
   See slides on wiki.

Marcelo:
   Having two track for this.   
   Solving ADD-ADDR should be enough for Stds track, as this is similar to since path TCP.
   Also it is exactly same as SCTP security level with dynamic addresses, which is Another 
   stds track documents. 
   In parallel, we should explore more secure version. Several approach are possible.
   But, should not stop/delay Stds track discussion.

Alan, Phil, Mark: 
   support approach

Mark: 
   as long as doesn't cause backwards compatibility issues later.
   Proposal to have MPTCP signal to other end increased security

Marcelo:
   One problem I envision is negotiation. Attacker might lower security parameter during negotiation.
   This usually is dealt by policy. Don't allow lower security if necessary.

Mark:
   Not very sure if it's policy question.
   If we cannot do it without the current spec, we should fix the spec now. Not later.

Marcelo:
   Agree. We should add one additional option in SYN to indicate more secure feature.

Mark: 
   What we should now is to sort out how we signal it.
   We should have an WG item as prong 1.

Marcelo:
   I agree.

Costin:
   Another way to think about this is to use something like TLS. 
   If we use TLS, we might not need something in SYN. We can get key from TLS.

Mark:
   If you use TLS, you will need to disable opening subflow feature in SYN.
   You need to stop MPTCP layer to open subflow until upper layer security negotiation has done.

Marcelo: 
   My question is negotiation needs to be more than just an option. 

Mark: 
   There is timing question when to open subflow. 
   if we don't negotiate, both ends will be configured not to open subflow. 
   How do we know when we are allowed to send the add_addr message? 
   Is this in prong one? It's not clear

Marcelo: 
   We'll add an option in SYN to indicate ���what the flavor osecurity in this session.
   If it is not there, then it will be what we have now. If there is an option, then
   it will be new security. Does this work?
 
Costin: 
   Do we have some bits in MP_CAPABLE for security mechanism?

Alan: 
   Yes. We have 4-5 spare bits for the purposes of negotiating 
   encryption algorithms.

Costin: 
   Question is We need more than 1 bit for this.
   Do we want to use a bit for this, or wait until a point in time.

Alan: 
   Sounds like one bit feature. binary, on or off... 

Mark:
   We might need 'do not set up subflows yet' bit.

Costin:
   I think I need to think about it.

Mark: 
   if we need to change the default behaviour with an extension, we should get it 
   in as early as possible, even if it takes a few more years to come up with 
   a stronger solution.

Philip: 
   Is it fair to say that there is general agreement how to prevent this add_addr attack

Marcelo: 
   I was convinced by Oliver's argument. Why we use should HMAC.
   That would be belong to prong 2.

Mark: 
   It seems sufficient. you'll also consider compatability issue.

Phil:
   What is compatibility issue?

Mark: 
   if we use Hmac in mp_join, we change its semantics

Yohifumi: 
   I would like to know What should be done in prong 1 and prong 2.

Marcelo
   Prong 1: update current spec, include hmac in add_addr. possibly update the
   spec to the attack discussed is dealt with in the way mark suggested.
   Eventually, we will understand if we need more to add compatability with 
   what we do in prong2 

Mark:
   We don't HMAC in MP_JOIN?

Marcelo:
   No. Nice thing If we get more secure key in the future. 
   having used hmac in add_addr as well as mp_join means we can improve security 
   of both similtaneously

Mark:
   OK. I see.

Yoshi: 
   We'll need to think about upgradable security mechanism in prong 1.

Marcelo:
   Yes.

Phil (summary):
   Prong 1: Solve the add_addr attack by securing with hmac, think a bit more about 
   compatability to add negotiation, to handle elegantly better security 
   when its added in (prong 2).

Phil: 
   propose to discuss prong2. Invites Marcelo to discuss it

Marcelo:
   We have 2 choises.
   1. Secure the signalling only
   2. Secure both signalling and data
   After discussion last week with group and it isn't clear if we can secure only control packets.
   Unclear whether it is worth benefits not worth the trouble,

   If both are encrypted, then only a DoS is really left as a possible attack.
   Solution space is much smaller, looks close to ssl or tcpcrypt.
   First decision will be to either secure the signalling or both signalling and payload

Mark: 
   If we secure signalling based on SSL, then payleoad is already secured from payload insertion.

Marcelo: 
   My question is how relevant to secure signals. What are the threats? 

Mark:
   Question is it would be potentially more open to DoS attack. I'm not sure what it would like.

Marcelo: 
   I don't know the answer. 
   The other point is in my feeling, majority of traffic is not SSL.
   If we can have a solution like tcpcrypt, it might be more generally beneficial to secure Internet whole.

Mark: 
   So are we talking about doing tcpcrypt in mptcp working group? :)

Marclo: 
   Yes.:) I mean if this is they way forward, we should go iesg.

costin: 
   Any encrypted payload solution running on top of mptcp would be great.
   In that case, I prefer add_addr should be completely unsecure.
   Or, we may need to do some things to make sure payload is going 
   to same box over all paths.

Mark: 
   It will secure not only add_addr, but also lots of injection/mitm scenarios.

Marcelo: 
   I agree. What we need to think is more practical question.
   Getting tcpcrypt in shape and adopted will take 12 months or more?

Mark: 
   mptcp and tcpcrypt are independent. They are not tied each other.
   we could look at re-integrating them later.

Marcelo:
   If we rely on tcpcrypt for security, we will need to wait until tcpcrypt is ready 
   for stds track.

Mark: 
   No. When we negotiate tcpcrypt, we can turn off authentiation for add_addr function. 
   Default protection of add_addr will be done in prong 1.

Marcelo
   Works for me.

Mark:
   question still in the air if tcpcrypt will protect add_addr option. :)

Costin:
   There is middlebox issue. There is a post to mailing list.

Ed: 
   That was me. concern that middleboxes strip mptcp options, if you can't 
   inspect it, I suspect intelligent middlboxes will develop mptcp proxys so
   that they would be benevolent to data centre design. 
   Listening to the overall conversation. 
   we do have to solve the add_addr issue.  ..independent... 
   my concern is that if we make it hard for carriers/enterprises to inspect the traffic, 
   they will simply strip the options... that will be it.

Costin:
   If middlebox can do the encryption, then it knows the key and will use add_addr 
   to make sure all the paths go to the same box. If they can deal with
   TLS, they should be able to deal with MPTCP. Maybe we need to understand a bit 
   more what middleboxes actually do so that when we design the security we can 
   take this into account. 

Ed: 
   receive tcp connection on 80.. as we inspect, we move to servers, and mptcp 
   gateway can now establish multiple subflows in a proxy type fashion...
   benefit to enterprise is increased perfmance and reliability of traffic in data 
   centre... without having to deal with various other tech.  it would enable 
   enterprises to very simply increase performance and reliability, example how 
   the proxy could be of benefit.

   Re indiegogo Idea of middlebox acting as a proxy and go to another device in 
   a data centre.. even if it ultimately goes from mptcp to tcp, terminated 
   as a service... these are useful potential middlebox solution.. strangely enough.. 
   integrity of direct client comms.. useful to have a middlbox in this scenario.

Ed: 
   do we want to be able to manipulate the options or just terminate...
   I woudl be interested in being able to do this in somethign other than an 
   explicit format... more like a transparent proxy.

Costin: 
   audio ...transparent proxys are the problem.. if you have a transparent middlebox 
   does a mitm.. .then it is expicit... preferable to being transparent.

Ed: 
   one problem with transparent, is you end up with middlebox attempt to multipath a 
   subflow (recursive), looking more at explicit type proxy functionality. havent really 
   objected to what is being said.. in explict mode, nothing proposed thus far would be problematic.


Philip: 
   Marcelo. in terms of your original question (secure signalling or data as well)
   my interpretation is we should look at securing data as well.. 
   or does securing just the signalling need more exploring?

Marcelo: 
   practical approach is we should start working on some of these options and see 
   what people propose. Although I haven't seen any proposal for securing the signalling.

Ed: 
   I'm not sure I'm convonced by the arcument that mptcp by its very nature is increaseing 
   the risk to the payload such that we have to force protection on the payload.. 
   I see them as independent concerns... if someone wants to support tcpcrypt or TLS they 
   are free to do so.. I understand the question is crossing nat boundarys.. 
   but I would argue that that is not a signifigant increase in risk over traditional TCP today.

Marcelo: 
   I think we fully agree. that is why we have prong1. Mptcp today with the few things we have 
   identified that need to be done is similiar to tcp, so we should move forward to standards 
   track. second, we can do better than today. My argument was, even though the signalling can 
   be secured.. due to having to retain compatability with nat. it isn't worth doing,  hence 
   we may as well look to secure both

Ed: 
   Agree in principle, concerned about the overhead this would impose.
   datacentre owner, the cost of protecting the payload would be too high visa-vis 
   the benefits they are trying to achieve by deploying mptcp.

Mark: 
   No one is advocation anything more than prong1. If you want to do more than prong1, 
   you will have to go prong2 to secure payload.

Marcelo: 
   In Data centres, they should just use prong 1. 

Mark: 
   there is an intermediate stage in the case where you don't have NAT..
   could apply in data centre scenario. In the internet, there is no middle ground 
   that will make any sense..

Marcelo: 
   if you believe IPv6 will not have nat. then prong1 with fixes is fine.

Ed: 
   Transparent proxys are not going to be workable solutions. I think manufacturers 
   will participate with explicit proxys.

Phil: 
   Are we reaching consensus? Is there any other point?

Mark: 
   I don't know anything what we need to do for tcpcrypt. we will need some support from IETF.
   If we think mptcp really wants it, we should give inputs to IESG.

Phil: 
   IESG may ask are we the only guys asking for it or do others require it in a different context?

Mark: 
   if i'm going to progress it I need someone to demand it.

Marcelo: 
   A good next step would be to understand how they would interact with one another 
   (mptcp and tcpcrypt). it's not as simple as stuff the options together

Mark: 
   I think it's pretty close, unless there is not enough space.

Costin: 
   We might engineer in different way. Putting strong HMAC data sequence mapping.
   Although we should keep overhead lower.

Mark: 
   might get extra compression doing that as well

Costin: 
   need to make sure it works for small data sequence payloads.

Mark: 
   that's the penalty to be paid for that kind of security

Costin:  
   in the initial syn, what is carried for tcpcrypt?

Mark: 
   pkconf option, then hikack fist two packets of payload for actually public key negotiation.

Costin: 
   We will need to think a bit more how to integrate this.

Costin: 
   Another observation. is it worthwhile to do the tcpcrypt handshake after the connection starts?

Mark: 
   can't trust anything until there is handshake.

Costin:
   we really need key for mptcp for subflow. That can be delayed.

Mark:
   You can actually encrypt the payload from beginning.

Mark: 
   There is current stuff in the MPTCP DSN option which can be taken out
   if we do tcpcrypt.

Costin: 
   Yes

Philip: 
   I'll post question to security AD's. MPTCP may be interested in exploring it.

Mark: 
   point is that we may do want to couple them a little.
   this is a question for the AD's