1 / 16

Automatic VPN Client Recovery from IPsec Pass-through Failures

Automatic VPN Client Recovery from IPsec Pass-through Failures. Dr. José Brustoloni Dept. Computer Science, University of Pittsburgh 210 S. Bouquet St. #6111, Pittsburgh, PA 15260 – USA Tel.: +1 (412) 624-8852, Fax: +1 (412) 624-8854 Email: jcb@cs.pitt.edu

armandon
Télécharger la présentation

Automatic VPN Client Recovery from IPsec Pass-through Failures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automatic VPN Client Recovery from IPsec Pass-through Failures Dr. José Brustoloni Dept. Computer Science, University of Pittsburgh 210 S. Bouquet St. #6111, Pittsburgh, PA 15260 – USA Tel.: +1 (412) 624-8852, Fax: +1 (412) 624-8854 Email: jcb@cs.pitt.edu Web: http://www.cs.pitt.edu/~jcb/

  2. 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

  3. Contributions • 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

  4. IPsec 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

  5. 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

  6. 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

  7. IPsec 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

  8. IPsec 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

  9. IPsec Pass-through version 3 (IPTv3) - timeouts • 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

  10. IPsec 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: • client sends packet to server • that server immediately sends packet back to that client • Communication hangs until rekeying (could take hours) or reboot Jose' Carlos Brustoloni

  11. IPTv3 race conditions In (b), (c), (d), none of the clients get their packets Jose' Carlos Brustoloni

  12. IPsec Pass-through Automatic Client Recovery (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 pingreply, 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

  13. 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

  14. IPTACR 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

  15. Related 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

  16. Conclusions • 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 Jose' Carlos Brustoloni

More Related