Subject: [multipathtcp] draft-ietf-mptcp-multiaddressed-03: break-before-make?

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Fri, 20 May 2011 17:24:02 -0500

Hi Alan, all,

Having read through draft-ietf-mptcp-multiaddressed-03, I am uncertain if break-before-make (BBM) scenarios are supported. With BBM, I refer to the situation where the host closes the last subflow of a data connection via FIN or RST *before* opening a new subflow via MP_JOIN. This use case applies to a mobile host which wants to hand over from one L3 network to another, while supporting only one L2 interface. In this case, the mobile should properly close the old subflow before switching L2/L3 connectivity.

Section 3.3.3 of the draft states:

"Essentially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. until all data has been DATA ACKed, or that the segment with the FIN flag set is the only outstanding segment."

This statement prohibits that a host exercises BBM handover since the connection must be closed before the last subflow is closed. Later on, section 3.3.3 states:

"If all subflows have been closed with a FIN exchange, but no DATA FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeout."

This statement seems to tolerate BBM scenarios as long as they are conducted within the timeout window.

Apart from the wording, I'd like to know if there are any specific reasons to prohibit BBM. The draft mentions security issues related to BBM without going into the details. I would be in favor of BBM support since this would substantially enhance MPTCP's versatility and applicability to wireless access networks.

Regards,

Georg Hampel

---

From: "Ford, Alan" <[email-masked]>
Date: Sun, 22 May 2011 11:29:09 +0100

Hello Georg,

Thanks for your feedback. BBM support is definitely intended - it is a
useful feature in many scenarios, and is intended to have a similar
timeout to a regular TCP session where there is temporary break in
connectivity. (Indeed, it was one of the most difficult constraints on
the security solution, since we could not rely on the ability to send
fresh data on a surviving subflow as authentication information).

The latter text you identify ("If all subflows have been closed with a
FIN exchange, but no DATA FIN has been received and acknowledged, the
MPTCP connection is treated as closed only after a timeout.") is
correct; we will look at clarifying the text in 3.3.3.

However, note that the text in 3.3.3 does not prohibit BBM. It says:
"Essentially, a host MUST NOT FIN all subflows unless it is safe to do
so, i.e. until all data has been DATA ACKed, or that the segment with
the FIN flag set is the only outstanding segment.". The purpose of this
text is to stop a deadlock scenario where there is no subflow available
to retransmit data if one fails with outstanding data whilst others have
been FINned.

It may be clearer just to say "until all outstanding data has been DATA
ACKed". The intention is that subflows can be opened and closed with
FINs at will - the reliability at the connection level is handled by the
data-level sequence numbering, and a timer will keep the connection
state alive until a DATA FIN has been exchanged.

Regards,

Alan

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hampel, K Georg (K
Georg)
Sent: 20 May 2011 23:24
To: [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: [multipathtcp]
draft-ietf-mptcp-multiaddressed-03:break-before-make?

Hi Alan, all,

Having read through draft-ietf-mptcp-multiaddressed-03, I am uncertain
if break-before-make (BBM) scenarios are supported. With BBM, I refer to
the situation where the host closes the last subflow of a data
connection via FIN or RST *before* opening a new subflow via MP_JOIN.
This use case applies to a mobile host which wants to hand over from one
L3 network to another, while supporting only one L2 interface. In this
case, the mobile should properly close the old subflow before switching
L2/L3 connectivity.

"Essentially, a host MUST NOT FIN all subflows unless it is safe to do
so, i.e. until all data has been DATA ACKed, or that the segment with
the FIN flag set is the only outstanding segment."

This statement prohibits that a host exercises BBM handover since the
connection must be closed before the last subflow is closed. Later on,
section 3.3.3 states:

"If all subflows have been closed with a FIN exchange, but no DATA FIN
has been received and acknowledged, the MPTCP connection is treated as
closed only after a timeout."

This statement seems to tolerate BBM scenarios as long as they are
conducted within the timeout window.

Apart from the wording, I'd like to know if there are any specific
reasons to prohibit BBM. The draft mentions security issues related to
BBM without going into the details. I would be in favor of BBM support
since this would substantially enhance MPTCP's versatility and
applicability to wireless access networks.

Regards,

Georg Hampel

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 23 May 2011 08:52:00 -0500

Hello Alan,

Thanks for your response.

I'm still struggling on how MPTCP would handle some BBM scenarios. Assume Host A and host B sustain a MPTCP session with one subflow, when host A suddenly moves out of the coverage area of its present access network. If host A only supports one L2 interface, it has to discontinue L2/L3 connectivity before it can access another, overlapping access network. In such a scenario, host A may still be able to send a final message on the old network (e.g. RST), but it cannot wait until all outstanding data have been data-acked or until a FIN-ACK handshake has completed. I guess the best behavior would be for host A to send RST, change L2/L3 attachment points, open a new subflow on the new network with MP_JOIN and do a cross-flow retransmission of all outstanding data.

I don't see any technical or security-related issues here. It's more a question of policy definition. Thanks.

Regards,
Georg

________________________________
From: Ford, Alan [mailto:[email-masked]]
Sent: Sunday, May 22, 2011 6:29 AM
To: Hampel, K Georg (K Georg); [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

Hello Georg,

Thanks for your feedback. BBM support is definitely intended - it is a useful feature in many scenarios, and is intended to have a similar timeout to a regular TCP session where there is temporary break in connectivity. (Indeed, it was one of the most difficult constraints on the security solution, since we could not rely on the ability to send fresh data on a surviving subflow as authentication information).

The latter text you identify ("If all subflows have been closed with a FIN exchange, but no DATA FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeout.") is  correct; we will look at clarifying the text in 3.3.3.

However, note that the text in 3.3.3 does not prohibit BBM. It says: "Essentially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. until all data has been DATA ACKed, or that the segment with the FIN flag set is the only outstanding segment.". The purpose of this text is to stop a deadlock scenario where there is no subflow available to retransmit data if one fails with outstanding data whilst others have been FINned.

It may be clearer just to say "until all outstanding data has been DATA ACKed". The intention is that subflows can be opened and closed with FINs at will - the reliability at the connection level is handled by the data-level sequence numbering, and a timer will keep the connection state alive until a DATA FIN has been exchanged.

Regards,
Alan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K Georg (K Georg)
Sent: 20 May 2011 23:24
To: [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

Hi Alan, all,

Regards,

Georg Hampel

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 23 May 2011 23:40:50 +0200

Georg,
> 
>  
> 
> I’m still struggling on how MPTCP would handle some BBM scenarios.
> Assume Host A and host B sustain a MPTCP session with one subflow, when
> host A suddenly moves out of the coverage area of its present access
> network. If host A only supports one L2 interface, it has to discontinue
> L2/L3 connectivity before it can access another, overlapping access
> network. In such a scenario, host A may still be able to send a final
> message on the old network (e.g. RST), but it cannot wait until all
> outstanding data have been data-acked or until a FIN-ACK handshake has
> completed. I guess the best behavior would be for host A to send RST,
> change L2/L3 attachment points, open a new subflow on the new network
> with MP_JOIN and do a cross-flow retransmission of all outstanding data.

In the case that you mentionned, the host should not send a RST when it
looses connectivity. Instead, it should leave the MPTCP session up,
switch to the new address and send an MP_JOIN. After that, it can use
REMOVE_ADDR to indicate that the old address does not work anymore
(section 3.4).

There is a small security risk in this case if another host has been
assigned the old address of host A and replies to the received keepalive
which is suggested in section 3.4 of the current draft. This Keepalive
reply will be subject to the standard tcp test (see
http://tools.ietf.org/html/draft-ietf-tcpm-tcp-security-02 for more
details) and thus the attacker would have to predict the value of the
sequence number that the connection reached.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 24 May 2011 08:31:06 -0500

Olivier,

I agree that your BBM procedure works. It is applicable to cases where L2/L3 conductivity tears off suddenly and host A has no time to send any further message. 

However, if host A has time to send RST on the old subflow I think it should do so. This clears state on firewalls and NATs, and it also allows host B to take down the old subflow without the detour procedure you mentioned. Also the security problem is avoided.

At the same time, the MPTCP connection prevails for some timeout interval since Data FIN has not been exchanged. Hence host A has time to re-establish a new subflow via MP JOIN.

Georg

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Monday, May 23, 2011 5:41 PM
To: Hampel, K Georg (K Georg)
Cc: Ford, Alan; [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

Georg,
> 
>  
> 
> I'm still struggling on how MPTCP would handle some BBM scenarios.

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 24 May 2011 14:30:04 -0700

Hi Georg,

I think L4 should be conservative to react on L2/L3 incidents, so I'm
a bit skeptical about sending RST here.
Because basically, L4 cannot know if it's temporary or permanent or forged.

Thanks,
--
Yoshifumi Nishida
[email-masked]

2011/5/24 Hampel, K Georg (K Georg) <[email-masked]>:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 24 May 2011 23:33:18 +0200

Yoshifumi,
> Because basically, L4 cannot know if it's temporary or permanent or forged.

I agree. Maybe MPTCP could include an additional timer that would be
used to send a REMOVE_ADDR option once a local address has been
unreachable for X seconds. I would not send a RST as soon as a L2/L3
change has been detected.

Olivier

---

From: Scott Brim <[email-masked]>
Date: Tue, 24 May 2011 18:15:59 -0400

> Because basically, L4 cannot know if it's temporary or permanent or
forged.

Agreed. Deciding when to send anticipatory RSTs gets you back into guessing
when you should failover, while one of the advantages of multipathing is
that you can safely defer those decisions.

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 25 May 2011 09:31:50 -0500

Yoshifumi, Oliver,

I understand your concerns. However, if a BBM scenario occurs, it is always a signal from L2/L3 that triggers events on higher layers. If such a signal occurs, L4 is better advised to react quickly. This means that it should start the new subflow right way and immediately retransmit outstanding data on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it knows that the old interface is gone. My suggestion to directly terminate the old subflow via RST is solely a short cut. 

Georg

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2011 5:33 PM
To: Yoshifumi Nishida
Cc: Hampel, K Georg (K Georg); [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

Yoshifumi,

Olivier

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 May 2011 14:23:16 -0400

On Wed, May 25, 2011 at 10:31, Hampel, K Georg (K Georg) <
[email-masked]> wrote:

> I understand your concerns. However, if a BBM scenario occurs, it is always
> a signal from L2/L3 that triggers events on higher layers. If such a signal
> occurs, L4 is better advised to react quickly. This means that it should
> start the new subflow right way and immediately retransmit outstanding data
> on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it
> knows that the old interface is gone. My suggestion to directly terminate
> the old subflow via RST is solely a short cut.
>

How does it _know_ the old interface is gone?  What if it's back in
milliseconds?

That seems to be more like quick failover (e.g.
draft-nishida-tsvwg-sctp-failover) than multipath.

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 26 May 2011 11:00:57 -0500

Scott, Olivier, Yoshifumi,

In summary, the expected behavior is: When a new IP address appears, a new subflow can/should/may be set up right away. When an IP address disappears, the affected subflows should stay on since the IP address may come back again. If necessary, NATs and firewalls can be closed later via the backdoor (i.e. REMOVE_ADDR + RST). A BBM on lower layers therefore becomes a MBB on L4.

What should a host do when its peer FINs or RSTs the only existing subflow without terminating the data connection? I guess the answer is: Wait and see. May be the peer MP_JOINs a new subflow soon!

Georg

________________________________
From: Scott Brim [mailto:[email-masked]]
Sent: Wednesday, May 25, 2011 2:23 PM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; Yoshifumi Nishida; [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

On Wed, May 25, 2011 at 10:31, Hampel, K Georg (K Georg) <[email-masked]<mailto:[email-masked]>> wrote:
I understand your concerns. However, if a BBM scenario occurs, it is always a signal from L2/L3 that triggers events on higher layers. If such a signal occurs, L4 is better advised to react quickly. This means that it should start the new subflow right way and immediately retransmit outstanding data on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it knows that the old interface is gone. My suggestion to directly terminate the old subflow via RST is solely a short cut.

How does it _know_ the old interface is gone?  What if it's back in milliseconds?

That seems to be more like quick failover (e.g. draft-nishida-tsvwg-sctp-failover) than multipath.