|Read about Lisa|
by Lisa Phifer, Core Competence
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
This column is the third in a series on securing enterprise network access by PDAs. Last month, we examined PDA access to wireless LANs -- an environment where handheld capabilities can be seen without bandwidth distractions. In today's column, we examine PDA security in a more traditional wireless setting: cellular data networks.
Pushing data over cellular
Patient business travelers have long combined PDAs with cellular to reach Internet mail and web servers. Second generation (2G) circuit-switched data services can support brief e-mails and other short transactions, but are far too slow for interactive access to large messages or file attachments. GSM services offered by carriers like Cingular and VoiceStream crawl at 9600 bps. CDMA services from Sprint PCS and Verizon Wireless pack a whopping 14.4 Kbps. iDEN services from Nextel and Southern LINC top out at 19.2 Kbps. At these speeds, web browsing can be painfully slow. "Web clipping" applications and WML conversion help to reduce bandwidth demands, but impose their own limitations.
Packet-switched data services like CDPD (Cellular Digital Packet Data) transmit bursts of data over radio channels. At 19.2 Kbps, CDPD is slightly faster than GSM or CDMA -- but billing may be quite different. Circuit-switched subscribers are charged by connect time. Packet-switched users are charged by data sent and received. Some providers offer both usage-based and flat rate plans. For example, if you want CDPD on your Palm, GoAmerica offers Go.Unlimited for $44.95/month, or Go.Lite for $9.95/month, plus 10 cents/KB after the first 25 Kbytes.
Many carriers are now moving up to GPRS (General Packet Radio Services), a next-generation packet-switched data service that has the potential to deliver 171 Kbps. According to early adopters, initial offerings like Verizon's Express Network and VoiceStream's iStream are delivering around 40-50 Kbps -- an experience roughly comparable to v.90 analog dial.
Exceeding 100 Kbps may take some time, but the 2G era is over. Today's GPRS is 2.5G. Once true 3G services emerge, pushing volume data over cellular will be far more realistic. Only then will PDA and smartphone access to enterprise networks evolve from a high-tech novelty to a commonplace business necessity.
Of course, you don't have to wait for 3G. Cellular data can be used now with any wireless-capable PDA. A few PDAs ship with built-in wireless modems, including the Palm i705 and VIIx (Mobitex), the Handspring Treo 180, Sony CLIE, and the Audiovox Thera Pocket PC (CDPD). Next-generation handheld processors based on the Texas Instruments OMAP architecture are expected to make embedded wireless more universal.
If your PDA lacks embedded wireless, don't fret -- there are many after-market alternatives. Tether your PDA to a data-capable CDMA, GSM, iDEN, or GPRS phone by purchasing a digital phone card for Pocket PC or a Mobile Internet Kit for Palm OS. For example, Socket Communications sells Compact Flash cards that connect Pocket PCs to Alcatel, Ericsson, Motorola, Nextel, Nokia, Qualcomm, Samsung, Siemens, and Spring PCS cellular phones. DPC cards and wireless kits are widely available; expect to spend about $100.
CDPD options include the Novatel Minstrell III (Palm III), Minstrel S (Handspring Visor), Minstrel m500 (Palm m500 series), Minstrel 540 (HP Jornada) and Merlin Type II PC card (WinCE). The Sierra Wireless AirCard 300 (WinCE) and AirPath 300 (Handspring Visor) also support CDPD. To use Verizon's GPRS, you'll need a Sierra Wireless AirCard 555 PC card. These PalmOS sleds and PC cards range from $99 to $400. For best compatibility and support, purchase your CDPD or GPRS card through your wireless service provider.
Adding VPN support
Wireless PDAs are commonly used to access public servers, like the POP accounts offered by wireless providers like Palm.net and GoAmerica. Roaming employees frequently forward e-mail between company and ISP mailboxes. But forwarding raises security concerns. Should your corporate e-mail really be relayed as plaintext over the public Internet? What if your weakly-authenticated public POP account were compromised? Who could access confidential or proprietary data forwarded to your ISP mailbox?
Data can be encrypted when stored on the PDA and in transit between the PDA and the ISP's POP server. These are excellent first steps. To avoid forwarding entirely, consider using a VPN to reach private servers inside your corporate network. VPN tunneling can provide a secure access platform not just for enterprise mail, but to any IP-based client/server application.
If you're a Pocket PC user on a tight budget, try Microsoft's embedded PPTP client. For a more secure alternative, consider this growing list of after-market IPsec clients for handheld devices:
- V-ONE's SmartPass client (WinCE)
- Certicom's movianVPN client (Palm OS, WinCE, Symbian OS)
- SafeNet's SoftRemotePDA client (Palm OS)
- CheckPoint's VPN-1 SecureClient (WinCE)
To get a first-hand look at how PDA VPN clients operate over 2G services, I tried SafeNet and Certicom clients on a Palm m505, tunneling to my Netscreen firewall over GoAmerica's CDPD service.
My test drive
GoAmerica sent me a Minstrel m500 modem, MobileOffice CD, and Getting Started Guide. Using the Minstrel Setup Wizard to configure my PDA's IP address, DNS/POP servers, and login/password was simple and intuitive. When done, the Modem Manager made it clear that something was wrong, but what? After a provisioning system account reset, my Palm was on the air.
For the next week, I used my CDPD-enabled PDA wherever I roamed: from Philadelphia to Princeton to New York City. On-the-road mail peeking and web queries proved quick and convenient -- for example, finding business locations, looking up phone numbers, and reading headlines. But viewing messages or articles longer than three paragraphs tried my patience. When I aborted page loads, my Palm often ignored me until it finished the task at hand. I quickly learned what I realistically could and could not do over CDPD, and adapted my behavior accordingly -- for example, by tuning message body and web page limits.
In fact, establishing baseline performance and reliability expectations is extremely important. Otherwise, employees with secure remote access may grumble about the VPN when they are actually being pinched by bandwidth or device limitations. If your application performs poorly when sending cleartext over wireless, don't expect a VPN client to make the situation any better. Get your applications working well over wireless first, then add VPN.
Lap one: movianVPN
To add IPsec, I started with Certicom's movianVPN. I had used movianVPN for secure PDA access to my WLAN -- see last month's column for specs and configuration details. I quickly established a new tunnel over CDPD to my company network, but could not pass traffic through this tunnel. My IPsec-to-Minstrel bindings were not quite right, possibly due to existing Intel WLAN bindings. On the advice of tech support, I performed a hard reset, reinstalling all apps from scratch -- that did the trick.
Thereafter, I had reliable connectivity when using split tunneling (IPsec to my network, cleartext elsewhere). But my Palm was very cranky without split tunneling. The VPN client would think CDPD was available when it was not, throwing "Send failed" errors. The Minstrel Modem Manager would hang on shutdown requests when a VPN tunnel was active. According to tech support, this is a general problem that can occur with any type of wireless modem. Applications like movianVPN write to send buffers; if there is no modem reading from the buffer, the PalmOS can hang. So, for the rest of my movianVPN trial, I used split tunneling.
Lap two: SoftRemotePDA
Next, I installed SafeNet's SoftRemotePDA client. According to documentation, this client runs on Palm Vx or m500 series PDAs with PalmOS 3.5 or later, 8MB of memory, and a CDPD or Palm V analog modem. SafeNet says they have also demonstrated this client over 802.11. At the time of my trial, IPsec tunnels had been tested to Windows 2000, Cisco 2621, Cisco PIX, Netscreen, SafeNet Speed, and the CoSine IPSX 3500 gateways.
SoftRemotePDA supports most popular IPsec VPN features, including ESP in tunnel mode, DES and 3DES encryption, MD5 and SHA1 HMACs, and IKE with preshared secrets, Diffie-Hellman (DH) Groups 1 or 2, and XAUTH. If you have used SafeNet's Win32 VPN client, you might expect SoftRemotePDA setup to be similar. Actually, it is not -- there is very little to configure in SoftRemotePDA.
The gateway chooses encryption and authentication algorithm from the four supported transforms -- the only client-side security options are DH Group and XAUTH. Selecting "medium security" proposes DH1 in Phase 1; "high" proposes DH2. Perfect forward secrecy, split tunneling, and non-IP IKE IDs do not appear to be supported. In my case, I had a static IP from GoAmerica and SoftRemotePDA worked just fine without split tunneling.
When I tested SoftRemotePDA, it was not yet available for download-on-demand. According to SafeNet, the client is available to US customers, but still awaiting export licensing. Last week, SafeNet and Texas Instruments announced an agreement to embed SafeNet's SecureIP technology in TI's OMP architecture. As a result, SafeNet hopes that SoftRemotePDA will evolve from downloadable software to an embedded client, shipped in next-generation handheld devices.
My VPN-over-CDPD experience
The movianVPN client has been around longer; it has an automated installer, more extensive documentation, and more detailed status info. The SoftRemotePDA client is visibly younger; it has been tested with fewer modems and gateways and requires manual connection and network setup. These clients are at different stages of development, so I did not spend much time comparing them to each other. Instead, I focused on the behavior of PDA applications when tunneled over a 2G service like CDPD.
One aspect of VPN usability is the time it takes to establish a tunnel. With CDPD, IP mobility is built in -- the PDA's IP address does not change as the PDA roams. This meant that I did not experience frequent tunnel reestablishment. However, reestablishment is usually required for IPsec to roam over wireless services that use dynamic IPs. So I wondered: How long do Win32 and PDA clients take to perform this same task?
As a baseline, I used Netscreen-Remote on an old P133 with v.90 dial. Establishing an ESP tunnel to my Netscreen with preshared secrets, DH1, DES, MD5, and no PFS averaged 4 seconds. Using movianVPN on my Palm m505 over CDPD, establishment averaged 30 seconds. Using SoftRemotePDA, it averaged 40 seconds. Note: These are rough stopwatch averages, for best-effort traffic over the Internet. "Your own mileage may vary." But these tests make it clear: on a Palm, establishment takes a noticeable amount of time. For best results, use your PDA with a VPN solution or wireless service that does not require frequent tunnel reestablishment.
Next, one must be able to productively use enterprise applications over the tunnel. PDA platforms and applications vary greatly. Even if one e-mail application works well, another may not. Therefore, I measured a few simple variables that contribute to the behavior of many applications:
- ICMP ping verifies reachability and reports network latency. Using my Palm over CDPD, I pinged a behind-the-firewall server. I compared cleartext pings to pings encrypted by movianVPN. Pings reached the server just as reliably in either case, but took 38% longer over the tunnel. The ping client I used did not work over the SoftRemotePDA tunnel.
- Most client/server applications, including POP mail clients and HTTP web browsers, run over TCP. I measured the time it took to establish a TCP connection from PalmTelnet to an inside Telnet server. There was no noticeable difference between connections over cleartext, movianVPN, or SoftRemotePDA. All averaged 5 seconds, from initiation to first server prompt.
- With applications like mail and instant messaging, short data bursts are the norm. To measure a data burst in a controlled fashion, I compared transfer time for one 808 byte transaction -- a dir command, executed from an inside FTP server to a freeware LFTP client. Most transfers took between 6 and 13 seconds -- whether or not a VPN tunnel was active. IPsec had little impact on the visible latency this brief transaction.
I made no attempt to measure the performance of interactive applications like e-mail clients and web browsers over VPN. This would have been interesting, but meaningful results would have been well beyond the scope of these informal stopwatch trials.
I was pleasantly surprised to get both of these VPN clients working over CDPD without much trouble. My setup went more smoothly with SoftRemotePDA, but this step differs for each PDA, modem, and gateway combination.
Launching and waiting for tunnel establishment is more intrusive on a PDA than on a typical laptop. Once established, tunneling was less noticeable than one might expect. My own experiments appeared to be more heavily influenced by bandwidth and platform. What worked fine in cleartext still worked over a VPN tunnel. Commands that were haltingly slow as cleartext were of course slow over IPsec. Short transactions were the most useful -- I would not expect to transfer bulk data over CDPD, with or without a VPN tunnel.
After trying out these PDA IPsec clients in wireless LAN and WAN environments, I am optimistic about secure PDA enterprise network access over 2.5 and 3G cellular services. WLAN-like bandwidth, combined with the wide-area convenience of cellular, should improve the end user experience. As this happens, wireless PDA business use will grow. It will become more important than ever to secure enterprise data sent by PDAs over wireless. In future columns, I will examine further solutions for addressing this challenge.
Do you have comments about this article, or suggestions for Lisa to write about in future columns? Let us know!