Subject: [multipathtcp] MPTCP abrupt connection termination

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 17 Jan 2012 03:31:11 -0800

Hi folks,
Although it's a bit quite these days, I personally believe we are
getting close to finish this feature.
I'm trying to create a simple summary of the current discussion items.
please feel free to add and modify it.

Also, I personally think the status of these items are followings
   1: reach consensus
   2: since procedure is fixed, we can just procced to create this
   3: no disagreement (if we use option)
   4: rather minor topic so easy to fix
   5: let's decide quickly if there's no blocker

1: bacis procedure

   - Host A sends a regular TCP segment containing MPTCP_RST(B's key)
on one subflow. It sends TCP RST segments on all other subflows and
tears them down.

   - Upon reception of a regular TCP segment containing MPTCP_RST and
its key, a host responds by sending a TCP RST segment on the same
subflow and releases the entire MPTCP connection.

   - Host A tears down the MPTCP connection as soon as it receives a
TCP segment containing MPTCP(A's key) or a RST segment on the
remaining subflow.

   note 1: need to add retransmission timeout for MPTCP_RST

2: new state diagram for this

3: option format for MPTCP_RST
    http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html

4: name for the option
    MPTCP_RST or DATA_RST might not be good?
    DATA_CLOSE?

5: using flag in DSS insted of option
    in case of DSS, we won't use KEY. Isn't it vulnerable?

Thanks,
--
Yoshifumi

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 17 Jan 2012 13:40:32 -0600

Hi Yoshifumi,

On your points:

1. I'm fine with the basic procedure. The third bullet should perhaps mention that host A has to send a TCP RST in case it receives a MPTCP_RST. This makes the third bullet compliant with the second bullet.

2. State diagram: I think we haven't converged on this issue yet. I once proposed to introduce the RST_WAIT state. 
- Host A transitions to RST_WAIT from any other state when it sends MPTCP_RST. 
- Host B transitions to CLOSED from any other state when it receives MPTCP_WAIT. 
- Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or MPTCP_RST.

The RST_WAIT state has a retransmission time out. If MPTCP_RST retransmissions don't succeed within this time out, host A transitions to CLOSED.

3. I'm fine with Olivier's proposal on the MPTCP_RST packet format.

4. I don't have specific name preferences. However, I think it makes sense to keep the term "RST" in the name since it builds on TCP RST and since it doesn't represent a "proper" handshake.

5. I agree that just having DSS + flag is too vulnerable. I'd prefer the solution proposed under 3.

Thanks.

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, January 17, 2012 6:31 AM
To: multipathtcp
Subject: [multipathtcp] MPTCP abrupt connection termination

Hi folks,

1: bacis procedure

4: name for the option

Thanks,
--
Yoshifumi
_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Fri, 20 Jan 2012 18:54:50 +0000

Let me just clarify I understand.

<<1: bacis procedure

[phil] TCP RST is an ordinary RST (at some earlier point there was discussion about this including the MPTCP-RST(A'skey) ; but this is not the proposal)
[phil] is it required /recommended that A sends MPTCP_RST on exactly one subflow or can it send it on several?

<<
[phil] the second case is the normal one. the first case could occur if both ends simulataneously send MPTCP-RST, is that right?

Re 4, I think it would be good if the name included MPTCP, as there are ordinary TCP msgs involved as well.

The summarised position seems good to me - is everyone ok with it? then we could finish this in the next couple of weeks?

Thanks
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K Georg (K Georg)
Sent: 17 January 2012 19:41
To: Yoshifumi Nishida; multipathtcp
Subject: Re: [multipathtcp] MPTCP abrupt connection termination

Hi Yoshifumi,

On your points:

Thanks.

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, January 17, 2012 6:31 AM
To: multipathtcp
Subject: [multipathtcp] MPTCP abrupt connection termination

Hi folks,

1: bacis procedure

4: name for the option

Thanks,

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 23 Jan 2012 14:39:49 -0600

Hi Phil,

Comments inserted. Thanks.

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 20, 2012 1:55 PM
To: Hampel, K Georg (K Georg); [email-masked]; [email-masked]
Subject: RE: [multipathtcp] MPTCP abrupt connection termination

<<1: bacis procedure

[georg] Correct. TCP RST is an ordinary RST.

[georg] I originally proposed an extended version where A can send MPTCP_RST on any subset of subflows. That is possible but it makes the tear-down procedure a little more complicated. 
- A sends MPTCP_RST on some subflows and TCP RST on all others.
- B, upon reception of the first MPTCP_RST, sends TCP RSTs on all subflows and shuts down.
- A, upon arrival of at least one MPTCP_RST or TCP RSTs on all remaining subflows shuts down.

Reliability: When no MPTCP_RST arrives, A retransmits MPTCP_RST on at least one subflow and TCP RSTs on all remaining subflows.

ML discussions with Olivier converged to the present simpler solution.

<<

[georg] yes.

Thanks
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K Georg (K Georg)
Sent: 17 January 2012 19:41
To: Yoshifumi Nishida; multipathtcp
Subject: Re: [multipathtcp] MPTCP abrupt connection termination

Hi Yoshifumi,

On your points:

Thanks.

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, January 17, 2012 6:31 AM
To: multipathtcp
Subject: [multipathtcp] MPTCP abrupt connection termination

Hi folks,

1: bacis procedure

4: name for the option

Thanks,

---

From: Alan Ford <[email-masked]>
Date: Mon, 30 Jan 2012 14:26:32 +0000

Hi Georg, all,

My thoughts on this:

1. The procedure seems ok. I don't see much benefit/difference between this
and doing the multiple-MPTCP_RST option that you mention in a later mail,
so this is fine. The timeout should ensure a relatively clean finish.

However, shouldn't B also send TCP RST on all other subflows on receipt of
MPTCP_RST?

2. Your state machine description below seems fine (although require notes
on transmitted packets on the transitions, too).

4. The name - I prefer "DATA_CLOSE" or "MPTCP_CLOSE" since I do not see
this analogous to a TCP RST and instead see it as presenting a subset of
TCP RST's (ab)uses.

3 and 5. Note that the use of the key makes the MPTCP_RST option up to 12
bytes long. This means we are unlikely to be able to fit a DSS option and
the MPTCP_RST in the same packet. This is fine if the data in the last
packet is already covered by a DSS option, but if not it would require a
second packet just carrying MPTCP_RST.

Although doing it by flag is open to replay attacks, is this really any
worse than regular TCP?

Regards,
Alan

On 17 January 2012 19:40, Hampel, K Georg (K Georg) <
[email-masked]> wrote:

> Hi Yoshifumi,
>
> On your points:
>
> 1. I'm fine with the basic procedure. The third bullet should perhaps
> mention that host A has to send a TCP RST in case it receives a MPTCP_RST.
> This makes the third bullet compliant with the second bullet.
>
> 2. State diagram: I think we haven't converged on this issue yet. I once
> proposed to introduce the RST_WAIT state.
> The RST_WAIT state has a retransmission time out. If MPTCP_RST
> retransmissions don't succeed within this time out, host A transitions to
> CLOSED.
>
> 4. I don't have specific name preferences. However, I think it makes sense
> to keep the term "RST" in the name since it builds on TCP RST and since it
> doesn't represent a "proper" handshake.
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2012 07:50:29 -0800

> [phil] TCP RST is an ordinary RST (at some earlier point there was discussion about this including the MPTCP-RST(A'skey) ; but this is not the proposal)

FWIW, I never liked any TCP mod in which a RST generates a response. I 
think it's counter to the point of the message; IMO, if you need further 
action, you should create a different message.

Two other points:

- RSTs (as all signals) can be lost; what happens to your system when 
they are?

- if you use existing TCP RSTs, what happens to other TCP interactions? 
(e.g., a middlebox tends to tear things down on receiving a RST; they 
also sometimes send RSTs - will that create problems?)

Joe

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 30 Jan 2012 17:51:35 +0100

Hi Alan,

On 01/30/2012 03:26 PM, Alan Ford wrote:
> 3 and 5. Note that the use of the key makes the MPTCP_RST option up to
> 12 bytes long. This means we are unlikely to be able to fit a DSS option
> and the MPTCP_RST in the same packet. This is fine if the data in the
> last packet is already covered by a DSS option, but if not it would
> require a second packet just carrying MPTCP_RST.

The DSS-option does not really matter, and can be ommitted on a packet
containing the MPTCP_RST.
Because, upon reception of the MPTCP_RST, the application will anyway
receive an "ECONNRESET" on the socket and the data won't get delivered
anymore.

Cheers,
Christoph

-- 
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
--

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 30 Jan 2012 11:23:12 -0600

Hi Alan,

I've inserted comments below. Thanks.

Georg

________________________________

Hi Georg, all,

My thoughts on this:

1. The procedure seems ok. I don't see much benefit/difference between this and doing the multiple-MPTCP_RST option that you mention in a later mail, so this is fine. The timeout should ensure a relatively clean finish.

However, shouldn't B also send TCP RST on all other subflows on receipt of MPTCP_RST?

[gh] The philosophy is to keep the number of messages small and to have the connection-disrupting host pay the price rather than the "innocent" peer. Since host A (initially) sends TCP RSTs on all but one subflow, the corresponding on-path middleboxes should be properly closed down. Host B's subflows also properly close down either through these TCP RSTs or due to the (reliably transmitted) MPTCP_RST. The only problem I see exists for middle boxes in case one of these TCP RST gets lost. We could improve this situation by having host B also sent TCP RST on each path, but this doesn't make this solution reliable.

2. Your state machine description below seems fine (although require notes on transmitted packets on the transitions, too).

4. The name - I prefer "DATA_CLOSE" or "MPTCP_CLOSE" since I do not see this analogous to a TCP RST and instead see it as presenting a subset of TCP RST's (ab)uses.

[gh] I don't really agree on the term "TCP RST abuse". RFC 1122 simply forgot to provide a mechanism which allows an application to forcefully close down. I assume there was no need to fix this at a later point in time since TCP RST had already been adopted for this purpose. Instead of TCP FIN = clean and TCP RST = dirty, I would rather say TCP FIN = close-down w/o data loss and TCP RST = close-down with data loss. The same applies to MPTCP FIN and MPTCP RST. Otherwise I would ask: Why do we need a MPTCP CLOSE handshake if we already have a MPTCP FIN handshake.

3 and 5. Note that the use of the key makes the MPTCP_RST option up to 12 bytes long. This means we are unlikely to be able to fit a DSS option and the MPTCP_RST in the same packet. This is fine if the data in the last packet is already covered by a DSS option, but if not it would require a second packet just carrying MPTCP_RST.

[gh] Since we assume connection abortion with data loss the DSS should not be necessary anymore.

Although doing it by flag is open to replay attacks, is this really any worse than regular TCP?

[gh] Do you mean DoS attacks? What would you accomplish with a replay attack?

Regards,
Alan

On 17 January 2012 19:40, Hampel, K Georg (K Georg) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshifumi,

On your points:

Thanks.

Georg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, January 17, 2012 6:31 AM
To: multipathtcp
Subject: [multipathtcp] MPTCP abrupt connection termination

Hi folks,

1: bacis procedure

4: name for the option

Thanks,
--
Yoshifumi
_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp
_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 30 Jan 2012 11:49:47 -0600

Hi Joe,

Georg

[gh] We don't propose any TCP response to a TCP RST. We propose a TCP-RST response to a MPTCP_RST. MPTCP is seen as the "higher layer" whose RST creates a "lower layer" RST, in the same manner as an HTTP error message may cause a TCP RST response.

Two other points:

[gh] Our system is fine since MPTCP_RST is sent reliably (i.e. retransmitted). Some middle boxes may keep hanging in.

[gh] We are planning to use existing TCP RSTs. The main reason is to tear down middle-box state (courtesy procedure). To the best of my knowledge, RSTs sent by middle boxes shouldn't create any problem.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2012 10:05:41 -0800

Hi, Georg,

Thanks for the clarification.

Joe

---

From: Alan Ford <[email-masked]>
Date: Mon, 30 Jan 2012 19:35:31 +0000

Georg,

Thank you for the clarifications below. I think that's cleared up my remaining issues/confusions (especially given Christoph's point that the signal needs a packet of its own anyway, so we might as well make it a semi-secure signal).

We'll get an updated version of the draft out shortly.

Cheers,
Alan

On 30 Jan 2012, at 17:23, Hampel, K Georg (K Georg) wrote:

> Hi Alan,
>  
> I’ve inserted comments below. Thanks.
> 
> Georg
>  
>  
> Hi Georg, all,
>  
> My thoughts on this:
>  
> [gh] The philosophy is to keep the number of messages small and to have the connection-disrupting host pay the price rather than the “innocent” peer. Since host A (initially) sends TCP RSTs on all but one subflow, the corresponding on-path middleboxes should be properly closed down. Host B’s subflows also properly close down either through these TCP RSTs or due to the (reliably transmitted) MPTCP_RST. The only problem I see exists for middle boxes in case one of these TCP RST gets lost. We could improve this situation by having host B also sent TCP RST on each path, but this doesn’t make this solution reliable.
>  
>  
> [gh] I don’t really agree on the term “TCP RST abuse”. RFC 1122 simply forgot to provide a mechanism which allows an application to forcefully close down. I assume there was no need to fix this at a later point in time since TCP RST had already been adopted for this purpose. Instead of TCP FIN = clean and TCP RST = dirty, I would rather say TCP FIN = close-down w/o data loss and TCP RST = close-down with data loss. The same applies to MPTCP FIN and MPTCP RST. Otherwise I would ask: Why do we need a MPTCP CLOSE handshake if we already have a MPTCP FIN handshake.
>  
>  
> On 17 January 2012 19:40, Hampel, K Georg (K Georg) <[email-masked]> wrote:
> Hi Yoshifumi,
> 
> On your points:
>