Subject: [multipathtcp] A query about DSS Option

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Fri, 9 Jun 2017 08:46:59 +0530

Hi All,

I have two questions for the group for clarification.

1. Assume that MPTCP connection has to fallback to regular TCP because 
of payload modification
by a middlebox. But I understand that payload modification risk is still 
there for the regular
TCP connection. In case of regular TCP there is no way for the end-host 
to find out that payload
is modified when the middlebox accordingly changes the checksum. That 
way the ability of the DSS Option to provide protection is very 
specific: so long as DSS Option can be enforced there is protection and 
when infinite mapping is to be enforced the protection disappears. So it 
appears to me that this feature is
not very general.

2. Let us consider the simplest case of a MPTCP connection that consists 
of just one subflow. I open the initial subflow for the MPTCP connection 
and then successfully negotiated the DSS
Option. Now until the time I open the second subflow, the DSS Option is 
only providing protection against
potential payload modification at the cost of control overhead because 
DSNs are unnecessary until the time
I open the second subflow, at least in principle. We need to keep in 
mind that this protection is available
to only those segments to which the DSS Option is attached. Because when 
a DSS Option covers large enough data
then we do not have to append DSS Option to every segment, thus saving 
on overhead. Then what about those segments to which DSS Option is not 
attached ? But the specification suggests that the DSS Option be sent 
frugally. So in other words, the protection that MPTCP design provides 
through the DSS Option is on/off. Also, there is no reason why one 
should provide protection selectively. So one needs to append the DSS 
Option to every segment which does not make much sense to me. First of 
all, I am not sure whether the DSS Option providing protection against 
payload modification is a stated goal of MPTCP.  But I like to 
understand that
the ability of DSS Option providing protection is an off-shoot of its 
intended design.

I thank you all in advance!

Best Regards,
-Sayee

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Alan Ford <[email-masked]>
Date: Sun, 11 Jun 2017 23:43:03 +0100

Hi Sayee,

To clarify - MPTCP is not attempting to prevent payload modification (for that, you should use encryption). The purpose of the checksum is to alert the MPTCP stack to any middleboxes which are not MPTCP aware and have potentially broken the MPTCP data flow by altering the payload and thus broken segment boundaries.

For example, if a NAT replaces “10.0.0.1” with “192.168.0.1” in the payload, that is now three bytes longer. The DSS mappings would no longer match the new length of the payload and without the checksum, the MPTCP stack would reassemble incorrectly and deliver garbage data to the application. The purpose of the checksum is purely to avoid this situation.

Regards,
Alan

> On 9 Jun 2017, at 04:16, Sayee Kompalli Chakravartula <[email-masked]> wrote:
> 
> Hi All,
> 
> 1. Assume that MPTCP connection has to fallback to regular TCP because of payload modification
> by a middlebox. But I understand that payload modification risk is still there for the regular
> TCP connection. In case of regular TCP there is no way for the end-host to find out that payload
> is modified when the middlebox accordingly changes the checksum. That way the ability of the DSS Option to provide protection is very specific: so long as DSS Option can be enforced there is protection and when infinite mapping is to be enforced the protection disappears. So it appears to me that this feature is
> not very general.
> 
> 2. Let us consider the simplest case of a MPTCP connection that consists of just one subflow. I open the initial subflow for the MPTCP connection and then successfully negotiated the DSS
> Option. Now until the time I open the second subflow, the DSS Option is only providing protection against
> potential payload modification at the cost of control overhead because DSNs are unnecessary until the time
> I open the second subflow, at least in principle. We need to keep in mind that this protection is available
> to only those segments to which the DSS Option is attached. Because when a DSS Option covers large enough data
> then we do not have to append DSS Option to every segment, thus saving on overhead. Then what about those segments to which DSS Option is not attached ? But the specification suggests that the DSS Option be sent frugally. So in other words, the protection that MPTCP design provides through the DSS Option is on/off. Also, there is no reason why one should provide protection selectively. So one needs to append the DSS Option to every segment which does not make much sense to me. First of all, I am not sure whether the DSS Option providing protection against payload modification is a stated goal of MPTCP.  But I like to understand that
> the ability of DSS Option providing protection is an off-shoot of its intended design.
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Sayee C. Kompalli" <[email-masked]>
Date: Mon, 12 Jun 2017 18:41:45 +0530

On Jun 12, 2017 4:13 AM, "Alan Ford" <[email-masked]> wrote:

Hi Sayee,

To clarify - MPTCP is not attempting to prevent payload modification (for
that, you should use encryption). The purpose of the checksum is to alert
the MPTCP stack to any middleboxes which are not MPTCP aware and have
potentially broken the MPTCP data flow by altering the payload and thus
broken segment boundaries.

I agree, I should have carefully chosen my wording.

For example, if a NAT replaces “10.0.0.1” with “192.168.0.1” in the
payload, that is now three bytes longer.

I didn't understand this; IPv4 address always occupies 4 bytes of memory.
Is it not?

The

 DSS mappings would no longer match the new length of the payload and
without the checksum, the MPTCP stack would reassemble incorrectly and
deliver garbage data to the application. The purpose of the checksum is
purely to avoid this situation.

Regards,
Alan

there for the regular
to find out that payload
> is modified when the middlebox accordingly changes the checksum. That way
the ability of the DSS Option to provide protection is very specific: so
long as DSS Option can be enforced there is protection and when infinite
mapping is to be enforced the protection disappears. So it appears to me
that this feature is
> then we do not have to append DSS Option to every segment, thus saving on
overhead. Then what about those segments to which DSS Option is not
attached ? But the specification suggests that the DSS Option be sent
frugally. So in other words, the protection that MPTCP design provides
through the DSS Option is on/off. Also, there is no reason why one should
provide protection selectively. So one needs to append the DSS Option to
every segment which does not make much sense to me. First of all, I am not
sure whether the DSS Option providing protection against payload
modification is a stated goal of MPTCP.  But I like to understand that
intended design.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 12 Jun 2017 13:40:53 -0700

On Mon, Jun 12, 2017 at 6:11 AM, Sayee C. Kompalli <[email-masked]
> wrote:

> I didn't understand this; IPv4 address always occupies 4 bytes of memory.

Not always. Some application protocols (e.g. ftp or protocols that exchange
SDPs) could use text format for IP addresses.
--
Yoshi