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

> On Feb 17, 2014, at 11:08 AM, Christoph Paasch <christoph.paasch@uclouvain.be> 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 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)"
>>> <michael.scharf@alcatel-lucent.com> wrote:
>>> 
>>> FYI - this could matter to tcpm as well
>>> 
>>>> -----Original Message----- From: multipathtcp
>>>> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch
>>>> Sent: Monday, February 17, 2014 12:56 PM To: Andrea Bittau Cc:
>>>> multipathtcp@ietf.org 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 multipathtcp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>> 
>>> _______________________________________________ multipathtcp mailing
>>> list multipathtcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>> 
>> _______________________________________________ tcpm mailing list
>> tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm