Subject: [multipathtcp] Next steps for WG

From: <[email-masked]>
Date: Mon, 29 Jul 2013 10:43:45 +0100

It would be nice to have some discussion during the WG meeting about how we progress on our charter.
>From the Implementations survey, http://datatracker.ietf.org/doc/draft-eardley-mptcp-implementations-survey/ I think these are the things for us to consider in order to progress the protocol RFC6824 on the standards track (which is the main topic on our charter)

1.ADD_ADDR needs more discussion
this was the one mptcp message that wasn't implemented by everyone. there were some worries about security, see also http://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attacks/ .
personally i think it would be a mistake for us to end up with two variants of mptcp, one which does add-addr and one that doesn't.

2.Fall-back needs a bit more clarification
i think this is "just" a matter of working through the extra corner cases that people have been found and adding /revising the current text.

3.‘Better’ security may be needed
RFC6824 exchanges keys in the clear during the initial handshake, then uses keyed HMAC.
there were some comments that something more secure may be needed and something with lower cost may be needed, preferably both in one.
we have the idea of building on top of ssl security, see http://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attacks/ and also (expired) http://tools.ietf.org/html/draft-paasch-mptcp-ssl-00
Is this a good way forward?

what would be good is if we can come to consensus on:
- what are the new threats (ie that weren't in RFC6181)
- which ones will we try and solve as we move the protocol onto the standards track
- what general approach will we pursue to solve them

We have an offer from Stephen F (Security AD) for help finding a sec area expert who'd work intensively with us. 
If we're ready after the wg meeting, we could go to the secarea meeting with our request. 

Other items on our charter
- More operational experience of different use cases, scenarios… (“particularly looking for cases where MPTCP could be detrimental in some way”)
- Implementation advice (heuristics)
- MPTCP-aware middlebox (where at least one end host is MPTCP-enabled)

I'll adjust the agenda to allow some discussion time about these Next Steps issues

thanks
phil