Minutes for MPTCP at interim-2013-mptcp-1
||Minutes for MPTCP at interim-2013-mptcp-1
Multipath TCP (MPTCP)
Date : Thursday October 3, 2013, 15:00-17:00 GMT
Note Taker: John Ronan
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
See slides on wiki.
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:
as long as doesn't cause backwards compatibility issues later.
Proposal to have MPTCP signal to other end increased security
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.
Not very sure if it's policy question.
If we cannot do it without the current spec, we should fix the spec now. Not
Agree. We should add one additional option in SYN to indicate more secure
What we should now is to sort out how we signal it.
We should have an WG item as prong 1.
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.
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.
My question is negotiation needs to be more than just an option.
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
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?
Do we have some bits in MP_CAPABLE for security mechanism?
Yes. We have 4-5 spare bits for the purposes of negotiating
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.
Sounds like one bit feature. binary, on or off...
We might need 'do not set up subflows yet' bit.
I think I need to think about it.
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.
Is it fair to say that there is general agreement how to prevent this
I was convinced by Oliver's argument. Why we use should HMAC.
That would be belong to prong 2.
It seems sufficient. you'll also consider compatability issue.
What is compatibility issue?
if we use Hmac in mp_join, we change its semantics
I would like to know What should be done in prong 1 and prong 2.
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
We don't HMAC in MP_JOIN?
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
OK. I see.
We'll need to think about upgradable security mechanism in prong 1.
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).
propose to discuss prong2. Invites Marcelo to discuss it
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
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
If we secure signalling based on SSL, then payleoad is already secured from
My question is how relevant to secure signals. What are the threats?
Question is it would be potentially more open to DoS attack. I'm not sure
what it would like.
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.
So are we talking about doing tcpcrypt in mptcp working group? :)
Yes.:) I mean if this is they way forward, we should go iesg.
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.
It will secure not only add_addr, but also lots of injection/mitm scenarios.
I agree. What we need to think is more practical question.
Getting tcpcrypt in shape and adopted will take 12 months or more?
mptcp and tcpcrypt are independent. They are not tied each other.
we could look at re-integrating them later.
If we rely on tcpcrypt for security, we will need to wait until tcpcrypt is
ready for stds track.
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.
Works for me.
question still in the air if tcpcrypt will protect add_addr option. :)
There is middlebox issue. There is a post to mailing list.
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.
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.
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
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.
audio ...transparent proxys are the problem.. if you have a transparent
middlebox does a mitm.. .then it is expicit... preferable to being
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.
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?
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
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.
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
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.
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.
In Data centres, they should just use prong 1.
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..
if you believe IPv6 will not have nat. then prong1 with fixes is fine.
Transparent proxys are not going to be workable solutions. I think
manufacturers will participate with explicit proxys.
Are we reaching consensus? Is there any other point?
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
IESG may ask are we the only guys asking for it or do others require it in a
if i'm going to progress it I need someone to demand it.
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
I think it's pretty close, unless there is not enough space.
We might engineer in different way. Putting strong HMAC data sequence
mapping. Although we should keep overhead lower.
might get extra compression doing that as well
need to make sure it works for small data sequence payloads.
that's the penalty to be paid for that kind of security
in the initial syn, what is carried for tcpcrypt?
pkconf option, then hikack fist two packets of payload for actually public
We will need to think a bit more how to integrate this.
Another observation. is it worthwhile to do the tcpcrypt handshake after the
can't trust anything until there is handshake.
we really need key for mptcp for subflow. That can be delayed.
You can actually encrypt the payload from beginning.
There is current stuff in the MPTCP DSN option which can be taken out
if we do tcpcrypt.
I'll post question to security AD's. MPTCP may be interested in exploring it.
point is that we may do want to couple them a little.
this is a question for the AD's