The integrity information

In order for the receiver to be able to check the integrity of the data, the sender must transmit some additional information which acts as a ``signature'' on the data. The receiver can then check this information to verify that the received data really was transmitted by the authenticated party at the other end of the link. The ``signature'' must also make it possible to verify that data is received in the same order as it was transmitted. This means the must be some kind of linkage between each block which is integrity checked. To avoid confusion with public key digital signatures will I call the signature for integrity information.

To check the integrity of the incoming data, the receiver will generate integrity information using the same algorithm as the sender, and then compare the result with the received integrity information. If the locally generated integrity information and the received integrity information are the same, one should be able to say, with great confidence, that the incoming data is authentic.

There are two main solutions for transferring the information:

1. One may send the integrity information at predefined intervals, e.g. for each n'th character in the data stream. The receiver would know that there is integrity information after each group of n bytes which must be extracted and checked. This method has the potential of producing very little transmission overhead. See Oksås [1] for more information on this method.
2. Another method is to send the integrity information in a custom IAC sequence. One may for example send:

         IAC SB INTEGRITY INFO <integrity information> IAC SE.

The first solution involves a special case when less than n bytes must be integrity checked (will occur e.g. when the user has pressed a single key since n normally is more than one). This can be solved by sending a special IAC sequence, like the one in the second solution.

It is thus only when blocks larger than n bytes of data are transferred that solution 1 gives an advantage over solution 2. For smaller blocks the the methods will give the same amount of overhead.

The following table compares transmission overhead for the two solutions for different values of n when 1024 bytes of user data + integrity information is sent in one transport layer protocol data unit (on a TCP/IP network). The integrity information is assumed to be 32 bits. The TCP/IP header is 48 bytes [20].

 

n Overhead Sol. 1 Overhead Sol. 2

64 9.9% 16.9%

128 7.2% 11.1%

512 5.1% 6.2%

1024 4.8% 5.4%

The client side will typically produce only one byte for each transmission of an INTEGRITY INFO sub-option sequence. In a TCP/IP network this gives a transmission overhead of 16%, equal for both solutions.

From the table, we see that for large n, the solutions give about the same amount of overhead. Solution 2 will be easier to implement, since we don't have to have the annoying special case in solution 1, but n must be large to minimize the overhead.

A large n means the algorithm for generating and checking the integrity information must make it possible to detect modifications of large data blocks. Algorithms that work with large blocks (e.g. 1024 bytes) exists, for instance a 32 bit cyclic redundancy check can be used.

An important design choice is therefore to use the Solution 2 in the integrity option.

Figure 3.6 illustrates the insertion of integrity information sub-option sequences in the data stream. Note that the number of bytes in the blocks between the integrity information sequences is not fixed.

  
Figure 3.6: Data stream with integrity information