Subject: [tcpinc] Flow control in draft-bittau-tcpinc-tcpcrypt?

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 19 Nov 2014 10:42:01 +0000

Hi,

I try to understand what the approach suggested in draft-bittau-tcpinc-tcpcrypt will do if during INIT1/INIT2 exchange one side announces a receive window of either zero or not large enough to accommodate the data contained in INIT1/INIT2. 

Is it correct that INIT1/INIT2 data would not be controlled by TCP flow control (i.e., announced receive window), even though there is data in the TCP payload?

Do I miss something?

Thanks

Michael

---

From: David Mazieres <[email-masked]>
Date: Wed, 19 Nov 2014 14:30:51 -0800

"Scharf, Michael (Michael)" <[email-masked]> writes:

> Hi,
>
> I try to understand what the approach suggested in
> draft-bittau-tcpinc-tcpcrypt will do if during INIT1/INIT2 exchange
> one side announces a receive window of either zero or not large enough
> to accommodate the data contained in INIT1/INIT2.
>
> Is it correct that INIT1/INIT2 data would not be controlled by TCP
> flow control (i.e., announced receive window), even though there is
> data in the TCP payload?
>
> Do I miss something?

Good catch!  This absolutely needs to be specified in the draft.

Perhaps the simplest fix is to say that when the CRYPT options is used,
the initial window MUST be at least 500 bytes.  And then in the public
key table, specify longer minimum window sizes for certain ciphers.
(Basically including something in PKCONF should require a minimum window
size, then selecting it in INIT1 should similarly require a minimum
window size.)

Then it is safe to say clients MUST ignore the window for the purposes
of INIT1 and INIT2, since exceeding the window size will only happen
when the receiver has already exhibited illegal behavior.

David

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 21 Nov 2014 09:49:00 +0000

> when the receiver has already exhibited illegal behavior.

Wouldn't EDO (draft-ietf-tcpm-tcp-edo) be a solution for INIT1/INIT2 data instead of disabling TCP flow control, which is a key element of TCP?

Michael