Joe Touch writes: > On 3/12/2015 2:23 AM, Tero Kivinen wrote: > > There is ways we can protect against the forcing restart of the tcpinc > > connection that does not include protecting headers, but they cannot > > really prevent them, they can just convert them to full scale DoS... > > I cannot make any sense of the following concurrent claims: > "protect against the forcing restart" > "cannot really prevent them,"
In most cases if we try too hard to protect against some things, we just makes other attacks easier. I.e if we always assume other end has tcpinc and will never talk in clear text, and will never restart in clear, that will protect against attackers forcing restart to lower security, but that might cause very easy denial of service attack against us, by just blocking tcpinc signaling, in which case we didn't prevent the attack, we just made it different (worse or easier etc). Another example was given by others, i.e. even if the implementation completely had protection for RST flag, but if NATs act on them, it would still protect us against forced restart, but on the other hand it would again allow easy DoS. If we would actually act on the RST the situation would be better, as then we could recover faster, i.e. immediately when we notice that connection is gone, and we would not need to wait for keepalive timers or similars to kick in. > Either you can protect against them or you cannot. "Protect against" and "prevent" do have different meanings, preventation is not the only form of protection as Stephen Farrell put it. We had this dicussion earlier on this list http://www.ietf.org/mail-archive/web/tcpinc/current/msg00445.html > >> I wonder how people think their solution will magically protect against > >> forced restarts if the TCP header isn't included. > > > > We cannot protect against forced restarts, but we can protect against > > downgrade attacks. > > A forced restart can be used as part of a downgrade attack, but it has > other purposes, notably disrupting communications while off-path. Which would most likely need different approach to protect against. > > I.e. using DNS (DANE) or some other method to > > signal that other end support tcpinc, and then if we actually manage > > to make first tcpinc connection to the peer, but then got tcp > > connection broken down and the next connection do not suddenly support > > tcpinc, we know something is fishy here. > > That presumes all TCP endpoints sharing an IP address are identical and > use identical paths. Partially yes. They do not need to be identical, but they all need to allow passing tcpinc through. > I.e., you could have been sent to a different endpoint (load balancing > at a server farm) that doesn't support TCPINC. And why would any sane people ever willingly end up configuring their system like that. And even if they would, it still looks that something is wrong there. Yes, the one load balancing server might be under control of TLA and thats why it does not support TCPINC, but that is even more the reason to try to use those which work... > Your path to that endpoint could also have changed to go over one that > no longer supports TCPINC. Yes, which would convert this to DoS. As I said in the beginning. Depending how much we want to protection against some attacks, will affect how easy it is to cause DoS against us too. All of these are compromises... > > Also some kind of protecting against TCP resets or FINs is possible > > even when we do not protect tcp headers. For example if we use TLS we > > might ignore FINs unless we have cleanly shut down the TLS before. > > In that case, you'd be protecting the TCP connection against useful > resets too. No. I said we can ignore FINs, I didn't say RST. If the other end has properly implemented TCPINC and TCPINC is using TLS and the text says it MUST do close notify before FIN is accpeted, then we can ignore FINs for TCPINC sessions which have not yet received close notify from other end (note, this is again just an example of one way to solve some parts of this problems using the information we have inside the tcp stream, without explictly protecting TCP flags). > > For the resets we might send keepalive for the TCP connection > > instead of tearing it down immediately. We the keepalive confirms > > the connection is still alive, we can ignore the reset etc. > > You then have to ask whether the keepalive is more important than the > reset. Wouldn't an attacker then just send a keepalive? If you don't > protect the header, you're back where you started, aren't you? Depending what you mean by keepalive. I.e off-path attackers most likely cannot send keepalive as they do not know sequence numbers etc, thats why they did blind RST attack. On the other hand if that is important thing to protect against we can make that keepalive not to be TCP keepalive, but inner layer protocol frame, i.e. in TLS case it could be some kind of heartbeat extension packet or similar. I am not trying to design the protocol here in this email, I am saying that I at least think there are solutions we can do that will solve some (or all) of those issues, even when we do not protect TCP headers. Which subset the "some of those issues" is going to be and what kind of protection we are going to provide, depends on the actual protocol we are going to use, and what we feel is importan to provide protection for. -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
