- Email: [email protected]
Secure VPN Design Considerations
secure vpn leaves Bluetooth traffic out in the open for anyone to sniff and potentially modify.
Risk: profile access When the security of an 802.11 network fails, an attacker can sniff data and access remote computers on an IP level. When the security of a Bluetooth device fails, the attacker has complete access to any profiles offered by the device. Rather than being limited to a network-layer attack, the attacker can shoot right to the application-layer. For instance, if a compromised device has the File Sharing Profile enabled, then an attacker can read any files exposed by that profile. By mixing so many layers of the protocol stack into one specification, a compromise of the link-layer is much worse in a Bluetooth environment than in an 802.11 LAN environment. Bluetooth lacks sufficient mechanisms to provide layered security protecting applications. It is up to an application developer to add another layer of protection to mitigate this risk.
Risk: low power ! = unsniffable There is a common misconception that Bluetooth traffic is difficult to intercept due to its low power output and
frequency hopping mechanism. While it is true that most Bluetooth devices transmit very weak signals, they can still be intercepted at large distances (several hundred feet) using strong antennas. Also, there are Bluetooth devices that are broadcast with much more power. Devices such as Bluetooth access points have been designed to provide Internet connectivity in an office environment using similar power outputs to 802.11 equipment. These signals can be intercepted miles away. Frequency hopping spread spectrum, the modulation technique Bluetooth uses, used to be implemented by the military to make traffic interception more difficult. By using a secret pattern to hop from frequency to frequency in rapid succession, the signal was difficult to lock on to. However, Bluetooth specifies a hopping pattern which is known to all Bluetooth devices so interoperability is guaranteed. Since the pattern is known to all, then it is not a security mechanism.
Risk: short PIN Bluetooth allows for user PINs up to 16 characters long. The PIN is used in conjunction with a random number when setting up a trust relationship with another device. Most users will use a short PIN, four to six digits, which can be guessed via brute force. However,
Secure VPN Design Considerations Kevin Regan, Consulting Systems Engineer, Cisco Systems
without knowledge of the random number used during the relationship setup process, traffic cannot be decrypted.
Tidal wave of Bluetooth Like it or not, Bluetooth is here to stay. Bluetooth radios are being integrated into all manner of devices, and users are becoming accustomed to the convenience Bluetooth offers. Until the Bluetooth specification mandates a minimum level of security, users need to be very aware of how their Bluetooth devices are configured. Through the use of corporate policy and user education, the risks involved in using Bluetooth can be mitigated.
About the Author Bruce Potter has a broad information security background that includes deployment of wireless networks. Trained in computer science at the University of Alaska Fairbanks, Bruce served as a senior technologist at several hi-tech companies. Bruce is the founder and President of Capital Area Wireless Network. In 1999 Bruce founded The Shmoo Group, a group of security professionals scattered throughout the world. Bruce co-authored 802.11 Security published through O'Reilly and Associates. He is co-authoring Mac OS X Security to be published by New Riders Publishing in May of 2003.
This article is intended to highlight major design considerations when planning site-to-site secure VPN deployments for Intranet or Extranet applications. The term secure, in this context is intended to highlight that this discussion revolves around VPN selection where the security posture requires some degree of confidentiality, integrity and authentication, which are typically provided by IPSec
5
secure vpn
Figure 1: Hub-and-Spoke VPN
Introduction A VPN is frequently defined as 'any network built upon a public network and partitioned for use by individual customers', which results in the term being applied to many network types. IP VPNs, meaning networks constructed across shared IP backbones, can also take many forms, with the use of MPLS and IPSec being widespread. Although there are multiple tunnel techniques which would provide connectivity and traffic separation between VPNs, we will focus on deployments where privacy and integrity controls are required, essentially a security policy consideration. For these reasons we will focus on IPSec. Internet VPNs provide cost effective and flexible network connectivity. The capabilities to service Intranet and Extranet applications with similar infrastructure, reduced complexity and global reach are compelling. Where the Internet is used, the need for strong security is clear, however, where the security policy requires it, the same technologies are also applicable to other
6
forms of shared and even private networks.
together with some newer hybrid architectures.
Site-to-site VPN functions
Hub-and-spoke
The IPSec standards provide numerous security features, which are well known and understood; data encryption, device authentication and data integrity. The use of these mechanisms is largely controlled by the security policy; however, there are many other design issues, which require consideration for optimal performance, availability and ease of support. This document focuses upon design features and attributes and does not focus directly upon VPN platform selection.
In this arrangement, as shown in Figure 1, each remote site's IPSec connectivity is exclusively with the hub location. This is most useful where the traffic flows are predominantly between the remote sites and the regional or headquarters location. This is not ideal for high traffic flows between remote offices, as this will involve decryption and encryption whilst traversing the hub site VPN device(s). In this case, each spoke site would have a very similar configuration, only requiring connectivity to hub sites, and would only require a single IPSec tunnel connection to each hub, so a minimal number of IPsec tunnels would be utilised, and therefore minimal resources would be required. This approach is very easy to deploy and simple to configure, and has the added advantage that when new spokes are added, existing spoke devices do not require configuration changes to communicate with
VPN topologies To fully realise the flexibility and cost of ownership advantages of a site-to-site VPN it is necessary to adopt the most suitable architecture. Although a hierarchical design may utilise multiple topology types, it is necessary to understand the constituent parts and contrast the traditional huband-spoke and full mesh options,
secure vpn
Figure 2: Meshed VPN the new locations. Multiple hub sites can be added for resilience, although not indicated in this example.
Mesh Figure 2 shows a meshed topology with IPSec tunnels configured directly between sites. This is optimal for traffic forwarding, as traffic flows directly between locations without necessarily traversing a head end or hub site. Mesh topologies require additional configuration complexity, as IPSec credentials need to be configured for all possible IPSec peers. This also dictates that static IP addresses are utilised on the external interfaces of the VPN peers for reachability.
Dynamic multipoint VPN This is a new approach leveraging the well-known standards of GRE and NHRP, and offers considerable scaling and ease of use enhancements.
In this arrangement, DM VPN capable devices are deployed with configurations very similar to the hub-and-spoke case. Each remote office VPN router would maintain a static spoke-to-hub IPSec tunnel to the regional or headquarter site, as shown in Figure 3. The use of a multipoint GRE tunnel together with NHRP routing allows on demand IPSec tunnels to be established directly between spokes. A DM-VPN provides the optimal traffic forwarding of a mesh design, avoiding hub decryption/encryption with the configuration simplicity of a hub-and-spoke design. As new spoke sites are added, the hub can dynamically learn of the new spoke, and the dynamic routing protocol will propagate routing information to other spokes.
Hierarchical designs For very large designs, a hierarchical approach allows further scaling. Regional
components could use mesh, hub-andspoke and DM-VPNs as appropriate.
Tunneling protocols and application support IPSec may appear the obvious choice to provide the encryption and authentication tasks, however there is a complementary tunneling type which may also be frequently necessary. An example of why this is useful is found with IP multicast traffic. The IPSec standards provide encryption and authentication of unicast traffic. To provide a means of transporting multicast applications, there are two standards-based approaches. Generic Routing Encapsulation (RFC 2784) and IP Encapsulation within IP (RFC 2003) both provide a means of transporting IP multicast in a manner which can be encrypted with IPSec. GRE can also be used to transport non-IP protocols over the IPSec VPN.
7
secure vpn
Figure 3: Dynamic Multipoint VPN Diverse traffic types, such as video and specific voice applications (e.g. hoot and holler, music on hold), make extensive use of IP multicast and may therefore require these tunneling schemes to be considered.
Resiliency considerations — resilient VPN termination An IPSec connection between two peers consists of one Internet Key Exchange (IKE) Security Association (SA) and at least two dependent IPSec Security Associations (SAs). If connectivity is lost between the peers, then a new set of SA relationships must be established (stateless failover), or the existing relationship must be taken over by another peer (stateful failover).
Stateful failover Stateful failover is available on some VPN products, such as Cisco 7x00 class
8
VPN Routers giving a very effective way of delivering a resilient VPN termination point.
Stateless failover A number of forms of stateless failover have also been widely deployed. One method has been based upon using keepalive packets after an IKE SA has been established. This allows loss of an IKE peer to be detected, and if multiple IKE peer addresses were configured, SAs can be established with an alternate peer. This behaviour was not included in the IKE and IPSec standards, but has been widely available for some time. A second method uses GRE tunnels, which were referenced in the section on Tunneling Protocols. Both GRE and IPinIP tunnels provide capability to transport multicast and broadcast traffic across IPSec and so provide a standards
based way of transporting a routing protocol over an IPSec VPN. When utilising GRE with a routing protocol, multiple GRE tunnels can be active and, protected by IPSec. This allows standard routing protocols to be utilised to detect loss of connectivity and route around failures. The ability to use conventional routing techniques has many benefits in terms of scale and ease of support, not least of which being that the mechanisms are well defined and understood.
Resiliency considerations — end to end high availability To provide high availability across an extended network on a large scale it is generally necessary to utilise routing protocols in one of two ways. Routing updates can be carried over the IPSec VPN infrastructure between IPSec
secure vpn
Figure 4: Use of Mode-Config peers. This can be achieved using IP in IP or GRE encapsulation schemes, encrypted by IPSec. Routing over IPsec provides resiliency based upon industry standards, which are well known and understood. Reverse Route Injection (RRI) is a feature designed to simplify VPN design where there is a requirement for redundancy or load balancing. As remote peers establish IPSec security associations (SAs) with an RRI-enabled device, a static route is created for each subnet or host protected by that remote peer. As routes are created, they are injected into a dynamic routing protocol such as RIP, OSPF or EIGRP. This means that even without transporting routing updates over the IPSec tunnel, return traffic is directed to the appropriate RRI router. This is particularly relevant in scenarios where there are a number of geographically dispersed VPN termination points.
capabilities are increasingly demanded where VPN technologies are used to replace dedicated private networks. IPSec can be utilised across any IP network, the public Internet, or shared IP networks of other types, although the QoS provided by the underlying network may constrain the overall architecture. This is a good example of how MPLS and IPSec are really complementary technologies, MPLS provides robust separation of traffic between MPLS VPNs, and provides strong QoS capabilities using higher layer resource reservation and DiffServ techniques. IPSec ensures privacy of confidentiality of data transported across the MPLS infrastructure. Regardless of the underlying IP network chosen, there are a small number of key considerations when considering encryption and QoS.
the original protocol will not be possible at the network layer, it will only be recognizable as IPSec traffic. To apply any specific per hop forwarding behaviours on encrypted traffic it is necessary to classify or mark the traffic correctly as it is encrypted. At the point of encryption, the IP Precedence bits or DiffServ Code Point (DSCP) settings should be transferred from the original to the encrypted packet, and it is important to understand that any selected VPN hardware provides this functionality. Many VPN devices can also "police" the settings indicated on incoming packets and change the classification if required. With classification and marking applied at the point of encryption, downstream devices can enforce class specific QoS attributes without visibility of the application or protocol type.
Traffic classification
Quality of service The trend towards converged networks means that Quality of Service (QoS)
Applying network layer encryption, as the security policy may mandate, will mean that once encrypted, visibility of
QoS in the encryption process Many IPSec implementations dedicated IPSec hardware for
use the
9
secure vpn encryption/decryption processes, which in conjunction with QoS attributes can ensure predictable and consistent encryption latencies and performance. In Cisco terms, the ability to use Low Latency Queuing allows multiservice traffic, like voice and video, to be prioritised and ensure that specific bandwidth and latency guarantees are delivered. Jitter (latency variation) is effectively controlled by the use of dedicated IPSec processing hardware with features such as Link Fragmentation and Interleaving (LFI) and Traffic Shaping or Class Based Weighted Fair Queuing.
Optimising network performance Fragmentation Reassembly of fragmented packets is a resource intensive process, which can often be avoided. Fragmented IPSec packets require reassembly before validation and decryption can take place, so reducing or eliminating fragmentation assists VPN performance. As long as filtering does not block ICMP (Internet Control Message Protocol) messages, Path Maximum Transmission Unit Discovery (PMTUD) will determine the maximum MTU that a host can use to send a packet through a tunnel without causing fragmentation. To allow PMTUD, ICMP Type 3 Code 4 messages should be permitted. If, for any reason, they cannot be permitted, then it may be necessary to configure the VPN devices with a specific MTU, or configure them to clear the DF (Don't Fragment) bit in the header and force fragmentation. It is useful to note that Path MTU Discovery is also available on GRE and IPinIP tunneling schemes in Cisco routers, and that by default these schemes will clear the DF bit, so provide a viable solution for situations where ICMP is blocked.
Compression Traditional compression methods, based upon link compression algorithms are 10
not effective with encrypted traffic and will not compress encrypted data. To allow compression with encryption, a standard called IP Payload Compression Protocol (IPComp), was defined in RFC 2393, which allows encrypting peers to negotiate to use an encrypted and compressed transform. In some implementations, such as certain Cisco platforms, dedicated hardware processing provides both the compression and encryption functions.
Management considerations One of the choices in deploying VPNs has been with the IPSec authentication method. For small deployments it has been common to utilise pre-shared keys for authentication purposes for ease of initial deployment. For larger deployments, to reduce the administrative overhead in pre-sharing keys between users and devices, digital certificates have been more widespread. As certificate enrolment techniques have developed, using mechanisms such as the Simple Certificate Enrolment Protocol, these processes have become much easier to implement. As VPNs are migrated to, frequently using connectivity without SLA performance guarantees, performance management may become more significant than in the private network case. In addition to monitoring IPsec status and activity with snmp and other means, the network performance that the VPN provides to applications is critical. Where routers are utilised, features like the Cisco Service Assurance Agent, allow monitoring of latency and packet loss experienced by different protocol types across the extended VPN. These have been widely used to allow QoS to be monitored.
Management of small office/home office connectivity One type of deployment has been given some specific ease of use focus, the Small Office/Home Office (SOHO) configurations. This would typically use broadband connectivity,
and leverages a mechanism called Mode-Config. Mode-Config has been utilised in Remote Access VPN deployments to push policy to laptop/desktop based IPSec client applications when they establish an IPSec connection to the corporate site. This allows the administration tasks to be centralised and removes configuration complexity from the workstation client, reducing the support effort greatly. Taking this a stage further, the development of "hardware client" capabilities have allowed firewalls and routers to be utilised in a VPN with the centralised dynamic assignment of IP address parameters, DNS and WINS settings, and split tunneling policies. This reduces the configuration required for the remote device dramatically.
Summary Site-to-site VPNs can provide high-performance and great flexibility, given the right topology and design approach. Several mechanisms can be used to provide resilient points of access or VPN termination, however, there is more to high availability than purely providing resilient gateways. End-to-end resiliency, as for any other form of large IP network, will need to leverage standard routing protocols, hence the ability to transport routing protocols over IPSec is very important. As QoS can be applied with IPSec and multicast traffic transported over IPSec, the use of an IPSec can be transparent to users and applications.
Standards referenced IP in IP http://www.ietf.org/rfc/rfc2003.txt GRE http://www.ietf.org/rfc/rfc2784.txt IPComp http://www.ietf.org/rfc/rfc2393.txt Security Architecture for the Internet Protocol http://www.ietf.org/rfc/rfc2401.txt
Risk: profile access When the security of an 802.11 network fails, an attacker can sniff data and access remote computers on an IP level. When the security of a Bluetooth device fails, the attacker has complete access to any profiles offered by the device. Rather than being limited to a network-layer attack, the attacker can shoot right to the application-layer. For instance, if a compromised device has the File Sharing Profile enabled, then an attacker can read any files exposed by that profile. By mixing so many layers of the protocol stack into one specification, a compromise of the link-layer is much worse in a Bluetooth environment than in an 802.11 LAN environment. Bluetooth lacks sufficient mechanisms to provide layered security protecting applications. It is up to an application developer to add another layer of protection to mitigate this risk.
Risk: low power ! = unsniffable There is a common misconception that Bluetooth traffic is difficult to intercept due to its low power output and
frequency hopping mechanism. While it is true that most Bluetooth devices transmit very weak signals, they can still be intercepted at large distances (several hundred feet) using strong antennas. Also, there are Bluetooth devices that are broadcast with much more power. Devices such as Bluetooth access points have been designed to provide Internet connectivity in an office environment using similar power outputs to 802.11 equipment. These signals can be intercepted miles away. Frequency hopping spread spectrum, the modulation technique Bluetooth uses, used to be implemented by the military to make traffic interception more difficult. By using a secret pattern to hop from frequency to frequency in rapid succession, the signal was difficult to lock on to. However, Bluetooth specifies a hopping pattern which is known to all Bluetooth devices so interoperability is guaranteed. Since the pattern is known to all, then it is not a security mechanism.
Risk: short PIN Bluetooth allows for user PINs up to 16 characters long. The PIN is used in conjunction with a random number when setting up a trust relationship with another device. Most users will use a short PIN, four to six digits, which can be guessed via brute force. However,
Secure VPN Design Considerations Kevin Regan, Consulting Systems Engineer, Cisco Systems
without knowledge of the random number used during the relationship setup process, traffic cannot be decrypted.
Tidal wave of Bluetooth Like it or not, Bluetooth is here to stay. Bluetooth radios are being integrated into all manner of devices, and users are becoming accustomed to the convenience Bluetooth offers. Until the Bluetooth specification mandates a minimum level of security, users need to be very aware of how their Bluetooth devices are configured. Through the use of corporate policy and user education, the risks involved in using Bluetooth can be mitigated.
About the Author Bruce Potter has a broad information security background that includes deployment of wireless networks. Trained in computer science at the University of Alaska Fairbanks, Bruce served as a senior technologist at several hi-tech companies. Bruce is the founder and President of Capital Area Wireless Network. In 1999 Bruce founded The Shmoo Group, a group of security professionals scattered throughout the world. Bruce co-authored 802.11 Security published through O'Reilly and Associates. He is co-authoring Mac OS X Security to be published by New Riders Publishing in May of 2003.
This article is intended to highlight major design considerations when planning site-to-site secure VPN deployments for Intranet or Extranet applications. The term secure, in this context is intended to highlight that this discussion revolves around VPN selection where the security posture requires some degree of confidentiality, integrity and authentication, which are typically provided by IPSec
5
secure vpn
Figure 1: Hub-and-Spoke VPN
Introduction A VPN is frequently defined as 'any network built upon a public network and partitioned for use by individual customers', which results in the term being applied to many network types. IP VPNs, meaning networks constructed across shared IP backbones, can also take many forms, with the use of MPLS and IPSec being widespread. Although there are multiple tunnel techniques which would provide connectivity and traffic separation between VPNs, we will focus on deployments where privacy and integrity controls are required, essentially a security policy consideration. For these reasons we will focus on IPSec. Internet VPNs provide cost effective and flexible network connectivity. The capabilities to service Intranet and Extranet applications with similar infrastructure, reduced complexity and global reach are compelling. Where the Internet is used, the need for strong security is clear, however, where the security policy requires it, the same technologies are also applicable to other
6
forms of shared and even private networks.
together with some newer hybrid architectures.
Site-to-site VPN functions
Hub-and-spoke
The IPSec standards provide numerous security features, which are well known and understood; data encryption, device authentication and data integrity. The use of these mechanisms is largely controlled by the security policy; however, there are many other design issues, which require consideration for optimal performance, availability and ease of support. This document focuses upon design features and attributes and does not focus directly upon VPN platform selection.
In this arrangement, as shown in Figure 1, each remote site's IPSec connectivity is exclusively with the hub location. This is most useful where the traffic flows are predominantly between the remote sites and the regional or headquarters location. This is not ideal for high traffic flows between remote offices, as this will involve decryption and encryption whilst traversing the hub site VPN device(s). In this case, each spoke site would have a very similar configuration, only requiring connectivity to hub sites, and would only require a single IPSec tunnel connection to each hub, so a minimal number of IPsec tunnels would be utilised, and therefore minimal resources would be required. This approach is very easy to deploy and simple to configure, and has the added advantage that when new spokes are added, existing spoke devices do not require configuration changes to communicate with
VPN topologies To fully realise the flexibility and cost of ownership advantages of a site-to-site VPN it is necessary to adopt the most suitable architecture. Although a hierarchical design may utilise multiple topology types, it is necessary to understand the constituent parts and contrast the traditional huband-spoke and full mesh options,
secure vpn
Figure 2: Meshed VPN the new locations. Multiple hub sites can be added for resilience, although not indicated in this example.
Mesh Figure 2 shows a meshed topology with IPSec tunnels configured directly between sites. This is optimal for traffic forwarding, as traffic flows directly between locations without necessarily traversing a head end or hub site. Mesh topologies require additional configuration complexity, as IPSec credentials need to be configured for all possible IPSec peers. This also dictates that static IP addresses are utilised on the external interfaces of the VPN peers for reachability.
Dynamic multipoint VPN This is a new approach leveraging the well-known standards of GRE and NHRP, and offers considerable scaling and ease of use enhancements.
In this arrangement, DM VPN capable devices are deployed with configurations very similar to the hub-and-spoke case. Each remote office VPN router would maintain a static spoke-to-hub IPSec tunnel to the regional or headquarter site, as shown in Figure 3. The use of a multipoint GRE tunnel together with NHRP routing allows on demand IPSec tunnels to be established directly between spokes. A DM-VPN provides the optimal traffic forwarding of a mesh design, avoiding hub decryption/encryption with the configuration simplicity of a hub-and-spoke design. As new spoke sites are added, the hub can dynamically learn of the new spoke, and the dynamic routing protocol will propagate routing information to other spokes.
Hierarchical designs For very large designs, a hierarchical approach allows further scaling. Regional
components could use mesh, hub-andspoke and DM-VPNs as appropriate.
Tunneling protocols and application support IPSec may appear the obvious choice to provide the encryption and authentication tasks, however there is a complementary tunneling type which may also be frequently necessary. An example of why this is useful is found with IP multicast traffic. The IPSec standards provide encryption and authentication of unicast traffic. To provide a means of transporting multicast applications, there are two standards-based approaches. Generic Routing Encapsulation (RFC 2784) and IP Encapsulation within IP (RFC 2003) both provide a means of transporting IP multicast in a manner which can be encrypted with IPSec. GRE can also be used to transport non-IP protocols over the IPSec VPN.
7
secure vpn
Figure 3: Dynamic Multipoint VPN Diverse traffic types, such as video and specific voice applications (e.g. hoot and holler, music on hold), make extensive use of IP multicast and may therefore require these tunneling schemes to be considered.
Resiliency considerations — resilient VPN termination An IPSec connection between two peers consists of one Internet Key Exchange (IKE) Security Association (SA) and at least two dependent IPSec Security Associations (SAs). If connectivity is lost between the peers, then a new set of SA relationships must be established (stateless failover), or the existing relationship must be taken over by another peer (stateful failover).
Stateful failover Stateful failover is available on some VPN products, such as Cisco 7x00 class
8
VPN Routers giving a very effective way of delivering a resilient VPN termination point.
Stateless failover A number of forms of stateless failover have also been widely deployed. One method has been based upon using keepalive packets after an IKE SA has been established. This allows loss of an IKE peer to be detected, and if multiple IKE peer addresses were configured, SAs can be established with an alternate peer. This behaviour was not included in the IKE and IPSec standards, but has been widely available for some time. A second method uses GRE tunnels, which were referenced in the section on Tunneling Protocols. Both GRE and IPinIP tunnels provide capability to transport multicast and broadcast traffic across IPSec and so provide a standards
based way of transporting a routing protocol over an IPSec VPN. When utilising GRE with a routing protocol, multiple GRE tunnels can be active and, protected by IPSec. This allows standard routing protocols to be utilised to detect loss of connectivity and route around failures. The ability to use conventional routing techniques has many benefits in terms of scale and ease of support, not least of which being that the mechanisms are well defined and understood.
Resiliency considerations — end to end high availability To provide high availability across an extended network on a large scale it is generally necessary to utilise routing protocols in one of two ways. Routing updates can be carried over the IPSec VPN infrastructure between IPSec
secure vpn
Figure 4: Use of Mode-Config peers. This can be achieved using IP in IP or GRE encapsulation schemes, encrypted by IPSec. Routing over IPsec provides resiliency based upon industry standards, which are well known and understood. Reverse Route Injection (RRI) is a feature designed to simplify VPN design where there is a requirement for redundancy or load balancing. As remote peers establish IPSec security associations (SAs) with an RRI-enabled device, a static route is created for each subnet or host protected by that remote peer. As routes are created, they are injected into a dynamic routing protocol such as RIP, OSPF or EIGRP. This means that even without transporting routing updates over the IPSec tunnel, return traffic is directed to the appropriate RRI router. This is particularly relevant in scenarios where there are a number of geographically dispersed VPN termination points.
capabilities are increasingly demanded where VPN technologies are used to replace dedicated private networks. IPSec can be utilised across any IP network, the public Internet, or shared IP networks of other types, although the QoS provided by the underlying network may constrain the overall architecture. This is a good example of how MPLS and IPSec are really complementary technologies, MPLS provides robust separation of traffic between MPLS VPNs, and provides strong QoS capabilities using higher layer resource reservation and DiffServ techniques. IPSec ensures privacy of confidentiality of data transported across the MPLS infrastructure. Regardless of the underlying IP network chosen, there are a small number of key considerations when considering encryption and QoS.
the original protocol will not be possible at the network layer, it will only be recognizable as IPSec traffic. To apply any specific per hop forwarding behaviours on encrypted traffic it is necessary to classify or mark the traffic correctly as it is encrypted. At the point of encryption, the IP Precedence bits or DiffServ Code Point (DSCP) settings should be transferred from the original to the encrypted packet, and it is important to understand that any selected VPN hardware provides this functionality. Many VPN devices can also "police" the settings indicated on incoming packets and change the classification if required. With classification and marking applied at the point of encryption, downstream devices can enforce class specific QoS attributes without visibility of the application or protocol type.
Traffic classification
Quality of service The trend towards converged networks means that Quality of Service (QoS)
Applying network layer encryption, as the security policy may mandate, will mean that once encrypted, visibility of
QoS in the encryption process Many IPSec implementations dedicated IPSec hardware for
use the
9
secure vpn encryption/decryption processes, which in conjunction with QoS attributes can ensure predictable and consistent encryption latencies and performance. In Cisco terms, the ability to use Low Latency Queuing allows multiservice traffic, like voice and video, to be prioritised and ensure that specific bandwidth and latency guarantees are delivered. Jitter (latency variation) is effectively controlled by the use of dedicated IPSec processing hardware with features such as Link Fragmentation and Interleaving (LFI) and Traffic Shaping or Class Based Weighted Fair Queuing.
Optimising network performance Fragmentation Reassembly of fragmented packets is a resource intensive process, which can often be avoided. Fragmented IPSec packets require reassembly before validation and decryption can take place, so reducing or eliminating fragmentation assists VPN performance. As long as filtering does not block ICMP (Internet Control Message Protocol) messages, Path Maximum Transmission Unit Discovery (PMTUD) will determine the maximum MTU that a host can use to send a packet through a tunnel without causing fragmentation. To allow PMTUD, ICMP Type 3 Code 4 messages should be permitted. If, for any reason, they cannot be permitted, then it may be necessary to configure the VPN devices with a specific MTU, or configure them to clear the DF (Don't Fragment) bit in the header and force fragmentation. It is useful to note that Path MTU Discovery is also available on GRE and IPinIP tunneling schemes in Cisco routers, and that by default these schemes will clear the DF bit, so provide a viable solution for situations where ICMP is blocked.
Compression Traditional compression methods, based upon link compression algorithms are 10
not effective with encrypted traffic and will not compress encrypted data. To allow compression with encryption, a standard called IP Payload Compression Protocol (IPComp), was defined in RFC 2393, which allows encrypting peers to negotiate to use an encrypted and compressed transform. In some implementations, such as certain Cisco platforms, dedicated hardware processing provides both the compression and encryption functions.
Management considerations One of the choices in deploying VPNs has been with the IPSec authentication method. For small deployments it has been common to utilise pre-shared keys for authentication purposes for ease of initial deployment. For larger deployments, to reduce the administrative overhead in pre-sharing keys between users and devices, digital certificates have been more widespread. As certificate enrolment techniques have developed, using mechanisms such as the Simple Certificate Enrolment Protocol, these processes have become much easier to implement. As VPNs are migrated to, frequently using connectivity without SLA performance guarantees, performance management may become more significant than in the private network case. In addition to monitoring IPsec status and activity with snmp and other means, the network performance that the VPN provides to applications is critical. Where routers are utilised, features like the Cisco Service Assurance Agent, allow monitoring of latency and packet loss experienced by different protocol types across the extended VPN. These have been widely used to allow QoS to be monitored.
Management of small office/home office connectivity One type of deployment has been given some specific ease of use focus, the Small Office/Home Office (SOHO) configurations. This would typically use broadband connectivity,
and leverages a mechanism called Mode-Config. Mode-Config has been utilised in Remote Access VPN deployments to push policy to laptop/desktop based IPSec client applications when they establish an IPSec connection to the corporate site. This allows the administration tasks to be centralised and removes configuration complexity from the workstation client, reducing the support effort greatly. Taking this a stage further, the development of "hardware client" capabilities have allowed firewalls and routers to be utilised in a VPN with the centralised dynamic assignment of IP address parameters, DNS and WINS settings, and split tunneling policies. This reduces the configuration required for the remote device dramatically.
Summary Site-to-site VPNs can provide high-performance and great flexibility, given the right topology and design approach. Several mechanisms can be used to provide resilient points of access or VPN termination, however, there is more to high availability than purely providing resilient gateways. End-to-end resiliency, as for any other form of large IP network, will need to leverage standard routing protocols, hence the ability to transport routing protocols over IPSec is very important. As QoS can be applied with IPSec and multicast traffic transported over IPSec, the use of an IPSec can be transparent to users and applications.
Standards referenced IP in IP http://www.ietf.org/rfc/rfc2003.txt GRE http://www.ietf.org/rfc/rfc2784.txt IPComp http://www.ietf.org/rfc/rfc2393.txt Security Architecture for the Internet Protocol http://www.ietf.org/rfc/rfc2401.txt