Re: [multipathtcp] MPTCP Audio Call - minutes.

[<[e-mail]>]

Also, here are the list of attendees (any corrections?):

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

> -----Original Message-----
> From: [e-mail] [mailto:multipathtcp-
> [e-mail]] On Behalf Of [e-mail]
> Sent: 04 October 2013 10:17
> To: [e-mail]
> Subject: [multipathtcp] MPTCP Audio Call - minutes.
> 
> Many thanks to John (Ronan) for taking some nice minutes. He joined
> late, so I added some less nice minutes about the start of the call.
> Please send any corrections to me & Yoshifumi Thanks phil
> 
> -----
> Phil: introduced meeting. See slides on wiki.
> 
> Marcelo:
> Solving ADD-ADDR should be enough for Stds track, as similar to TCP and
> exactly same as SCTP with dynamic addresses In parallel more secure
> version
> 
> 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
> 
> Philip: Apps should be able to disable the 'increased security' syn
> option on request.
> 
> Request from client to server to not do mptcp... we don't want server
> to send an add_addr option back to us.
> 
> Marcelo: Negotiation needs to be more than just an option.
> 
> Mark: Timing question, if we don't negotiate, (I missed a bit) how do
> we know when to send the add_addr message?
> Is this in prong one?  Its not clear
> 
> Marcelo: Missed his point
> 
> Costin: Muffeled audio, question to Alan
> 
> Alan: We have 4-5 (to be schecked) spare bits for the purposes of
> negotiating encryption algorithms.
> 
> Costin: Do we want to use a bit for this, or wait until a point in
> time, or
> 
> Alan: Use one bit, binary, one or off... 'do not set up subflows yet'
> 
> 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 generall agreement how to
> prevent this add_addr attack
> 
> Marcelo:  I was convinced by Oliver's argument.
> 
> Mark: It seems sufficient.... there is a compatability issue
> 
> ?:What issue?
> 
> Mark: if we use Hmac in mp_join, we change its semantics
> 
> Yohifumi: Not understanding what should be done in prong 2.. question
> is unclear
> 
> 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.. understand if we need more to add compatability with what
> we do in prong2 (as yet unknown)
> 
> 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
> 
> Yoshi: Yes, this answers question 1.. missed next question
> 
> Philip (summary):
> Prong1: 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 (prong2) and maybe...
> 
> Philip, propose to discuss prong2 Invites Marcelo to discuss it
> 
> Marcelo:
> 1. Secure the signalling only
> 2. Secure both signalling and data
> After discussion last week with group and it isn't clear if
> 
> 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 ??crypt.
> First decision will be to either secure the signalling or both
> signalling and payload
> 
> Mark: Secured based on SSL, then payleoad is secured from payload
> insertion already.
> 
> Marcelo, how relevant are the threats?
> 
> Mark: question is really does it increase the attack vectors? Marclo
> agrees.
> 
> Marcelo: broad point about whether using ssl (tcpcrypt) on top of MPTCP
> 
> Mark: are we talking about doing tcpcrypt in mptcp working group
> Marclo: if this is they way forward, the iesg....
> 
> costin: any encrypted payload solution running on top of mptcp would be
> great... (not sure), may need to do some things like make sure payload
> is going to same box over all paths.
> 
> Mark: Not securing add_addr allows for lots of injection/mitm
> scenarios.
> 
> Marcelo: getting tcpcrypt in shape and adopted will take 12 months or
> more
> 
> Marl: oroginally they were kept separate so one wouldn't drag the other
> down.  we could look at re-integrating them
> 
> Mark: Negotiate tcp-crypt, turn off add_addr function, default
> protection of add_addr, question still in the air if tcp-crypt will
> protect add_addr option.
> 
> Costin: missed it.. mentioned 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.
> 
> Missed question from Yoshi.
> 
> 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.
> 
> Missed question from Costin possibly.
> 
> Philip: Marcelo.. in terms of your original question (secure signalling
> or both)... my interpretation is... we should look at securing both..
> or does securing just the signalling need more exploring.
> 
> Marcelo: practical approach.. we should start working on some of these
> options and see what people propose... i haven't seen any proposal for
> securing the signalling... any other option.
> 
> Ed: I'm not sure I'm convonced by the arcument that mptpcp 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 re 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
> can we 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 vis-a-vis the benefits they are trying to achieve by
> deploying mptcp.
> 
> Mark: No one is advocation anythign more than prong1
> 
> Marcelo: Data centres should just use prong 1 with fixes...
> 
> 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.
> 
> Mark: missed his point re tcpproxy...does mptcp wg think this is
> something we need?
> Philip: IESG may ask are we the only guys asking for it or do others
> require it in a different context?
> 
> Mark: if i'm 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)... its not as simple as
> stuff the options together
> 
> Mark: yes, but not enough space
> 
> Philip: separate at present
> 
> Mark: yes
> 
> Costin: question re hmac
> 
> Mark: bit of mac and option header, thats about it (not sure about last
> two/three exchances)
> 
> Costin: could play with longer Data sequence mapping and hmac in
> different segments..should keep overhead lower and
> 
> Mark: might get extra compression doing that as well
> 
> Costin: need to make sure it works for small data sequence payloads
> 
> Mark: thats the penalty to be paid for that kind of security
> 
> Costin:... in the initial syn, what is carried?
> 
> Mark: pk??? option, hikack fist two packets of payload for public key
> negotiation.
> 
> Costin: there we need to think a bit more... need to go to....
> 
> Mark: discussed options
> 
> Costin: Another observation... is it worthwhile to do the tcpcrypt
> handshake after the connection starts?
> 
> Mark: can't trust anything until after the negotiation starts
> 
> Discussion between Costin and Mark. Costin agreed with Mark at the end.
> 
> Mark: There is current stuff in the MPTCP DSN option which can be taken
> out if we do tcpcrypt.
> 
> Costin: Yes
> 
> Mark: Different discussion
> 
> 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.. questions
> for the AD's
> 
> Philip: Anyone want to bring up anything else?
> 
> <silence>
> Philip:  discussion re Vancouver IETF.
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp