Subject: [multipathtcp] MPTCP Audio Call - minutes.

From: <[email-masked]>
Date: Fri, 4 Oct 2013 10:16:51 +0100

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.

---

From: <[email-masked]>
Date: Fri, 4 Oct 2013 10:41:39 +0100

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: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of [email-masked]
> Sent: 04 October 2013 10:17
> To: [email-masked]
> 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
> 
> -----
> 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
> 
> Mark: Timing question, if we don't negotiate, (I missed a bit) how do
> we know when to send the add_addr message?
> 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.
> 
> 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
> 
> 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...
> 
> 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.
> 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.
> 
> 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.
> 
> 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.
> 
> 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 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: 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..
> 
> Ed: Transparent proxys are not going to be workable solutions.. I think
> manufacturers will participate with explicit proxys.
> 
> 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
> 
> Costin: could play with longer Data sequence mapping and hmac in
> different segments..should keep overhead lower and
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp