CODEWITHSUNDEEP
linuxtcplinux-kernel
sjsam
sjsam

Reputation: 21965

Initial Sequence Number generation in Linux TCP stack

What is the procedure for generating the Initial Sequence Numbers (ISN) in LINUX tcp/ip protocol. I know the procedure for ISN generation in the LINUX kernels 2.4 to 2.6 that are described in pages 7 & 8 of Embedding Covert Channels into TCP/IP. I have searched for similar procedures in later kernels, but to my dismay I couldn't find any. I understand that much details may not be available for obvious reasons related to security. As I'm verifying the possibilities of implementing a similar steganography scheme(as described in the link) in the later Linux kernels, I am badly in need of some information. Any help is appreciated.

Upvotes: 5

Views: 7971

Answers (3)

user1744056
user1744056

Reputation:

Update to previous answers so that to represent current state (2019 and Linux kernel 5.1.3) because algorithm to generate ISNs in the kernel was changed again to be more secure.

secure_tcp_seq now uses SipHash (add–rotate–xor) functions to generate ISN based on initial secret key, source and destination IP address and port. I suppose this change was related to hash collision vulnerability resulted in hash flooding attacks.

Upvotes: 2

TOC
TOC

Reputation: 4446

Read my answer here: Most efficient way to manipulate ISN numbers in TCP headers

This algorithm is used on the latest kernel TCP Stack (3.5).

EDIT : See image below to see all concerned kernels versionsenter image description here

EDIT2 : See the sources of the kernel for older versions of the function secure_tcp_sequence_number:

Kernel 2.4.22

Kernel 2.6.30

Kernel 2.6.39

Kernel 3.0

Kernel 3.1 : (MD5 has replaced half-MD4)

Upvotes: 4

sjsam
sjsam

Reputation: 21965

After more careful reading of RFC6528 and RFC1948 I came to a conclusion that the algorithm for generating Initial Sequence Numbers(ISNs) as specified in RFC1948 :

       ISN = M + F(LocalIP, LocalPort, RemoteIP, RemotePort, Secretkey)

has not changed. Instead, the algorithm which was proposed by Bellovin S.M in RFC1948 is formally specified and taken into the Standards Track(as per RFC2119) in RFC6528 which was written together by Bellovin S.M and Gont. F.. As the now obsolete RFC1948 can't be used in any documentations, RFC6528 has replaced it.

But as pointed out in the answer to my original question MD5 has replaced half-MD4 as the Hash Function from kernels 3.1. This is completely justified by RFC6528 as it did give the flexibility to change F() which is the Pseudo-Random function. (Please have a look at the links for more details).

Upvotes: 2

Related Questions