上文我們對IPsec協議的基本內容作了介紹，包括它的工作流程，具體的操作細節等方面。現在呢我們再來對IPsec協議它的實現的具體情況進行一個深入的講解。下面是IOS IPsec協議實現的概況：

認證報頭（Authentication Header）：AH是定義在IETF RFC 2402的，它支持IPsec數據驗證、認證和完整性服務。它不支持數據加密。典型情況下AH是單獨實現的，但它也可以與ESP一起實現。在僅僅需要保證數據交換安全的時候，我們才使用AH。既然AH不支持數據加密，你也許會問為什么我們還要用AH？你可以這樣來看這個問題：如果應用已經支持數據加密，那就不需要額外的數據加密。相對于ESP而言，AH在處理開銷上是更“輕”的，所以它更容易應用在低端的路由器上。

此外，相對于ESP，AH提供了更好的IP層安全性。AH通過為所有在傳輸中不被修改的IP數據包信息生成Hash簽名數據來保證IP數據包的安全。AH安全性數據是存儲在32位長度的AH報頭中的，而這是安裝在IP數據報頭和4層協議報頭之間的。因為AH是負責使IP數據包“安全”的，所以AH不能部署在使用Network Address Translation (NAT)的網絡環境中。AH是在傳輸模式或通道模式中的起作用的。大多數情況下我們會使用通道模式，而將原始IP數據包封裝在一個新的AH安全IP數據包中。這個新的數據包包含一個新的IP報頭（其中有IPsec協議遠程節點網關的目標地址）和AH報頭，接著是原始IP數據包和四層報文。IANA（Internet Assigned Numbers Authority）將ESP的協議ID賦為51。

封裝安全載荷（Encapsulating Security Payload）：ESP是定義在IETF REF 2406中的，它支持IPsec數據加密、驗證、認證和和完整性服務。ESP可以單獨實現或者與AH一起實現。AH報頭是預先就包含在IP數據包的數據負載部分的，而ESP將IP數據包中的整個數據部分和一個報頭及報尾封裝在一起。ESP報頭包含安全性和序列化信息。ESP報尾包含補充參數和（必要的）驗證數據。ESP對原始ULP數據及其密文的封裝要求比AH更多的路由器處理資源。此外，ESP也要求將1500-byte Layer 4報文進行分片，以支持額外的安全負載數據。類似于AH，ESP也支持傳輸和通道操作地方，但幾乎所有供應商都專門實現了通道模式。ESP RFC沒有規定哪個協議必須用于加密數據。Cisco IOS支持56-DES、3DES和AES的加密協議。還有其它一些供應商也實現了Blowfish和IDEA。IANA將ESP的協議ID賦為50。

Internet安全聯系和密鑰管理協議（Internet Security Association and Key Management Protocol，ISAKMP）和Internet密鑰交換（Internet Key Exchange，IKE）: 這些協議提供了實現IPsec VPN服務協商的框架和過程。ISAKMP是定義在IETF REF 2408中，而IKE定義在IETF RFC 2409中。ISAKMP定義了創建和刪除認證密鑰和安全聯系（SA）的計劃、語法和程序。IPsec協議節點使用SA去跟蹤不同IPsec節點間協商的安全服務策略的不同方面。

當節點連接建立后，SA就負責節點間的協商。在連接建立（及隨后的重建立）過程中，每一個節點將它自己的安全參數索引（SPI）數年賦給它其它節點協商的SA。SPI是在節點之間交換的，并用于識別數據包。當一個節點接收到一個IPsec數據包，它會檢查其中的SPI，通過查找SPI數據庫，找到相應的SA，然后根據SA中的規則處理數據包。關于ISAKMP需要記住的一個關鍵點是它是獨立于實現IPsec的密鑰管理協議、密文和認證。

IKE是Oakley密鑰決定協議和SKEME密鑰交換協議的混合體。IKE協議負責管理IPsec節點的ISAKMP中的IPsec安全聯系。IKE協議可用于ISAKMP，但它們并不是一樣的。IKE是建立IPsec節點間的IPsec協議“連接”的機制。這要求對下面幾種協商：

認證算法：IKE使用Diffie-Hellman在非安全網絡傳輸上建立共享的機密會話密鑰。

機密性算法：IKE節點將使用的安全性協議協商，它們是AH、ESP或AH和ESP組合。

哈希算法：IKE使用哈希算法來驗證報文數據。#p#

認證密鑰：IKE支持使用預共享密鑰、RSA密鑰（或者暫時）、數字認證和可擴展認證（Extended Authentication，Xauth)來進行認證管理。

IKE可以在三種模式下操作：主模式、積極模式和快速模式。其中主模式和積極模式都實現相同的目標，即建立初始化階段和第1階段的IKE SA。第一階段的SA引導了IKE過程。一旦第一階段的協商完成，快速模式就可以用于第二階段的IKE操作，它允許全SA協商和在SA過期時刷新SA信息。

主模式、積極模式和快速模式之間的不同與安全級別和消息交換數量有關。主模式有六種信息交換模式（三種是在創建者中，三種是在響應者中）。主模式始于連接創建者發起一個保證Diffie-Hellman密鑰交換安全的協商SA。一旦協商的SA建立，用于快速模式認證、IKE認證和SA加密的Diffie-Hellman密鑰就會生成并交換，實現身份認證管理。

積極模式從連接創建者生成一個Diffie-Hellman密鑰開始，目標是得到一個第一階段的SA和節點的身份。然后響應者回復一個SA和身份認證數據，以及完成數據驗證過程的創建者。整個的積極模式交換是在沒有SA協商完成的，所有交換的數據都是不加密的。所以雖然與第1階段有同樣的交換信息，但一個更安全而另一個更快速。而且雖然快速模式與積極模式使用了相同數量的報文交換，但是快速模式更依賴在第1階段協商中建立的身份認證和安全完整性。但至少現在我們應該很清楚IPsec的所有東西都是協商的。IPsec協議節點間支持的安全服務是在兩個節點建立通信時協商的。根據節點（如網關、主機）的不同類型，它會支持多個或一個IKE策略。當一個會話被初始化，連接的節點會發送它所有支持的IKE策略。遠程節點會比較目標策略和它的最高優先級策略及按優先級從高到低順序的后續策略，然后返回一個匹配的響應。只有兩個節點都支持IPsec協議服務才能夠在此運用。

例如，節點A能夠支持數據加密和完整性驗證服務，但節點B僅僅支持數據加密服務。因些節點A和B都需要有一個通用的IKE策略。這樣，A將需要有兩個不同的IKE策略：一個支持數據和完整性服務的策略，還有一個僅支持數據服務的策略。為了使節點A和B能夠通信，就只能使用數據加密服務。如果節點A僅僅有一個支持數據或完整性的IKE策略，那么IKE將會終止它們之間的協商，這樣節點將不會建立一個IPsec連接。