In simple terms a virtual circuit is a dedicated communication line between two end points usually on a packet switched or cell relay network. A common use is to provide a temporary or dedicate link through a router or switch connected network. Any devices along the circuit will be programmed with the specific circuit number so that when packets arrive the switch has the correct information to forward them. This saves the potentially lengthy process of examine the packet header in detail.
Using a predefined path like this can improve performance substantially and also reduces the size of frames and packets specifically by ensuring the header sizes are much smaller. The underlying physical routes of these connections may change in a standard packet switching network however the two end stations will retain a connection and update paths as appropriate. Typically this could happen when the network is experiencing congestion or perhaps some sort of physical problem with a downed line.
There are two main types of virtual circuits which can be described as follows:
PVC: (Permanent Virtual Circuit) – a connection between end points defined in advance. often with a predetermined bandwidth and speed allowance. In commercial public switched carrier networks (like ATM) or frame relay the customers will be allocated the endpoints of the PVC in advance. In internal networks the administrators create the PVCs to direct applications or certain traffic to specific parts of the network. For example a common use would be to retain bandwidth and define a network path for video enabled applications such as video conferencing. Video needs specific quality to operate correctly so it makes sense to define specific routes – although this could also be done to block access to external video applications like Netflix.
SVC: (Switched Virtual Circuit) – an on-demand connection which is normally temporary between two stations. An easy way to visualize an SVC is something like a phone call which is a temporary connection created to transfer voice. Connections on an SVC will only last as long as necessary to complete the transaction, they are then taken down. Many carriers let customers establish these ‘on the fly’ or a carrier may set up a number of defined SVCs which can be used when required. Perhaps these could be useful for establishing internal secure channels such as a VPN or IP Cloaker application.
It’s best remembered that PVCs are most effective when there is a large amount of specific data anticipated between two locations on a regular basis. Using an SVC is much more suitable for temporary or recurring connections for example unscheduled video or voice conferences. Most commercial carriers prefer to set up PVCs because they are easier to manage bandwidth requirements in advance than SVCs. It is very common for PVCs to have monthly costs, rates or bandwidth allowances assigned to them making it easier to allocate costs and budgets against them.
The SSL Tunneling Protocol allows any proxy server which supports it the ability to act as a tunnel for SSL enhanced protocols. This feature is essential to support normal web traffic and increasingly SSL is being used to secure normal web requests which would previously have been sent in clear text. The client makes the initial HTTP request to the proxy and asks for an SSL tunnel. If we look at the protocol level the actual handshake to establish the SSL tunneling connection is fairly straight-forward.
The connection is simple and in fact looks like virtually any other HTTP request, the only difference is that we use a new ‘Connect’ method. The format is also slightly different as the parameter is not a full url but rather the destination host address and the post number in the format 192.168.1.1:8080. The port number is always required with these connection requests, as the default number is generic and not always correct.
When the client has received a successful response then the connection will pass all data in both directions to the destination server. For the proxy server much of it’s role in authentication and establishing the connection is over, and it’s role is then limited to simply forwarding data for the connection. The final significant role for the proxy server is to close the connection which it will do when it receives a close request from either the client or the server.
Other situations where the connection will be closed mainly refer to error status codes. For example an error generated in response to authentication would be a typical situation where authentication has failed. Most proxies will require some sort of authentication especially the high quality US proxies such as this. The methods might change however from a simple username password supplied via a challenge and response to pass through authentication from a system like the Active Directory or LDAP.
It’s interesting to note that the mechanism used to handle SSL tunnelling is not actually specific to this protocol. It is in fact a generic technique which can be used to tunnel any protocol including SSL. There is no actual reliance on any SSL support from the proxy, which can be confusing when you see people look for SSL enabled proxies online. It is not required on a properly configured proxy server as the data is simply transported there is no need for the actual protocol to be understood after the initial connection request.
There are issues with some protocols transferring through proxies, certain specialised protocols need more support than is offered with the standard tunneling mechanism. For example for many years LDAP (Lightweight Directory Access Protocol) was not able to work across most common proxies. Some implementations support LDAP by using SOCKS while there is some difficulty with LDAP queries being cached and subsequently causing performance issues. Most protocols however work perfectly with this ‘hands off’ tunneling mechanism which you can see perfectly illustrated if you try and stream video through proxies like this which used to circumvent BBC iPlayer blocked abroad.