Internet-Draft TCP Stealth January 2015.
Since the complete integrity of the internet infrastructure cannot be assumed, it follows that adversaries may be able to observe all traffic of an Internet host and perform man-in-the-middle attacks on traffic originating from specific clients. Furthermore, on the server side, an adversary looking for exploitable systems should be expected to have the ability to perform extensive port scans for TCP servers. To help address this problem, we propose to standardize TCP Stealth, a stealthy port-knocking variant where an authenticator is embedded in the TCP SQN number.
TCP Stealth enables authorized clients to perform a standard TCP handshake with the server, while obscuring the existence of the server from port scanners. The basic idea is to transmit an authorization token derived from a shared secret instead of a random value for the initial TCP SQN number in the TCP SYN packet. The token demonstrates to the server that the client is authorized and may furthermore protect the integrity of the beginning of the TCP payload to prevent man-in-the-middle attacks. If the token is incorrect, the operating system pretends that the port is closed. Thus, the TCP server is hidden from port scanners and the TCP traffic has no anomalies compared to a normal TCP handshake.
The TCP MD5 Signature Option defined in RFC 2385 defines a similar mechanism, except that RFC 2385 does not work in the presence of NATs (RFC 1631) and visibly changes the TCP wire protocol, and can thus be easily detected. While TCP Stealth does not change the TCP wire protocol, the specific method for calculating the authorization token must be consistent across Internet hosts and their TCP/IP implementations to ensure interoperability. By embedding the port knocking logic into the TCP/ IP implementation of an operating system, we minimize the possibility of detecting hidden services via timing attacks, and avoid the pitfalls of applications trying to re-implement TCP in user-space. Implementors MUST make sure that the response to a connection request with wrong ISN value does not differ in any way from the response to a connection request to a closed port. read further : http://www.ietf.org/id/draft-kirsch-ietf-tcp-stealth-01.txt