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