There are companies today who provide fast path implementations - either as software component or as an add-on card such as PCIe card that goes onto PCI slot of main processing unit such as x86 based mother board.
Software based fast path implementations are becoming quite popular in Multicore processing environment. Fast path is run on some cores and rest of the cores are used for other applications.
Ipsec fast path implementations typically work as follows:
- Fast path typically owns the Ethernet and other L2 ports. That is, all packets come to the fast path plane first.
- If there is enough state information to process the packet, fast path implementations act on the packets without involving normal path running in main cores. Packet might even get transmitted out after working on the packet. If the packet requires some other application processing that is not present in the fast path, then the packet is handed over to normal path processing unit. In case of Ipsec fast path, decrypted packets are given to the normal path in inbound direction. In outbound direction, it does Ipsec processing before packet is sent out.
All fast path implementation from different vendors are not created equal.
In this post, I specifically would like to concentrate on 'Inbound Policy Check'. Some fast path implementation skip this check. Reasons given by vendors of the fast path implementation typically is that this is done for performance reasons. Some people believe that it can be done without any implications on security too. Unfortunately, that is not true.
What is inbound policy check?
Inbound policy check ensures that the decapsulated IPsec packets used the SA that was formed for this traffic. And also it ensures that the inbound policy rules allow this traffic to come through.
What are the issues if the inbound policy check is not done?
I can think of two issues - DoS attack & Allowing the traffic that is supposed to be denied (Access control violation).
Let us assume that a corporation gateway has two tunnels to two different partners - Partner1 and Partner2. Without inbound policy check, it is possible for partner1 to interfere with the sessions/traffic between corporate gateway and partner2. That is, partner1 can create denial of service attack on partner2 traffic. Even though I have taken the example of partners, this kind of attack is possible among IPsec remote users.
Let us assume this scenario:
SGW: Security Gateway of a corporation - It is protecting network 10.1.10.0/24
PSGW1: Partner 1 Security Gateway - Its LAN is 10.1.11.0/24
PSGW2: Parnter 2 Security Gateway. Its LAN is 10.1.12.0/24
There are two security tunnels from SGW - One to PSGW1 and another to PSGW2. Let us call them Tunnel1 and Tunnel2 respectively.
Tunnel1 is negotiated to secure traffic between 10.1.10/24 to 10.1.11.0/24. Tunnel2 is negotiated to secure traffic between 10.1.10/24 and 10.1.12.0/24. Let us also assume that the Tunnel1 SPI at the SGW is SPI1 and the Tunnel2 SPI at the SGW is SPI2.
It is expected that any packets coming from PSGW1 are expected to have SPI1 in its ESP header and inner IP packet SIP address be one of addresses in 10.1.11.0/24 and DIP address be one of 10.1.10.0/24. Similarly it is expected that any packet coming from PSGW2 is expected to have SPI2 in its ESP header and inner IP packet SIP address be one of addresses in 10.1.12.0/24 and DIP address be one of 10.1.10.0/24.
Now to the attack scenario:
If PSGW1 network sends the inner packets whose IP addresses is other than 10.1.11.0/24 and 10.1.10.0/24 , then the SGW is expected to drop those packets. SGW can only drop the traffic only if SGW does the inbound policy check. If PSGW1 is allowed to send any inner packets, then it is possible that PSGW1 and its network can misuse this by sending packets with inner packets with IPs of PSGW2 LAN and SGW LAN. Since it sends the traffic on the right SA using its own SPI, SGW IPsec packet processing will happen smoothly. If no other check is done, this traffic can go to SGW LAN. Based on type of traffic, different attacks are possible. Some of the attacks that are possible are:
- If attacker at PSGW1 guesses the TCP ports of some long lived sessions between PSGW2 network and SGW network, it can send the RST packets or ICMP Error messages to terminate the connections.
- Attacker at PSGW1 can send ICMP Echo message to SGW1 LAN network multicast IP address with SIP as PSGW2 LAN machine. Replies from all machines in the SGW1 LAN go to PSGW2 victim machine and overwhelm the machine.
Access Control Violation:
This is one more problem that can be faced if inbound policy check is not done.
Many Ipsec normal path implementations provide facility for administartors to add multiple rules with different actions to the secuirty policy database (SPD). Rules normally have 5-tuple selectors in ranges/subnets/exact IP addresses for source and destination and ranges/exact values for UDP/TCP ports. Actions can be one of 'Bypass', 'Discard' and 'Apply'. Rules are arranged in a ordered list. During packet processing, rule search is done. Rule search is stopped upon match. Action specified on the matching rule is taken. If the action is 'Bypass', then the packet is forwarded without any Ipsec processing. 'Discard' action indicates the packet is to be dropped. Apply action indication that Ipsec processing is to be applied. Normally administartors configure the rules with respect to outbound traffic. Inbound policy rules are created automatically by the system from outbound policy rules by reversing the selectors - That is SIP becomes DIP and vice versa. Similary SP becomes DP and vice versa.
Now let us look at the possible access policy violation with following example:
Let us take these two policy rules in outbound list:
Rule 1: SIP: 10.1.10.0/24 DIP 10.1.11.0/24 Protocol UDP Action : Discard
Rule 2: SIP: 10.1.10.0/24 DIP 10.1.11.0/24 All Protocols Action : Apply.
Inbound policy rule list would look like this:
Rule 1: SIP: 10.1.11.0/24 DIP: 10.1.10.0/24 Protocol: UDP Action : Discard
Rule 2: SIP: 10.1.11.0/24 DIP: 10.1.10.0/24 Protoco: All Action: Apply.
Administartor creates the rules in above fashion to indicate that to discard any UDP traffic between the networks, but allow everything else by securing the traffic.
Assume that above policy rules are created in SGW1.
When a TCP packet is sent from the SGW1 LAN and SGW2 LAN, then second rule gets matched and SA is created to allow traffic 10.1.10/24 to/from 10.1.11.0/24 for all protocols. If SGW2 either misconfigured or intentionally sends UDP traffic in the SGW1-SGW2 tunnel, then SGW1 is expected to drop the packet even if it successfully decrypts and decapsualtes the packet. This can only happen if the SGW1 does the inbound policy check on inner IP packet.
If SGW1 does not do any inbound policy check, UDP traffic would have been passed to the 10.1.10.0/24 network thereby violating the access rules configured by the administartor.
I hope I could give good reasoning on why inbound policy check is required. Some fast path implementation don't do this. So, as a development integration engineer, please ensure that not only your implementation, but also fast path implementation does all the checks that are required.