Processing Inbound IPSec or non IPsec Trac From the lecture: 1. Determine if the packet contains an IPSec header. • If there is an IPSec header then extracts the SPI from the IPSec header, look up the SA in the SAD

and perform the appropriate AH/ESP processing.

•

.

If there is no SA referenced by the SPI, drop the packet

2. After the AH and/or ESP processing, determine if and how the packet should have been protected, this is again realized by performing a lookup in the SPD. • If the policy species "discard" then drop the packet. • If the protection of the packet did not match the policy, drop the packet.

3. If the packet had been properly secured, then deliver it. Now what about non-IPsec-protected incoming trac? In this case lookup diercly in the SPD to verify if there is a matching rule and if the packet is to be discarded or bypassed (the default), do so. Example 1:

In the example below when pinging from 192.0.0.3 to 192.0.0.12, the ICMP echo requests will go from 192.0.0.3 to 192.0.0.12 without IPSec protection as the SPD on 192.0.0.3 does not enforce this protection. On 192.0.0.12 using tcpdump we can see ICMP echo requests without IPSec protection. But we do not see any ICMP echo reply because the ICMP echo requests will be discarded before answering as they do not match the policy on 192.0.0.12.

Figure 1: On 192.0.0.3

Figure 2: On 192.0.0.12

1

2

Figure 3: ICMP echo requests on 192.0.0.12, without ICMP echo replies

Figure 4: Ping failure on 192.0.0.3

Example 2:

Now if we keep the same policy on 192.0.0.3 and change the policy on 192.0.0.12 to be:

Figure 5: On 192.0.0.12 The ping from 192.0.0.2 to 192.0.0.12 will be ok as illustrated the gure beside we can observe ICMP echo requests and ICMP echo responses on 192.0.0.12.

3

Figure 6: Ping from 192.0.0.3

Figure 7: Tcpdump on 192.0.0.12