IPsec Security ServicesIPsec 安全服務

IPsec VPNs provide security services to traffic traversing a relatively less trustworthy network between two relatively more trusted systems or networks. The less-trusted network is usually the public internet. But IPsec VPNs can also be used for things like protecting network management traffic as it crosses an organization intranet.

IPsec VPN 為往返於相對不受信任的網路（兩個相對受信任的系統或網路之間）的流量提供安全服務。這個較不受信任的網路通常是公共網際網路。但 IPsec VPN 也可以用於保護管理流量穿越組織內部網路等情境。

IPsec is a framework of open standards that spells out the rules for secure communications. IPsec relies on existing algorithms to implement encryption, authentication, and key exchange. The figure below illustrates some of the standard algorithms that IPsec uses. The framework is a modular design allowing technologies to be replaced over time. When cryptographic technologies become obsolete, it does not make the IPsec framework obsolete. Current technologies are swapped to replace the obsolete technologies, keeping the framework in place. For example, AES is now commonly implemented for confidentiality in place of the aging DES and 3DES technologies. Similarly, SHA 2-based algorithms are used for data integrity, in place of the deprecated MD5 and SHA-1-based algorithms.

IPsec 是一套開放標準的框架，明確規範了安全通訊的規則。IPsec 依賴既有的演算法來實作加密、驗證與金鑰交換。下圖說明 IPsec 使用的一些標準演算法。此框架採模組化設計，讓技術可以隨著時間更換。當某種密碼技術過時後，並不會使 IPsec 框架跟著過時，只需要將過時的技術替換成目前的技術，框架本身則維持不變。例如，AES 目前已普遍被實作用於機密性保護，取代已老舊的 DES 及 3DES 技術。同樣地，基於 SHA-2 的演算法也已用於資料完整性保護，取代已淘汰的 MD5 及基於 SHA-1 的演算法。

ESP supports various symmetric encryption algorithms. The original data is well protected by ESP, because the original IP packet is encrypted. As illustrated in the figure for an IPv4 packet, an ESP header is added to the ciphertext, which consists of the encrypted IPv4 packet and ESP trailer. When ESP authentication is also used, the encrypted IPv4 packet and ESP trailer, as well as the ESP header, are included in the hashing process.

ESP 支援多種對稱式加密演算法。由於原始 IP 封包已被加密，原始資料受到 ESP 良好的保護。如圖中所示的 IPv4 封包，ESP 標頭會被加到密文之前，密文則由已加密的 IPv4 封包及 ESP 尾端組成。當同時使用 ESP 驗證時，已加密的 IPv4 封包、ESP 尾端以及 ESP 標頭都會納入雜湊運算過程。

When both authentication and encryption are used, the encryption is performed first. Authentication is then performed by sending the encrypted information through a hash algorithm. The hash provides data integrity and data origin authentication. Finally, a new IPv4 header is prepended to the authenticated payload. The new IPv4 address is used to route the packet. ESP does not attempt to provide data integrity for this new external IP header.

當同時使用驗證與加密時，會先執行加密。接著透過將已加密資訊送入雜湊演算法來進行驗證，此雜湊值可提供資料完整性與資料來源驗證。最後，會在已驗證的承載資料前面加上一個新的 IPv4 標頭，這個新的 IPv4 位址則用於路由該封包。ESP 並不會為這個新的外部 IP 標頭提供資料完整性保護。

Performing encryption before authentication facilitates rapid detection and rejection of replayed or bogus packets by the receiving device. Before decrypting the packet, the receiver can authenticate inbound packets. By doing this authentication, it can quickly detect problems and potentially reduce the impact of DoS attacks. ESP can, optionally, enforce anti-replay protection by requiring that a receiving host sets the replay bit in the header to indicate that the packet has been seen.

先加密後驗證的做法，能讓接收端裝置快速偵測並拒絕重放或偽造的封包。在解密封包之前，接收端便可以先驗證進入的封包，藉由這樣的驗證，能快速偵測問題並可能降低 DoS 攻擊造成的衝擊。ESP 也可以選擇性地強制執行防重放保護，方法是要求接收端主機在標頭中設定重放位元，以表示該封包已被看過。

In modern IPsec VPN implementations, the use of ESP is common. Although both encryption and authentication are optional in ESP, one of them must be used.

在現代 IPsec VPN 實作中，普遍會使用 ESP。雖然 ESP 中的加密與驗證都是選用的，但兩者至少必須使用一個。

Choosing an encryption algorithm is one of the most important decisions that a network security professional makes when building a cryptosystem.

選擇加密演算法是網路安全專業人員在建置密碼系統時，所做出最重要的決策之一。

Symmetric encryption algorithms such as AES require a common shared-secret key to perform encryption and decryption. You can use email, courier, or overnight express to send the shared-secret keys to the administrators of the devices. This method is obviously impractical, and does not guarantee that keys are not intercepted in transit. Public-key exchange methods allow shared keys to be dynamically generated between the encrypting and decrypting devices:

像 AES 這樣的對稱加密演算法，需要一組共同的共享密鑰才能進行加密與解密。你可以透過電子郵件、快遞或隔夜快遞將共享密鑰傳送給裝置的管理員，但這種方式顯然不切實際，也無法保證金鑰在傳輸過程中不會被攔截。公開金鑰交換方法可讓加密端與解密端裝置之間動態產生共享金鑰：

These algorithms are used within IKE to establish session keys. They support different prime sizes that are identified by different DH or ECDH groups.

這些演算法在 IKE 中用於建立工作階段金鑰，並依不同的 DH 或 ECDH 群組支援不同的質數大小。

The following figure illustrates the key exchange process.

下圖說明金鑰交換的流程。

IPsec implements a VPN solution using an encryption process that involves the periodic changing of encryption keys. IPsec uses the IKE protocol to authenticate a peer computer and to generate encryption keys. IKE negotiates a security association (SA), which is an agreement between two peers engaging in an IPsec exchange, and the SA consists of all the required parameters that are necessary to establish successful communication.

IPsec 使用的加密流程包含定期更換加密金鑰，以此實作 VPN 解決方案。IPsec 使用 IKE 協定來驗證對等電腦並產生加密金鑰。IKE 會協商一個安全關聯（SA），這是進行 IPsec 交換的兩個對等端之間的協議，SA 包含成功建立通訊所需的所有必要參數。

IKEv2 was created to overcome some of the IKEv1 limitations.

IKEv2 是為了克服 IKEv1 的一些限制而建立的。

IKEv2 is an enhancement to IKEv1. It is an updated version of the IKE protocol and it provides several benefits compared to IKEv1. Also, Cisco IOS FlexVPN relies on IKEv2 as a security technology.

IKEv2 是 IKEv1 的強化版本，是更新版的 IKE 協定，相較於 IKEv1 提供了多項優點。此外，Cisco IOS FlexVPN 也是以 IKEv2 作為其安全技術。

The two IKE versions are not compatible so both peers must use the same IKE version. IKEv2 uses similar negotiation messages to IKEv1, but with some differences. IKEv2 uses four messages for the Exchange phase; IKEv1 uses either six messages (in main mode) or three messages (in aggressive mode) for Phase1. Also, IKEv2 reduces the required bandwidth as compared to IKEv1.

這兩個 IKE 版本並不相容，因此雙方對等端必須使用相同的 IKE 版本。IKEv2 使用與 IKEv1 類似的協商訊息，但有一些差異。IKEv2 在交換階段使用四則訊息；IKEv1 在 Phase 1 則使用六則訊息（主模式）或三則訊息（積極模式）。此外，與 IKEv1 相比，IKEv2 減少了所需的頻寬。

IKEv2 is more secure and gives more authentication options to build a secure tunnel between the peers.

IKEv2 更為安全，並提供更多驗證選項，以在對等端之間建立安全通道。

IKEv2 supports EAP authentication besides the Pre-Shared Key (PSK) and the Certificate authentication. It also supports asymmetric authentication (different authentication method on each peer). The following table summarizes some of the differences between IKEv1 and IKEv2, and the benefits of the new version:

除了預先共享金鑰（PSK）與憑證驗證外，IKEv2 也支援 EAP 驗證，同時也支援非對稱驗證（每個對等端可使用不同的驗證方法）。下表整理了 IKEv1 與 IKEv2 之間的一些差異，以及新版本的優點：

VPN data is transported over untrusted networks such as the public internet. Potentially, this data could be intercepted and read or modified. To guard against modification, Hashed Message Authentication Codes (HMACs) are used by IPsec.

VPN 資料是透過像公共網際網路這樣不受信任的網路傳輸的，這些資料有可能被攔截、讀取或竄改。為了防範資料被竄改，IPsec 使用雜湊訊息鑑別碼（HMAC）。

IPsec uses HMAC as the data integrity algorithm that verifies the integrity of the message. Hashing algorithms such as SHA-2 are the basis of the protection mechanism of HMAC. HMACs use existing hash algorithms, but with a significant difference. HMACs add a secret key as input to the hash function. Only the sender and the receiver know the secret key, and the output of the hash function now depends on the input data and the secret key. Therefore, only parties who have access to that secret key can compute the digest of an HMAC function.

IPsec 使用 HMAC 作為驗證訊息完整性的資料完整性演算法。像 SHA-2 這樣的雜湊演算法，是 HMAC 保護機制的基礎。HMAC 使用既有的雜湊演算法，但有一個重大差異：HMAC 會將一組密鑰做為雜湊函式的額外輸入。只有寄送端與接收端知道這組密鑰，此時雜湊函式的輸出不僅取決於輸入資料，也取決於這組密鑰。因此，只有擁有該密鑰的一方才能計算出 HMAC 函式的摘要值。

The following figure depicts a keyed hash that is a simplification of the more complex HMAC algorithm. The HMAC algorithm itself is beyond the scope of this material. HMAC is defined in RFC 2104. Like a keyed hash, HMAC utilizes a secret key known to the sender and the receiver.

下圖描繪了一個帶金鑰的雜湊，這是對更複雜的 HMAC 演算法的簡化說明。HMAC 演算法本身已超出本教材範圍，HMAC 是在 RFC 2104 中定義的。與帶金鑰的雜湊一樣，HMAC 也使用寄送端與接收端所知道的密鑰。

When you conduct business long distance, it is important to know who is at the other end of the phone, email, or fax. The same is true of VPN networks. The device on the other end of the VPN tunnel must be authenticated before the communication path is considered secure.

當你進行長途業務往來時，知道電話、電子郵件或傳真另一端的對象是誰非常重要，VPN 網路也是如此。在通訊路徑被視為安全之前，VPN 通道另一端的裝置必須先經過驗證。