Vous êtes sur la page 1sur 10

Fact Sheet SEN-326

Virtual security is not enough

Copyright Senetas Corporation 2012 - All rights reserved. Permission to reproduce and distribute this document is granted provided this copyright notice is included and that no modifications are made to the original. Revisions to this document may be issued, without notice, from time to time. Rev. 01

Virtual security is not enough


Introduction
Most service provider VPN security provides little more than a promise to keep each customers data separated across a shared infrastructure. What are the risks in this model and how can it to wrong? This fact sheet is a transcript of an interview with Senetas CTO Julian Fay in which these topics are discussed and practical considerations given for using encryption on VPNs to enhance organisational security.

1) Why is encryption needed on networks, isn't there sufficient data protection on standard service provider offerings?
JF: Well if we look at service provider metro or wide area services then are a few things to consider, firstly whilst these networks can provide good separation of traffic between different users they dont typically provide any inherent confidentiality of the information that is sent. These services are often described as VPNs or virtual private networks, this is misleading in the sense that the word private is not a synonym for encrypted and although each customer does see a logically private network service it still runs on a shared infrastructure and all that is separating one customers data from another is a tag or label that the core switches use for customer separation. This means that if there is accidental or malicious mis-configuration in the network which results in data being sent to the wrong destination than that information will be exposed. Secondly unencrypted traffic is still vulnerable to snooping anywhere in its journey from source to destination if for example an attacker can get access to the physical network at any point. And like all security if the cost of the attack is less than the value of the information - to someone then this becomes a genuine threat. So a better approach is to use strong encryption to protect the traffic during transmission which will mitigate these threats.

2) What encryption technologies are available to ensure the confidentiality of transmitted information across services?
JF: There are a few different ways that encryption can protect information in motion. They principally relate to the layer in the network stack where encryption is applied.

__________________________________________________________________________________ Page 1

Virtual security is not enough


So for example TLS or SSL is usually implemented on top of the transport layer protocols (ie TCP) and is will securely encapsulate application specific protocols such as HTTP or FTP, thats what you get for example when you see the little padlock in your browser when you connect to a secure site on the internet Alternately you can encrypt at the network layer using the standard IPSec protocol, this will protect each IP packet typically by encrypting and tunnelling an entire IP packet inside a secure wrapper before transmission. IPSec can be provided either in standalone appliances or built into some routers or switches. Lastly you can choose to encrypt at the data link layer which is also known as layer 2 and this is where Senetas has chosen to steer its product direction and focus. In all cases the challenge lies in ensuring the security and privacy of user data without in any way constraining the performance or operation of the network itself.

3) Why has Senetas focussed on encryption at layer 2 or the data link layer, what advantages does that bring?
JF: Yes thats a good question. Well there are some tradeoffs that must be made when encrypting at layer 3 using IPSec that are mostly around scalability and performance. Because IPSec tunnels the original IP packet it does introduce a performance hit on the network which leads to a loss of throughput and limits to both scalability and the kind of applications or services that it may be possible to deliver across that network. On the other hand because layer 2 encryption operates at the data link layer (ie at the frame layer) then it is optimised for operation on layer 2 services such as metro or VPLS and means that you can encrypt transparently and with far lower overhead than you can at layer 3. Encryption at layer 2 is also independent of all traffic types and applications that run above layer 2 so it automatically supports not only IP but also any legacy protocols such as IPX or AppleTalk for example. Encryption of multicast traffic is also far simpler to achieve at layer 2 which is important because of the large growth in network video traffic.

__________________________________________________________________________________ Page 2

Virtual security is not enough


4) Where are Senetas encryptors typically located in an encrypted environment?
JF: They are perimeter devices that normally sit at the edge of the customer network and protect information transmitted from the private network to the WAN. On the customer side they will usually plug into some kind of CPE (customer premise equipment) which may be just a router or a switch if theres a flat network behind the encryptor. Then on the WAN side they can plug into an NTU (network termination unit) or maybe directly into a fibre patch panel and will have an appropriate optical transceiver to drive the required wavelength and distance. Encryptors are also sometime deployed inside data centre environments as well for example to encrypt high speed inter-server traffic between racks that may span a single facility.

5) What is the impact of overlaying encryption on top of a network service; does it slow down traffic or inhibit the kind of services that can be run?
JF: Thats a great question and again this is one of the major differentiators between encryption at layer 2 and other approaches as it comes without built-in performance degradation. Because of the characteristics of layer 2 networks its possible to provide wire speed encryption at rates up to 10Gbps with constant low latency and depending on the mode of operation either zero or close to zero per frame overhead. Having minimal delay or latency is of course critical but perhaps even more important is jitter or variation in latency. Jitter occurs when packets are sent and received with variable delays and can really impact certain time sensitive traffic such as VOIP. To ensure low latency all of our encryption and network processing in our CN product range is implemented using dedicated chips that we program ourselves for maximum performance. We also use whats called a cut-through architecture; this means that instead of buffering and storing every frame we receive we are able to start processing, encrypting and then retransmitting a frame whilst it is still being received on the incoming port. With this approach you can get not only low latency (which for example is approximately four microseconds through a 10G encryptor) but also very consistent delay which is independent of the size of the data or application.

__________________________________________________________________________________ Page 3

Virtual security is not enough


So this means that it doesnt matter whether the information being sent is voice or video or data as the encryptor is agnostic to the traffic type.

6) Can virtual local area networks or VLANs be run across an encrypted network, for example if an organisation wants to run the marketing department on one VLAN and the accounting department on another?
JF: Yes this is a very common deployment and is supported by the encryptors. As you say a VLAN is often used to segment a network into different domains which might map directly to a company department or perhaps a government agency or different customers on a shared network. There are a couple of challenges around securing VLANs, first its highly desirable that each VLAN be encrypted using unique encryption keys so that there is true cryptographic separation between each VLAN domain. This can be done by using the VLAN identifier to cryptographically separate. Secondly because VLANs are likely to span different physical locations we have an arrangement whereby a frame from a single transmitter will be received by one or more of several receivers who must all share the encryption key. For that reason we use a group encryption key mechanism per VLAN which ensures that all encryptors can securely communicate with each other and also that unique keys will be used for each separate VLAN ID.

7) How can an enterprise still access the internet if encryption is used?


JF: The short answer is that there is a great deal of flexibility in the configuration policy of the encryptors which allows traffic to be selectively processed according to different requirements. So in this case the customer may wish to encrypt all traffic that flows across their organisational links but still allow some traffic to be sent to a gateway device that provides internet access for example and obviously the requirement here is that all traffic sent to and from the gateway must be bypassed. This can easily be achieved if the layer 2 or MAC address of the gateway device is known, all that is required is that this gateway MAC address is configured in the encryptor with a stated action of __________________________________________________________________________________ Page 4

Virtual security is not enough


BYPASS which means that traffic to and from this device will be sent transparently whilst all other traffic is secured as normal. Depending on the network architecture it may be necessary to send unencrypted traffic on an entire VLAN, this can easily be achieved since for each VLAN there is control over whether that traffic should be selectively bypassed, discarded (i.e. dropped) or encrypted. This kind of control exists in a hierarchy of policies which gives a great deal of flexibility and control down to per the frame ethertype or MAC address as well as by VLAN. Weve also learned the hard way that not all networks are alike and so weve also built in the ability to bypass certain multicast control plane frames that are required for normal network operation which includes things like Spanning tree frames, link aggregation control and various CISCO management types.

8) What is the maximum number of layer 2 MAC addresses that can be supported through a Senetas encrypted connection?
JF: Well if youre operating in VLAN mode or in a simple pt-pt configuration then we support all possible MAC addresses because in these modes the encryption key is tied to either VLAN ID or in the case of pt-pt mode there is only a single connection which encrypts information between two locations. In multipoint MAC mode we establish secure connections between any pair of devices across the network with any individual encryptor supporting over 500 concurrent secure connections to other devices. In this mode the encryptor does look up the remote address of each frame during its processing and we support up to 10,000 unique MAC addresses on the CN1000 encryptor (which runs from 10M to 1G) and currently up to 512 on the CN6100 10G device. A common deployment though is to have a router directly connected to the encryptor on the private side in which case there one source MAC address per site is required.

9) How can jumbo frames be transported across a Senetas encrypted network?


JF: Very easily, in all of our CN models as they support jumbo frames up to 10,000 bytes long.

__________________________________________________________________________________ Page 5

Virtual security is not enough


10) What types of customer edge device are compatible with Senetas encryptors?
JF: Thats a good question and really there are no constraints on the customer edge devices as long as the equipment we connect to is standards compliant and delivers layer 2 frames of the expected protocol type to the encryptor. So far weve spoken mostly about encryption but its worth pointing out that the CN platform is capable of securing have a broad range of layer 2 protocols including: low speed serial links, E1/T1 TDM connections, ATM and SONET networks and fibre channel storage links as well Weve specialised in the development of this technology since 1997 and in that time have been deployed into pretty much every conceivable environment and connected to every type of 3rd party equipment you can imagine. More important are the characteristics of the WAN service that the encryptors are securing and the requirement there is that to encrypt at layer 2 you must have a layer 2 type of service or connection. Its easy to see why this is the case because by default a layer 2 encryptor will scramble the IP header inside the layer 2 frame which means that it is invisible at the IP layer and therefore cant be routed. If the environment is layer 3 then we also have a complete range of layer 3 IP encryptors that are suitable for this scenario. In general though we do recommend a layer 2 approach when compatible with the network environment and that is for reasons of simplicity and performance.

11) How do you manage the encryptors; is a separate dedicated management network required?
JF: This really depends on the customers environment and how they want to organise their management of the overall network not just the encryptors. Basically there are a couple of choices but both provide for full remote management of the encryptors using a GUI tool that we provide called CypherManager. CypherManager uses the industry standard SNMPv3 protocol to remotely manage devices and we quite happily share the device MIB or management information base which allows other network management tools to also manage the encryptors if required. So in terms of management options each encryptor has a standard serial port for local command line configuration as well as a separate port for remote management purposes.

__________________________________________________________________________________ Page 6

Virtual security is not enough


This is what the majority of our customers use as they typically implement a separate management network from the encrypted data plane. There is another option though which is to manage the encryptors across the encrypted network itself using what we call inband management. This requires one of the encryptors in the network to act as a management gateway, the management gateway is connected by its dedicated management port to the workstation or PC running CypherManager and will forward SNMP management traffic across the encrypted WAN to the appropriate encryptors network interface. Senetas has its own ethertype registered with the IEEE which is used to distinguish control plane from data plane traffic on the receiving port.

12) Doesn't encryption prevent the use of WAN optimisation technologies across the network?
JF: Well if WAN optimisation is being used then you have to be careful where the encryption takes place. WAN accelerators dont have visibility into encrypted data of course so they cant perform their optimisation function, the solution here is to ensure that any encryption in the network occurs downstream of the WAN optimisation devices.

13) Can quality of service be guaranteed across an encrypted connection?


JF: Great question, quality of service can occur at different layers in the stack for example using DiffServ at layer 3. On layer 2 networks service providers can offer different traffic priority levels using the class of service field in the frame header. This is called the 802.1P frame marking. All traffic can be assigned to one of 8 priority levels and the network will honour these markings to the agreed service levels. So to support this on an encrypted connection requires a couple of things, firstly the 802.1P markings must be transparent to the service provider so that they act on them in the middle of the network and secondly the encryption must allow for some frames to be prioritised ahead of others, that is potentially reordered in the network.

__________________________________________________________________________________ Page 7

Virtual security is not enough


We support both of these in our encryptors when using the VLAN mode of operation, in this mode the encryptors will leave the entire 802.1Q header containing the priority bits in the clear so that it can be switched through the cloud with all priority markings intact.

14) How much work is required by the customer to configure the devices when installing them into a network, for example do they have to manually configure MAC addresses?
JF: Well unlike IP addresses, MAC addresses are not user defined they are actually built into the hardware of the network equipment and also unlike IP subnets they dont follow any logical grouping so for these reasons manual configuration would be extremely difficult. The problem isnt quite so bad for VLAN identifiers because there are only 4096 possible values but even so its preferable to automate this as much as possible. To facilitate this, the encryptors have an automatic discovery mechanism, this allows you to connect an encryptor onto a network and the device will automatically detect other encryptors on the other side of the WAN and establish a secure connection between them with no manual intervention. This turns out to be ideal for all kinds of deployments but especially large complex meshes because all you need to do beforehand is issue an X.509 certificate to each device then you can literally turn the encryptors on and the entire network will automatically configure itself and start passing traffic securely. Of course if you dont want to enable automatic discovery then this can be disabled from the manager, in this case the VLAN identifiers or MAC addresses need to be manually added which is manageable for small numbers of addresses.

__________________________________________________________________________________ Page 8

Virtual security is not enough


15) What final thoughts would you give to enterprises trying to secure their network?
JF: Well I think we are seeing that data security is front of mind for many organisations these days and I guess you just need to look at some of the recent high profile data breaches to see the damage that can be do to an organisations reputation and ultimately their value when these breaches occur. So in general our message to organisations and government of all types is that they need to take stock of how they protect and handle data to prevent serious breaches. Mistakes will happen but its important to realise that should data be stolen then strong encryption will protect that information from disclosure.

__________________________________________________________________________________ Page 9

Vous aimerez peut-être aussi