Share via

Mobile VPN Protocols

  • Article

4/8/2010

The Mobile Virtual Private Network (VPN) uses the Internet Key Exchange (IKE) v2 protocol to establish a encrypted and authenticated channel that will handle VPN traffic. This section describes the cryptographic algorithms and protocols used by Mobile VPN to establish connections with the System Center Mobile Device Manager VPN Gateway.

IKE v2 (RFC 4306)

The Mobile VPN uses IKE version 2 to negotiate the security associations that handle VPN traffic. This is done during a two-phase negotiation process.

In Phase I, which is also known as the key management phase, a secure channel is established for subsequent negotiations. The certificates configured during enrollment are used to authenticate the mobile device with the other VPN endpoint and pass identification information through this channel. After the negotiation is completed and the Phase 1 IKE tunnel is established, the mobile device and the VPN Gateway use it to negotiate which security parameters will be used for the communication in Phase II. The key negotiation is done using one of the supported Diffie-Hellman cryptographic protocols, a group which includes Modular Exponential (MODP) group 2, group 5, and group 14. More specific information on which cryptographic functions are supported by this IKE implementation can be found in the Cryptography section below.

In Phase II, which is also known as the data management phase, the IKE tunnel is used to negotiate the parameters that the IPSec ** security associations will use, such as encapsulation mode, hashing algorithms, encryption algorithms, and so on.

Once the Mobile VPN has been successfully established, application traffic will be delivered to the VPN Gateway over the IPSec tunnel. This data traffic will be encrypted and authenticated using the algorithms negotiated during the IKE Phase II negotiation.

NAT traversal (RFC 3947) is supported by the Mobile VPN. If NAT is detected by the Mobile VPN, keep-alives will be sent periodically as specified in RFC 3948. The period between keep-alives is configurable. Because sending too many keep-alive signals may significantly impact the battery life of the mobile device, it is recommended to contact the Mobile Operator and use a cellular data connection that does not require NAT or ensure that NAT inactivity timeouts have been customized for UDP. **

Inactivity timeouts for NAT and for the UDP ports used by IKE and IPSec should be at least 900 seconds to ensure acceptable battery longevity.

MOBIKE (RFC 4555)

The Mobile VPN can employ the MOBIKE protocol to update the VPN Security Associations (SAs) in cases where the base connection initially used by the Mobile VPN is lost and needs to be re-established. Using the MOBIKE protocol in these cases allows the Mobile VPN to avoid having to perform an IKEv2 re-negotiation. The benefits of this approach include:

  • Faster reconnection.
  • Performance improvement in device on reconnection. There is no need for full negotiation or to recalculate new Diffie-Hellman public or private keys. This results in better device usability and responsiveness.
  • Less bandwidth usage. Each IKEv2 negotiation requires 4000-8000 bytes, while MOBIKE negotiations require less than 500 bytes.

When the Mobile VPN connects, it will store the SA's information and, if the base connection is lost, and if another connection is available, then the Mobile VPN will attempt to update the SA's information using MOBIKE. If the SA's information is still valid, then the MOBIKE protocols will be used. If the update attempt fails, then a full re-negotiation with IKEv2 is necessary. IKEv2 is also used in the following situations:

  • The rekey timer expired while the Mobile VPN was disconnected. In this case, the SA information is deleted and MOBIKE can no longer use it to reconnect.
  • The Mobile VPN needs to retry connecting to a different VPN Gateway than the one that it previously connected to. In this case, the SA information saved from the first connection will not be valid for the second, so a full re-negotiation with IKEv2 is necessary.
  • The VPN connection was disconnected for a long period of time.
  • The Mobile VPN was manually disabled and re-enabled prior to reconnection. Manually disabling the Mobile VPN causes all saved SA information to be deleted.
  • The device was restarted. Restarting the device causes all saved SA information to be deleted.

Cryptography

The Mobile VPN protocols use Windows Embedded CE's Microsoft Crypto API (CAPI) to handle encryption, hashing and key management. The following cryptographic functions are supported by the Mobile VPN and provided by the Microsoft CAPI.

Cryptographic function

Supported protocols

Encapsulation

ESP (RFC 4303)

Hashing
  • SHA-2 with 256-bit hash length
  • SHA-2 with 384-bit hash length
  • SHA-2 with 512-bit hash length

Signature validation
  • DSS
  • RSA

Data encryption
  • AES with 128-bit key length
  • AES with 192-bit key length
  • AES with 256-bit key length
  • 3DES

Key Management algorithms
  • Diffie-Hellman group 2 with 1024 bit key length
  • Diffie-Hellman group 5 with 1536 bit key length
  • Diffie-Hellman group 14 with 2048 bit key length

See Also

Other Resources

Technical Overview of Mobile VPN