4.3 Cross-layer Size Restrictions
4.3.3 Cross-layer Data Size Conflicts
The obtained worst case size of the security envelope for CAMs shows a design weaknesses of the protocol stack. With a 570 bytes long security envelope, it is not even possible to send a BTP packet without any further payload. The sum of all protocol layers’ overheads already exceeds the maximum packet size of the MAC layer. A main contributor is the polygonal region validity restriction of certificates, which holds 12 GNSS positions, with four bytes each (see also
Section 4.3.1). Hence, this kind of validity restriction should be removed, as its usage renders the remaining system useless, unless the accepted maximum packet size is significantly increased.
Layer two to four overhead for CAMs commonly sums up to either 175 bytes without in- cluded PSC, 299 bytes in case of an included PSC and even 431 bytes in case of a contained certificate chain (see Table 4.8). However, in case of a CAM with present low frequency con- tainer, the facility layer leaves only 261 bytes to lower layers. This only works out in case the security entity does not include any certificate. Currently, certificate inclusion is not done in a data length aware manner [125]. Therefore, violation of the message length limit, which leads to discarding of messages at the MAC layer, can occur.
In case of a low CAM generation rate of fCAM = 1 Hz, all the mentioned optional data fields (CAM’s low frequency container and PSC) are always present in each message [119,125]. The timeout interval to include the low frequency container is 500 ms [119]. This can lead to a situation in which the affected node cannot transmit any CAM, as these are all dropped at its access layer. Hence, this has to be regarded as a severe design weakness of the current ETSI ITS protocol stack. The CAM discarding rate dCAM for fCAM > 1 can be calculate by
dCAM = fcert fCAM + fcert fCAM · fcert− 1 Hz fCAM − 1 Hz + ( 1 − fcert fCAM ) · fcert fCAM − 1 Hz · 1 Hz. (4.3) fcert gives the PSC inclusion frequency. Please note that due to the used PSC piggybacking strategy fCAM ≥ fcertholds. Furthermore, it is assumed that inclusion of low frequency con- tainer is statistically independent from inclusion of the PSC. This is reasonable, as within ETSI ITS there is no coupling between the inclusion rules for both data sets.
The minimum inclusion frequency of PSCs min (fcert) = 1 Hz leads to min (dCAM). Cor- responding values are given in Table 4.9. For an exemplary PSC emission rate of fcert = 3 Hz (obtained from the freeway scenario described in Section 3.2), values for dCAM are also given in Table 4.9. fCAMin Hz 10 9 8 7 6 5 4 3 2 1 min (dCAM) in Hz 15 29 14 72 13 25 12 23 1 1 min (dCAM) in % 2 2.5 3.1 4.1 5.6 8 12.5 22.2 50 100 dCAM in Hz (fcert = 3 Hz) 35 23 34 67 1 1.2 1.5 2 2 1 dCAM in % (fcert= 3 Hz) 6 7.4 9.4 12.2 16.7 24 37.5 66.7 100 100 Table 4.9: Average share of CAMs discarded due to a maximum packet size violations at the access layer.
Under presence of an attacker who wants to perform a DOS attack the situation is even worse. Rapid certificate (chain) inclusion in (almost) every CAM can be caused, as explained in detail in Section 5.1.1 and 5.1.2. Hence, a node can be banned from sending any CAM in case it is attacked and subject to the above described internal message discarding. This clearly makes the attacker achieve his goal of performing a DOS attack.
Protocol stack behavior in both cases, with and without presence of an attack, clearly shows that the message assembling approach, which has been used so far, needs to be improved. Hence, an alternative is suggested in Section 4.3.4.
Moreover, the found cross layer data size issues questions the usability of a PSC omission approach, like the one suggested in [133, 135]. Such kind of PSC dissemination strategy tries to achieve fcert = fCAMand only omits PSC emissions in case the channel load is found to be too high. However, this leads to a massive amount of messages getting dropped due to maximum size violations at the MAC layer.
Basically, three different possibilities exist to overcome the found message length problem without changing the sporadically included content itself. Theses are
1. to increase the maximum allowed message size at the access layer by either (a) increasing the maximum air time Tair(see [103]) of a single packet, or
(b) increasing the fixed transmission data rate of the control channel at the physical layer, or
2. to use packet fragmentation, e.g., at the network layer,
3. to coordinate inclusion of sporadically included large data sets between different protocol layers to efficiently share message content resources.
Approaches 1a and 1b would significantly change the characteristics of the VANET’s wireless channel. With increased Tairboth the probability of packet collisions and the channel load cre- ated by a transmitted packet increase. Moreover, increasing the transmit data rate on the physical layer makes the system less robust against common challenges of wireless communication, e.g., signal distortion. Hence, both approaches can be expected to significantly reduce the average communication range of nodes. Therefore, such kinds of approaches are not recommend.
Packet fragmentation support for VANETs is studied in [62] assuming package reception is acknowledged by receivers. However, this is not the case in broadcast mode of ETSI ITS and WAVE approaches. [158] studies the trade off between large packets with no or low amount of fragmentation and many short packets, as a result of massive fragmentation. Thereby, it is found that optimal packet length depends on traffic conditions, and should be smaller than 1000 bytes for typical traffic densities. Hence, massively increasing Tairseems infeasible to overcome the found packet size issue. Moreover, the influence of fragmentation on delays for data distribution, which influences the cooperative awareness quality of nodes, has not been looked at. However, increasing the number of packet transmissions by fragmentation will increase the channel load on the highly bandwidth restricted single control channel, due to significant protocol overhead contained in each packet. One can assume that the problems encountered in case of fragmenta- tion support show similarities to the ones shown in the case of IP-based communication [187]. Therefore, inclusion of fragmentation support into VANET approaches seems unlikely in the near future.
Instead, a cross-layer content aware message assembling strategy, as suggested in no. 3, is recommended. Hence, such a strategy is introduced in Section 4.3.4.