Re: [tcpm] [multipathtcp] new tcpcrypt draft available

[Andrea Bittau <[e-mail]>]

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.


On Mon, Feb 17, 2014 at 11:31 AM, Joe Touch <[e-mail]> wrote:
>
>
>> On Feb 17, 2014, at 11:18 AM, Joe Touch <[e-mail]> wrote:
>>
>>
>>
>>>> On Feb 17, 2014, at 11:08 AM, Christoph Paasch <[e-mail]> wrote:
>>>>
>>>> On 17/02/14 - 10:13:36, Joe Touch wrote:
>>>> FYI that trick was discussed for multipath tcp.  See their archives goe
>>>> 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.
>>
>> Star
>
> See. Not star.  Sorry for the autocorrect.
>
>
>> the multipath archives. That still won't work.
>>
>>>
>>> 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?
>>
>> If not you're using TLS. Securing the control bits ought to be equally important, though I have other problems with this draft
>> Joe
>>
>>>
>>>
>>> Cheers,
>>> Christoph
>>>
>>>
>>>>> On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)"
>>>>> <[e-mail]> wrote:
>>>>>
>>>>> FYI - this could matter to tcpm as well
>>>>>
>>>>>> -----Original Message----- From: multipathtcp
>>>>>> [mailto:[e-mail]] On Behalf Of Christoph Paasch
>>>>>> Sent: Monday, February 17, 2014 12:56 PM To: Andrea Bittau Cc:
>>>>>> [e-mail] 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):
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________ multipathtcp mailing
>>>>>> list [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>>>>
>>>>> _______________________________________________ multipathtcp mailing
>>>>> list [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>>>
>>>> _______________________________________________ tcpm mailing list
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp