Multipath TCP (MPTCP)
          
Meeting  : IETF85, Tuesday November 6, 2012, 1520-16:50
Location : Atlanta, Grand Ballroom D
Chairs   : Philip Eardley
           Yoshifumi Nishida
AD       : Wesley Eddy
URL      : http://tools.ietf.org/wg/mptcp/
Note Taker: Alan Ford, Peer Azmat Shah

--------------------------------------------------------------------------------------------
          
1: Introduction

  Phil Eardley:
    Protocol doc is in editor queue
    API doc is under IESG review
    Milestone is updated  

--------------------------------------------------------------------------------------------

2: Protocol & API - Brief update 

  Alan Ford:
     Protocol updated due to IESG review. Tightening text, error cases,
     etc. Security negotiation bits given letters for IANA assignment and also
     more extensibility discussion. Finally, tying of security negotiation to
     algorithm for IDSN and token generation. Thank you to everyone who
     provided reviews and input to the documents.
 
  Chairs: and thanks to Alan who has done most of the work to get through IESG review

--------------------------------------------------------------------------------------------

3: Alternative security solutions for the MPTCP handshake
 
   Georg Hampel: 
     Question about external key exchange. This implies a SSL exchange every time? 

   Christoph: 
     Yes. It's per MPTCP connection.

   Georg: 
     If two hosts share multiple keys then you may require pointers in MPTCP handshake.
    
   Christoph:
     It might be a good idea to have some kind of key identifier inside MP_JOIN.

   Georg:
     Not in MP_CAPABLE?
  
   Christoph:
     MP_JOIN. In MP_CAPABLE, we need to send it in clear

   Alan:
     How about using new SSL handshake for new MPTCP subflow?

   Christoph:
     It might be doable. But, current approach seems to be simpler

   Michael Tuxen:
     How do you get a key from TLS? 
     RFC5705 defines TLS exporter for this kind of things.

   Michael Tuxen:
     This is protecting against an on-path attacker? 
     If you care about on-path there are many many risks, not just this. like reset attack.
     The difference between active and passive on-path is relatively small.

   Christoph: OK
     
   Keith Moore: 
     Layering here is strange and hard to use.

   Christoph: 
     We're also looking at DH scheme in MPTCP layer which doesn't use TLS or SSL.

   Keith Moore: 
     I think it's worth for looking.

   Allison Mankin: 
     Could use the keys from TCPcrypt?

   Christoph:
     Mark has a similar idea. Not done yet, though.

--------------------------------------------------------------------------------------------

4: FreeBSD MPTCP Swinburne

   Chairs presented slides from Swinburne folks

   Yoshifumi:
     Discussion point 1. How about simly copying the regular 16bit TCP checksum into a MPTCP option?
 
   Alan:
     The method doesn't work when packet is just resegmented without modifying content.

   Yoshifumi:
     So, any good idea for this?

   Alan:
     Take it to the list.

   Yoshifumi:
     Discussion point 2. What does DS SND.NXT mean for >1MMS? 

   Christoph: 
     It just increases, no difference if it's > 1MSS.

--------------------------------------------------------------------------------------------

5: MPTCP proxy

   Georg: 
     software proxy in front of kernel via packet filter. Main goal is
     for mobility. Could even have two proxies and both non-MPTCP hosts. 
     Uses one subflow at a time for mobility.
     Thanks Christoph for removing bugs at both sides during the interoperability test.

--------------------------------------------------------------------------------------------

6: Transitioning to MPTCP with efficient Protocol Converters

   Christoph:
     Protocol Converters (proxies). On-path, router-like transparent
     proxy (like squid for transparent HTTP proxying). In-kernel design for
     efficiency. Doing it in-kernel is far more effective, by 1000s per second.

   Gorry Fairhurst:
     Does SYN go all the way through? 

   Christoph:
     Yes, first it's sent transparently to far end, if MPTCP is not supported 
     then connection is split and sockets operated completely independently 
     and the MPTCP connection terminated on box. 
   
   Peer Azmat  
     By doing protocol conversion, will it lost some information in MPTCP?

   Christoph:
     It's actually fully split connection. I mean converter terminates MPTCP connection 
     and starts new TCP connection to the end.
 
   Peer:
     Where does converter resides?

   Christoph:
     It's in the network. We need to put a converter between server and client 
     for initial subflow

   larmit from ericsson?:
     How about buffer management?

   Christoph:
     Buffering is completly independent. We have two independent sockets.
     We'll need to look at sophisticated tuning for this. It will be done.
     Our first focus is to have best possible performance.

   Michael Tuxen:   
     What is the remote IP for the client. Is it proxy's IP or end host's IP?
  
   Christoph:
     It depends. If you can put a proxy on the path. It can be a transparent proxy.
     But, there is another mechanism which redirects MPTCP SYN to a host on the path.

   Alan:
     So, it's snooping?

   Christoph:
     Yes. Essentially it's a L4, transparent on-path proxy (i.e. on a box as a router) 
     like a transparent HTTP proxy today

   Alison Mankin:
     Would this latency to the converter matter if you put it immediately in front of server so get mptcp over whole Internet?

   Christoph: 
     not explored yet.