Joe Touch writes: > Although I can't disagree with your assessment of the direct discussion > on protecting TCP headers, the conclusion below seems to ignore the > discussion on "Forcing the restart of a TCPINC connection".
Breaking TCP connections is active attack. 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 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. 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. Also if the certificate / raw public key or similar changes after the restart, we again now something is fishy there. The question is what do we do for that? We simply assume that as this is opportunistic we do not care, and continue. We might give some indication to user (warnings are usually bad, put some people might want to configure them on). We might stop communicating and convert that attack to DoS attack. And I think there might be even more things... 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. 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. I.e. there are ways to get some protection for those even when we do not protect TCP header, but what of those methods can be used and will be used, depends on the solution we are going to use, and the protocol we define needs to explain what it tries to protect and how. So I do not consider it impossible to provide limited support against TCP resets or FINs, or downgrade attacks even when we do not protect TCP header. -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
