The IPSEC protocols in Linux
This section provides details of the IPSEC protocols which FreeS/WAN implements
The basic idea of IPSEC is to provide security functions, authentication and encryption , at the IP (Internet Protocol) level. This requires a higher-level protocol (IKE) to set things up for the IP-level services (ESP and AH).
Three protocols are used in an IPSEC implementation:
ESP, Encapsulating Security Payload
Encrypts and/or authenticates data
AH, Authentication Header
Provides a packet authentication service
IKE, Internet Key Exchange
Negotiates connection parameters, including keys, for the other two
The term "IPSEC" is slightly ambiguous. In some contexts, it includes all three of the above but in other contexts it refers only to AH and ESP.
Applying IPSEC
Authentication and encryption functions for network data can, of course, be provided at other levels. Many security protocols work at levels above IP.
PGP encrypts and authenticates mail messages
SSH authenticates remote logins and then encrypts the session
SSL or TLS provides security at the sockets layer, e.g. for secure web browsing
and so on. Other techniques work at levels below IP. For example, data on a communications circuit or an entire network can be encrypted by specialised hardware. This is common practice in high-security applications.
Advantages of IPSEC
There are, however, advantages to doing it at the IP level instead of, or as well as, at other levels.
IPSEC is the most general way to provide these services for the Internet.
Higher-level services protect a single protocol; for example PGP protects mail.
Lower level services protect a single medium; for example a pair of encryption boxes on the ends of a line make wiretaps on that line useless unless the attacker is capable of breaking the encryption.
IPSEC, however, can protect any protocol running above IP and any medium which IP runs over. More to the point, it can protect a mixture of application protocols running over a complex combination of media. This is the normal situation for Internet communication; IPSEC is the only general solution.
IPSEC can also provide some security services "in the background", with no visible impact on users. To use PGP encryption and signatures on mail, for example, the user must at least:
remember his or her passphrase,
keep it secure
follow procedures to validate correspondents keys
These systems can be designed so that the burden on users is not onerous, but any system will place some requirements on users. No such system can hope to be secure if users are sloppy about meeting those requirements. The author has seen username and password stuck on terminals with post-it notes in an allegedly secure environment, for example.
Limitations of IPSEC
IPSEC is designed to secure IP links between machines. It does that well, but it is important to remember that there are many things it does not do. Some of the important limitations are:
IPSEC cannot be secure if your system isnt
System security on IPSEC gateway machines is an essential requirement if IPSEC is to function as designed. No system can be trusted if the underlying machine has been subverted. See books on Unix security such as Garfinkel and Spafford or our web references for Linux security or more general computer security.
Of course, there is another side to this. IPSEC can be a powerful tool for improving system and network security. For example, requiring packet authentication makes various spoofing attacks harder and IPSEC tunnels can be extremely useful for secure remote administration of various things.
IPSEC is not end-to-end
IPSEC cannot provide the same end-to-end security as systems working at higher levels. IPSEC encrypts an IP connection between two machines, which is quite a different thing than encrypting messages between users or between applications.
For example, if you need mail encrypted from the senders desktop to the recipients desktop and decryptable only by the recipient, use PGP or another such system. IPSEC can encrypt any or all of the links involved -- between the two mail servers, or between either server and its clients. It could even be used to secure a direct IP link from the senders desktop machine to the recipients, cutting out any sort of network snoop. What it cannot ensure is end-to-end user-to-user security. If only IPSEC is used to secure mail, then anyone with appropriate privileges on any machine where that mail is stored (at either end or on any store-and-forward servers in the path) can read it.
In another common setup, IPSEC encrypts packets at a security gateway machine as they leave the senders site and decrypts them on arrival at the gateway to the recipients site. This does not even come close to providing an end-to-end service. In particular, anyone with appropriate privileges on either sites LAN can intercept the message in unencrypted form.
IPSEC cannot do everything
IPSEC also cannot provide all the functions of systems working at higher levels of the protocol stack. If you need a document electronically signed by a particular person, then you need his or her digital signature and a public key cryptosystem to verify it with.
Note, however, that IPSEC authentication of the underlying communication can make various attacks on higher-level protocols more difficult. In particular, authentication prevents man-in-the-middle attacks.
IPSEC authenticates machines, not users
IPSEC uses strong authentication mechanisms to control which messages go to which machines, but it does not have the concept of user ID, which is vital to many other security mechansims and policies. This means some care must be taken in fitting the various security mechansims on a network together. For example, if you need to control which users access your database server, you need some non-IPSEC mechansim for that. IPSEC can control which machines connect to the server, and can ensure that data transfer to those machines is done securely, but that is all. Either the machines themselves must control user access or there must be some form of user authentication to the database, independent of IPSEC.
IPSEC does not stop denial of service attacks
Denial of service attacks aim at causing a system to crash, overload, or become confused so that legitimate users cannot get whatever services the system is supposed to provide. These are quite different from attacks in which the attacker seeks either to use the service himself or to subvert the service into delivering incorrect results.
IPSEC shifts the ground for DoS attacks; the attacks possible against systems using IPSEC are different than those that might be used against other systems. It does not, however, eliminate the possibility of such attacks.
IPSEC does not stop traffic analysis
Traffic analysis is the attempt to derive intelligence from messages without regard for their contents. In the case of IPSEC, it would mean analysis based on things visible in the unencrypted headers of encrypted packets -- source and destination gateway addresses, packet size, et cetera. Given the resources to acquire such data and some skill in analysing it (both of which any national intelligence agency should have), this can be a very powerful technique.
IPSEC is not designed to defend against this. Partial defenses are certainly possible, and some are described below, but it is not clear that any complete defense can be provided.
