Unfortunately, the author of this article to hear the bell, but has no idea where the clapper hangs.
First, there is no “rfc 5961 Protocol”. RFC 5961 (with capital letters, just stop even with the horrible ugly letter abbreviations in lower case) describes a number of possible attacks on TCP connections. You could at most write that it is an error in the implementation of the TCP protocol, but even that is not entirely correct because it is not an adaptation of the TCP protocol, but only the manner in which the host responds to certain TCP segments .
RFC 5961 is designed to make TCP connections robust. One of the recommendations – the one where the particular matters here – is to reduce the number of “Challenge ACKs”, to thus make it more difficult to find the correct TCP sequence number
. implementation of Linux was, contrary to what the article says, right. The idea in the RFC was not good.
The problem is that in the white paper which in the last paragraph are linked, describes the undesirable leakage of information by this limitation. In the Linux implementation, the number of ACKs Challenge was limited to 100 per second. If you want to know now if Host A and Host B communicate with each other, send a packet to one of the two hosts, which should trigger a Challenge ACK. Then send 100 packets from your own host who also trigger a Challenge ACK. You get 100 answers: there is no communication between Host A and B, you get 99 answers, then there’s obviously been a challenge ACK sent and there is therefore a TCP session between Host A and Host B
.
the solution that in the Linux kernel has been implemented is to raise the limit of 100 to 1000 and the addition of a random factor, causing the limit is not exactly 1000, but “somewhere in the vicinity of 1000″.
That
no solution has been found for the Linux kernel on Android
is sheer nonsense. The solution is to implement the patch in the Android kernel. This is apparently not happened yet.
No comments:
Post a Comment