Multipath TCP (MPTCP) Meeting : IETF88, Monday November 4, 2013, 17:40-19:40 Location : Vancouver, Gergia A Chairs : Philip Eardley Yoshifumi Nishida AD : Martin Stiemerling URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Lawrence Stewart -------------------------------------------------------------------------------------------------------- 1: Chair Slide ????: Question about commercial router: what's their basis for using mptcp? Phil: You would share your broadband connections. Yoshi sent a link on the ML a while ago. You can check it. Martin: Security Adviser Updates: Still looking for people. As soon as we think it should be workable, we should directly to ship to security area to get early review. Phil: How do we proceed? Martin: I will handle this. Phil: In order to proceed to std track, currently we are thinking that two prong approach Lars: Prong 1 and Prong 2 can talk each other right? How do make sure you can protect agaist downgrading attack? Marcelo: Yes. That's problem, but it's a standard problem we know how to deal with. For example, We can only accept secured connections using policy. Lars: In prong2, we seems to presume tcpcrypt, what if tcpcrypt didn't get consensus? Marcelo: Leverage other work if it's needed, otherwise we can do our own for just MPTCP Lars: I'd prefer if we do tcpcrypt here, we should do it for tcp. Martin: We should raise a question in the area meeting. Karen Nielsen: If you have prong 1, does it mean you don't have a secure solution does NAT? Marcelo: In both prong1 and prong2, we should allow source address to be changed by NAT. In prong 1, we secure the MP_JOIN or addr message. In prong 2, we will secure payload. You can tweak source address, but you cannot read payload. Michael Tuexen: In SCTP, if we have TLS on top of SCTP, we can utilize key material in it. Does prong1 do this kind of thing? Marcelo: In prong1, we use HMAC for addr address like SCTP. HMAC contains a key. We can use a key derived from something else, like TLS. Michael: SCTP always takes combination. Send keys in clear, plus use some shared secrets later. We will need APIs for this. Alan Ford: That's perfectly reasonable. But, in prong1, we will focus on what's on the wire. Michael: In prong2, do you encrypt tcp header? Alan: So far only data. We need to consider it more, though. We need to support NAT. Michael: If you only protect only data, what is the different using TLS? Alan: They are just different approach to similar problem. Marcelo: Question is how we invoke TLS. Michael: If application wants to protect data, it has to do something. Marcelo: In prong2 proposal, this won't be decided by application, but by mptcp. It won't be a choice of application. We want to provide security when application doesn't do encryption. Michael: Encryption is mandatory? Marcelo: When We do TLS, we somehow need to specify we don't do prong2. We shouldn't do tcpcrypt and TLS at the same time. We should avoid it. Michael: Using tcpcrypt is you want always have encryption without any help from application or users. Or, do you have something else in your mind? Marcelo: Currently we focus on tcpcrypt only for encryption. We can protect applications which doesn't use TLS. Michael: I think if application doesn't use TLS, I assume there should be good reason for it. You might override decisions by applications. Lars: Laziness can be a reason. Randall Stewart: There is a case we don't need security like local net connection. Marcelo: My answer for it is use prong 1. Phil: Is there any consensus questions for prong 1 and prong 2 approach? Steven Farrell: If we do prong 1, do we do automated key management as per BCP107? If we don't have key management in prong 1, can we go std track? Marcelo: SCTP with dynamic addr is PS. What prong 1 does is exactly the same. Steven Farrell: OK. that might work. I have to think about it, though. Michael: SCTP protects against replay attack, but MPTCP doesn't. Marcelo: Question is do we want to HMAC of MP_JOIN against replay attack. Alan: I think there's a way. We thought we have covered such attacks. We'll need to check. Phil: Question: we should go 2 prongs approach? (lots of hum for support. None for oppose) We think we have consensus. Phil: Question: we should 6824 for fix secure issue as prong 1? (small hum for support. None for oppose) Marcelo: We put out a call for objections on prong 1/prong 2 and move ahead for the moment. Phil: If people don't like this approach, please share. Phil: Do we adpot raft-bagnulo-mptcp-attacks as a WG document? (lots of hum for support. None for oppose) We think we have consensus. -------------------------------------------------------------------------------------------------------- 2: RFC6824bis -- Alan Ford Marcelo: There's attack described on mailing list by Olivier. It should be looked at. Also out of band key stuff. Alan: OK. -------------------------------------------------------------------------------------------------------- 3: MPTCP path selection using Port Control Protocol (PCP) -- Dan Wing Alan: More examples of metrics? Dan: It's just an I-D, so we can change it if we want. Bandwidth, latency and jitter are defined. Phil: Does it just tell you about the first link? Or arbitrary depth? Dan: It's an arbitrary depth, and routers can pass the 5 tuple along the chain and report back info. How devices come up with the question is completely device specific. Lars: If I have 3G and wifi. I don't want to fire up 3G in order to check bandwidth. But, even MPTCP packets won't be sent, PCP packet might be sent via 3G. Dan: All you need is just one packet. Lars: We might think about energy model if we need to fire up 3G interface anyway. Alan: We don't the level of congestion on the link. I'm a bit worry about quality of information. Dan: Fair point. But, I'm trying to propose what is the best this network can do. In case of DSL, we know we cannot exceed 300Kbps. Michael: PCP is in the kernel? Dan: In the kernel. We want to hide the complexity from applications. Lars: Even if we have good metrics for networks at a certain moment, we should think about how frequent we should query it. -------------------------------------------------------------------------------------------------------- 4: Evolving the Internet with Connection Acrobatics -- Marcelo Bagnulo Ed Lopez: Waypoint migration. You are leveraging the weakness of security solution. Marcelo: It means you need explicit authorization from the other end in order to do this. Michael: if you do tcpcrypt, after the handshake can the middle box read payload? Marcelo: Not sure. good question. Lars: Wondering about having to involve the client in a migration decision because it adds delay to the process. You can do it, but you might not want to do it because of delay. Dan: you may want to do both local state + hacks for initial speed and involve client to do things properly i.e. hacky state only used until client completes signaling and is therefore complicit. Ed: 3 new cases will be still possible even after prong 1? Marcelo: I think it should be possible. It might require some changes, though. Peter ????: In waypoint migration. if this is a problem for middlebox, it should not involve end nodes. ????: For waypoint migration. In which we use it? Marcelo: For traffic engineering or might be for some policy cases. -------------------------------------------------------------------------------------------------------- Multipath TCP (MPTCP) Meeting : IETF88, Wednesday November 6, 2013, 15:50-16:50 Location : Vancouver, Regency B Chairs : Philip Eardley Yoshifumi Nishida AD : Martin Stiemerling URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Lawrence Stewart -------------------------------------------------------------------------------------------------------- 1: Chair Slide Confirmed the consensus on 2 prong approach and adoption for draft-bagnulo-mptcp-attacks Alan: Opportunistic encryption was heavily discussed. Feasibly possible without impacting the protocol negatively. Phil: We will have a meeting with tcpcrypt folks -------------------------------------------------------------------------------------------------------- 2: Apple Update -- Stuart Cheshire Stuart: If you are using Wifi and if signal gets weak, by using mptcp, we can migrate to 3G with a RTT. Right now, mptcp has been only for Siri. If you want to use mptcp for your app, send a request to https://bugreport.apple.com. We want to see demands for it. After you got bug-report number, if you send it to my mail acct, I might be some help. Phil: Why you chose siri? Stuart: We didn't choose siri. Siri chose us. Question was how make siri work better and we found mptcp. Karen: When you move from wifi to 3G, are you using timeout? Stuart: When you retransmit packets, we only try alternative path. Karen: What will happen if you gets wifi signal again? Stuart: I am not be the person who wrote code. In my understand, both paths are active, so I think it eventually will use wifi. Alan: Any metrics or statistics to show how mptcp improve performance? Stuart: I don't have anything specific. What I can say is it makes big difference in user experiences. Ed: Do you have any info on middleboxes or career that drop unknown options such as mptcp? Stuart: It is relatively rare to find such careers. ????: When mptcp will be used for itune? Stuart: It is Apple's policy not to comment on unannounced products. But, it sounds sensible. We would like to see how mptcp work well more. Go Wang: What if iphone changes the IP address on the interface? Stuart: If you get new addr, it will create a new subflow. Ed: Has apple considered MPTCP in other scenarios other than for Siri and how it interacts with middle boxes? The implementation will fall back if a few SYNs with option fail. Mostly found problems with corporate firewalls Dan Wing: We make a firewall (ASA firewall) which blocks everything by default. Can be configured to allow things through though, and other firewalls Stuart: In our experiments, only small percentage of middleboxes interfere mptcp. Corporate FW might do. Go Wang: Have you done any kind of analysis whether you can leak data across interfaces? Stuart: It sounds generic problems. I don't see mptcp adds new vulnerability on this. Alper Yegin: Did you consider mobile IP for siri? Stuart: Yes we did. But, we think mptcp is better for this. Yoshi: What was the design criteria? Stuart: Mobile IP is more host-level solution which affect all connections. It will require home agents, which cause extra costs for forwarding. mptcp doesn't require home address. Dapeng Liu: But, mptcp does require servers that support mptcp. Stuart: Yes. But, it's engineering trade off. Phil: Do you have new suggestions on mptcp? Stuart: My concern is it might be too easy to setup new subflow. Yoshi: Does using MPTCP affect battery life? Stuart: I don't believe it has any impact on battery life. Both interfaces are already on. mptcp is only used to choose the path for transmission. -------------------------------------------------------------------------------------------------------- 3: Open mic Ed: Do we need to consider MIIM related to prong1 in addition to add_addr? Alan: Good point. I think We'll need to think about. Ed: Problem is what middlebox is trying to do. For example, if middlebox want to do Web filtering, mptcp might be problematic. If we don't consider these use cases, middlebox might just drop mptcp options. Yoshi: There is proxy draft for mptcp. Do you have comments on this? It might be related what you are suggesting. Ed: I think it'll be an interesting use case. Phil: Could you talk about your analysis on MIIM with benevolent boxes? Ed: Difficult point of mptcp is it splits session into multiple tcp connections. But, these boxes look individual TCP flow. I think we don't have a way to identify a benevolent middlebox in the spec now. Phil: Proxy is in our charter. We're welcome for contribution. Jeff Couper: If we look at http 1.1, there is a checkpoint between the connections. If we can identify these points, they are relatively allow us to shift connections. We might be able to do this kind of things with mptcp. Lars: mptcp is designed to instantiate resource pooling idea. If we enforce a specific subflow to a specific path, we might have to give up this feature which is one of big benefits of using mptcp. Ed: There might be a way to specify how to utilize paths. E.g., this is the path to be exclusively used until unavailable. Stuart: Problem is it's difficult to know when it's unavailable. In order for good performance, you'll need to try. Steve ????: I have a question on apple implementation. What will happen if wifi doesn't allow mptcp? Stuart: In a direction we are going, it's up to the apps. Apps will be able to specify their preferable behavior. Ed: If Wifi doesn't allow mptcp, does it still uses mptcp or fallback to tcp over fastest connection? This is an implementation question to be addressed.