VPNs - Overview, IPSEC, and Considerations

1. VPNs By Dr. Shadi Masadeh

2. Virtual Private Networks (VPNs) • Overview • IPSEC overview • Security Policy Database (SPD) • Split tunneling • Considerations • Deploying VPNs

3. VPN Overview • The goal of a Virtual Private Network (VPN) is to allow 2 parties to securely communicate over an insecure medium – A medium that is host to adversaries. • A VPN must minimally provide: • Authentication – You must be able to ensure your communication partner is who they claim to be. • Integrity – Data can not be changed in an undetected manner. • Confidentiality – The communication must be encrypted. • Anti-Replay – An adversary can not capture data and replay it later on in an undetected manner.

4. IPSEC Overview • Internet Protocol Security (IPSEC) is a framework to provide secured communication for IP. • This IETF framework is defined in a suite of RFCs. • It does not specify the authentication and encryption protocol to use. This makes it flexible and able to support new authentication and encryption methods as they are developed. • IPSEC provide a new sub-layer just above IP, layer 3 of OSI model. This has 2 main advantages: • Layer 3 is the lowest layer in the OSI model that provides end-to-end connectivity between 2 nodes. That means that the end-to-end communication is secured, you do not need to provide security service at each link in the path. • The security services are totally transparent to upper layers. Specifically, TCP and UDP can transparently use these services. This also means that all applications that use TCP or UDP as transport mechanism can now have their communication secured without any changes.

5. IPSEC Architecture Overview

6. IPSEC Architecture Overview • Architecture – Describes general concepts, security requirements, definition, mechanism and interaction of components. • ESP – Packet format, integrity and encryption of IP packet – Optionally: also include authentication and anti-replay. • AH – Packet format and origin authentication. Optionally includes limited anti-replay. NO ENCRYPTION. • Encryption algorithm. • Authentication Algorithm. • Domain of Interpretation (DOI). How different documents and protocols relate to each other’s. • Key management. How key are exchanged, managed and their lifetime.

7. IPSEC IETF Documents • RFC 2401 – Architecture • RFC 2411 – Roadmap • RFC 2402 – Authentication Header (AH) • RFC 2406 – Encapsulating Security Payload (ESP) • RFC 1828 – IP Authentication using MD5 • RFC 2412 – Oakley key determination • RFC 2408 – ISAKMP (Internet Security Association and Key Management Protocol) • RFC 2409 – IKE – Internet Key Exchange • RFC 2104 – HMAC – Hashing for Message Authentication

8. IPSEC Protocols • Encapsulating Security Payload (ESP) • Provide confidentiality (via encryption), integrity, anti-replay and optionally authentication. • IP protocol number 50 • Authentication Header (AH) • Provide data integrity, authentication and optional anti-replay services. • IP protocol number 51 • Does not provide confidentiality (encryption) • Internet Security Association and Key Management Protocol (ISAKMP) • Assist in the dynamic and automatic establishment of IPSEC-protected connection and Security Associations (SA) via the Internet Key Exchange (IKE) protocol. • Also performs key management and renewal. • ISAKMP/IKE is not required: The SAs can be setup manually but this is difficult to setup and manage. • Uses UDP port 500 for communication.

9. IPSEC AH (from Stallings)

10. AH Fields • Next Header – Identifies type of the next IP header • Payload Length – Length of the AH in 32-bit words minus 2. Example: default AH authentication data is 96 bits = 3 words. 3 words for AH header. total = 6 words. Length field value is 4. • SPI – Identify SA. • Sequence number – For anti-replay – we will see that in the few next slides. • Authentication Data - Variable length (depend on algorithm used for integrity (most will be 96 bits long). It is the Integrity Check Value (ICV) for that packet.

11. AH Anti Replay Services

12. AH Integrity Check Value (ICV) • The ICV is a truncated HMAC. • Current specification dictate that AH must minimally support: • HMAC-MD5-96 • HMAC-SHA-1-96 • HMAC is fully calculated but only first 96 bits are included in header. • HMAC is calculated on payload and IP header fields that are immutable (do not change in transit). Field that may change are set to 0 for HMAC calculation. • AH authentication data itself is set to 0 for HMAC calculation.

13. IP ESP Header

14. ESP Header Fields • SPI – Identifies the SA • Sequence number – same as AH • Payload • Padding – The whole ESP packet must be in 32-bit words boundaries. • Pad length – identifies how many bytes immediately preceding are PADs • Next header – Next IP header type (or layer 4 protocol) in the payload. • Authentication data – If ESP also provides authentication (optional) • ESP must minimally support DES in Cipher Block Chaining mode (CBC).

15. Key Management • In order to provide AH and ESP services, the 2 communicating parties need to share common, symmetric, keys. • Two methods to establish these keys: • Manual – The administrator manually define the keys for each SA at each VPN node. This is of course a fairly painful process. • Automated – The parties creates these keys on-demand. • The automated key exchange uses: • Oakley Key Determination protocol – Based on Diffie-Hellman algorithm but provides supplementary security services to eliminate some weaknesses of Diffie-Hellman. • Internet Security Association and Key Management Protocol (ISAKMP). This provides a framework for key management including key format, key lifetime, renewal and security attibutes.

16. Oakley Key Exchange • Based on Diffie-Hellman but provides services to prevent some attacks: • Prevent man-in-the-middle attacks. (Solution: use Authentication) • Prevent clogging attacks: the process of key determination is processor intensive and with only DH, an attacker may be able to requests a victim to create a large number of keys and deplete computing resources. (Solution: don’t calculate from the 1st handshake, send a cookie if Ack’d the calcualte) • Anti-replay attack prevention. (Solution: use encrypted pseudo random number) • Provides a framework for initial authentication of 2 parties that want to exchange keys. Although open, currently it mainly uses: • Pre-shared keys/pre-shared secret • Digital signature or Digital certificates • Oakley Key Exchange also also support the use of different “Groups” of possible keys and algorithms for DH. • Group 1: 768-bit based on prime number modulus arithmetic. • Group 2: 1024-bit based on prime number modulus arithmetic. • Group 3: 155-bit based on Elliptic Curve cryptography • Group 4: 185-bit based on Elliptic Curve cryptography • Group 5: 1680-bit based on prime number modulus arithmetic. • Group 1 must be implemented – others are optional. Also the standards allows other groups can be negotiated between 2 parties. (I have never seen it implemented though) • Unless students request it, we will not go in details on how DH works: just understand that it allows 2 parties to securely establish a symmetric key over an insecure medium.

17. IPSEC Security Association (SA) • In IPSEC, a party communicate to another via a “Security Association” or SA. • A SA is a simplex (one way) association with the following parameters: • A unique identifier: the “Security Parameter Index” or SPI. This locally significant index identify the SPI. • IPSEC service type: is it AH or ESP? • IP Destination address – Unicast currently – Research is been done on allowing some multicast in IPSEC but this is very tricky – Issues of anti-replay and source authentication • Key associated with it: note: keys are usually symmetric with short lifetime. Lifetime can be expressed in term of time or amount of data processed. After that time/amount of data, new keys must be generated. • Question: Two peers setup IPSEC communication between each others for AH and ESP. How many SA(s) will be setup? • How will a sender handle a packet? What will determine if the packet should be sent using a SA? Which SA? • The way a packet is handled is determined by the “Security Policy Database” or SPD

18. IPSEC Security Policy Database (SPD) • The role of the SPD is to determine how a packet should be handled. • This is a very unfortunate terminology that was chosen by IETF: The term “Security Policy” for IPSEC means how the traffic should be handled. This is just a very small part of what a corporation “Security Policy” should encompass. • The SPD will look at a packet and determine if it should be sent using an SA and which SA based on one (or more) of the following: • Destination IP address • Source IP address • Protocol number • Source/destination port number • UserID (if available to the IPSEC software) • IPv6 or MPLS Flow Label • TOS or DiffServ • Packets are examined to see if they fulfill condition and then forwarded to IPSEC engine to be transmitted via an SA. • What if packet does not match any SPD condition? (we will cover that a little later) • What if SA is not yet established? (Discussion in class)

19. Tunnel and Transport Mode • IPSEC can function in 2 different modes: • Tunnel Mode: The whole original IP packet (including its header) is encrypted and/or authenticated. A new IP packet is created and the AH or ESP header added. • Transport Mode: The original IP header is kept, the AH/ESP header is inserted between the original header and the payload. The payload (and immutable header parts) is encrypted and/or authenticated. • Example in class.

20. IP Packet with AH

21. IP Packet with ESP

22. Split Tunneling Considerations • When a packet arrives at an IPSEC device and do not match any SPD entries, what should we do? • Drop the packet? • Transmit it in clear? • The decision to allow the packets out in clear is really a decision based on the enterprise security policy. • Enabling the non-IPSEC traffic to share the same connection as IPSEC traffic is often referred as using/enabling “Split Tunneling” • Let’s look at some examples and discuss the pros and cons of split tunneling in each scenario.

23. Split Tunneling Example 12.2.2.2 44.4.4.4 16.6.6.6 10.22.12.0/24 172.16.1.0/24

24. Why use VPNs? • In many case it is much more economical that WAN links. This is specially true for international locations. • Most locations have low cost connectivity to the Internet • Use the Internet as the communication media if the application allows it. • Speed of deployment • Usually much quicker to get link to Internet instead of WAN link • Link to Internet may already exist • Cost Considerations: • Often VPN can pay for itself in weeks/months • Sometime hidden costs kill the project: administration, maintenance, expertise…etc… • Two main types of VPN applications: • Client VPN – Mobile nodes “dial” (or DSL/cable) to Internet then establish VPN • Site to site VPN – usually fixed sites with fixed IPs

25. NAT/PAT Considerations • Several issues with NAT/PAT: • ISAKMP negotiations is a device is NATed may be a problem if ID is based on IP. • If Certificate used in authentication, which IP does it have? • The firewall translating the address can not “see” the inside of the packet since it is encrypted: This is a problem for NAT-unfriendly protocols such as Netbios over IP which includes part of the IP header information in the payload. Firewall doing NAT usually are able to “fix” the issues in the IP payload but if the payload is encrypted: they can’t unless they are the VPN termination point. • With PAT: even worse: If several hosts are in PAT, who do you send the IPSEC responses?????? • How to Solve the Problem? • Sometime cannot be solved! This means the current network/security infrastructure cannot accommodate IPSEC as is! • Answer: DESIGN NETWORK AND SECURITY INFRASTRUCTURE PROPERLY! • Good link: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac182/about_cisco_ipj_archive_article09186a00800c83ec.html

26. Handling of Non-IP Protocols • IPSEC only functions on IP networks, how can we transmit non-ip traffic (IPX, Netbios, …etc…) • Solution: Generic Router Encapsulation (GRE) • The idea is simple, take the non-IP protocol and encapsulate it into an IP packet. • Then you can transport that IP packet in an IPSEC tunnel. • Other possible solutions: use non IPSEC VPNs such as L2F, L2TP.

27. Site-to-site VPNS • Establish a tunnel between 2 (or more) fixed sites. • Usually the VPN termination points are routers, firewalls or VPN concentrators. • If the sites have fixed IPs, you can use the IP addresses as another authentication factor. If the site is a SOHO, the ISP may do dynamic IP allocation and we will need another method for additional authentication. • Usually uses Tunnel-mode IPSEC • IP routing must be carefully considered. How do you update route tables when site goes up or down? • Examples and discussions in class.

28. Client-based VPN • Clients “dial” to a VPN concentrator via the Internet. • Requires an Internet connection: • Can be permanent (DSL, Cable, T1) • Or dial (Analog, ISDN, DSL via PPPOE) • Since IP of client may/will change, we need some other form of authentication.

29. Authentication Considerations • By providing a VPN connection, you are extending you network to a remote site: If an intruder may not have user ID to login to systems, he must NOT be allowed to establish a VPN tunnel. • How do you setup initial authentication: • For fixed VPN: peer IP address can be configured. This is not enough though as it can be spoofed. • Pre-shared key. Easy to setup but how do you manage key changes if mitigated? Easy for site-to-site and small VPN, hard for large dial-based VPNS. • Digital Certificate. Great solution but requires PKI.

30. ISP Considerations • Although VPNs SHOULD work regardless of ISP, some “aspects” may be good to know (or be aware of the possibility they are present). • Some time ago … some ISP filters ESP/AH protocols. This is sometime true for ISPs that provide consumer-oriented high-speed Internet. When asked, they usually mention that their AUP say “No VPN” but for an additional charge are willing to upgrade you to “business-class” services. • Some ISP have short (4 hours or less) DHCP leases. This can create tunnel to go down. Sometimes requires hard reset to re-establish it.

31. Point-To-Point Tunneling Protocol (PPTP) • PPTP was developed by Microsoft and a few other partners. Then became RFC 2637. • Uses GRE to establish a tunnel over a Point-to-point connection. • Optionally the PPTP transport MAY be encrypted. If Microsoft VPN end point: MPPE is used. MPPE is based on RC4 and has 40 or 128 bits encryption. Encryption keys are derived from passwords: very serious weaknesses in early implementation. • 2 modes of operations: • Client “dials” to a NAS, the NAS then use PPTP tunnel to VPN server • Client directly connects to VPN server via PPTP. • Uses GRE – IP protocol 47 and TCP port 1723. • Note: if possible at all try to stay away from PPTP and use L2TP or L2F or IPSEC.

32. Layer 2 Forwarding (L2F) • L2F was developed by Cisco and directly compete against PPTP. • L2F also became an IETF “standard” RFC 2341. • Also uses PPP but can also use SLIP. • 2 modes of operations: • Client “dials” to a NAS, the NAS then use L2F tunnel to VPN server • Client directly connects to VPN server via L2F. • Use UDP 1701.

33. Layer 2 Tunneling Protocol • L2TP is the result of the merge of PPTP and L2F. • IETF RFC2661 and a LOT of other RFC that specify usage of L2TP in various environments and extensions: ATM AAL5, IPSEC over L2TP, DiffServ Extensions. • Uses IP protocol 115 and TCP 1701 for control connection. • L2TP is a tunneling protocol. • Uses Attribute-Value Pairs (AVP) to allow the protocol to expand over time and offer further functionalities. • Similarly to PPTP and L2f, 3 types of devices: (source: Cisco) • L2TP Access Concentrator (LAC)—LAC is a device attached to a network or colocated with a PPP end system capable of handling the L2TP protocol. Example: user PC initiating L2TP tunnel, router terminating L2TP tunnel. • L2TP Network Server (LNS)—LNS operates on any platform capable of PPP termination. It handles the server side of the L2TP protocol. LNS is the initiator of outgoing calls and the receiver of incoming calls. Example: Win2K VPN server. • Network Access Server (NAS)—NAS is a device providing temporary, on-demand network access to users. This access is point-to-point, typically using PSTN or ISDN lines.

34. Other “VPNs” • Some other application-layer solutions may provide similar services than VPNs to workstations: • SSL • Most often: Terminal Services or Metaframe • Discussion in class.

35. VPNs and Firewalls • What are possible strategies for deploying VPNs in an enterprise environment. • 2 examples are proposed below – Discussion in class

36. Possible VPN Deployement

37. Possible VPN Deployement

38. So what is better A or B? • Pros and Cons discussion in class

39. VPNs and Firewall - Filtering Example

40. VPNs and Firewall - Filtering Example • Development of filtering rules • Well you guest it!!! Another little extra homework! This will replace your lowest HW or lab grade! • Functional requirements: • All users can browse the web • All internet users should be able to access the public web server. • All ip traffic between main site and remote site must be allowed… but must be using a VPN tunnel! • Remote commuters access all internal resources via VPN concentrator at corporate site • You must deliver in class hardcopies of: • NAT/PAT spreadsheet • Firewall rules spreadsheet • Static routing spreadsheet

41. Performance, Fragmentation and MTU Considerations • Application performance is affected in a VPN environment by the following: • Usually most important aspect: latency. • In a typical dedicated link or Frame-relay/ATM WAN, propagation delays are: • Very low - for dedicated links it is basically propagation delay • Low and consistent for Frame-relay/ATM – For these the delay can also be reduced by specifying maximum in Service Level Agreements (SLAs). • In a VPN that uses the Internet as transport mechanism, latency can be very high and jittering very important. • This can very negatively affect some applications such a terminal emulations, multimedia, interactive applications, some client-server apps. • You can sometime help by requiring QOS from ISP but this is sometimes hard and in all cases, will require the VPN end-points to be on same ISP.

42. Performance, Fragmentation and MTU Considerations • Performance can also be severely degraded because of added AH/ESP Header. • Although the added traffic is minimal: it can lead to a really bad thing: fragmentation! • In certain scenario (specially with GRE tunneling) this can even lead to multiple fragmentation. • Solution: try to prevent fragmentation by lowering MTU at senders/receivers or at VPN devices. • Some VPN devices also can perform MTU discovery. (If interest: discussion in class of how it is performed and why it seldom works well) • Rule of thumb: in VPN environment, just put MTU to 1400 bytes. • Another VPN characteristics that sometimes create problems is that is does require a significant (1-5 seconds, sometimes more!) time to create the VPN tunnel. Certain custom apps may fail at startup. This problem is usually fairly easy to solve if you realize it: just create a batch that pings the destination or create traffic in order to bring the tunnel up before launching the apps. • Test your application to make sure it will perform properly in a VPN environment before deciding to roll-out!

43. VPNs and Compression • Sometime organizations uses compression on WAN links. What happen if you start using encrypted data on these links? • Compression does not provide anymore performance enhancement! In fact it can reduce performance. • Solution for compression: you have to compress the data before encryption. • Some solutions exist: • PCP compression • PPP LZS Compression Protocol. (RFC 1974)

44. Redundancy Considerations • In “classic” (non-VPN) environments, you often want redundancy in core or distribution layer devices. • If a user or device connects to a VPN concentrator: How do you handle redundancy? Failover? Where are the issues/problems? • Discussion in class.