Minutes for MPTCP at interim-2013-mptcp-1
minutes-interim-2013-mptcp-1-2

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