Route Discovery Process in S-AMCQ Routing Algorithm

Before describing the route discovery process in the S-AMCQ routing algorithm, it is worth noting that the structure of routing control ants proposed in Section 5.4.1 for AMCQ stays the same for S-AMCQ except for the RPANT messages. As the E- VoEG model is now available at each vehicle, the following fields are omitted from RPANTs: RT_reliability, RT_Delay, and RT_Cost. These fields contain the reliability, end-to-end delay, and cost of the computed forward route, respectively, and were mutable and traceable. These values can be now calculated on the basis of the E-VoEG model and the TraversedList field information. In this way, the contents of a RPANT message are all now immutable and thus the security information overhead needed to protect it is reduced as we describe below. Furthermore, we recall that routing control ants do not carry the pheromone value, which is used by intermediate nodes to update their routing tables. This is a main design advantage we have proposed in AMCQ because all we need to do for S-AMCQ is to ensure the

A B D C (5,1,0) (5,1,8.4) (5,1,16.1) (5,1,14.4) (5,1,11.2) (5,1,6.8) E G F (5,1,22.4) (5,1,0) (5,1,9.4) (5,1,7)

necessary information to calculate the pheromone value, which is carried by routing control ants, is authentic, i.e., created or updated by authenticated vehicles.

As the plausibility checks defined in the next section are devoted to defending the routing process against internal adversaries, we utilise the digital signature mechanism from the PASS scheme to protect the routing control ants from external adversaries and ensure their integrity and authenticity. The digital signature mechanism is applied to all control messages in S-AMCQ, which are RQANTs, RPANTs, QMANTs, and REANTs. In the following, we illustrate the route discovery process in the S-AMCQ routing algorithm when plausibility checks and digital signature mechanisms are applied.

When sr has data belonging to traffic flow TC to send, it commences a new

route discovery process if no route, associated with TC, to de is known. It starts by

initialising the immutable fields of a RQANT and leaves the RT_Reliability, RT_Delay, RT_Cost, and TraversedList fields empty. Then, it uses the one-way hash function Hash(.) to hash all the immutable fields and produce the message digest

RQANTm. After that, sr uses SKsr,j the secret signing key of sr for the current timeslot

TSj associated with its pseudonymous certificate CertCA,sr,j to sign RQANTm ,i.e.,

obtains the signature DSigsr,RQANTm = Sign(SKsr,j, RQANTm). Finally, sr attaches its

signature to the RQANT message and broadcasts it to its neighbours. It can be noted that the certificate used, CertCA,sr,j, is issued directly by the CA. However, for future

route discovery processes, after sr has obtained an updated certificate from an

authenticated RSUx, the certificate used will be CertRSUx,sr,j. The certificate sr used,

either CertCA,sr,j or CertRSUx,sr,j, is not attached to the RQANT message because it is

distributed and verified by its neighbouring vehicles during the transmission of the BSMs. Since we assumed that BSMs are protected using the PASS scheme, there is no need to send the certificate again. In this way, we reduce the verification overhead at the neighbouring vehicles, when they receive this RQANT, to signature verification only and reduce the communication overhead by not transmitting the sr’s

certificate. It is important to notice that this solution is feasible within the certificate validity period, i.e., before sr changes its certificate to a new one. Hence, sr and other

nodes should always ensure that the current used certificate is distributed during the transmission of BSMs.

When an intermediate node Cv receives the control message (RQANT,

DSigsr,RQANTm) from sr, it verifies the signature DSigsr,RQANTm by computing the hash

value over the immutable fields of RQANT and verifies the resulting RQANTm

against the signed value attached to RQANT. If Verify(PKsr,j, RQANTm,

DSigsr,RQANTm) is successful, where PKsr,j is the public key of sr for the timeslot TSj,

then the RQANT message is accepted, and plausibility checks are performed at this stage. If the RQANT fails any of the plausibility checks, then it is discarded and the sender vehicle is reported malicious. If the plausibility checks were successful, Cv

checks if this RQANT has been processed before, i.e., with the same RQANT_ID and

RQANT_Gen information. If yes, then it is discarded, otherwise Cv calculates the

QoS metrics of the link l(Cv, sr). If l(Cv, sr) violates any of the QoS constraints

determined by the data traffic type, even after applying QoS tolerance factors if applicable, then this RQANT is discarded, and the pheromone value of l(Cv, sr) is set

to τ0. Otherwise, Cv continues by either inserting a new or updating an existing

pheromone table entry to the node it receives the RQANT from, which is sr in this

case, depending on the pheromone value calculated according to (5.14). After that, Cv updates the mutable information of the RQANT message as follows. It inserts the

new calculated QoS metrics into the RT_Reliability, RT_Delay, RT_Cost fields and inserts its identifier into the TraversedList field. After that, it signs these updated fields only using the same mechanism described above and attaches its signature DSigCv,RQANTm along with DSigsr,RQANTm to the RQANT message. In this way, each

RQANT after this stage will contain two signatures, sr’s one on the immutable fields

and the signature of the last node that processed this RQANT on the mutable fields. The second signature should be verified by using the identifier of the last node in

TraversedList field to identify the public key to be used. Finally, Cv checks its

pheromone table for route entries to de. If an entry is found, the RQANT is

forwarded based on the state transition rule defined in (5.12) and (5.13), else it is broadcasted again. If any of the mentioned security information verifications fails, then the RQANT is discarded.

For each intermediate node that receives this RQANT message afterwards, it verifies the two signatures included and that the node it receives this RQANT from is the last one in the TraversedList field. After that, it processes the RQANT as

described above. The process continues until de is reached. On receipt of a valid

RQANT, de generates a RPANT and sends it back to sr following the route found in

the TraversedList field, i.e., following the trail of the corresponding RQANT to arrive at sr. The RPANT is protected using the signature of de only since all its fields

are immutable. At each intermediate node, when the RPANT is received, the signature of de is verified, and the QoS metrics of the forward link/route toward de

are evaluated on the basis of the QoS constraints, TC_ID, and the E-VoEG model information.

Finally, sr evaluates the computed routes in MTC(sr, de) and selects the route

that maximises the objective function F(PTC) value defined in (5.8). Similar to AMCQ, sr is allowed to start data transmission once it receives the first RPANT with

a route that satisfies the QoS constraints. If a better route becomes available upon receipt of another RPANT, then sr will choose the best route according to (5.7), and

so on. In both cases, all feasible routes, i.e., MTC(sr, de), are kept at sr for further use

if needed as explained later in the route maintenance process.

Using the security mechanism described above, S-AMCQ ensures the authentication, integrity, and non-repudiation of information within its control messages while protecting vehicles privacy using pseudonymous certificates. External adversaries cannot carry out route disruption or perform incorrect routing state attacks because any spoofed control message is going to be detected. However, the adversary can still create spoofed control ants and deliver them to one or more vehicles for verification. Although a spoofed control ant will be discarded, the verification process consumes time and may jeopardise the availability of the target vehicle(s). It is important to notice that if the adversary unicast spoofed control ants, then the denial of service at the target vehicle does not necessarily affect the ability of S-AMCQ to discover feasible routes. The reason is that S-AMCQ is originally a multipath routing algorithm. However, if spoofed control ants are broadcast, then blocking the sender of these ants when possible can mitigate this attack.