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
Jose' Carlos Brustoloni 3WoNS 2005
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
Jose' Carlos Brustoloni 4WoNS 2005
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
Jose' Carlos Brustoloni 5WoNS 2005
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
Jose' Carlos Brustoloni 6WoNS 2005
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
Jose' Carlos Brustoloni 7WoNS 2005
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
Jose' Carlos Brustoloni 8WoNS 2005
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
Jose' Carlos Brustoloni 9WoNS 2005
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
Jose' Carlos Brustoloni 10WoNS 2005
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
Jose' Carlos Brustoloni 11WoNS 2005
IPTv3 race conditionsIPTv3 race conditions
In (b), (c), (d), none of the clients get their packets
Jose' Carlos Brustoloni 12WoNS 2005
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
Jose' Carlos Brustoloni 13WoNS 2005
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
Jose' Carlos Brustoloni 14WoNS 2005
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
Jose' Carlos Brustoloni 15WoNS 2005
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
Jose' Carlos Brustoloni 16WoNS 2005
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