Dynamic Routing Inside IPsec VPNs New Threats and Defenses Paul Knight, Nortel Networks paknight@nortelnetworks.com

Agenda Setting the stage Attack and Defense IPsec topology background Dynamic routing in IPsec Attack and Defense Attacks from the Internet Denial of service Remote access “Split tunnel” Internal “branch-to-branch” attacks Routing attacks Misconfigurations Requirements: Securing IPsec routing

IPsec topology background The IPsec VPN model What is an “IPsec Gateway’? What are Tunnel and Transport Modes? What’s a Security Association? IPsec VPN topologies Not host-to-host Remote access VPN Major focus: Multi-site, branch offices

IPSec VPN models: Hosts and Security Gateways Internet Untrusted Network Host-to-host (not VPN) IPSec Gateway Internet Untrusted Network Trusted Network Trusted Network “Branch-to-branch” VPN model: between IPsec gateways IPSec may be implemented in two types of equipment, hereafter referred as “IPSec system” : a host or a Security Gateway that is an intermediate system between two networks ; one side of the Security gateway is viewed as untrusted, the other side as trusted. The Security Gateway implements IPSec on the untrusted interface in order to permit secure communications between hosts in the trusted network and hosts in the untrusted sides. Security services can be provided : between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. In the following slides : “Outbound traffic” refers to traffic coming from a trusted network, that must be forwarded to an untrusted network with an IPSec security protocol (ESP or AH). “Inbound traffic” refers to traffic received from an untrusted network with an IPSec protection, that must be forwarded to a trusted or untrusted network (with a Security Protocol or not). IPSec Gateway Internet Untrusted Network Trusted Network “Remote access” VPN model: host to gateway

Two IPSec Modes: Transport and Tunnel Mode Transport Mode IP Header Data Original IP Header IPSec ESP Header Data Tunnel Mode Optional Encryption Outer IP Header Inner IP Header The security protocols ESP and AH may be employed in two modes : Transport Mode or Tunnel Mode. In case of IPSec tunnel mode, a new IP header is attached to the original datagram. The entire original packet becomes the payload of the new one. The security protocol header is inserted after the outer IP header, and before the inner IP header. The outer IP addresses do not need to be the same as the inner IP address. The advantage of the tunnel mode is the complete protection of the encapsulated datagram and the possibility to use two addressing schemes : one public (in the outer header), one private (in the inner header). In case of IPSec transport mode, the original header is the outer header. The security protocol header appears after the IP header of the original packet and before the IP payload. In short, the location of the security protocol header, the IPSec header is inserted : after the IP header and before the upper layer protocol header (transport mode) or before the encapsulated IP header (tunnel mode). New IP Header IPSec ESP Header Original IP Header Data Optional Encryption

Application of the IPsec modes Host Host Internet Untrusted Network Can use Transport (or Tunnel) Mode between Hosts IPSec Gateway Internet IPSec may be implemented in two types of equipment, hereafter referred as “IPSec system” : a host or a Security Gateway that is an intermediate system between two networks ; one side of the Security gateway is viewed as untrusted, the other side as trusted. The Security Gateway implements IPSec on the untrusted interface in order to permit secure communications between hosts on the trusted network and hosts on the untrusted sides. Security services can be provided : between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. Untrusted Network Trusted Network Trusted Network Can ONLY use Tunnel Mode between Gateways (or extra IP encapsulation inside Transport Mode) – MUST hide IP addresses of trusted networks

Application of the IPsec modes – Remote Access IPsec Gateway Internet Untrusted Network Trusted Network SHOULD use Tunnel Mode between host and gateway Hide IP addresses of trusted networks Allow remote host to truly join trusted network IPsec gateway assigns host a tunnel address, like DHCP IPSec may be implemented in two types of equipment, hereafter referred as “IPSec system” : a host or a Security Gateway that is an intermediate system between two networks ; one side of the Security gateway is viewed as untrusted, the other side as trusted. The Security Gateway implements IPSec on the untrusted interface in order to permit secure communications between hosts on the trusted network and hosts on the untrusted sides. Security services can be provided : between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. Alternative: Transport Mode to “Application Level Gateway” IPsec gateway actually becomes a “host” Remote host is limited to applications supported by “gateway” Similar to SSL gateway model; heavy burden on “gateway”

Security Association (SA) SA = All the information shared between two IPsec systems to establish secure communication Selection of the security mechanisms: ESP or AH protection Ciphering algorithm Hash function Choice of authentication method Authentication of the two parties Choice of the ciphering and authentication keys As shown on the previous page, a choice is offered as to the way of fulfilling the IPSec services. The two IPSec Gateways must therefore first: negotiate the protocols used for authenticating and ciphering themselves, authenticating themselves, and choosing the keys. The exchange of this information leads to the creation of a “Security Association”, which allows the two Gateways to later exchange the data securely after the moment. A Security Association is a set of policy and keys used to protect information. A Security Association is a uni-directionnal (also called “simplex”) and logical connection between two IPSec Tunnels. To secure bi-directional communication between two hosts or two security gateways, two Security Associations (one in each direction) are required.

Security Databases A model to ensure a minimum of interoperability RFC 2401 - “Security Architecture for IP” Two Security Databases maintained on the IPSec system Security Policy Database (SPD) Security Association Database (SAD) Processing the IPSec traffic is largely a question of local implementation on the IPSec system and is not a standardization subject. However, some guidelines are defined to ensure interoperability between multi-vendor IPSec systems. RFC 2401 “Security Architecture for IP” defines a model with the two following databases : the Security Policy Database that contains the security rules, and the Security Association Database that contains parameters associated with each active Security Association. As a Security Association is a uni-directional concept, two SPDs and SADs (inbound SPD/SAD and outbound SPD/SAD) are required on each IPSec interface of a security system (either a host or a gateway). Typically, an IPSec Gateway has one IPSec interface connected to an untrusted public network, and one non-IPSec enabled interface connected to a trusted private network. In that case only one pair of SADs and SPDs is necessary.

Security Association Database All active Security Associations For each SA entry, includes : Identifier : Outer destination IP address Security Protocol SPI – Security Parameter Index Parameters Authentication algorithm and keys Encryption algorithm and keys Lifetime Security Protocol Mode (tunnel or transport) Anti-replay service Link with an associated policy in the SPD The Security Association Database contains all active Security Associations; these Security Associations are the SAD entries. The SA entries contains the negotiated parameters at the SA creation, such as : AH authentication algorithm and keys ESP authentication algorithm and keys ESP encryption algorithm and keys Lifetime of the Security Association : time after which an SA must be terminated or replaced with a new SA. This interval is expressed as a time or byte count. Security Protocol Mode : tunnel, transport. SAD

Security Policy Database Applies to every packet For each policy entry, includes: Selectors Destination IP Address Source IP Address Name Transport Layer Protocol (protocol number) Source and Destination Ports The policy : Discard the packet, bypass or process IPSec For IPSec Processing : Security Protocol and Mode Enabled Services (anti-replay, authentication, encryption) Algorithms (for authentication and/or encryption) Link to an active SA in the SAD (if it exists) According to the IPSec model, Security Policy Database (SPD) specifies what security services are to be offered to an IP packet. The Security Policy that should apply to an inbound or outbound traffic is chosen in the SPD by considering specific IP header fields and upper layer protocol fields. Those criteria are called “Selectors”. Selectors may be : Destination IP Address (inner header in tunnel mode) A single address (unicast broadcast, multicast) or a range of addresses (a single Security Association can be used to exchange packets destined to different hosts, behind an IPSec Gateway). Source IP Address (inner header in tunnel mode) A single IP address (unicast, broadcast or multicast) or a range of addresses (a single Security Association can be used to exchange packets coming from different sources). Name (User ID : DNS name, X500 distinguished name, or System Name : host name, X500 distinguished/general name) Transport Layer Protocol (protocol number) Source and Destination Ports (UDP, TCP,…) Each policy entry in the SPD includes an indication of whether traffic matching this policy will be discarded (traffic not allowed), subject to IPSec processing or whether IPSec processing will be bypassed (traffic allowed to pass without IPSec protection). If IPSec should be processed, the SPD specifies the security service to be provided : Security Protocol, Protocol Mode, anti-replay, authentication or encryption service, encryption or authentication algorithm. The SPD is managed via an administrative interface . The policy entry includes a Security Association, or a link to a Security Association defined in the SAD. Consequently, when an IPSec system identifies the policy that should be used for an outbound traffic, it knows in the mean time the Security Association that must be processed. Similarly, when an IPSec system identifies the SA associated with an inbound traffic, it knows in the same time the Security Policy that should apply. SPD

Inbound Packet Processing IPSec System SAD IP Header IPSec IP Header Destination IP address Security Protocol SPI SPD At receipt of an inbound packet, the receiver determines the appropriate SA in the SAD based on three fields : the outer destination IP address (although it could be a non unicast address, SAs management procedures are only defined for unicasts SAs) the Security Protocol (ESP or AH) and the SPI used to distinguish among different SAs terminating at the same destination and using the same IPSec protocol. Until the SA expires, the same SPI number is used by both sides of the IPSec connection. If no valid SA is identified, the packet is discarded. After identifying the SA entry in the SAD, the Gateway performs the IPSec processing according to the parameters specified in the SAD : it checks the Sequence Number if the anti-replay service is enabled it authenticates the packet with the algorithm and key specified in the SAD (for AH processing or ESP with authentication option enabled) ; it computes the ICV over the appropriate fields ; the packet pass the authentication check if the computed ICV matches the ICV included in the Authentication Data field. Otherwise, the packet is discarded. It decrypts the packet cyphertext with the algorithm and key specified in the SAD (for ESP processing with encryption option enabled) The IPSec system then looks up the matching security policy in the SPD ; this action is simplified by the link existing between an SA of the SAD and a Security Policy in the SPD. Finally the system verifies that the rules are respected by the inner IP packet (inner packet in tunneled mode). 1. Identifies the SA in the SAD upon the selectors 3. Performs the enabled IPSec services - Authentication - Decryption - Anti-replay service 4. Identifies the policy according to the selector 2. Read the SA parameters 5. Check the policy

Outbound Packet Processing IPSec System IP Header IP Header IPSec Policy Selectors SAD SPD For each outbound traffic (IP traffic received from the trusted network and sent to the public side of the Gateway), the IPSec system determine the IPSec processing that is required by looking up the SPD. The appropriate policy is selected considering the selector values. The Security System checks if the packet should be discarded, bypassed without IPSec processing, or protected by a Security Protocol. If IPSec is required, the packet is mapped to an existing SA, according to the SAD link, or a new SA is created, and a link is created between the SAD entry and the SPD entry. The authentication and/or encryption services are applied according to the algorithms and keys specified in the SAD. All traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, it might be spread over multiple SAs, depending on the applications being used, with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. 4. Read the SA parameters specified by the link 1. Identifies the policy in the SPD according to the selectors 2. Read the policy parameters 5. Computes the IPSec processing 3. Initiate new SA if necessary

Agenda Setting the stage Attack and Defense IPsec topology background Dynamic routing in IPsec Attack and Defense Attacks from the Internet Denial of service Remote access “Split tunnel” Internal “branch-to-branch” attacks Routing attacks Misconfigurations Requirements: Securing IPsec routing

Why is dynamic routing in IPsec VPNs important? Like ANY sizable network – without dynamic routing, life is HARD! It’s to hard to maintain static routes Hard to set up load balancing Hard to set up failover Hard to manage changes Hard to add new network sites

The IPsec “routing problem” Usual conversation: What’s the problem? You can already carry routing protocols over IPsec. Yes, but you can’t actually use them to ROUTE. Huh? The IPsec Security Associations have selectors that determine the traffic they allow. They are like static routes. Oh… Yeah… I see the problem.

The IPsec “routing problem” Dynamic routing in VPNs is a requirement Tunnel mode is incompatible with dynamic routing draft-touch-ipsec-vpn-04.txt (IETF – http://www.ietf.org/internet-drafts/X) draft-wang-cevpn-routing-00.txt draft-knight-ppvpn-ipsec-dynroute-01.txt WHY? Security Associations are created with selectors  Tunnels have built-in “static routes” SP and SA Database lookups do the “routing” SA setup is orders of magnitude slower than routing change Dynamically changing SA due to routing updates doesn’t scale

Reference topology Site X CPE Untrusted Network Site Y CPE Site A CPE Site Z CPE Typical dynamic routing issues “Z” adds a new network New site added (Hub/spoke model) A link (IPsec connection) breaks; re-route through another site

SP, SA Databases determine “routing” into tunnels – cannot adapt dynamically IPsec Gateway (CPE) at Site A SAD SPD Site X Untrusted Network SA pairs – 1 per address range Site Y Outbound traffic Site Z Route exchange possible, but useless… (SPD, SAD control “routing”)

The basic solution IP-in-IP over Transport (IIPtran) Remove the tunnel’s “static routes” …. HOW? (1) Use “wild card” in tunnel SAs (allow all traffic) OR (2) Use encapsulation to make the traffic fit the “static route”, by setting destination address in the encapsulated traffic IP-in-IP over Transport (IIPtran) Generic Routing Encapsulation (GRE) in tunnel or transport Both approaches are essentially similar in key ways, but (2) is more secure IPsec can still apply source/destination selectors Less chance for errors due to different systems’ dynamic routing abilities Either way, you must do “routing” (SA selection or encapsulation addressing) outside IPsec, and push traffic into a “VPN Tunnel” (may be Transport Mode)

Routing outside IPsec: Each SPD/SAD handles a smaller address selector range One “VPN Tunnel” SA pair between sites (unless QOS or security requires more) IPsec Gateway at Site A SAD SPD Site X CPE Untrusted Network Routing SPD SAD Site Y CPE Outbound traffic SPD SAD Site Z CPE Routing Exchange Via OSPF, RIP, etc.

Tunnel mode = Transport mode + IP encapsulation Key concept for dynamic routing Determine “next IPsec hop” of the packet, using policy, based on any criteria the “routing engine” can handle –route to destination (using dynamic information!), protocol, port (socket), even content analysis (URL, etc.) Construct new encapsulating IP header with source/destination of next IPsec hop Pass to IPsec process for TRANSPORT mode processing Resulting packet is equivalent to tunnel mode, but now it is routed using dynamic routing updates

Tunnel mode = Transport mode + IP encapsulation Remember transport mode? Original IP Header IPSec ESP Header Data { New “Data” Optional Encryption IP Header Data IP-in-IP encapsulation Original IP Header Data New IP { New “Data” Addresses in new IP header determines where packet goes New IP Header IPSec ESP Data Transport Mode Original IP Optional Encryption The security protocols ESP and AH may be employed in two modes : Transport Mode or Tunnel Mode. In case of IPSec tunnel mode, a new IP header is attached to the original datagram. The entire original packet becomes the payload of the new one. The security protocol header is inserted after the outer IP header, and before the inner IP header. The outer IP addresses do not need to be the same as the inner IP address. The advantage of the tunnel mode is the complete protection of the encapsulated datagram and the possibility to use two addressing schemes : one public (in the outer header), one private (in the inner header). In case of IPSec transport mode, the original header is the outer header. The security protocol header appears after the IP header of the original packet and before the IP payload. In short, the location of the security protocol header, the IPSec header is inserted : after the IP header and before the upper layer protocol header (transport mode) or before the encapsulated IP header (tunnel mode). Packet looks like Tunnel Mode!

Routing with VPN tunnels What is a “VPN TUNNEL?” An IPsec SA with NO effective address filters May be IPsec tunnel mode or IP-in-IP over transport mode It allows ANY IP traffic (unicast/multicast) to pass It allows routing protocols to pass Its end points are the IPsec gateway interfaces It still protects all traffic with encryption It is like an Ethernet, ATM, or Frame Relay “link” over the Internet, but secured by IPsec Since you can’t use the IPsec tunnel definitions or “filters” to select destinations, you MUST route before putting the traffic into an IPsec “VPN tunnel” VPN tunnel = “a logical link between two entities which is created by encapsulating packets within an encapsulating header for purpose of transmission between those two entities for support of VPNs. In the context of provider provisioned CE-based VPNs, a VPN tunnel is an IP tunnel (e.g., using IPsec, L2TP, GRE, IP-in- IP) between two CE devices over the SP's network. In the context of this document, a VPN tunnel is achieved using IPsec in tunnel mode or via an IP-in-IP tunnel protected by IPsec in transport mode between two CE devices.” “A Framework for Provider Provisioned CE-based Virtual Private Networks using IPsec”, - draft-ietf-ppvpn-ce-based-01.txt

Routing with VPN Tunnels: Requirements for IPsec Gateways Full-power router “inside” the IPsec gateway, with traffic and route filters, even firewalls Ability to separate VPN routes from external (untrusted network) and local routes Ability to use the endpoint of the IPsec “VPN Tunnel” just like any IP-capable interface To pass routed traffic To send and receive routing protocols

Agenda Setting the stage Attack and Defense IPsec topology background Dynamic routing in IPsec Attack and Defense Attacks from the Internet Remote access “Split tunnel” Denial of service Internal “branch-to-branch” attacks Routing attacks Misconfigurations Requirements: Securing IPsec routing

Remote Access IPsec VPN routing attack IPsec Gateway Internet Untrusted Network Remote Client Trusted Network Split tunneling Captive tunnel: Client’s “default route” points into tunnel to IPsec gateway; other routes not allowed Split tunnel: Client’s default route is into Internet; specific routes to trusted network are loaded into Client’s routing table by IPsec Gateway Denial of Service Attacks Various attacks to waste Gateway’s resources (bandwidth, open connections, processing time, etc.) Not the subject of this talk (but interesting!)

No Split Tunneling: Split Tunneling: IPsec Gateway Internet Untrusted Network Remote Client Trusted Network Internet Host Firewall Split Tunneling: IPsec Gateway Internet Untrusted Network Remote Client Trusted Network Internet Host Firewall

Why allow split tunneling? Avoid wasting bandwidth at VPN hub site Internet traffic of clients would traverse the hub site (Can be avoided by policy blocking Internet access during remote access, forcing client to logout of VPN) Short DHCP/PPPOE leases may require frequent contact to server at client’s ISP Can’t contact server if all routes point to VPN tunnel Convenience of keeping VPN connection up during other Internet access

Split Tunneling – Potential Attacks FTP relay through client Client running FTP server can become conduit from Internet into trusted network Other similar services running on client – tftp, smtp, or custom relay application, maybe malicious application RAT – Remote Access Trojan on client Back Orifice, etc. PC Anywhere (not a “Trojan” but same issue) Allow remote control control of PC, and thus potential access to trusted network

Split Tunneling – Defenses Prevent split tunneling Corporate policy decision Enforcement through Gateway/client software capabilities Gateway sends only default route to client Client s/w reads routing table on client, reports to gateway and/or blocks access if routes are found. Prevent active relay services or remote control Break connection if unexpected port is open on client Both defenses depend on client software ability to determine true state of client machine. Depends on operating system and multitasking, multiprocessing capabilities of client system.

Branch-to-Branch IPsec VPN Routing Issues IPSec Gateway IPSec Gateway Internet Untrusted Network Trusted Network ? Default Route? Default Route? Trusted Network Firewall Firewall Misconfiguration Default Route issues Internal Routing Attack

Security risks of incorrect routing in IPsec VPNs Traffic may be forced over an unprotected path May be intercepted Traffic goes toward wrong destination Doesn’t get to correct destination Traffic follows “wrong” path toward correct destination

Attacks on routing Injection of routes inside a site Malicious Routing process running on compromised host or router Redirect traffic toward a compromised system internal to trusted network Redirect via default route over unprotected path through untrusted network Misconfiguration Advertising routes via unprotected path Static routes configured in routers Routed (routing daemon) running on unauthorized hosts

Protection against routing attacks Routing authentication Options for OSPF Keyed MD5 verifies identity Digital signature allows tracing of bad route information Audit routers for bogus routes Restrict use of routing protocols on hosts Use default route instead Implement redundancy on routers (VRRP) or switches in LAN, not in host routing

Default route attacks Where does default route point? To Internet? Lost “internal” route can result in traffic being sent over Internet Particularly problematic if the destination is reachable via Internet Key solution: policies on firewall No traffic to internal destinations goes out through firewall No traffic from internal source address can com in through firewall Harder solution: no default route to Internet Specific management/advertisement of “allowable” routes

Securing IPsec Routing – Dynamic Routing Requirements IPsec Gateway at Site A SAD SPD Site X CPE Firewall functions Untrusted Network Routing SPD SAD Site Y CPE Outbound traffic SPD SAD Site Z CPE Routing Exchange Via OSPF, RIP, etc.

Securing IPsec Routing – Dynamic Routing Requirements Strong Firewall capabilities Inbound/outbound Full range stateful inspection capabilities Full router functionality INSIDE the IPsec Gateway Route filtering to prevent attacks Ability to separate internal/external routes Ability to see IPsec peer gateways as next-hop for routes learned via IPsec VPN tunnels Apply the routing rules by encapsulating the traffic, with “next IPsec hop” as the destination

Conclusion: Dynamic IPsec Routing opens new vulnerabilities The manageability and flexibility of dynamic routing are important for large networks, BUT: It is not enough to just add routing to an IPsec VPN box Firewall traffic filtering PLUS full-featured routing capabilities must be integrated into the system Remote access IPsec VPN security depends on trusted client software To control insecure routing or relay capabilities of client Use intrusion detection monitoring for verification

Questions??? Thank You!