Title Place here by forrests

VIEWS: 7 PAGES: 16

									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/

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)



 
WoNS 2005

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 2

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 Passthrough’s failures improves IPsec Pass-through’s interoperability requires only simple modifications in IPsec client negligible overhead

WoNS 2005

Jose' Carlos Brustoloni

3

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


WoNS 2005

Jose' Carlos Brustoloni

4

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


WoNS 2005

Jose' Carlos Brustoloni

5

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


WoNS 2005

Jose' Carlos Brustoloni

6

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


WoNS 2005

Jose' Carlos Brustoloni

7

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


WoNS 2005

Jose' Carlos Brustoloni

8

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

WoNS 2005

Jose' Carlos Brustoloni

9

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:





WoNS 2005

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

IPTv3 race conditions

In (b), (c), (d), none of the clients get their packets
WoNS 2005 Jose' Carlos Brustoloni 11

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 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 WoNS 2005 Jose' Carlos Brustoloni 12 starts another one
♦

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

WoNS 2005

Jose' Carlos Brustoloni

13

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

WoNS 2005

Jose' Carlos Brustoloni

14

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 15

WoNS 2005

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


WoNS 2005

Jose' Carlos Brustoloni

16


								
To top