Automatic VPN Client Recovery from IPsec Pass-through Failures Dr. José Brustoloni Dept. Computer Science, University of Pittsburgh 210 S. Bouquet St

Automatic Automatic VPN Client Recovery from VPN Client Recovery from

IPsec Pass-through FailuresIPsec Pass-through Failures

Dr. José BrustoloniDept. Computer Science, University of Pittsburgh210 S. Bouquet St. #6111, Pittsburgh, PA 15260 – USA Tel.: +1 (412) 624-8852, Fax: +1 (412) 624-8854Email: [email protected]: http://www.cs.pitt.edu/~jcb/

Jose' Carlos Brustoloni 2WoNS 2005

Motivation Motivation

♦ Use of Network Address Translation (NAT) is widespread in home and SOHO networks

♦ However, NAT interoperates badly with many protocols including IPsec, the protocol suite commonly used in virtual

private networks (VPNs)

♦ IPsec Pass-through promotes interoperation between NAT and a useful subset of IPsec (IKE and ESP tunnel mode) some IPT version included in most home and SOHO routers heuristic scheme, not well characterized before can fail in certain scenarios these scenarios not well characterized before, either


ContributionsContributions

♦ We characterize IPsec Pass-through’s: operation modes (there are three in commercial use), limitations and failure modes, and interoperation with other solutions

♦ We propose and evaluate IPsec Pass-through Automatic Client Recovery (IPTACR): promotes automatic VPN client recovery from IPsec

Pass-through’s failures improves IPsec Pass-through’s interoperability requires only simple modifications in IPsec client negligible overhead


IPsec Pass-through’s constraintsIPsec Pass-through’s constraints♦ NAT can translate only IP addresses / not IKE port numbers or ESP security parameters index (SPI):

IKE layered on UDP, but many implementations require both source and destination ports equal to 500

ESP does not have a source “port number” field that can be translated, like TCP’s and UDP’s source port numbers

ESP’s SPI set by destination♦ Must resort to heuristics to determine client that should get an

IPsec packet received from Internet♦ Cannot support AH (any mode) or ESP transport mode

AH scope includes IP addresses Given that NAT does not have authentication keys, NAT

invalidates AH Authentication scope in ESP transport mode includes TCP or UDP

checksum Therefore, ESP authentication depends on addresses in IP

header, invalidated by NAT


IPsec Pass-through version 1 (IPTv1)IPsec Pass-through version 1 (IPTv1)

♦ IPTv1 enables only one IPsec session at a time♦ If IPTv1 receives IPsec packet from a client and currently

there is no IPsec session active, IPTv1: notes client’s address forwards to client’s address any IPsec packets received from

Internet drops IPsec packets from any other client deactivates session after a period of inactivity


IPsec Pass-through version 2 (IPTv2)IPsec Pass-through version 2 (IPTv2)

♦ IPTv2 enables only one IPsec session per server♦ If IPTv2 receives IPsec packet from a client and currently

IPTv2 has no IPsec session active for the server at the packet’s destination, IPTv2: notes client’s address and server’s address forwards to client’s address any IPsec packets received from

server drops IPsec packets to that server from any other client deactivates session after a period of inactivity


IPsec Pass-through version 3 (IPTv3) - IKEIPsec Pass-through version 3 (IPTv3) - IKE

♦ IPTv3 enables any number of IPsec sessions per server♦ IKE table: client address, client cookie, server address, server cookie

entry outstanding if no server cookie, otherwise established

♦ If IPTv3 receives from server packet whose client and server cookies match established entry, forward packet to entry’s client

♦ If IPTv3 receives from client IKE packet whose client’s address and cookie and server address match no entry in table: if client cookie and server address match another client’s outstanding

entry, drop packet otherwise, create outstanding entry with client’s address and cookie and

server address

♦ If IPTv3 receives from server IKE packet whose client and server cookies match no established entry, but client cookie and server address match an outstanding entry: convert entry to established, including server cookie forward packet to that entry’s client


IPsec Pass-through version 3 (IPTv3) - ESPIPsec Pass-through version 3 (IPTv3) - ESP

♦ ESP table: client address, client SPI, server address, server SPI entry outstanding if no client SPI, otherwise established

♦ If IPTv3 receives from server ESP packet whose client SPI matches established entry, forward packet to entry’s client

♦ If IPTv3 receives from client ESP packet whose server address and SPI match no entry in table: if server address matches an outstanding entry, drop packet otherwise, create outstanding entry with client address and server

address and SPI

♦ If IPTv3 receives from server ESP packet whose client SPI matches no established entry: if server address matches an outstanding entry:

convert entry to established, including client SPI forward packet that entry’s client

otherwise, multicast packet to all clients that recently sent IKE packets to server


IPsec Pass-through version 3 (IPTv3) - IPsec Pass-through version 3 (IPTv3) - timeoutstimeouts

♦ Timeout ESP outstanding entries after short period To

♦ After ESP outstanding entry collides with another client, limit to No the number of packets sent that match that entry

♦ Timeout ESP established entries after period of inactivity Tei


IPsec Pass-through limitationsIPsec Pass-through limitations

♦ Ready recovery from crashes, since only IP addresses translated♦ No fail-over recovery, however♦ IPTv1 problematic, e.g., in household where both spouses work♦ IPTv2 still problematic, e.g., in hotel where more than one guest

works for same employer♦ IPTv3 overcomes this limitation, but can suffer ESP collisions and

race conditions: Collision: more than one client connected to same server chooses

same client SPI client whose entry gets established first receives all such packets

Race conditions: sequence of ESP packets not in expected order:1. client sends packet to server2. that server immediately sends packet back to that client

Communication hangs until rekeying (could take hours) or reboot


IPTv3 race conditionsIPTv3 race conditions

In (b), (c), (d), none of the clients get their packets


IPsec Pass-through Automatic Client Recovery IPsec Pass-through Automatic Client Recovery (IPTACR)(IPTACR)

♦ Immediately after client sends final IKE packet for creating or rekeying ESP tunnel, client sends server ping request using new outgoing security association (SA)

♦ Client keeps using old outgoing SA (except for ping requests) until it receives a ping reply in corresponding incoming SA, or old outgoing SA expires

♦ If for period greater than maxidle client has not received any packets from incoming SA, client sends ping request using corresponding outgoing SA

♦ Client retries ping request each pingtime period, up to pingtries times

♦ If client persistently does not receive ping reply, client rekeys tunnel

♦ If client repeatedly tries to rekey tunnel and does not receive any packets from server, then clients drops existing IKE session and starts another one


IPTACR benefits IPTACR benefits

♦ Ping requests immediately after rekeying can greatly reduce chance of races #1 and #2

♦ Ping requests when tunnel idle can eliminate race #4♦ Tunnel rekeying promotes recovery from collisions or any of

the race conditions♦ New IKE session promotes fail-over recovery if there is a

back-up router


IPTACR resultsIPTACR results

♦ Instrumented clients and server to create collisions and race conditions on demand

♦ IPTACR automatically recovered from each failure♦ Negligible impact on FTP performance between client and

server if tunnel busy, overhead simply a ping request/reply per SA

lifetime


Related workRelated work♦ NAT Traversal

client and server discover NAT between them IKE/UDP dynamic ports ESP/UDP same dynamic ports as corresponding IKE session Standards-track, but previously implemented in incompatible

ways by different vendors; needs to be configured in VPN gateway

Does not interoperate well with IPTv1, IPTv2 new IPsession only after entry timeout

Interoperates well with IPTv3, especially with IPTACR♦ RSIP, EASE

client leases SPIs from NAT needs modifications both in client and in NAT

♦ IPv6 could reduce need for NAT ... if providers do no charge for extra addresses


ConclusionsConclusions

♦ IPsec Pass-through enables NAT to interoperate well with a useful subset of IPsec

♦ Several versions available♦ IPTv2 only slightly more complex and much less limited

than IPTv1♦ IPTv3 considerably more complex and less limited than

IPTv2, but susceptible to collisions and race conditions that may require rebooting

♦ IPTACR promotes automatic recovery from IPTv3 failures without rebooting neglibible overhead better interoperation with NAT Traversal

Documents

Automatic VPN Client Recovery from IPsec Pass-through Failures Dr. José Brustoloni Dept. Computer Science, University of Pittsburgh 210 S. Bouquet St