> "Scharf, Michael (Michael)" <[email protected]> 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.
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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
