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
- 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
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
- 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 is a tunnelling protocol, does not provide encryption / confidentiality but rely on an encryption protocol to provide privacy