# Performance of the Transport Layer Security Handshake Over 6 TiSCH
## 4 Insights: The (DTLS Handshake over 6 TiSCH
### Fragmentation  
The maximum size of a (D)TLS record is 16,535 B. A (D)TLS record is the unit of protection, meaning that the encryption and Message Authentication Code (MAC) are calculated over an entire record. The record must be fully received before it can be processed. In theory, both (D)TLS endpoints require an output and input buffer of 16,535 B to store records. Typically, constrained devices do not have sufficient RAM for buffers of this size. Several approaches are available to ensure the size of the incoming and outgoing handshake messages is limited. By default, the DTLS handshake protocol supports the fragmentation of handshake messages to make sure that they do not exceed the PMTU, see Figures 3 and 9. Large handshake messages can frequently occur when the messages contain certificate chains. In a 6 TiSCH network, the PMTU depends on the number of 6 LoWPAN fragments the individual constrained devices along the path can handle. In addition, the constrained destination must store all the fragments before reassembly. When the nodes are IPv6-compliant (MTU of 1280 B), they should at least be capable of storing 11 6 LoWPAN frames. To give the other endpoint an early warning about the limited PMTU, DTLS clients can use the MFL extension. When supported, MFL limits the size of the record fragments to 512 B, 1024 B, 2048 B or 4096 B. The main drawback is that MFL is optional and thus not supported by all DTLS endpoints. In addition, MFL negotiation can only be triggered by the DTLS client; the DTLS server cannot indicate to the client it wishes to limit the record fragment size. To address these issues the \"record size limit\" extension was defined. It is valid for all (D)TLS version and supposed to replace the deprecated MFL extension [23]. TLS endpoints do not have a built-in fragmentation mechanism to limit the size of the handshake messages, but TLS depends on TCP to appropriately size its segments Figure 9. A constrained device can make use of TCP' Maximum Segment Size (MSS) option to explicitly set an upper bound to the segment size. In addition, TLS could use the MFL extension to reduce the record fragment size. To analyze the impact of different MFL and MSS sizes on the fragmentation load in the network, we set up an experiment that measures the 6 LoWPAN buffer pressure on the constrained (D)TLS endpoint. We do not consider the buffer pressure of the intermediate router nodes since they use fast fragment forwarding. 6 LoWPAN fragments are not reassembled on the routers and are forwarded directly to the next hop [24]. As long as intermediate routers have sufficient active slots--allocated by the SF algorithm--their buffers should not overflow. Figure 10 shows the results for varying configurations for both TLS and DTLS. We notice that for large handshake messages, [PERSON]'s algorithm increases the buffer pressure (see the top plot). Recall that Nagle will try to fill up a TCP segment before transmission. The larger TCP segments require many 6 LoWPAN fragments. We can clearly distinguish two phases in the handshake protocol. The initial peak corresponds to the reception of a group a 6 LoWPAN fragments containing the _ServerCertificate_, _ServerKeyExchange_, _CertificateVerify_, and _ServerDone_ messages. The second bump is the accumulation of 6 LoWPAN fragments being queued for transmission, after the node has prepared its _ClientCertificate_, _ClientKeyExchange_, _CertificateVerify_, _ChangeCipherSpec_, and _Finished_ messages. Without Nagle, the endpoints are free to split the TLS record data over several smaller segments, resulting in fewer 6 LoWPAN fragments per IPv6 datagram. It does increase the total amount of bytes, as shown in Table 2, due to more header overhead and additional TCP acknowledgments. Figure 9: The different layers on which fragmentation occurs before a handshake message is sent by the IEEE802.15.4 radio. The behavior changes when we lower the handshake message size to 356 B. The initial peak, caused by the incoming server handshake messages, has completely disappeared.