Subject: [multipathtcp] Integration with SSL

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Jul 2009 17:36:43 +0200

We have two security mechanisms in the IETF: IPsec and SSL/TLS. One is  
very secure, the other one is widely used.

With IPsec, every packet is authenticated independently, which causes  
huge overhead but means we don't have any issues in the multipath  
case. SSL on the other hand exchanges blocks of data over TCP which  
are then authenticated. If there is an authentication failure you  
break the session and at least you know you didn't accept any bad data.

However, in the multipath case we can do more: if we make sure that  
every block of SSL data is only sent over a single path, and then we  
get an authentication failure, we have the opportunity to shut down  
the path with the failure and keep the other one open. That would be  
more robust.

However, this requires integrating SSL and MPTCP and we may also need  
a way to get SSL to retransmit the data that failed to authenticate  
over another path... This seems like a lot of work.

Another interesting prospect: SSL comes with a PKI of sorts. If we can  
reuse the security stuff negotiated by SSL to secure MPTCP  
interactions we don't have to come up with new security infrastructure  
for the two-ended multipath TCP (when SSL is used, at least).

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 2 Jul 2009 20:40:33 +0200

Hi Iljutsch,

have you looked at running DTLS/MTCP? It has the similar security  
features
than TLS but does not required in-sequence delivery and complete message
transfer.

We use it for securing SCTP traffic using multiple streams.

Best regards
Michael

On Jul 2, 2009, at 5:36 PM, Iljitsch van Beijnum wrote:

> We have two security mechanisms in the IETF: IPsec and SSL/TLS. One  
> is very secure, the other one is widely used.
>
> With IPsec, every packet is authenticated independently, which  
> causes huge overhead but means we don't have any issues in the  
> multipath case. SSL on the other hand exchanges blocks of data over  
> TCP which are then authenticated. If there is an authentication  
> failure you break the session and at least you know you didn't  
> accept any bad data.
>
> However, this requires integrating SSL and MPTCP and we may also  
> need a way to get SSL to retransmit the data that failed to  
> authenticate over another path... This seems like a lot of work.
>
> Another interesting prospect: SSL comes with a PKI of sorts. If we  
> can reuse the security stuff negotiated by SSL to secure MPTCP  
> interactions we don't have to come up with new security  
> infrastructure for the two-ended multipath TCP (when SSL is used, at  
> least).
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Jul 2009 14:01:19 +0200

Iljitsch van Beijnum skrev:
> huge overhead but means we don't have any issues in the multipath case.
> SSL on the other hand exchanges blocks of data over TCP which are then
> authenticated. If there is an authentication failure you break the
> session and at least you know you didn't accept any bad data.
> 
> every block of SSL data is only sent over a single path, and then we get
> an authentication failure, we have the opportunity to shut down the path
> with the failure and keep the other one open. That would be more robust.
> 
> However, this requires integrating SSL and MPTCP and we may also need a
> way to get SSL to retransmit the data that failed to authenticate over
> another path... This seems like a lot of work.
> 
> reuse the security stuff negotiated by SSL to secure MPTCP interactions
> we don't have to come up with new security infrastructure for the
> two-ended multipath TCP (when SSL is used, at least).

Iljitsch, isn't TCP Authentication Option another possible mechanism
that could be used by MP-TCP? It falls closer to IPsec in that it
doesn't allow NATs to modify anything in the header.

https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-auth-opt/

The keying of TCP AO is also question mark where several different
approaches are possible but not really specified.

Then at least we consider all the possible places to secure TCP, under
it, in it and over it. I am certain that likely all models are going to
be needed in the end.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Jul 2009 21:12:54 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Monday, July 06, 2009 5:01 AM
> To: Iljitsch van Beijnum
> Cc: [email-masked]
> Subject: Re: [multipathtcp] Integration with SSL
> 
> interactions

TCP-AO doesn't work over NATs, which was a design decision to 
reduce the complexity of the protocol and to avoid sending 
additional bits on the wire.  I objected to this decision,
but consensus was to ignore NATs.
http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-05#section-11.2

I expect multipath TCP wants to work over NATs, so if TCP-AO is
on the table we would also need to enhance TCP-AO to work across
NATs.

-d

> it, in it and over it. I am certain that likely all models 
> are going to be needed in the end.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Jul 2009 23:38:58 -0700

Dan Wing wrote:
...
> http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-05#section-11.2

TCP-AO is intended to protect against the kind of modification a NAT
performs. It can be encapsulated to traverse a NAT, just like nearly any
other protocol including IPsec, however.

Note that TCP-AO does permit the non-AO options to be ignored, which can
help in traversing option-modifying middleboxes.

> on the table we would also need to enhance TCP-AO to work across

It might be useful to show how multipath TCP makes sense over NATs
first, since NATs could destroy the multipathing.

Joe

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 9 Jul 2009 09:17:21 +0200

> on the table we would also need to enhance TCP-AO to work across
As said in an earlier e-mail: Have a look at DTLS/M-TCP. Use
it similar to DTLS/SCTP, but with SCTP-AUTH, since MTCP does not
have something like PR-SCTP.

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Jul 2009 00:18:09 -0700

> performs. It can be encapsulated to traverse a NAT, just like 
> nearly any other protocol including IPsec, however.

Yes, I recall that argument.  I still disagree with that argument.

> Note that TCP-AO does permit the non-AO options to be 
> ignored, which can help in traversing option-modifying 
> middleboxes.
> 

Iljitsch's one-ended multipath, draft-van-beijnum-1e-mp-tcp-00, would 
work with a NAT in front of the subscriber's computer.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 10:47:02 +0200

> work with a NAT in front of the subscriber's computer.

Right. As long as you avoid having different NAT applied on the  
different paths there are no issues.

I've also been thinking about a way to extend the one-ended MPTCP into  
a simple two-ended MPTCP that can actually take advantage of NAT. In  
multi6/shim6 we used to talk about "basement multihomers", which would  
be people with two regular consumer type broadband connections, for  
instance, one cable and one ADSL. Those users would have two NATs for  
IPv4. An MPTCP would be able to take advantage of that by talking to  
the same destination through both NATs. It would work something like  
this:

- client sends SYN over one path with MPTCP capability in it
- server responds with SYN/ACK with the MPTCP capability in it
- client ACKs the SYN/ACK and also sends a copy of the SYN over the  
other path
- server sees that the other SYN belongs to the session created  
before, sends SYN/ACK
- client ACKs the SYN/ACK
- data packets are distributed over the two (or more paths)
- every path is given a packet per window to advance the window

This obviously requires both ends to be MPTCP but it doesn't require  
the complex address negotiation in Alan's draft. I think it can also  
work most of the time without a second sequence number space.

It would be helpful if different capabilities, such as the ability to  
bond additional implicitly created "sessions" as per the above, the  
ability to negotiate addresses explicitly and the ability to have a  
second sequence number space all individually, so there is a smooth  
upgrade path from basic MPTCP to a more fully featured MPTCP, where  
implementations with different capabilities can work together.

---

From: Scott Brim <[email-masked]>
Date: Thu, 09 Jul 2009 07:03:17 -0400

> first, since NATs could destroy the multipathing.

Joe, what do you mean, "makes sense"?  Do you mean how it would work?

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2009 07:35:41 -0700

Iljitsch van Beijnum wrote:
> I've also been thinking about a way to extend the one-ended MPTCP into a
> simple two-ended MPTCP that can actually take advantage of NAT. In
> IPv4. An MPTCP would be able to take advantage of that by talking to the
> same destination through both NATs. It would work something like this:
> 
> - server sees that the other SYN belongs to the session created before,
> sends SYN/ACK

How does that happen? The first SYN was translated. What makes the
second SYN look like the first one, i.e., it could be translated
differently (by a different NAT or the same NAT)?

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 16:42:36 +0200

On 9 jul 2009, at 16:35, Joe Touch wrote:

>> before,

> differently (by a different NAT or the same NAT)?

There would have to be a cookie in the SYN packet.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Jul 2009 08:00:11 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Thursday, July 09, 2009 7:43 AM
> To: Joe Touch
> Cc: Dan Wing; [email-masked]

This isn't a problem created by NAT.

The same problem (and solution) exists as without NAT, where the client system
has two interfaces -- one interface (e.g., 802.11) with an IPv4 address from
the ADSL provider and another interface (e.g., wired ethernet) from the cable
provider.

-d

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2009 08:48:51 -0700

> the ADSL provider and another interface (e.g., wired ethernet) from the cable

In a system with two interfaces, you can know how to emit the SYN over
the "other path". In a system with some NATs, it's not always possible
to know where paths are.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Jul 2009 09:00:13 -0700

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Thursday, July 09, 2009 8:49 AM
> To: Dan Wing
> Cc: 'Iljitsch van Beijnum'; [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Dan Wing wrote:
> >  
> > 
> > the ADSL provider and another interface (e.g., wired 
> > ethernet) from the cable provider.
> 

I will agree with you all day that NATs break things and NATs add complexity.

My point was that NATs do not create the need for Iljitsch's suggestion to put
a cookie in the SYN; a PC with two interfaces to two ISPs (and no NAT on the
path) will need to send the same cookie in the SYN.

-d

> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkpWEWMACgkQE5f5cImnZrvl9ACfeO18FR7D56NbfZIt8y8++pgm
> iFYAoOz3gBkf6rkn9PhteZnxvaqXu4BJ
> =JTmZ
> -----END PGP SIGNATURE-----

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 18:08:59 +0200

On 9 jul 2009, at 18:00, Dan Wing wrote:

> My point was that NATs do not create the need for Iljitsch's  
> suggestion to put a cookie in the SYN; a PC with two interfaces to  
> two ISPs (and no NAT on the path) will need to send the same cookie  
> in the SYN.

Indeed.

The reason why I jumped on the NAT here is because if you want to do  
explicit address negotiation, the no NAT no firewall case is simple,  
but things get complex fast when you add middleboxes. With the  
implicit system I outlined, NAT doesn't introduce additional  
complexities.

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2009 09:32:29 -0700

Dan Wing wrote:
...
>> path) will need to send the same cookie in the SYN.

I'm wondering if the ISN is the cookie you need or if you need a longer one?

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Jul 2009 10:05:07 -0700

> I'm wondering if the ISN is the cookie you need or if you 

IPv4 addresses are also 32 bits long and many things use 
IPv4 addresses as 'identity'.  So the ISN could be sufficient.

I notice that both Windows and FreeBSD send the initial
SYN with the ACK=0.  I don't know if there is a reason or
purpose for setting ACK=0 in the initial SYN; but that
might be a safe place to encode another 32 bits.

-d

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2009 10:36:07 -0700

> IPv4 addresses as 'identity'.  So the ISN could be sufficient.

IP/port pair is 6 bytes, though (see below) there might be another place
for the port. That presumes only the source IP/port is altered, though.

> might be a safe place to encode another 32 bits.

The Urgent field too, when URG=0.

That presumes that implementations correctly ignore these fields, rather
than making assumptions about them ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2009 11:30:07 -0700

> Joe, what do you mean, "makes sense"?  Do you mean how it would work?

How it would work is a solution.

Makes sense just requires explaining how a solution could exist. If you
multipath and both paths go through a NAT, even if the paths have
different properties, the question is whether you can detect the
existence of the different paths, and whether you can control the
segments you send to determine which path they would use.

If you can't do both, a solution isn't worth looking for, AFAICT.

Joe

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sat, 11 Jul 2009 05:27:24 +0200 (CEST)

> IPv4 addresses as 'identity'.  So the ISN could be sufficient.

...unless there's a firewall in the middle randomizing the ISN.

What about the TSVal within the timestamp option ?

(Probably the TSVal in the second SYN would need to go via a PRF, and 
via the reverse PRF on the receiver side to do a check - because we can't 
assume the timestamps are uniformly distributed?).

thanks,
andrew

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sat, 11 Jul 2009 05:39:41 +0200 (CEST)

On Sat, 11 Jul 2009, Andrew Yourtchenko wrote:

> (Probably the TSVal in the second SYN would need to go via a PRF, and via the 
> reverse PRF on the receiver side to do a check - because we can't assume the 
> timestamps are uniformly distributed?).

ugh. re-reading my own mail - the presence or absence of PRF won't change 
a thing. So if the TSVal received from the different peers is not 
distributed randomly, too bad.

thanks,
andrew

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 12 Jul 2009 13:57:26 -0700

> From: Andrew Yourtchenko [mailto:[email-masked]] 
> Sent: Friday, July 10, 2009 8:27 PM
> To: Dan Wing
> Cc: 'Joe Touch'; [email-masked]

Ugh.  Good point.

-d

---

From: Costin Raiciu <[email-masked]>
Date: Mon, 27 Jul 2009 14:58:24 +0200

Iljitsch,

Please read the design decisions document we've made available. The  
reason we've included the complex looking explicit address signaling  
is because implicit signaling as you propose below does not work in  
all cases; fixing it to work in all cases effectively requires  
explicit signaling.

As for the separation of sequence numbers, this has been a long- 
standing discussion. We know there are cases where using a single  
sequence number space does not work. Why are we still talking about  
this in the 2-ended case? In the single ended case, where there is no  
choice to have multiple sequence spaces, we have to live with single  
seq space.

As for integrating one-ended with two ended, the difference resulting  
from one sequence space  vs multiple sequence spaces is big enough  
that you effectively need "switch" from one to the other. The only  
way I see is to make them working together is to use the MPTCP  
negotiation in the beginning. For instance:
1. Start with MTCP capable option in the SYN
2. If the other end replies with MPATH capable, then use 2-ended  
algorithm.
3. If the other end doesn't include MPATH capable in his SYN, use one- 
ended mpath if you can.

Is there more to that?

Cheers
Costin

> I've also been thinking about a way to extend the one-ended MPTCP  
> into a simple two-ended MPTCP that can actually take advantage of  
> NAT. In multi6/shim6 we used to talk about "basement multihomers",  
> which would be people with two regular consumer type broadband  
> connections, for instance, one cable and one ADSL. Those users  
> would have two NATs for IPv4. An MPTCP would be able to take  
> advantage of that by talking to the same destination through both  
> NATs. It would work something like this:
>
> This obviously requires both ends to be MPTCP but it doesn't  
> require the complex address negotiation in Alan's draft. I think it  
> can also work most of the time without a second sequence number space.
>
> It would be helpful if different capabilities, such as the ability  
> to bond additional implicitly created "sessions" as per the above,  
> the ability to negotiate addresses explicitly and the ability to  
> have a second sequence number space all individually, so there is a  
> smooth upgrade path from basic MPTCP to a more fully featured  
> MPTCP, where implementations with different capabilities can work  
> together.