On Mon, Aug 18, 2014 at 03:52:07PM -0700, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Mon, Aug 18, 2014 at 15:42 -0700: > > I have reviewed the security considerations on the other proposals, > > and I must say that they need to be fleshed out... The TLS one is > > especially lacking in details... It says nothing about various attacks > > that it is vulnerable to... The others aren't much better... > > Just for the proposals, I feel that a minimum of the following should > be included in the security considerations section: > > 1. What happens upon spoofed packets, including fake and replayed > packets > 2. What happens upon deleted data > 3. How are attackers able to force close your connection, if any. > > I'm sure others have ideas of what should be included.
Requirements are needed too. I realize now that we can't expect to defend well against RST attacks, as they are a DoS attack after all. A sufficiently well-equiped and positioned adversary can just stop all bits moving for the given connection or client/server pair. I'm having a harder time with confidentiality-but-not-integrity protection for the octet streams though. IMO integrity protection for the octet streams has to be a requirement, so that the answers to (1) must be "replays are detected and dropped" and "fake segments are dropped", while the answer to (2) must be the same as for plain TCP. Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
