Tero Kivinen <[email protected]> writes: > As we discussed in the meeting, everybody who cares about the > integrity protection of the services provided by the TCP headers > should send email to the list and explain why TCP header bit X should > be integrity protected, and what kind of attacks are possible if we do > not protect it.
I know I was pushing for discussion of particular header fields, but then someone (I thought it was you) made the excellent point that really what we care about are *functions*, and that the header bits may be one way to provide functions that could alternatively be provided some other way. So perhaps we should split the discussion into A) what functions do we want to secure, and B) which of those functions are best secured by protecting header bits. Here is my list of functions. At a high level, my goal is to ensure that *if you establish a tcpinc connection to the right host*, then the connection will behave as much as possible like vanilla TCP on a secure network, even in the presence of active attackers (provided they don't drop/mangle all of your packets). Of course, since it's opportunistic, you might connect to the wrong host, or you might use session IDs to ensure you are talking to the right host. * Payload integrity. This is a given, but I list it because it means either disabling urgent data or protecting the urgent data pointer. There do exist legacy applications that use urgent data. My linux system ships with GNU inetutils 1.9.2 (released 2013), which uses urgent data in rlogin/rlogind, telnet/telnetd, and ftp/ftpd. We can maybe bid good riddance to rlogin and telnet, but not ftp. Fortunately, ftp uses SO_OOBINLINE, so strictly speaking byte-by-byte payload integrity will be preserved against an attacker toggling the URG bit (though read boundaries will change, which is not great). However, it looks like ftpd counts on receiving a SIGURG for the ABOR, STAT, and QUIT commands. Injecting or suppressing such signals is an integrity attack (and, I'm now remembering, has even been abused for privilege escalation in the past). * End of file. EOF is part of the semantics of a TCP connection, used by applications for signaling (e.g., in old versions of HTTP). An attacker who injects a premature EOF can cause data such as file transfers to be truncated without software noticing the error. This is a data integrity attack, but like many integrity attacks poses a confidentiality threat as well. Contrived example: a bunch of people upload identical-length files to an anonymization server. All participants say their uploads completed. The server reveals the files but not their sources. If the attacker truncated exactly one sender's file, he knows which user supplied the truncated file. * Connection abort (the function played by TCP's RST bit). Documented cases exist of attackers causing problems by injecting RST packets. There may be unilateral and/or non-cryptographic ways of protecting against RST forgery, but tcpinc should at least optionally provide connection integrity comparable to TCP-AO. The attack here is the same as for TCP-AO. * Keepalive. It must not be possible for an attacker to cause a tcpinc endpoint to keep the connection (and associated crypto keys) around indefinitely if the other endpoint no longer exists. This is a confidentiality attack that undermines forward secrecy. For example, if an attacker keeps a defunct connection alive for many months, he then has plenty of time to compromise and extract session keys from the remaining endpoint. (Note: TCP's keepalive feature is insufficient here, which is why tcpcrypt has the replay-protected SYNC_REQ.) * Reliable data delivery over established connections. Clearly an on-path attacker who tampers with packets can cause both downgrade attacks and denial of service attacks, most simply by dropping all packets. However, an attacker who can eavesdrop on and forge packets but not suppress legitimate ones should not be able to disrupt established tcpinc connections. This is a DoS attack that could happen if, for example, the attacker succeeds in desynchronizing the TCP connection. * Deadlock freedom and buffer space control. TCP implementations provide control over buffer space via socket options such as SO_SNDBUF and SO_RCVBUF. Applications should be able to send data simultaneously in both directions without deadlocking if the data fits in the specified buffers. An attacker who reduces the effective buffer space can mount a DoS attack. Note this primarily applies to proposals that consume extra sequence numbers for non-payload data. A straw man would be an attacker who manipulates the window to induce a bunch of one-byte segments with eight-byte MACs. These must each consume one byte of buffer space, not nine. * Flow control. People assume they cannot continuously write large amounts of data to a TCP connection unless most of it is getting through to the other side. Hence, applications use flow control as a means of reporting progress (based on bytes written), estimating transfer completion times, and adapting to network conditions. Unprotected flow control enables attacks that lie somewhere between mere DoS and integrity failure. An example is someone trying to upload a video to either of two servers for safe keeping. The user starts two file transfers then kills the one that seems slower, when in fact the fast-looking server is hardly getting any data at all because the attacker has disabled flow control and is faking the ACK and Window fields. > Also explain what the receiving end should do if it detects attack > against the protected piece (i.e. either real active attacker attack, > or middlebox messing that thing up). With the exception of RST, which should be discussed separately, an integrity failure (detected attack) should be treated the same as a checksum failure. The segment should be discarded and should not affect the TCP connection state. It doesn't matter whether the corruption happened in the payload or in header bits that are necessary to tcpinc's security. That said, there are really three cases to consider: valid integrity, invalid integrity, and as-yet unknown integrity. The first is easy: accept. The second is easy: discard. In the third case, if, for instance, an endpoint is waiting for a cumulative MAC in a different segment, it should buffer the ambiguous segment until such point as it determines whether or not the segment has been corrupted or receives an unambiguously correct segment for the same sequence numbers. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
