IPsec is an extension of the Internet Protocol (IP) to secure network communication through cryptography. Its primary goals are data confidentiality, data integrity, and host authentication. The combination of integrity and authentication provides non-repudiation. IPsec also detects replay attacks.
It is a modification of the IP implementation within the TCP/IP protocol suite, and so it means a modification to the kernel of modern operating systems.
Table of Contents
The following attempts to be a "just enough" explanation. If you want all the details, see the official documents:
How do you pronounce its name? I've heard all of these:
IPsec provides network communication security between hosts. User issues like authenticating a human as some user, restricting access to data by users, and so on, are outside the scope of IPsec. Those important security tasks are left to the operating systems run on the hosts.
Two hosts interested in securely communicating with each other (and pardon the anthropomorphism, but it makes this story much easier to tell and understand) must establish a Security Association (SA) with each other. The details can be tremendously complicated, but the SA comes down to the following. See my "Just Enough Crypto" page for explanations of ciphers, hashes, and HMACs:
The SA is negotiated by the Internet Key Exchange (IKE) protocol. There is a quick burst of IKE traffic before two hosts start communicating with IPsec. IKE simplifies to these major steps:
The SA information is then passed to the IPsec module of the kernel.
Once the SA has been established, IKE is used from time to time to negotiate new session keys. You want to use a key only for a limited time and amount of data. IKE can quickly re-run Diffie-Hellman to agree on new keys. Any delay caused by periodic re-keying will tend to disappear into the background noise of routine network latency jitter.
Once the kernel has an SA for another host, it will enforce its use. Every packet sent to that host will be modified according to the SA. Every packet apparently from that host will be dropped if it cannot be handled according to the SA. That means that if one host of an IPsec pair suddenly quit using IPsec and simply sent IP datagrams, the other host would drop all those apparently bogus datagrams.
Authentication Header is an IPsec extension to IP to provide data integrity, source host authentication, and protection against replay attacks.
Encapsulating Security Payload is an IPsec extension to IP to provide data confidentiality, data integrity, source host authentication, and protection against replay attacks.
Authentication Header inserts an extension to the original IP header. The AH header includes the Security Parameters Index (SPI), which is effectively an index number indicating which SA is used. It also includes the integrity check value (ICV), basically a hashed message authentication code of the payload, the non-changing IP header fields, and appropriate key.
I have no idea why the term is Encapsulating Security Payload when Encrypting Security Payload would better emphasize the main point....
ESP inserts an extension to the original IP header, and adds an authentication block to the end of the datagram. The ESP header includes the Security Parameters Index (SPI), which is effectively an index number indicating which SA is used. It also includes a sequence number, a number that should increase with each IPsec datagram sent. This allows a system to recognize and ignore duplicate received IPsec datagrams.
A "Next header" field is added to the end of the encrypted payload, along with padding to make the datagram an integer multiple of 32 bits. Then a final authentication data block contains the ICV, an HMAC of the payload, the non-changing IP header fields, and appropriate key.
Transport Mode encrypts only the payload, the IP header itself is left alone (beyond changing the Protocol Type field to 50 for ESP). The source and destination IP addresses are the actual endpoints. Transport Mode is used for host-to-host communications. The data contents are protected, but anyone observing network traffic can see traffic flow patterns.
Tunnel Mode is used to encrypt the entire original IP datagram, both payload and original header, and then encapsulate that inside a new IP header. You create a Virtual Private Network (VPN) between two remote sites by doing Tunnel Mode IPsec at the gateways. Let's think about sending a packet from site #1 to site #2. Sites #1 and #2 each have correspondingly numbered gateways connecting them to the Internet.
The original datagram's IP header has the IP addresses of the endpoints. That entire datagram is encrypted at the site #1 gateway, and encapsulated inside a header routing it from gateway #1 to gateway #2. When it gets there, gateway #2 decrypts its payload according to the SA specified by the SPI in the header. The result is an IP datagram which is identical to the one that disappeared into the encryption back at the other site. That cleartext datagram is routed onto the networks within site #2.
Packets moving the opposite direction are encrypted on gateway #2, encapsulated inside a GW2-to-GW1 IP header and routed to gateway #1. It is decrypted there, and the resulting cleartext datagram is routed onto the internal site #1 networks.
If GW1 and GW2 do not not have an SA established, they set one up via IKE when the first packet bound for the other site reaches one of the gateways.
If the end-point hosts shared an SA, the payload of the datagrams crossing the internal networks of the two sites would be ciphertext. There's certainly no harm in encrypting data that happens to already be ciphertext. And this would provide defense in depth and protect against hostile insiders at both sites.
Do these steps on the CA host:
Assuming that you have generated and distributed certificates as shown above, and you want to turn on IPsec between the two hosts 192.168.0.1 and 10.1.2.3:
Create a policy in /etc/setkey.conf
on each host:
Put the following in /etc/setkey.conf
on host 192.168.0.1:
# Out our 192.168.0.0/24 connection to 10.1.2.3: spdadd 192.168.0.0/24 10.1.2.3/32 any -P out ipsec esp/transport//require ah/transport//require; # In from 10.1.2.3 on our 192.168.0.0/24 connection: spdadd 10.1.2.3/32 192.168.0.0.0/24 any -P in ipsec esp/transport//require ah/transport//require;
Then put the converse in /etc/setkey.conf on host 10.1.2.3:
# Out our 10.1.2.0/24 connection to 192.168.0.1: spdadd 10.1.2.0/24 192.168.0.1/32 any -P out ipsec esp/transport//require ah/transport//require; # In from 192.168.0.1 on our 10.1.2.0/24 connection: spdadd 192.168.0.1/32 10.1.2.0/24 any -P in ipsec esp/transport//require ah/transport//require;
Configure the racoon daemon to run IKE
on each host:
Modify /etc/raccoon/racoon.conf to include
two stanzas like this, replacing thishostname
with the local host name in each case:
sainfo anonymous
{
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael, aes ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
remote anonymous
{
exchange_mode main;
doi ipsec_doi;
situation identity_only;
my_identifier asn1dn;
# Change these host names to match yours!
certificate_type x509 "thishostname_cert.pem" "thishostname_key.pem";
verify_cert off;
nonce_size 16;
initial_contact on;
proposal_check obey; # obey, strict, or claim
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 2;
}
}
Start racoon and configure it to start after
each boot:
# /etc/init.d/racoon start # chkconfig racoon on
Many people very reasonably say that it makes no sense to arrange a method for whispering secrets to strangers. Data encryption implies data sensitivity, and so you should only send sensitive data to a host of known identity. Well, sure, but....
There is an interesting thing called opportunistic encryption. This is an attempt to establish encrypted communication with any host before falling back to plaintext communication if needed. This means you can routinely encrypt some of your network traffic without setting up any Security Associations, just by asking your operating system to attempt opportunistic encryption and then communicating with other hosts supporting the same thing.
I have taught networking and information security to people from various U.S. Government Three-Letter Agencies. The topic of opportunistic encryption takes them through these stages:
Yes, this would allow the opportunistic encryption subset of Internet users to communicate with each other while frustrating attempts to routinely eavesdrop on them. See the Wikipedia page for pointers to the details for doing this on Linux and routers with Openswan and other FreeS/WAN derivatives, on Windows, to protect e-mail and VoIP, and more.
|
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell Feb 2012. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |
