- Unison Kernel
- Pthread Cancellation
- Message Queues
- Conditional Variables
- Memory Allocation
- Directory Services
- Unison I/O Library
- Unison STDIO Library
- STDIO Library Calls
- Do-nothing Stubs
- STDIO Library Calls
- Unison LIBC Library
- Unison I/O Servers
- Graphics, Camera, Video, Audio
- Network Protocols
- TCP and UDP Server - tcpd
- DHCP Client Service - dhcp client
- DHCP Server - dhcpd
- Telnet Server - telnetd
- Tiny FTP Server - tftpd
- Point to Point - pppd
- Network Translation - NAT with PAT
- Tiny HTTP Server - thttpd
- Tiny HTTP Server with TLS
- POP3 Server
- Simple Mail Transfer Protocol Services (SMTP)
- Bootp Protocol
- File Transfer Protocol Server (FTP)
- File Transfer Client Services
- RPC / XDR
- DNS Client
- HTTP/HTTPS Client
- REST Client
- AutoIP Service - autoip client
- mDNS server - mdnsd
- SNTP Client
- SNMP Agent - Snmpd server
- SSL/TLS library
- SSH server
- IP security
- Power Control
- Serial I/O
- System Services
- Universal Serial Bus (USB)
- Remedy Tools for Unison
IPsec – IP Security Protocol
IPsec may be enabled or disabled using the following external variables:
extern int esp_enable; – Enable the ESP IPsec protocol
extern int ah_enable; – Enable the AH IPsec protocol
By default, both protocols are disabled.
IPsec is a pair of protocols, ESP (for Encapsulating Security Payload) and AH (for Authentication Header), which provide security services for IP datagrams.
The internet protocol (IP) does not inherently provide any protection to your transferred data. It does not even guarantee that the sender is who he says he is. IPsec tries to remedy this. There are several kinds of properties you might want to add to your communication, the most common are:
- Make sure it is hard for anyone but the receiver to understand what data has been communicated. You do not want anyone to see your passwords when logging into a remote machine over the Internet.
- Guarantee that the data does not get changed on the way. If you are on a line carrying invoicing data you probably want to know that the amounts and account numbers are correct and not altered while in-transit.
- Sign your data so that others can see that it is really you that sent it. It is clearly nice to know that documents are not forged.
- Replay protection
- We need ways to ensure a transaction can only be carried out once unless we are authorized to repeat it. I.e. it should not be possible for someone to record a transaction, and then replaying it verbatim, in order to get an effect of multiple transactions being received by the peer. Consider the attacker has got to know what the traffic is all about by other means than cracking the encryption, and that the traffic causes events favourable for him, like depositing money into his account. We need to make sure he cannot just replay that traffic later. WARNING: as per the standards specification, replay protection is not performed when using manual-keyed IPsec (e.g., when using ipsecadm).
IPsec can provide all of these properties, in two new protocols, called Authentication header (AH) and Encapsulated security payload (ESP).
ESP can provide authentication, integrity, replay protection, and confidentiality of the data (it secures everything in the packet that follows the IP header). Replay protection requires authentication and integrity (these two go always together). Confidentiality (encryption) can be used with or without authentication/integrity. Similarly, one could use authentication/integrity with or without confidentiality.
AH provides authentication, integrity, and replay protection (but not confidentiality). Its main difference with ESP is that AH also secures parts of the IP header of the packet (like the source/destination addresses).
Authentication Header (AH)
AH works by doing a computation of a value depending on all of the payload data, some of the IP header data and a certain secret value, the authentication key and sending this value along with the rest of each packet. The receiver will do the same computation, and if the value matches, he knows no one tampered with the data (integrity), the address information (authenticity) or a sequence number (replay protection). He knows this because the secret authentication key makes sure no man in the middle can recompute the correct value after altering the packet. The algorithms used for the computations are called hash algorithms and is a parameter in the SA, just like the authentication key.
Encapsulating Security Payload (ESP)
ESP optionally does almost everything that AH does except that it does not protect the outer IP header but furthermore it encrypts the payload data with an encryption algorithm using a secret encryption key. Only the ones knowing this key can decrypt the data, thus providing confidentiality. Both the algorithm and the encryption key are parameters of the SA.
Security Associations (SAs)
These protocols need some parameters for each connection, telling exactly how the wanted protection will be added. These parameters are collected in an entity called a security association, or SA for short. Typical parameters are: encryption algorithm, hash algorithm, encryption key, authentication key etc. When two peers have setup matching SAs at both ends, packets protected with one end’s SA, will be possible to verify and/or decrypt using the other end’s SA. The only problem left is to see that both ends have matching SAa, which can be done manually, or automatically with a key management daemon.
Unison supports only manual SA establishment which is described in ipsecadm.
Security Parameter Indexes (SPIs)
In order to identify a SA we need to have a unique name for it. This name is a triplet, consisting of the destination address, security parameter index (aka SPI) and the security protocol. Since the destination address is part of the name, a SA is a unidirectional construct. For a bidirectional communication channel, two SAs are needed, one outgoing and one incoming, where the destination address is our local IP address. The SPI is just a number that helps us making the name unique, it can be arbitrarily chosen in the range 0x100 – 0xffffffff. The security protocol number should be 50 for ESP and 51 for AH, as these are the protocol numbers assigned by IANA.
Modes of Operation
IPsec can operate in two modes, either tunnel or transport mode. In transport mode the ordinary IP header is used to deliver the packets to their endpoint, in tunnel mode the ordinary IP header just tells us the address of a security gateway, knowing how to verify/decrypt the payload and forward the packet to a destination given by another IP header contained in the protected payload. Tunnel mode can be used for establishing VPNs, virtual private networks, where parts of the networks can be spread out over an unsafe public network, but security gateways at each subnet are responsible for encrypting and decrypting the data passing over the public net. A SA will hold information telling if it is a tunnel or transport mode SA, and for tunnels, it will contain values to fill in into the outer IP header.
To better illustrate how IPsec works, consider a typical TCP packet:
[IP header] [TCP header] [data...]
If we apply ESP in transport mode to the above packet, we will get:
[IP header] [ESP header] [TCP header] [data...]
where everything after the ESP header is protected by whatever services of ESP we are using (authentication/integrity, replay protection, confidentiality). This means the IP header itself is not protected.
If we apply ESP in tunnel mode to the original packet, we would get:
[IP header] [ESP header] [IP header] [TCP header] [data...]
where, again, everything after the ESP header is cryptographically protected. Notice the insertion of an IP header between the ESP and TCP header. This mode of operation allows us to hide who the true source and destination addresses of a packet are (since the protected and the unprotected IP headers don’t have to be exactly the same). A typical application of this is in Virtual Private Networks (or VPNs), where two firewalls use IPsec to secure the traffic of all the hosts behind them. For example:
Net A <----> Firewall 1 <--- Internet ---> Firewall 2 <----> Net B
Firewall 1 and Firewall 2 can protect all communications between Net A and Net B by using IPsec in tunnel mode, as illustrated above.
Security Associations need be set up manually with the ipsecadm library.
- Specifies the use of authentication for packets ent or received by the socket.
- Specifies the use of encryption in transport mode for packets sent or received by the socket.
- Specifies the use of encryption in tunnel mode.
For each of the categories there are five possible levels which specify the security policy to use in that category:
- Bypass the default system security policy.
- If a Security Association is available it will be used for sending packets by that socket.
- Use IP Security for sending packets but still accept packets which are not secured.
- Use IP Security for sending packets and also require IP Security for received data.
- The outbound Security Association will only be used by this socket.
When a new socket is created, it is assigned the default system security level in each category. These levels can be queried with getsockopt().
For example, a server process might want to accept only authenticated connections to prevent session hijacking. It would issue the following setsockopt() call:
int level = IPSEC_LEVEL_REQUIRE; error = setsockopt(s, IPPROTO_IP, IP_AUTH_LEVEL, &level, sizeof(int));
The system does guarantee that it will succeed at establishing the required security associations.
There is a demo available for the Unison and DSPnano IPsec which is found in installdir/demos.