On 3/16/2015 8:21 AM, Tero Kivinen wrote: > 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).
If someone can block TCPINC signalling, they can create any DOS attack they want anyway. Attacker effectiveness isn't increased, just the number of ways an attacker can achieve the same result with the same vulnerability. > 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. Once you support NAT interaction, you are open to DOS. Again we're back to whether the protection increases the effectiveness of the attacker given the same vulnerability. > 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. You recover from the additional attacks you're vulnerable to faster. That means your overall vulnerability increased. Don't have a party about it, IMO. > "Protect against" and "prevent" do have different meanings, > preventation is not the only form of protection as Stephen Farrell put > it. Agreed. Prevention is a-priori. > 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. It happens, esp. during incremental deployment. That's part of why farms use stateful load distribution. > 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). You do realize that having a mechanism that tells you when to accept or ignore FINs *is* header protection, the very protection you just decided you don't want or need? You can't do that with conventional TLS - TLS is carried over TCP, and TCP would have processed the FIN before TLS knew about it. If this is header-based TLS, then that TLS *is* protecting the header. So which is it? >>> 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. Sorry - TCP keepalives. As per RFC1122, Sec. 4.2.3.6. > 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. Yes, for off-path attacks. Not all RST attacks are blind, though, and we all continue to use shared nets where snooping is possible. > 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. Yes, but that would be outside the scope of solutions here, no? > 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. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
