When it comes to discuss about Remote Connectivity technology and solution, one should see where actually all the technologies and acronyms actually stand. IPSec is one of most commonly used acronyms and needs a closer focus.
Any information exchange from or to a company location with off-premises (either a remote-site or a telecommuter) should meet confidentiality, integrity, authentication requirements in terms of information security. Technologies meeting these requirements are not many and can be grouped as below.
Virtual Private Networks (VPNs) can be established as
· Site to Site (Connecting remote sites to hubs)
· Remote Access (Connecting individuals to company networks)
VPNs may also be classified per technology as following:
· IPSec (More suitable for Site-to-Site VPNs, may require more configuration or client software)
· SSL VPN ( Easier to establish for clients, a specific client software is not needed most of the times)
Protocols like PPTP and L2TP are not mentioned in this classification because they are no longer considered as viable alternatives and their use in industry is limited comparing to aforementioned technologies.
I personally am configuring and troubleshooting IPSec VPNs for more than 5 years and have been asking myself many times whether I should keep the configuration long and complicated or not. The question goes further about the choices for different algorithms to use in different phases of IPSec, such as “should I really configure Diffie-Hellman algorithm for phase 2 or not”. After this article, I hope you will be able to answer these questions by yourselves.
Before starting to dive into more detail some important concepts about IPSec should be known. IPSec supports 2 modes of operation, Tunnel mode and Transport mode. Tunnel mode is used for end-to-end communications in remote locations (requiring a tunnel IP at both ends, easing the routing operations) while Transport mode is preferred more in Gateway to Gateway communications. I can say that 99% of the times Tunnel mode is preferred and offered by default in devices.
The second important thing to know is the packet structure.
AH (Authentication Header) protocol offers an authentication header in front of the payload providing a means of integrity, authentication and non-repudiation. However it does not deal with encryption and does not provide confidentiality.
ESP (Encapsulating Security Payload) protocol encapsulates the original packet header and payload inside a new authentication header and IP header. This provides integrity, authentication and non-repudiation just like in AH protocol. Furthermore, ESP also encrypts the initial payload and header providing confidentiality.
So, to start with, we have 2 network devices defining the perimeters of 2 remote locations which are so far connected to each other over Internet only. I suggest you to remember asymmetric cryptography whenever you see “Internet” word involved in a communication.
Before any IPSec operation configured, decision about which protocol and mode for IPSec should be made and respected at both sides. Configuration steps should be followed according to this decision.
Our remote sites, having no secure way to exchange keys periodically, look for a solution to establish a communication through which they can send and receive information in a secure manner.
IPSec establishes a 2 phase method to solve that problem.
IPSec Phase 1 sets a primary communication channel between the peers for their internal communications and the most important of all, for the exchange of secret keys, which are going to be used for faster encryption in Phase 2.
IPSec Phase 2 is actually the phase where communications between endpoints in remote locations are sent securely.
IPSec Phase 1 uses asymmetric cryptography and should pay attention to:
Hashing : Needed for integrity check. Uses MD5 or SHA-1
Authentication : Needed for the authentication of peers. Pre-shared keys or Certificates can be used.
Group : Group represents the Diffie-Hellman algorithm group to securely exchange secret keys over Internet.
Lifetime : Lifetime represents how long the secret keys, established at the end of Phase 1 will be valid. At the end of lifetime, new secret keys should be exchanged for Phase 1.
Encryption : Encryption method for secret keys should be defined. These should be symmetric algorithms such as 3DES or AES.
When these parameters are correctly set at both ends of an IPSec connection, negotiation for IPSec Phase 1 can start. IPSec Phase 2 negotiations can start only after Phase 1 negotiations are successfully completed and secret keys are exchanged.
During Phase 2 of IPSec, a number of parameters should be set in order to allow data communications for both ends to start. These parameters should be listed as:
Encryption : Encryption algorithm for Phase 2. (Can be different from Phase 1, this algorithm will encrypt the actual data.)
Hashing : Hashing algorithm for Phase 2. (Also can be different from Phase 1.)
Lifetime : Validity period of keys used in Phase 2.
Group : If different keys from those who were obtained during Phase 1 are planned to be used, Diffie-Hellman algorithm should be chosen to re-exchange keys.
Once Phase 2 negotiation is finished and unidirectional Security Associations (SAs) are established, secure data communications between gateways or endpoint can finally start.
I am perfectly aware that this explanation document is not as clear as an RFC document but I still think that it can be help you understand the basics of IPSec VPNs faster.
Please feel free to share your views on any points on this article.
No comments:
Post a Comment