Secure IP

From Hill2dot0
Jump to: navigation, search

In the VPN environment, most of the tunneling protocols use UDP or TCP as the delivery protocol and a Data Link protocol as the payload protocol. Secure IP (IPSec) is considered a Network Layer tunneling protocol, in the sense that IP is both the payload protocol and the delivery protocol. IPSec is a security architecture described in RFC 2401 through RFC 2412, a few of which are listed below.

RFC 2401 Security Architecture for the Internet Protocol
RFC 2402 IP Authentication Header (AH)
RFC 2406 IP Encapsulation Security Payload (ESP)
RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409 The Internet Key Exchange (IKE)
RFC 2411 IP Security Document Roadmap

IPSec can employ two security protocols, IP AH and/or IP Encapsulation Security Payload (ESP). If data integrity and origin authentication are the only security features required, only IP AH is used. If in addition encryption is required, only IP ESP is used. The data integrity and origin authentication provided by AH is more thorough than that provided by ESP, so a combination of the two protocols can also be used. In this case the authentication header AH would be followed by the ESP header.

The IP AH contains authentication information about the payload data. An authentication algorithm, such as the hash function MD5, verifies the data integrity within the packet, and also the sender’s identity. The packet recipient calculates the algorithm and verifies the information.

The IP ESP header provides confidentiality via encryption of the payload. ESP supports the use of DES and triple DES. A key component of the IPSec architecture is the concept of a security association (SA). An SA is a one-way agreement that defines the security parameters/options between two entities. For two devices to use IPSec, two associations are required. An association must exist prior to the use of either security protocol, AH and/or ESP. Associations can be manually created or created via another IPSec protocol, ISAKMP.

Lastly, protocols within IPSec architecture depend on the use of keys. How are these keys distributed? How are they managed? In brief, it’s either done manually, which is fine for small environments, or automatically via another IPSec protocol—IKE—that provides the needed scalability.

IPSec Environment

IPSec Environment

The visual depicts two environments where IPSec might be used, gateway-to-gateway and host-to-host. A third environment, host-to-gateway, might be found but is not shown. Although the first two environments are shown together, they do not have to be deployed together.

One environment is for a company to use the gateway-to-gateway model and secure specific IP traffic, or traffic from a particular source address or range of source addresses. This is called the tunnel mode because a second IP header, denoted IP2, is added to the packet. This second IP header contains the source and destination address of the tunneling endpoints. The original IP header, IP1, is inside the data portion of the packet. A few of the tasks the gateway performs are as follows: when it receives the traffic of interest, a new IP header is added to the packet; a previously defined encryption algorithm is run to encrypt the data and the ESP header is added; then a previously defined authentication algorithm authenticates the data and the authentication header is added. An advantage of the gateway-to-gateway tunnel mode is that the operation is transparent to the actual source and destination hosts; no new software is required on the hosts. A disadvantage is the traffic between the host and the gateway is not secure. The traffic over the Internet is secure, authenticated, and encrypted, though.

A second environment is the host-to-host model. Here, upper-layer traffic is secured end-to-end at the expense of adding software to the end stations. If only a few hosts require the IP security this is a manageable task but as the number of hosts increases this becomes a time consuming task. In the host-to-host model the tunnel mode or the transport mode can be used. In the transport mode a new header is not required because the security endpoints are in the source and destination host. (A handy way to remember which mode does what is to think of the transport mode as protecting Transport Layer, and higher, traffic. These layers exist only at the endpoint hosts.)

A third environment, not shown on the visual, would be a combination of the first two. A source host might establish a secure tunnel to a gateway because the destination host might not have the software required to support IPSec.

IPSec Authentication Header


The Authentication Header (AH) enables authentication to a datagram. The data being authenticated are portions of the IP headers, the portions which do not change in transit, and the layers above IP (e.g., TCP/SMTP or UDP/SNMP). In this context, authentication is defined as providing data integrity: making sure the datagram did not change during transit (i.e., it wasn’t modified in any way)—and providing origin authentication (i.e., assuring it was sent from the address noted as the source to prevent source address spoofing). AH also provides an optional anti-replay service to help counter denial of service (DoS) attacks.

Authentication algorithms are agreed upon during security association establishment, an agreement of options between the source and destination entities. For example, authentication algorithms today include one-way hash functions, such as MD5 or SHA-1, and keyed authentication codes based on symmetric encryption such as DES. The source and destination entities are required to use the same authentication algorithm.

AH can be employed in one of two ways. One way called transport mode is used to secure host-to-host (i.e., end-to-end) communication. In this case the source and destination hosts are IPSec aware and will insert the AH header between the IP Layer and the next higher layer (e.g., ICMP, TCP, UDP). The second way is called tunnel mode. Tunnel mode can be employed in either a host or a security gateway (e.g., router, firewall, access server). As shown in the visual, IP1 carries the ultimate source and destination address, and IP2 carries the tunneling source and destination addresses. In tunnel mode the entire IP2 header is authenticated versus just portions of it in transport mode. The IPv4 or IPv6 header preceding the AH will contain the value 51 in the protocol (i.e., next header) field.

The AH can be applied alone or in combination with the IP ESP. When used with ESP, both authentication and encryption security services are realized.

A few of the Authentication Header fields are noted and defined below.

  • Security Parameter Index (SPI): This 32 bit value along with the destination IP address and security protocol type field (AH) identify the security association for this packet. The value is typically selected by the destination host during the security association establishments. In the destination host the value will be used to look up the security association for this packet. It’s a pointer into a security database.
  • Sequence Number: This field is used to help counter DoS attacks. The number is set to zero when the source and destination first establish the security association.
  • Authentication Data (Integrity Check Value): This field contains the Integrity Check Value (ICV), which is the results of the authentication algorithm employed. The actual algorithm employed is determined when the security association is established. When the destination station produces the same ICV as indicated in the AH, the data is authentic.

IPSec Pass Through

IPSec Pass Through

In common SOHO networks that access a VPN through a cable or DSL connection, placing the IPSec device “after” the NAT device typically isn’t possible, since the client PC initiates the IPSec tunnel and the low-end router performs NAT. (This technology only works with the IPSec using ESP in tunnel mode. AH protects part of the header, and changes to the header (e.g., source IP address) will result in an invalid checksum on the remote side of the connection.) A limited solution called IPSec pass through allows IPSec to operate in this configuration. The two primary methods of IPSec pass through, both of which rely on common NAT technology, are described below.

The first, simpler method allows only one IPSec tunnel through the router/NAT device at any time. Identified by ports 50 and 51, all IPSec traffic is forwarded back to the first machine that created an IPSec connection. Most low end consumer routers (e.g., Linksys and D-Link) support this functionality. For the home network with one “business” PC with VPN software and a number of “family” PCs without, this is an inexpensive, if not robust, solution.

The second method is more complex. To connect multiple PCs using IPSec, a tunneled packet must contain an identifier that enables the NAT router to identify the client PCs. Normally, NAT uses the TCP or UDP port number for this purpose, but since the port number is not available, it can use the unique security parameters index (SPI), part of the IPSec ESP or AH. While more complicated, this solution is found in consumer devices costing as little as $150. One flaw with the SPI association is that only outbound connections can be initiated, because the NAT device captures the return SPI when it detects initiation of an IPSec connection. Unless static port forwarding to a single device is used on the NAT/router, any IPSec connection the router receives will not be forwarded. While an important technical consideration, most home users will not host servers that require IPSec negotiations.