Subject: A proposal about maximizing VPN service availability

From: "Huang, Yuming, ALABS" <[email-masked]>
Date: Tue, 3 Oct 2006 15:58:52 -0500

Seems to me that the current available VPN software and protocols (RFCs)
are not able to handle the following situation:

A laptop (say with WinXP OS) has both Wifi 802.11 a/b/g and NIC (RJ-45)
port.  Both physical network connections are in working status, and both
are talking to a router which is connected to a cable modem. A VPN
client is started on the laptop. The VPN client picks RJ-45 cable
physical connection (saving ip# etc.) and establishes a VPN (logical)
connection to a VPN server (of certain intranet). Everything works well
before the RJ-45 cable is unplugged as the laptop must be moved into
another room. Although the wifi network is still connecting the laptop
to the router, the VPN client stops working. On the other hand, if the
RJ-45 cable is unplugged when the VPN client is started, the VPN client
keeps working when the laptop moves among rooms.

The above sample has two physical connections on a LAN setting.
Actually, average computers (desktop, laptop, notebook, etc.) nowadays
have phone line (RJ-11), NIC net (RJ-45), Wifi 802.11 a/b/g, USB,
Firewire (IEEE 1394), etc.  which make the above sample common.

It's obvious that we need a VPN protocol that switches among all the
physical connections on a computer (based on, say availability, speed,
security level, etc.) and maintains certain security level, in order to
provide maximum service availability.

Do we have it now?

If not, the following logic may help us to achieve the goal:

The new VPN Client detects and monitors all the available physical
connections (ip#, mac#, gateway ip#, speed, security level, etc.) on the
computer the VPN runs from. The VPN Client communicates (in certain time
period or based on change) with VPN server about the information using
the existing encryption algorithm. The VPN client knows which physical
connection it is using. If the physical connection becomes invalid and
it finds (and picks if more than one) another physical connection
available, then the VPN client sends a request to the VPN server via the
available physical connection. The VPN sever, upon receiving the
request, and does the authentication, sends back data packets to the VPN
client (via new port, ip# on the computer). Given this is done quick
enough, the switch is transparent to users. The VPN client may inform
users about the switch.

On the other hand, the VPN client UI may allow users to switch among
available physical connections (for fast speed, for example).

SAMPLE FLOW CHART: 

-         Step1. vpn client starts to run on user's PC; 

-         Step2. vpn client collects available IP#s corresponding to
every physical connection; 

-         Setp3. vpn clients send data frame/packet to vpn server,
including user id, pwd, token display, etc. together with the collected
IP#s. Before sending out, these data are encrypted using existing
encryption algorithms, for example, public/private keys. 

-         Step4. Upon authentication, negotiation about keys etc, a
secure tunnel is established between user's PC and VPN server. VPN
server saves all the IP#s (available on a client) sent from the client.
This is the only new stuff -- all the old VPN saves/uses only ONE IP# of
client PC. The tunnel is based on one (and only one) physical connection
(one network interface, one ip#) on user's pc. As for which one is
picked, it is determined by platform OS and VPN implementation. 

-         Setp5. User's applications based on VPN are ready to run. 

-         Setp6. If the physical connection (used by VPN) fails, VPN
client knows this via many ways. Either platform OS may send out events,
or VPN timeout without receiving data packets (waited by VPN). The VPN
server may notice the failure too. 

-         Step7. (Similar to TCP/IP)The VPN client sends signal packet
(containing say, packet# it is waiting for) to server via another still
available physical connection (IP#). The signal/data is encrypted using
standard VPN technologies. 

-         Step8. Upon receiving the signal, VPN server matches the VPN
client IP# to the saved IP#s. Then VPN server may keep or change
existing encryption parameter and send data packets to the new vpn
client IP#. The IP# is the real IP# on user's PC. For VPNs that hide the
real IP#, the logic applies too. 

-         Step 9. VPN client receives packets via its new (available)
physical connection (new IP#). 

Given the auto switch (step6~9) is quick enough, User may not notice the
physical connection failure (setp6).  For all the VPNs: PPTP, L2F, L2TP,
IPSec etc (both OSI level 2 (data-link layer) or 3 (network layer)), if
a VPN client IP# is involved, the logic can be applied. The new VPN
client and server save user's login credential, and all the ip#s
corresponding to all the available connections on user's computer. When
the selected connection (which is used for previous VPN connection)
becomes un-available, the new VPN switches to another available
connection. Basically, VPN server continues to recognizes/responds to ip
packets from the same user on the same machine, regardless the IP# being
used. Therefore user's application keeps working if there is at least
one connection. 

 

Thanks for your attention.

Yuming Huang

630-810-7856

AT&T Labs