TechNet網路協定: IPSec VPN

摘自: http://www.ipsec-howto.org/x202.html,  https://technet.microsoft.com/library/bb878090

https://technet.microsoft.com/en-us/library/cc959510.aspx

H3C IPSec : http://www.h3c.com/cn/Service/Document_Center/Routers/Catalog/ER/ER3100/Configure/Typical_Configuration_Example/H3C_SMB_Router_IPSec_VPN_CG(V1.02)/

What is IPsec?

IPsec is an extension to the IP protocol which provides security to the IP and the upper-layer protocols. It was first developed for the new IPv6 standard and then “backported” to IPv4. The IPsec architecture is described in the RFC2401. The following few paragraphs will give you a short introduction into IPsec.
    IPsec uses two different protocols - AH and ESP - to ensure the authentication, integrity and confidentiality of the communication. It can protect either the entire IP datagram or only the upper-layer protocols. The appropiate modes are called tunnel mode and transport mode. In tunnel mode the IP datagram is fully encapsulated by a new IP datagram using the IPsec protocol. In transport mode only the payload of the IP datagram is handled by the IPsec protocol inserting the IPsec header between the IP header and the upper-layer protocol header (see Figure 1).

Figure 1. IPsec tunnel and transport mode

To protect the integrity of the IP datagrams the IPsec protocols use hash message authentication codes (HMAC). To derive this HMAC the IPsec protocols use hash algorithms like MD5 and SHA to calculate a hash based on a secret key and the contents of the IP datagram. This HMAC is then included in the IPsec protocol header and the receiver of the packet can check the HMAC if it has access to the secret key.
To protect the confidentiality of the IP datagrams the IPsec protocols use standard symmetric encryption algorithms. The IPsec standard requires the implementation of NULL and DES. Today usually stronger algorithms are used like 3DES, AES and Blowfish.
To protect against denial of service attacks the IPsec protocols use a sliding window. Each packet gets assigned a sequence number and is only accepted if the packet's number is within the window or newer. Older packets are immediately discarded. This protects against replay attacks where the attacker records the original packets and replays them later.
For the peers to be able to encapsulate and decapsulate the IPsec packets they need a way to store the secret keys, algorithms and IP addresses involved in the communication. All these parameters needed for the protection of the IP datagrams are stored in a security association (SA). The security associations are in turn stored in a security association database (SAD).
Each security association defines the following parameters:

• Source and destination IP address of the resulting IPsec header. These are the IP addresses of the IPsec peers protecting the packets.
• IPsec protocol (AH or ESP), sometimes compression (IPCOMP) is supported, too.
• The algorithm and secret key used by the IPsec protocol.
• Security Parameter Index (SPI). This is a 32 bit number which identifies the security association.

Some implementations of the security association database allow further parameters to be stored:

• IPsec mode (tunnel or transport)
• Size of the sliding window to protect against replay attacks.
• Lifetime of the security association.

Since the security association defines the source and destination IP addresses, it can only protect one direction of the traffic in a full duplex IPsec communication. To protect both directions IPsec requires two unidirectional security associations.
The security assocations only specify how IPsec is supposed to protect the traffic. Additional information is needed to define which traffic to protect when. This information is stored in the security policy (SP) which in turn is stored in the security policy database (SPD).
A security policy usually specifies the following parameters:

• Source and destination address of the packets to be protected. In transport mode these are the same addresses as in the SA. In tunnel mode theymay differ!
• The protocol (and port) to protect. Some IPsec implementations do not allow the definition of specific protocols to protect. In this case all traffic between the mentioned IP addresses is protected.
• The security association to use for the protection of the packets.

The manual setup of the security association is quite error prone and not very secure. The secret keys and encryption algorithms must be shared between all peers in the virtual private network. Especially the exchange of the keys poses critical problems for the system administrator: How to exchange secret symmetric keys when no encryption is yet in place?
To solve this problem the internet key exchange protocol (IKE) was developed. This protocol authenticates the peers in the first phase. In the second phase the security associations are negotiated and the secret symmetric keys are chosen using a Diffie Hellmann key exchange. The IKE protocol then even takes care of periodically rekeying the secret keys to ensure their confidentiality.

IPsec Protocols

The IPsec protocol family consists of two protocols: Authentication Header (AH) and Encapsulated Security Payload (ESP). Both are independent IP protocols. AH is the IP protocol 51 and ESP is the IP protocol 50 (see /etc/protocols). The following two sections will briefly cover their properties.

AH - Authentication Header

The AH protocol protects the integrity of the IP datagram. To achieve this, the AH protocol calculates a HMAC to protect the integrity. When calculating the HMAC the AH protocol bases it on the secret key, the payload of the packet and the immutable parts of the IP header like the IP addresses. It then adds the AH header to the packet. The AH header is shown in Figure 2.

Figure 2. The AH Header protect the integrity of the packet

The AH header is 24 bytes long. The first byte is the Next Header field. This field specifies the protocol of the following header. In tunnel mode a complete IP datagram is encapsulated; therefore the value of this field is 4. When encapsulating a TCP datagram in transport mode the corresponding value is 6. The next byte specifies the length of the payload. This field is followed by two reserved bytes. The next double word specifies the 32 bit long Security Parameter Index (SPI). The SPI specifies the security association to use for the decapsulation of the packet. The 32 bit Sequence Number protects against replay attacks. Finally the 96 bit holds the hash message authentication code (HMAC). This HMAC protects the integrity of the packets since only the peers knowing the secret key can create and check the HMAC.
Since the AH protocol protects the IP datagram including immutable parts of the IP header like the IP addresses the AH protocol does not allow NAT. Network address translation (NAT) replaces an IP address in the IP header (usually the source IP) by a different IP address. After the exchange the HMAC is not valid anymore. The NAT-Traversal extension of the IPsec protocol implements ways around this restriction.

ESP - Encapsulated Security Payload

The ESP protocol can both ensure the integrity of the packet using a HMAC and the confidentiality using encryption. After encrypting the packet and calculating the HMAC the ESP header is generated and added to the packet. The ESP header consists of two parts and is shown in Figure 3.

Figure 3. The ESP header

The first doubleword in the ESP header specifies the Security Parameter Index (SPI). This SPI specifies the SA to use for the decapsulation of the ESP packet. The second doubleword holds the Sequence Number. This sequence number is used to protect against replay attacks. The third doubleword specifies the Initialization Vector (IV) which is used in the encryption process. Symmetric encryption algorithms are susceptible to a frequency attack if no IV is used. The IV ensures that two identical payloads lead to different encrypted payloads.
IPsec uses block ciphers for the encryption process. Therefore the payload may need to be padded if the length of the payload is not a multiple of the block length. The length of the pad is then added. Following the pad length the 2 byte long Next Header field specifies the next header. Lastly the 96 bit long HMAC is added to the ESP header ensuring the integrity of the packet. This HMAC only takes the payload of the packet into account. The IP header is not include in the calculation process.
The usage of NAT therefore does not break the ESP protocol. Still in most cases NAT is not possible in combination with IPsec. The NAT-Traversal offers a solution in this case by encapsulating the ESP packets within UDP packets.

IKE Protocol

The IKE protocol solves the most prominent problem in the setup of secure communication: the authentication of the peers and the exchange of the symmetric keys. It then creates the security associations and populates the SAD. The IKE protocol usually requires a user space daemon and is not implemented in the operating system. The IKE protocol uses 500/udp for it's communication.
The IKE protocol functions in two phases. The first phase establishes a Internet Security Association Key Management Security Association (ISAKMP SA). In the second phase the ISAKMP SA is used to negotiate and setup the IPsec SAs.
The authentication of the peers in the first phase can usually be based on pre-shared keys (PSK), RSA keys and X.509 certificates (racoon even supports Kerberos).
The first phase usually supports two different modes: main mode and aggressive mode. Both modes authenticate the peer and setup an ISAKMP SA, but the aggressive mode uses only half the number of messages to achieve this goal. This does have its drawbacks though, because the aggressive mode does not support identity protection and is therefore susceptible to a man-in-the-middle attack if used in conjunction with pre-shared keys. On the other hand this is the only purpose of the aggressive mode. Because of the internal workings of the main mode it does not support the usage of different preshared keys with unknown peers. The aggressive mode does not support identity protection and transfers the identity of the client in the clear. The peers therefore know each other before the authentication takes place and different pre-shared keys can be used for different peers.
In the second phase the IKE protocol exchanges security association proposals and negotiates the security associations based on the ISAKMP SA. The ISAKMP SA provides the authentication to protect against a man-in-the-middle attack. This second phase uses the quick mode.
Usually two peers negotiate only one ISAKMP SA, which is then used to negotiate several (at least two) unidirectional IPsec SAs.

NAT-Traversal

What is NAT-Traversal and why is it needed?
Often one peer in the VPN is behind a NAT-device. I just assume Source-NAT devices here. Whenever I talk about NAT I mean Source-NAT or Masquerading. What does this mean concerning the VPN? Well, first of all the original IP address of the peer is hidden by the NAT-device. The NAT-device conceals the original source IP address and replaces it by its own IP address.
This make the IPsec AH protocol immediately unusable. But ESP can still be used if both sides are configured correctly.
So why do you need NAT-Traversal? Because as soon as two machines behind the same NAT device try to build a tunnel to the outside, both will fail.
Why is this happening? The NAT device needs to keep track of the "natted" connections to be able to "de-nat" the reply packets back to the original client. Therefore the NAT device maintains an internal table where all "natted" connections are stored. Lets assume one client connects to a webserver on the Internet. The NAT device conceils the original address by replacing it with its own address. It then makes a note in its internal table that all packets coming back on the chosen client port have to be send to the original client1. As soon as the second client starts a connection, it handles that connection identical. If the second client chose the same client port by coincidence the NAT device will also modify the client port for unambuigity. This works very well using TCP and UDP because those protocols provide ports. ESP does not use ports. Therefore the NAT device can only use the protocol distinguish the packets. When the first client connects it stores the information in the table that all ESP packets have to be "denatted" to the first client. When the second client connects it will overwrite this entry with the appropiate entry for the second one thus breaking at least the first connection.
What does NAT traversal do to help? NAT-traversal again encapsulates the ESP packets in UDP packets. These can easily be handled by a NAT device since they provide ports. By default port 4500/udp is used. NAT traversal is specified in several drafts. There are no RFCs at the moment. A nice feature of NAT traversal is the fact that once activated the peers automatically use it when needed

IPSec NAT Problem

https://technet.microsoft.com/library/bb878090

Historically, one of the issues with deploying Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPSec) is that IPSec peers cannot be located behind a Network Address Translator (NAT). Internet service providers and small office/home office (SOHO) networks commonly use NATs to share a single public IP address. Although NATs help conserve the remaining IP address space, they also introduce problems for end-to-end protocols such as IPSec.

A new technology known as IPSec NAT Traversal (NAT-T) is in the process of being standardized by the IPSec Working Group of the Internet Engineering Task Force (IETF). IPSec NAT-T is described in the Internet drafts titled "UDP Encapsulation of IPSec Packets" and "Negotiation of NAT-Traversal in the IKE". IPSec NAT-T defines both changes in the negotiation process and different methods of sending IPSec-protected data.

IPSec NAT-T-capable peers during the IPSec negotiation process automatically determine:

• Whether both the initiating IPSec peer (typically a client computer) and responding IPSec peer (typically a server) can perform IPSec NAT-T.
• If there are any NATs in the path between them.

If both of these conditions are true, the peers automatically use IPSec NAT-T to send IPSec-protected traffic across a NAT. If either peer does not support IPSec NAT-T, then normal IPSec negotiations (beyond the first two messages) and IPSec protection is performed. If both peers support IPSec NAT-T and there are no NATs between them, normal IPSec protection is performed.

IPSec NAT-T, as defined in version 2 of the "UDP Encapsulation of IPSec Packets" and "Negotiation of NAT-Traversal in the IKE" Internet drafts, is supported by Windows Server 2003, Windows XP with Service Pack 2, L2TP/IPSec NAT-T Update for Windows XP and Windows 2000 (a free download that provides IPSec NAT-T support for computers running Windows XP with Service Pack 1, Windows XP with no service packs installed, and Windows 2000), and Microsoft L2TP/IPSec VPN Client (a free download that enables computers running Windows 98, Windows Millennium Edition, and Windows NT 4.0 Workstation to create L2TP/IPSec connections).

This article examines the problems associated with using IPSec across NATs, how these problems are solved by IPSec NAT-T (based on version 2 of the IPSec NAT-T Internet drafts), and the resulting changes in the Internet Key Exchange (IKE) negotiation for Quick Mode and Main Mode negotiations.

Note   IPSec NAT-T is only defined for ESP traffic.

Problems Associated with using IPSec over NATs

The problems associated with using IPSec over NATs are the following:

• NATs cannot update upper-layer checksums.
  TCP and UDP headers contain a checksum that incorporates the values of the source and destination IP addresses and port numbers. When a NAT changes the IP address and/or port number of a packet, it normally updates the TCP or UDP checksum. When the TCP or UDP checksum is encrypted with ESP, it cannot be updated. Because the addresses or ports have been changed by the NAT, the checksum verification fails at the destination. Although UDP checksums are optional, TCP checksums are required.
• NATs cannot multiplex IPSec data streams.
  ESP-protected IPSec traffic does not contain a visible TCP or UDP header. The ESP header is between the IP header and the encrypted TCP or UDP header and uses the IP protocol of 50. Because of this, the TCP or UDP port numbers cannot be used to multiplex traffic to different private network hosts. The ESP header contains a field named the Security Parameters Index (SPI). The SPI is used, in conjunction with the destination IP address in the plaintext IP header and the IPSec security protocol (ESP or AH), to identify an IPSec security association (SA).
  For inbound traffic to the NAT, the destination IP address must be mapped to a private IP address. For multiple IPSec peers on the private side of a NAT, the destination IP address of inbound traffic for multiple IPSec ESP data streams is the same address. To distinguish one IPSec ESP data stream from another, the destination IP address and SPI must either be tracked or mapped to a private destination IP address and SPI.
  Because the SPI is a 32-bit number, the chance of using the same SPI value between multiple private network clients is low. The problem is that it is difficult to determine which outbound SPI value corresponds to which inbound SPI value.
  NATs cannot map the SPI, because the ESP trailer contains a hashed message authentication code (HMAC) that verifies the integrity of the ESP protocol data unit (PDU) (consisting of the ESP header, the ESP payload, and the ESP trailer), the SPI cannot be changed without invalidating the HMAC value.
• IKE UDP port number cannot be changed.
  Some implementations of IPSec use UDP port 500 as both the source and destination UDP port number. However, for an IPSec peer located behind a NAT, the NAT changes the source address of the initial IKE Main Mode packet. Depending on the implementation, IKE traffic from a port other than 500 might be discarded.
• NAT timeout of IKE UDP port mapping can cause problems.
  UDP mappings in NATs are often deleted very quickly. The initiator's IKE traffic creates a UDP port mapping in the NAT that is used for the duration of the initial Main Mode and Quick Mode IKE negotiations. However, if the responder later sends IKE messages to the initiator and the UDP port mapping is not present, it is discarded by the NAT. This can cause IPSec SAs to time out and be removed by the responder.
• Identification IKE payload contains embedded IP addresses.
  For the Main Mode and Quick Mode negotiations, each IPSec peer sends an Identification IKE payload that includes an embedded IP address for the sending peer. Because the source address of the sending node has been changed by a NAT, the embedded address does not match the IP address of the IKE packet. An IPSec peer that validates the IP address of the Identification IKE payload will discard the packet and abandon the IKE negotiation.

Overview of NAT-T Changes to IPSec

The following are the changes to IPSec for NAT-T:

• UDP encapsulation for ESP
  A UDP header is placed between the outer IP header and the ESP header, encapsulating the ESP PDU. The same ports that are used for IKE are used for UDP-encapsulated ESP traffic.
• A modified IKE header format
  The IPSec NAT-T IKE header contains a new Non-ESP Marker field that allows a recipient to distinguish between a UDP-encapsulated ESP PDU and an IKE message. IPSec NAT-T-capable peers begin to use the new IKE header after they have determined that there is an intermediate NAT.
• A new NAT-Keepalive packet
  A UDP message that uses the same ports as IKE traffic, contains a single byte (0xFF), and is used to refresh the UDP port mapping in a NAT for IKE and UDP-encapsulated ESP traffic to a private network host.
• A new Vendor ID IKE payload
  This new payload contains a well-known hash value, which indicates that the peer is capable of performing IPSec NAT-T.
• A new NAT-Discovery (NAT-D) IKE payload
  This new payload contains a hash value that incorporates an address and port number. An IPSec peer includes two NAT-Discovery payloads during Main Mode negotiationone for the destination address and port and one for the source address and port. The recipient uses the NAT-Discovery payloads to discover whether a NAT translated addresses or port numbers, and, based on which addresses and ports were changed, which peers are located behind NATs.
• New encapsulation modes for UDP-encapsulated ESP transport mode and tunnel mode
  These two new encapsulation modes are specified during Quick Mode negotiation to inform the IPSec peer that UDP encapsulation for ESP PDUs should be used.
• A new NAT-Original Address (NAT-OA) IKE payload
  This new payload contains the original (untranslated) address of the IPSec peer. For UDP-encapsulated ESP transport mode, each peer sends the NAT-OA IKE payload during Quick Mode negotiation. The recipient stores this address in the parameters for the SA.

IPSec NAT-T Solutions to the Problems of Using IPSec over NATs

IPSec NAT-T solves the problems of using IPSec across a NAT in the following ways:

• Problem: NATs cannot update upper-layer checksums.
  Solution: By sending the original address in the NAT-OA IKE payload, a recipient has all of the information it needs to verify the upper-layer checksum (source and destination IP addresses and ports) after it is decrypted.
• Problem: NATs cannot multiplex IPSec data streams.
  Solution: By encapsulating the ESP PDU with a UDP header, the NAT can use the UDP ports to multiplex the IPSec data streams. Tracking the SPI in the ESP header is no longer necessary.
• Problem: IKE UDP port number cannot be changed.
  Solution: IPSec NAT-T peers can accept IKE messages from a source port other than 500. Additionally, to prevent an IKE-aware NAT from modifying IKE packets, IPSec NAT-T peers change the IKE UDP port of 500 to the UDP port 4500 during Main Mode negotiation. To allow IKE traffic using this new UDP port, you might have to configure your firewalls to permit UDP port 4500.
• Problem: Identification IKE payload contains embedded IP addresses.
  Solution: By sending the original address in the NAT-OA IKE payload, a recipient has the original address with which to verify the contents of the Identification IKE payload during Quick Mode negotiation. Because the NAT-OA IKE payload is not sent until Quick Mode negotiation occurs, IPSec implementations that validate the IP address in the Identification IKE payload that is sent during Main Mode must either not perform this validation or validate the peer by using another mechanism, such as name verification.
• Problem: NAT timeout of IKE UDP port mapping can cause problems.
  Solution: By sending periodic NAT Keepalive packets, the UDP port mapping for both continued IKE negotiations and UDP-encapsulated ESP PDUs is refreshed in the NAT.

Example IKE Negotiation for Main Mode and Quick Mode SAs using IPSec NAT-T

The addition of the new NAT-D and NAT-OA payloads and UDP tunnel types modifies Main Mode and Quick Mode IKE negotiations. For example, the following table shows the use of the Vendor-ID and NAT-D IKE payloads during Quick Mode negotiation for a Windows-based IPSec peer using Kerberos authentication. The additional IKE payload and message changes for IPSec NAT-T are bolded.

Table 1   Main Mode messages for the Kerberos authentication method

Main Mode Message	Sender	Payloads
1	Initiator	Security Association (contains proposals), Vendor ID, Vendor ID (NAT-T capability)
2	Responder	Security Association (contains a selected proposal), Vendor ID, Vendor ID (NAT-T capability)
3	Initiator	Key Exchange (contains Diffie-Hellman public key), Nonce, Kerberos Token (initiator), NAT-D (Destination address and port), NAT-D (Source address and port)
4	Responder	Key Exchange (contains Diffie-Hellman public key), Nonce, Kerberos Token (responder), NAT-D (Destination address and port), NAT-D (Source address and port)
5 (encrypted)	Initiator	Identification, Hash (initiator)
6 (encrypted)	Responder	Identification, Hash (responder)

If both nodes are IPSec NAT-T-capable and there is at least one NAT between them, they use IPSec NAT-T options in the Quick Mode negotiation. Assuming that there is at least one NAT between these two peers, the resulting Quick Mode negotiation is shown in the following table.

Table 2   Quick Mode messages

Quick Mode Message	Sender	Payload
1 (encrypted)	Initiator	Security Association (contains proposals including the selection of UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport tunnel mode), Identification (contains secure traffic description), Nonce, NAT-OA
2 (encrypted)	Responder	Security Association (contains a selected proposal), Identification (contains secure traffic description), Nonce, NAT-OA
3 (encrypted)	Initiator	Hash
4 (encrypted)	Responder	Notification

At the end of the Quick Mode negotiation, both IPSec peers have each other's original address, send periodic NAT-Keepalive packets as necessary, and use UDP encapsulation for ESP PDUs.

https://wiki.wireshark.org/ESP_Preferences

ESP Payload Decryption / ESP Authentication Checking

If Libgcrypt is linked with Wireshark you can decrypt ESP Payloads and/or Authentication Checking. You can see if your version of Wireshark supports ESP decryption by looking for "with Gcrypt" in the about box.