IPsec and IKEv2 Android VPN
Isn't SSH everyone's favorite quick and dirty VPN? Get Putty, setup browser to use the SSH connection as a proxy and you're good to go.
Not long after DARPA released ESP, IPsec emerged as the de facto standard for creating encrypted tunnels to move data over the Internet between two geographically separate networks. It works at Layer 3, it's application agnostic and built right in to TCP with tighter integration in IPv6.
It's adoption outside of corporate endpoints remains less than stellar, and for good reason.
A typical conversation between a young developer Alice, wanting to secure her fledgling application's communication with her Network Engineer mate Bob, who works at a multi-homed Tier 4 datacenter in VRF hell.
Alice: Hey mate, I'm deploying my application via Docker and would like to use a VPN to communicate between my Docker hosts. My M2M devices use 6LoWPAN and IPsec seems perfect.
Bob: Uhh, 6LoWPAN? Not my area of expertise but what general IPsec strategy did you have in mind for the Docker instances?
Alice: Strategy? I just want to secure my network comms, can't I just authenticate my remote endpoints with passwords or certificates to an IPsec gateway and route all traffic through it?
Bob: Sure.. that depends though.. Do all endpoints have public IP addresses? If there's NAT, there's no AH, you gotta go with ESP. Once you're clear on Tunnel vs Transport mode it should make more sense.
Alice: Mmm yea sure
Bob: What version of SHA for hashing out Integrity Check Values (ICV)? What are we using for encryption? 3DES, Blowfish or AES? This will be critical on low power devices.
Alice: AES! Some of my smaller ARM devices have hardware acceleration for it too.
Bob: Alright, and I assume you're going with IKE instead of manual keying?
Alice: Yes, IKE
Bob: Cool, now decide between Aggressive or Main mode and there's your basic IPsec strategy.
This is a tiny anecdotal sample of the staggering options and settings in IPsec which often makes setting it up non-trivial. A stock Android phone today offers these IPsec VPN types:
Linux alone has OpenSwan, strongSwan, LibreSwan and ipsec-tools.
Getting these to work with Microsoft IPsec is another jar of fun.
IPsec VPNs have been complex beasts to setup, maintain and troubleshoot for the casual user. Interoperability was a myth and here's perhaps why.
Some of these are integral in the average corporate customer's expectation of IPsec -
IP Authentication Header
IP Encapsulating Security Payload
Cryptographic Suites for IPsec
Negotiation of NAT-Traversal in the IKE
This is all IKEv1.
IKEv2 brings many things of interest to an estimated 20 billion devices by 2020 - The smartphone/M2M centric standards.
Standard IPsec tunnels require static IP v4/v6 addresses, these define the endpoints.
Enter MOBIKE.
MOBIKE was designed for endpoints or initiators whose IP addresses are expected to change often. A common use case would be a cell phone/tablet shifting Internet access between residential Wifi, telco enabled 3G/4G to the office AP. This includes shifting interfaces, IP addresses and routes.
MOBIKE keeps the VPN alive during these otherwise fatal changes to an IPsec tunnel.
Sound delicious? It is! You have an IKEv2 IPsec VPN that just works across *all* your shifting Internet connections. You don't need to setup and shift between 3 connections.
You will need an IPsec server, we will use strongSwan and OpenBSD as examples.
An Android phone with a recent OS (Kit Kat+).
strongSwan (by default) implements MOBIKE by watching interfaces, addresses and routes. If the configuration changes, route lookups are done to find a better path than the current one and, if necessary, the path is changed using a MOBIKE update (UPDATE_SA_ADDRESS).
Part 2 coming soon (tm)..
Not long after DARPA released ESP, IPsec emerged as the de facto standard for creating encrypted tunnels to move data over the Internet between two geographically separate networks. It works at Layer 3, it's application agnostic and built right in to TCP with tighter integration in IPv6.
It's adoption outside of corporate endpoints remains less than stellar, and for good reason.
A typical conversation between a young developer Alice, wanting to secure her fledgling application's communication with her Network Engineer mate Bob, who works at a multi-homed Tier 4 datacenter in VRF hell.
Alice: Hey mate, I'm deploying my application via Docker and would like to use a VPN to communicate between my Docker hosts. My M2M devices use 6LoWPAN and IPsec seems perfect.
Bob: Uhh, 6LoWPAN? Not my area of expertise but what general IPsec strategy did you have in mind for the Docker instances?
Alice: Strategy? I just want to secure my network comms, can't I just authenticate my remote endpoints with passwords or certificates to an IPsec gateway and route all traffic through it?
Bob: Sure.. that depends though.. Do all endpoints have public IP addresses? If there's NAT, there's no AH, you gotta go with ESP. Once you're clear on Tunnel vs Transport mode it should make more sense.
Alice: Mmm yea sure
Bob: What version of SHA for hashing out Integrity Check Values (ICV)? What are we using for encryption? 3DES, Blowfish or AES? This will be critical on low power devices.
Alice: AES! Some of my smaller ARM devices have hardware acceleration for it too.
Bob: Alright, and I assume you're going with IKE instead of manual keying?
Alice: Yes, IKE
Bob: Cool, now decide between Aggressive or Main mode and there's your basic IPsec strategy.
This is a tiny anecdotal sample of the staggering options and settings in IPsec which often makes setting it up non-trivial. A stock Android phone today offers these IPsec VPN types:
- L2TP/IPsec PSK
- L2TP/IPsec RSA
- IPsec Xauth PSK
- IPsec Xauth RSA
- IPsec Hybrid RSA
Linux alone has OpenSwan, strongSwan, LibreSwan and ipsec-tools.
Getting these to work with Microsoft IPsec is another jar of fun.
IPsec VPNs have been complex beasts to setup, maintain and troubleshoot for the casual user. Interoperability was a myth and here's perhaps why.
65 IPsec RFCs to date
13 of which are marked obsolete or historic
14 informational RFCs
A Best Practice RFC and an Experimental RFC
Finally, 37 current Standards Track RFCs
Some of these are integral in the average corporate customer's expectation of IPsec -
IP Authentication Header
IP Encapsulating Security Payload
Cryptographic Suites for IPsec
Negotiation of NAT-Traversal in the IKE
This is all IKEv1.
IKEv2 brings many things of interest to an estimated 20 billion devices by 2020 - The smartphone/M2M centric standards.
Standard IPsec tunnels require static IP v4/v6 addresses, these define the endpoints.
Enter MOBIKE.
MOBIKE was designed for endpoints or initiators whose IP addresses are expected to change often. A common use case would be a cell phone/tablet shifting Internet access between residential Wifi, telco enabled 3G/4G to the office AP. This includes shifting interfaces, IP addresses and routes.
MOBIKE keeps the VPN alive during these otherwise fatal changes to an IPsec tunnel.
Sound delicious? It is! You have an IKEv2 IPsec VPN that just works across *all* your shifting Internet connections. You don't need to setup and shift between 3 connections.
You will need an IPsec server, we will use strongSwan and OpenBSD as examples.
An Android phone with a recent OS (Kit Kat+).
strongSwan (by default) implements MOBIKE by watching interfaces, addresses and routes. If the configuration changes, route lookups are done to find a better path than the current one and, if necessary, the path is changed using a MOBIKE update (UPDATE_SA_ADDRESS).
Part 2 coming soon (tm)..
Comments
Post a Comment