Generation of PPD Packets

Using separate packets to deliver partial paths raises several issues. First, an end host system must be able to identify the set of PPD packets which carry partial paths of a particular IP packet. Since an end host may receive a number of PPD packets, there should be an association between an IP packet and the set of PPD packets carrying its partial paths. Second, an end host system must be able to authenticate the sources of PPD packets. Since an attack can also generate PPD packets carrying a set of partial paths to a victim, end host system must be able to authenticate the received PPD packets and their association. Third, an end host system must be able to determine the order among the set of authenticated PPD packets which are associated with the same IP packet.

To address the first issue, each PPD packet contains a digest value used to relate the PPD packet to a particular IP packet. Since the digest is used to uniquely identify a IP packet, its value in PPD packets associated with the same IP packet must be identical.

This digest value is computed by applying a hash function to selected IP packet header fields of the packet. With careful selection of header fields, the end host can effectively identify a set of PPD packets associated with an IP packet. The invariant IP header fields are selected as inputs to a digesting function. As shown in Fig. 4.6, marked IP fields are used to generate the digest value.

As to the second issue, each PPD packet has a 32-bit Iauth field which is presented in Section 4.3.4 in further details. Finally, as to the third issue, each PPD packet has a distance value which is used to determine its order. This distance value is obtained from

Figure 4.6: Selected IP fields for computing the digest value

Figure 4.7: The format of a PPD packet which is used to transmit partial paths to end hosts

the TTL value of the IP packet. Specifically, whenever a router decides to deliver a set of partial paths to the destination host by an PPD packet, in addition to the computing of the digest value, it copies the current TTL value to the distance field in the PPD packet.

The entire PPD packet format is depicted in Fig. 4.7.

4.3.4 Authentication

Authentication is an essential component in the proposed scheme. It allows an end host to filter out false path information and subsequently helps to correctly identify the source of an attack. In our approach, partial paths are treated as basic units that constitute the entire path. Thus, as we have seen in Fig. 4.3, there is an one-byte “Pauth” field which is used to assure the authenticity of the partial path. Furthermore, PPD messages are used to carry partial paths to the end host systems. It is also important to authenticate PPD message so as to prevent the attack from injecting forged PPD packets to the victim.

Herein, we present the way to generate the “Pauth” and “Iauth” field respectively.

The “Pauth” field can be generated in several ways. One straightforward approach is to have the last router in a partial path generates a digital signature using public key cryptography. However due to the high computational overhead of public key crypto-graphic operations, this approach is infeasible in many network environments. Thus, we

choose conventional cryptographic system which may incur less computational overhead.

We adopt one-way key chain to achieve lightweight authentication. The technique is orig-inally proposed to authenticate the sources of messages in a broadcast/multicast network environment [88,89]. One of its important characteristics is the use of symmetric cryptog-raphy that perfectly fits the lightweight requirement of generating signatures for partial paths. In the following, we detail the use of one-way key chain to achieve authentication.

In the one-way key chain framework, we assume that that EBRR-enabled routers, TSs, and end-hosts are loosely time synchronized. That is, their clocks are time synchronized up to a maximum error of ∆. Moreover, the maximum propagation delay of an IP packet from source to destination is denoted as T_prop. Then, the time is divided into a set of uniform intervals, and each interval is of duration T_int and T_int  ∆, Time interval 0 starts at time T₀ and time interval i starts at time T_i = T₀+ i ∗ T_int. Each EBRR-enabled router constructs a reversed one-way key chain and shares its key chain with the TS in its correspondent TED. That is, in a key chain, each time interval is associated with a secret key which is used to generate signatures in the corresponding time period. Each secret key can then be disclosed after a small amount of time after the key expires. Specifically, consider a key K_i which is associated with time interval [T_i, T_i+1]. K_i can be disclosed at time T_i+ T_int+ T_δ where T_δ represents the waiting time after K_i expires and T_δ T_prop. The set of keys are organized as a reverse key chain sequence, as shown in Fig. 4.8, that is, K_i = H(K_i+1). Since the key is disclosed reversely, the disclosure of K_i does not reveal K_i+1.

As Fig. 4.8 shows, a key chain can be generated in a straightforward manner. An EBRR-enabled router first randomly generates a random number as K_L (here we assume the length of key chains is a pre-defined parameter within a TED). Then, the subsequent elements of the key chain can then be generated. To allow a TS to generate the same key chain, the router securely sends K_Lto the TS and consequently the TS can then construct a key chain that is identical to the key chain in the EBRR-enabled router. Whenever a key chain is exhausted (all of the secret keys have expired), each EBRR-enabled should reconstruct a new key chain and deliver K_L to TS for generating a new key chain in TS.

Note that, we do not impose any restriction on the length of the key chain. The settings of T_intand T_δ are not strictly limited. They can be set to an hour, twelve hours, a day or even a week. However, setting a “too-long” duration for T_int and T_δ will delay the time

Figure 4.8: Reversed one-way key chain

for the disclosure of secret keys and consequently delay the time to start the traceback process since each partial paths must be authenticated first. Thus, we suggest that T_int be set to an hour and T_δ to 30 minutes. (This suggestion comes from the observation that ∆ one hour and T_prop  30 minutes)

Whenever a router decides to terminate a partial path, denoted as p.path_x, the router will compute the value of the Pauth filed by applying a keyed hash function to a partial path and some other fields in the IP header. Specifically, let Ki denote the key of the router in the correspondent time interval when the partial path is to be terminated, and ζ denote the concatenation of values of the IP header fields which are selected for computing the digest values, as depicted in Fig. 4.6. Then P auth = H1(p.pathx.links, p.pathx.end, ζ, Ki), where H1(.) denotes a HMAC [11, 65] function that generates one-byte keyed hash result. In this way, the victim can verify the authenticity of each partial path by examining the “Pauth” field once the correspondent secret key of the router is disclosed. Shortly we will present how the victim can acquire required secret for authenticating partial paths. In this way, as we shall see in Section 4.4.2, attackers can only have the probability of 1/256 to mislead the victim by forging an partial path or replay any partial path that he has recently accumulated.

Similar to the generation of the “Pauth” field, the “Iauth” field is also generated by applying a hash function to some of IP and PPD header fields, and the set of partial paths in the PPD message. That is, Iauth=H₂(ip_src,ip_dst,distance, digest value, partial paths in the PPD message, Ki ), where ipsrc and ipdst denote the source and destination IP address of the PPD packet, K_i denote the key of the current router that generates this PPD packet and H2(.) is a HMAC function that generates a four-byte keyed hash result.

For a victim who wishes to authenticate a partial path (or an PPD packet) received at time Tarrival and within the duration of Ti, he must acquire correct keys first. The victim will first lookup the TS associated with the router R which terminated the partial path (or delivering the PPD packet) via DNS hierarchy. Afterwards, the victim waits until T_i+T_int+T_δ+∆, and then send a key retrieval request to the TS. The request indicates the

time that the offensive packet arrives at (i.e. T_arrival) and the router R. After receiving the request, the TS can retrieve the key chain of R. Subsequently, TS returns secret keys which fall in the duration between T_arrival − ∆ + T_prop and T_arrival + ∆ + T_prop. (Since T_int  ∆, the victim may receive two secret keys when T_arrival is near the boundary of two consecutive intervals. In most cases, only one secret key is returned from TS.) Finally, the victim can authenticate the partial path (or PPD packet) using the retrieved keys. If there exists a secret key that can successfully authenticate the partial path (or PPD packet), it is considered valid. Otherwise, the partial path (or PPD packet) will be dropped.