| |||||
|
|
|
I've just spent a couple of hours reading on VPNs.
Points to ponder: (OSI = Open Systems Interconnection, which specifies the seven-layer networking interoperability model, where layer 1 = the wire, and layer 7 = the apps.) * VPNs are available in hardware-based and software-based configs. * All VPNs use tunnelling, encryption, and authentication. a) Tunnelling comes in four flavours: * Socks 5 -- apparently used in proxy VPN situations only. * PPtP -- Point-to-Point tunnelling Protocol -- Microsoft NT4, Ascend, 3Com, US Robotics and ECI Telematics. Also uses RD4 using encryption, which uses an encryption key generated using the user's login, and is therefore subject to a brute-force attack on the key. MS uses MPPE to encrypt the link data only, and MS-CHAP, and EAP to encrypt the payload (data). * L2TP - Layer 2 tunnelling protocol -- Cisco and others, it adds Layer 2 Forwarding to PPtP, and can itself do authentication, via certificates that authenticate the computer itself, not the user. Encryption can be handled by IPSec (!) using DES or 3DES. * IPSec -- Internet Protocol Security -- "generic" layer 3 tunnelling, gained early wide support in the automotive supplier industry, does not route protocols other than IP. Uses DES, 3DES and Blowfish and others for encryption. W2k uses IPSec b) Encryption varies, but is generally handled in a non-dialup environment using keys with 40 to 192 bitlengths. Encryption of data using long bitlengths can *significantly* increase overhead for software-based VPNs at DSL and higher rates, though it has less impact at dialup data rates. c) Authentication is often accomplished by communication with the VPN device or software, and a RADIUS ("Remote Authentication Dial-In User Service") server or domain controller. This is handled at the host end, of course. WAG: It is not unlikely that RMLS' authentication service will not allow two client connections from one IP, as an authentication security rule. The other firm that is doing this now may have had to have RMLS change that rule for them. * The RF500S does not "do" VPN. It "Supports outbound IPSec and PPTP pass through", whatever that means (http://www.multitech.com/DOCUMENTS/datasheets/63.asp), and the "User Manual" mentions IPSec not at all. It should be noted that many "old" firewalls cannot route VPN traffic at all, esp. IPSec. From the MultiTech statement above, it appears that the RF500S can. * IPSec in tunnel mode is difficult to implement with NAT, as IKE does not work with NAT, making the exchange of keys impossible. Proprietary extensions to IPSec work around this. * IPSec, as implemented in W2k, can operate in two modes: transport and tunnelling. "Transport" mode is for end-to-end connections between two systems. "Tunnelling" mode is better suited for use where the data will travel through multiple gateway servers. * Authentication on W2k systems can use Kerberos v5, public/private key (PKI) signatures using certificates, or passwords and pre-shared keys. After successful authentication, the IPSec policy determines the level of encryption and session key refresh interval. W2k's VPN Wizard has several presets or templates to initially populate the IPSec policy table and filters. * VPN technology is still not standardized. VPN products from one vendor frequently cannot work with VPN products from a different vendor, even when both use the same tunnelling method and encryption. * Software VPN, as implemented in W2k, is not noted for working with other VPN solutions. * Intel and 3Com market NICs that do IPSec encryption and packetizing, thereby offloading the heaviest VPN chores onto dedicated hardware. MultiTech offers a RouteFinderVPN ($3,200) that does this function for a network. This latter is a true VPN device, rather than VPN software. More later; bedtime now.19 Oct 2001 01:22:34 PST |
| |||||
|
|
