Subject: [multipathtcp] new tcpcrypt draft available

From: Andrea Bittau <[email-masked]>
Date: Sun, 16 Feb 2014 14:54:18 -0800

Hi,

For those interested, we posted a revised version of the tcpcrypt
draft (opportunistic TCP encryption):

http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt

This will be discussed on Monday morning in tcpm, at the end of
Session 1 (09:00--11:30).

All comments are welcome, including any points that you'd like us to
address in our presentation.

thanks!

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 17 Feb 2014 12:55:52 +0100

Hello Andrea,

> address in our presentation.

I think it would be important to consider moving the MAC from the TCP
options space to the payload (similar to an SSL-record) to allow support
for TSO and segment splitting middleboxes and to avoid using up all the TCP
option space.

Cheers,
Christoph

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 17 Feb 2014 12:06:16 +0000

FYI - this could matter to tcpm as well

> -----Original Message-----
> From: multipathtcp [mailto:[email-masked]] On Behalf Of
> Christoph Paasch
> Sent: Monday, February 17, 2014 12:56 PM
> To: Andrea Bittau
> Cc: [email-masked]
> Subject: Re: [multipathtcp] new tcpcrypt draft available
> 
> Hello Andrea,
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Feb 2014 10:13:36 -0800

FYI that trick was discussed for multipath tcp.  See their archives goe the reasons this isn't a good approach. 

Joe

> On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)" <[email-masked]> wrote:
>

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 17 Feb 2014 20:08:12 +0100

> the reasons this isn't a good approach. 

Oh indeed - I realize that the tcpcrypt draft mandates the MAC on every
packet (even on empty acknowledgments).

If the MAC would only be used on packets with data, then it would have been fine.

The problem for MPTCP was (if I remember correctly from the archives) because a
zero-window announcment would prevent acknowledgments on the return-path.

I think there is a second point of discussion for tcpcrypt:

Is it really worth to enforce the MAC on non-data segments?

Cheers,
Christoph

> > On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)"
> > <[email-masked]> wrote:
> > 
> >> -----Original Message----- From: multipathtcp
> >> [mailto:[email-masked]] On Behalf Of Christoph Paasch
> >> Sent: Monday, February 17, 2014 12:56 PM To: Andrea Bittau Cc:
> >> [email-masked] Subject: Re: [multipathtcp] new tcpcrypt draft
> >> available
> >> 
> >> Hello Andrea,
> >> 
> >>> On 16/02/14 - 14:54:18, Andrea Bittau wrote: For those interested, we
> >>> posted a revised version of the tcpcrypt draft (opportunistic TCP
> >>> encryption):
> >>> 
> >> options space to the payload (similar to an SSL-record) to allow
> >> support for TSO and segment splitting middleboxes and to avoid using up
> >> all the TCP option space.
> >> 
> >> 
> >> Cheers, Christoph
> >> 
> >> _______________________________________________ multipathtcp mailing
> >> list [email-masked]
> > _______________________________________________ multipathtcp mailing
> > list [email-masked]
> _______________________________________________ tcpm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Feb 2014 11:18:45 -0800

> On Feb 17, 2014, at 11:08 AM, Christoph Paasch <[email-masked]> wrote:
> 

Star the multipath archives. That still won't work. 

> Is it really worth to enforce the MAC on non-data segments?
 
If not you're using TLS. Securing the control bits ought to be equally important, though I have other problems with this draft
Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Feb 2014 11:31:22 -0800

> On Feb 17, 2014, at 11:18 AM, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> Star

See. Not star.  Sorry for the autocorrect. 

> the multipath archives. That still won't work. 
> 
>>

---

From: Andrea Bittau <[email-masked]>
Date: Mon, 17 Feb 2014 22:07:45 -0800

Here's our current thinking on the MAC option and TSO:

As already mentioned, including in the MAC in the payload has its
complications like pure ACKs.  Also, we wanted to stay as "clean" as
possible and not mix metadata and payload throughout the TCP
connection.  We do want to MAC control bits, and possibly even empty
RST packets.  Having the MAC as an option also makes it possible to
immediately MAC-check and decrypt packets that arrive out of order.
Having the MAC in payload would change TCP implementations quite
significantly and we did not want to over complicate things.  Having
it as an option felt more natural, and certainly simpler.

As for limited option space, especially in the context of mptcp, we
need to understand mptcp better and see if we can come up with a
compact integration.  We do intend to discuss this at the IETF meeting
to see if this will be a fundamental problem.

TSO: in the context of tcpcrypt, we're using the CPU to MAC and
encrypt every payload byte, and that operation will be the bottleneck
compared to (software-based) segmentation.  The offload probably won't
buy you much.  We'd love to offload the crypto in next-generation
TSOs, though! ;D

Of course our current design does not work with middleboxes that
coalesce or split packets.  If this proves to be an issue, we need to
redesign.

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 18 Feb 2014 08:10:56 +0000

Hi,

On 2014-2-18, at 7:07, Andrea Bittau <[email-masked]> wrote:
> buy you much.

I'd really like to see this benchmarked. Modern CPUs can do crypto quite efficiently, but the 40x call chain overheads without TSO are killer.

Lars

---

From: Andrew Mcgregor <[email-masked]>
Date: Tue, 18 Feb 2014 20:20:52 +1100

Although, TSO doesn't buy you that much on a WAN connection where tcpcrypt
is more useful.  Take a look at the TSO autotuning in recent linuxen, and
realise that it's backing the TSO segment size right down in typical wide
area situations.

On 18 February 2014 19:10, Eggert, Lars <[email-masked]> wrote:

> I'd really like to see this benchmarked. Modern CPUs can do crypto quite
> efficiently, but the 40x call chain overheads without TSO are killer.
>
> Lars
>

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 1071 2221

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 18 Feb 2014 09:54:03 +0000

>> zero-window announcment would prevent acknowledgments on the return-path.

As individual contributor to TCPM, I wonder if it would be worthwhile to expand on this a little bit further. tcp-crypt apparently uses both options and payload for signaling (in one specific case).

I don't recall all the past discussions of option vs. payload encoding in MPTCP, but out of my head a number of advantages of using options in MPTCP were:

(1) A structure in the payload would typically need an additional memory copy operation in the kernel and thus result in overhead, unlike options

(2) An option-based MPTCP architecture facilitate a basic, single-path MPTCP-capable endpoints ("bump-in-the-wire")

(3) Clearer semantics of the TCP receive window (in particular if rwnd is small, deadlock situations have to be considered)

(4) Payload is more difficult to parse in TSO engines

Now, I wonder whether (1)-(4) applies to tcp-crypt, too?

> If not you're using TLS. Securing the control bits ought to be equally important, though I have other problems with this draft

As a non-security expert I would like to better understand: Is there something missing in TCP-AO regarding securing control bits?

Thanks, and sorry for my potentially naive questions

Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 08:28:51 -0800

> Now, I wonder whether (1)-(4) applies to tcp-crypt, too?

It also presents a very simple DOS attack vector - "find the MAC".

FWIW, I'm not at all concerned about this not supporting rewriting engines. As I noted for TCP-AO, rewriting and resegmenting are the kinds of attacks a TCP-level security mechanism ought to protect against.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 18 Feb 2014 20:09:27 +0000

> It also presents a very simple DOS attack vector - "find the MAC".

Maybe I am really naïve/stupid/tired right now, but could you explain a bit more what the DoS attack vector actually is? Do you refer to a scenario where the MAC covers several segments and has to be verified before byte stream reassembly?

Thanks

Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 13:06:15 -0800

On 2/18/2014 12:09 PM, Scharf, Michael (Michael) wrote:
> Maybe I am really naïve/stupid/tired right now, but could you
> explain  a bit more what the DoS attack vector actually is? Do you refer to a
> scenario where the MAC covers several segments and has to be verified
> before byte stream reassembly?

You have to parse the entire data body to find the MAC location, rather 
than having it in a fixed, known place.

A body that you really shouldn't be looking at until you process the header.

FYI, another issue - what happens if two options try this trick (bury 
control in the data body)?

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 18 Feb 2014 21:34:49 +0000

Ok, so we actually have two (hypothetical) variants, right?

a) The protocol buries the MAC in the payload of (every?) segment, and it defines a way how to find the MAC therein (e.g., it is always the first/last bytes of the segment). At first sight, this is not very different to any extension of the TCP option header (long options).

b) The protocol runs its own framing in the payload, but finding the MAC may then obviously require body reassembly and potentially requires in-order-delivery (what about TCP Minion?).

Michael

________________________________________
Von: Joe Touch [[email-masked]]
Gesendet: Dienstag, 18. Februar 2014 22:06
An: Scharf, Michael (Michael)
Cc: Christoph Paasch; [email-masked]; [email-masked]
Betreff: Re: [tcpm] [multipathtcp] new tcpcrypt draft available

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 13:42:45 -0800

On 2/18/2014 1:34 PM, Scharf, Michael (Michael) wrote:
> a) The protocol buries the MAC in the payload of (every?) segment,
> and it defines a way how to find the MAC therein (e.g., it is always
> the first/last bytes of the segment). At first sight, this is not
> very different to any extension of the TCP option header (long
> options).

That's not the case I was concerned about; if it's fixed, it's basically 
the same as if it is in the header (except that you have to access the 
body to get to it, but you have to access the body to verify the MAC 
anyway).

> b) The protocol runs its own framing in the payload, but finding the
> MAC may then obviously require body reassembly and potentially requires
> in-order-delivery (what about TCP Minion?).

That's the case I am thinking about; I can't see how you can get away
with not running your own framing over the body for a number of reasons.

And I won't speculate about the interaction of two protocols I don't see 
as viable individually.

Joe