Compromisos relacionados con Gener.

As previously stated, there are several factors which affect performance in the standardised SCTP security solutions. Therefore, S-SCTP’s efficiency and performance over a broad range of application scenarios and SCTP parameter settings were all together the main objectives of my design.

One major factor is that S-SCTP uses only one secure session per association. This decreases secure session initialisation cost. The TLS handshake uses 13 messages (see figure 3.12). Therefore with TLS over SCTP in a multistreaming scenario (N secure streams), N*13 messages are exchanged between two associated endpoints to establish the secure sessions completely. In the same scenario S-SCTP uses 8 messages to establish a secure session (see figure5.11). This decreases setup time and bandwidth consumption. The same is in principle true when compared to IPsec with multihoming, but normally the number of IP addresses is not so high, so the effect is not that dramatic.

When a secure session is long-lived, it is necessary to update the secret keys periodi- cally. For S-SCTP, only one key has to be updated, for TLS over SCTP with multistream- ing, or SCTP over IPsec with multihoming, this is much more complex. Because every secure session independently performs the update mechanism, the cost in terms of compu- tations and bandwidth consumption obviously increases when a large number of streams or IP addresses are used in an SCTP association for the latter two solutions.

Moreover, TLS implementations define a data structure, which stores security parame- ters related to a TLS connection. Every TLS connection has its own structure. This means when N TLS connection are used, then N structures have to be replaced in memory. Also certificates that are used in TLS handshakes have to be replaced in memory. Therefore, TLS over SCTP memory usage obviously depends on the number of secure streams which is a drawback compared to S-SCTP and SCTP over IPsec.

Overhead is one factor that decreases the throughput. With respect to protocol over- head, the SCTP over IPsec and the S-SCTP security solutions are rather similar. The overhead (in bytes) can be calculated as follows:

SCTP over IPsec: 20(IP header)+ 8(ESP header)+ 28(AH header)+12(SCTP Common header)= 68 bytes

S-SCTP: 20(IP header)+ 12(SCTP Common header)+ 16(EncData chunk header)+ 24(AUTH chunk header)= 72 bytes

From above calculations the difference in overhead size between SCTP over IPsec and S-SCTP is just 4 bytes. This result is not influenced by the message size, because frag-

mentation on one side and message bundling on the other has the same consequences for the overhead in both solutions.

However, this is not true when comparing the overhead for S-SCTP and TLS over SCTP.

In SCTP, small messages can be bundled together in one packet, but they are increas- ing the overhead. Figure5.3 shows the relationship between overhead and message size (MTU=1500 bytes Ethernet) for S-SCTP and TLS over SCTP which can be derived by a simple calculation.

Figure 5.3: Relationship between packet overhead and message size

The y axis indicates the total overhead percentage, which includes IP header, SCTP common header, authentication header and data chunk header. For example, 40 percent means 2/5 of a packet is just overhead and 3/5 is a user data. The x axis indicates the ratio of IP packet size1_{to MTU.}

We can distinguish three zones:

1_{MTU size(1500 byte) - IP header(20 byte) - S-SCTP overhead(72 byte) leaves 1408 bytes maximum}

data length per packet if a packet includes only one DATA chunk. If IP packet includes two DATA chunks then maximum data length per chunk is (1408 - Second DATA chunk header(16 byte))/2 = 696 byte.

• The first zone is between 0% and 52.5%2_{. This is the bundling zone of SCTP. The} bundling mechnism will continue until the IP packet size reaches 52.5 percent of the MTU.

• The second zone is between 52.5% and 100%. This is the zone where every packet

inlcudes only one message but no fragmentation is necessary.

• The third zone is over 100%. This is the fragmenting zone where messages bigger

than the MTU are fragmented.

TLS over SCTP has a high overhead in zone 1 and S-SCTP has obviously advantages. In S-SCTP, the authentication field is calculated for the whole packet not each separately for each message as in TLS over SCTP. Therefore, every SCTP packet includes only one authentication code and several messages. Because of this, S-SCTP is clearly more ef- fective than TLS over SCTP for small messages. As you see in figure5.3, the overheads of TLS over SCTP and S-SCTP are increasing on the boundary of zone 1 and zone 2, because here a fragmentation occurs and the data message is fragmented into two packets thus increasing overheads.

Because there is only one message per SCTP packet, S-SCTP has a total overhead of 72 bytes (12 bytes common header, 16 bytes EncData chunk header, 16 bytes DATA chunk header and 28 bytes AUTH chunk), whereas TLS over SCTP has only an overhead of 52 bytes (12 bytes SCTP common header, 16 bytes DATA chunk header, 4 bytes TLS record header and 20 bytes authentication code). Therefore, TLS over SCTP is slightly more efficient than S-SCTP in zone 2.

In zone 3, S-SCTP requires one authentication field per SCTP packet, whereas TLS over SCTP authenticates a whole message which is transported in two or more SCTP packets. Therefore, TLS over SCTP has less overhead for fragmented messages.

To clarify the jumps in overhead, consider e.g. a message of length 1410 bytes (in the S-SCTP scenario). For a 1500 byte MTU resulting in maximum chunk size of 1408 bytes, the data message will be divided into two parts of size are 1408 and 2 bytes, re- spectively. The first packet size is 1408+72+20=1500 bytes and the second packet size is 2+72+20=94 bytes. The total overhead size of the two packets is (72+20)*2=184 bytes and total length of two packet is 1500+94=1594. The percentage of the overhead is (184/1594)*100=11.54%. If we calculate the overhead percentage before fragmentation occurs, we have only one packet which has 1500 bytes and overhead size is 72+20=92 bytes. The percentage of overhead is therefore 92/1500=6.13%. Therefore, the overhead

2_{Maximum data length per chunk(696 byte) + IP header(20 byte) + S-SCTP overhead(72 byte) = 788}

will be increased in every time when an additional fragment is needed i.e. at 200%, 300% etc.

A major performance advantage of S-SCTP compared to IPsec is that S-SCTP can mix secure and insecure messages. We know the computation time of encryption mechanisms is relatively high. In SCTP over IPSec, all data will be encrypted which will unnecessarily increase computation time and decrease throughput. In S-SCTP, just the data requiring security will be encrypted. Of course, the effect of computation time depends on the ratio of secure and insecure messages. When the percentage of secure messages is high (e.g. 90 percent) then both security solution’s computation times are similar. When the percentage of secure messages is low (e.g. 10 percent) then S-SCTP has lower computation time and higher throughput than SCTP over IPsec. In section6.4results of experiments with a mix of secure and insecure messages are discussed.

Another factor that influences the performance is the implementation of the security protocols and their cryptographic algorithms. IPsec is completely implemented in the ker- nel space, whereas TLS and S-SCTP are implemented in user space. That’s why IPsec is highly optimised and its performance is in general superior to TLS and S-SCTP. There- fore, the comparison experiments for the SCTP security solutions provided in section6.4

are not ideal. However, I tried to use as identical conditions as possible in my experiments by using the same encryption and authentication algorithms in every experiment.