VPN & IPSEC

References

http://network.51cto.com/art/201112/305499.htm

http://en.wikipedia.org/wiki/IPsec

ScreenOS VPN Manual

Secure Policy Database, Secure Association Database

http://wiki.treck.com/Security_Policy_Database_%28SPD%29_and_Security_Association_Database_%28SAD%29

IPSEC Cheat Sheet : http://www.atomicfission.com/index.php/white-papers/42-information-security/82-ipsec-vpn-cheat-sheet

RFC 4301 Security Architecture for IP : http://www.ietf.org/rfc/rfc4301.txt

RFC 2409 IKE: http://www.ietf.org/rfc/rfc2409.txt

VPN Concepts

  • IPSec VPN - at network layer; needs infrastructure and client software support
  • SSL VPN - at HTTP/TCP layer; no software but standard browser
  • OpenVPN - strong encryption; less efficiency than IPSec
  • L2TP / IPsec

IPSec VPN

http://en.wikipedia.org/wiki/IPsec

  • End-to-end security scheme in the Internet Layer
    • host-to-host
    • network-to-network
    • network-to-host
  • Modes of operation
    • Transport mode: only payload of the IP packet is encrypted / authenticated; routing is intact; IP header not modified / encrypted - host-to-host only
    • Tunnel mode: entire IP packet is encrypted / authenticated, then encapsulated into a new IP packet with a new IP header; used to create VPN for network-to-network, host-to-network and host-to-host communications; supports NAT traversal
  • Authentication Headers (AH)
    • IP protocol #51
    • less used
    • cannot go through NAT
    • Connectionless integrity and data origin authentication for IP datagrams;
    • No confidentiality protection
    • Protect from tampering, not eavesdropping
    • Suitable for non-secret data communication
    • Algorithm options:
      • MD5 (Message Digest) - faster, less strong
      • SHA-1 (Secure Hash Algorithm) - stronger
      • SHA-2 more secure than SHA-1
  • Encapsulating Security Payloads (ESP)
    • IP protocol #50
    • widely used
    • Origin authenticity, integrity and confidentiality protection
    • Also supports encryption-only and authentication-only configurations but encryption-only is strongly discouraged
    • In transport mode does not provide integrity and authentication for entire IP packet
    • In tunnel mode, protects entire inner IP packet but not outside header
    • Encryption algorithm options:
      • DES (weakest and fastest, suitable for normal requirement)
      • 3DES (more powerful than DES)
      • AES (strongest and slowest)
    • Authenticity and integrity algorithm options:
      • MD5 - faster and less strong
      • SHA-1 - stronger
  • Selection of AH / ESP
    • AH (stronger authentication than ESP, no encryption, less used)
    • ESP (encryption and weaker authentication, widely used)
    • AH-ESP (rarely used)
  • Secure Policy Database (SPD)
    • an ordered database
    • match all packets going through the system
    • selector - to select packet covered by an entry
    • action: discard, bypass, protect (ipsec)
  • Security Association between peers (SA)
    • Unidirectional: "the bundle of algorithms and parameters (such as keys) that is being used to encrypt and authenticate a particular flow in one direction"
    • Group together the following:
      • Security algorithms and keys
      • Protocol mode (transport or tunnel)
      • Key-management method (manual or AutoKey IKE)
      • SA lifetime
    • SA is looked up by:
      • Security Parameter Index (SPI)
      • Destination IP address
      • Security protocol (AH or ESP)
    • Tunnel negotiation: established using the "Internet Security Association and Key Management Protocol" (ISAKMP), implemented by
      • Manual configuration with pre-shared secrets (never expire) / no negotiation and direct encrypt and send
        • Administrators at both ends configure all the parameters
        • Viable for small, static networks
      • Internet Key Exchange (IKE & IKEv2) / automatic, negotiation first, connect later (see below)
      • Kerberized Internet Negotiation of Keys (KINK)
      • IPSECKEY DNS records
      • Better-Than-Nothing Security (BTNS) - unauthenticated
    • Determination of protection is by
      • Security Parameter Index (SPI), an index of the Security Association Database (SADB)
      • along with the incoming / outgoing IP address
  • Diffie-Hellman (D-H) key exchange:
    • for IKEv1 phase 1
    • for phase 2 only when select the Perfect Forward Secrecy (PFS)
    • PFS makes keys more secure by requiring DH exchange occurs each time a new SA is negotiated
    • allow two parties that have no prior knowledge of each other to jointly establish a shared secret key over insecure communication channel
    • anonymous, i.e. parties are not authenticated
    • provides basis for a variety of authenticated protocols
    • DH Groups:
      • determine the strength of the key used in the key exchange process
      • higher group numbers are more secure but requires additional time to compute the key
      • both peers of a VPN exchange must use the same DH group
      • if PFS is selected, phase 2 DH group does not need to match phase 1 DH group
      • DH group 1 deprecated and not recommended to use (Juniper ScreenOS manual).
  • Internet Key Exchange (IKE)
    • is the protocol used to set up a SA
    • builds upon Oakley protocol and ISAKMP
    • Authentication: uses X509 certificates, either
      • pre-shared
      • or distributed using DNS (preferably with DNSSEC) and a D-H key exchange to set up a shared session secret from which cryptographic keys are delivered
    • Architecture: Most IPsec implementation consists of IKE daemon runs in user space and access configuration information, and IPsec stack in kernel
    • Listen: IKE protocol uses UDP usually on port 500
    • IKEv1 Phases
      • Phase 1 - establish a secure channel
        • exchange of proposals for authenticate and secure the channel, such as
          • Encryption algorithms (DES / 3DES)
          • Authentication algorithms (MD5, SHA-1 or SHA-2)
          • D-H group
          • Authentication method (preshared key or RSA/DSA certificates)
        • to establish a secure authenticated communication channel
        • using D-H key exchange to generate a shared secret key to encrypt further communications
        • authenticate by either
          • pre-shared keys (shared secret) (ScreenOS: AutoKey IKE with preshared keys)
          • signatures
          • public key encryption (ScreenOS: AutoKey IKE with Certificates)
            • each side generates a public / private key pair
            • acquires a certificate
            • issuing CA is trusted by both sides
        • operates in
          • Main Mode - protects the identity of the peers, in three two-way exchanges (6 messages); for dial-up user, if it has static IP or if certificates are used for authentication
          • Aggressive Mode - does not protect, in only two exchanges a total of three messages; required when IP address of one of the peers is dynamically assigned and a pre-shared key is used;
          • Dial-up VPN user: main mode + preshared key not possible for dialup VPN user; aggressive mode has inherent security problems; consequently, strongly advisable to use main mode + certificates (ScreenOS VPN Guide)
        • Juniper ScreenOS predefined phase 1 proposals:
          • Standard: pre-g2-aes128-sha & pre-g2-3des-sha
          • Compatible: pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha, pre-g2-des-md5
          • Basic: pre-g1-des-sha, pre-g1-des-md5
      • Phase 2 - negotiate the IPsec SAs using the channel
        • negotiate SA on behave of other services like IPsec
        • results in at least 2 unidirectional SAs
        • operates in Quick Mode
        • Juniper ScreenOS predefined phase 2 proposals:
          • Standard—g2-esp-3des-sha and g2-esp-aes128-sha
          • Compatible—nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha, and nopfs-esp-des-md5
          • Basic—nopfs-esp-des-sha and nopfs-esp-des-md5
      • Has life-cycle
        • Time based
        • Traffic volume based
      • Problem with IKE
        • lack general facility for automatic negotiation of a well-known default case that is universally implemented
        • complication - had to exactly agree on the type of SA option-by-option,
        • specifications were open to a significant degree of inerpretation
  • Cryptographic Options Recommendations:
    • ScreenOS manual vol 5 (VPN) chapter 3 VPN Guidelines has good illustration and recommendations

Juniper ScreenOS IPSEC

  • Route-based / Policy-based tunnels
    • Policy based : tunnel as an object; source / destination / service / action (tunnel action) -> policy permits VPN traffic; refers VPN tunnel by name; each policy creates an individual IPSEC SA, each counts as an individual tunnel; can do granular restrictions on VPN traffic
    • Route based : route lookup find a tunnel interface through which it muse send traffic to reach the address; tunnel interface bound to a specific VPN tunnel; multiple policies to regulate traffic through single tunnel between two sites; just one SA at work; allow dynamic routing protocol through tunnel;
    • Choose policy based VPN : for dial-up and for simple networks (no dynamic routing protocols)
    • Choose route based VPN : when remote (Netscreen-remote client) dialup client supports virtual internal IP address; also it can bind the tunnel interface to any zone or define Mapped IP on tunnel interface;

L2TP / IPsec

  • L2TP is a tunnelling protocol, does not provide encryption / confidentiality but rely on an encryption protocol to provide privacy