数字签名有如下几种含义：

        如果签名得到证实，说明所接收到的报文在从签名到接收的一段时间内未经任何改动。
如果不能证实签名，则说明或者是报文在传送过程中受到了破坏或篡改，或者是签名计算错误，又或者是签名在传送过程中被破坏或篡改。在上述任何情况下，未得到证实的签名并不一定是坏事，但是要求对报文重新签名并重传，以便最终能为接收者所接受。

        如果签名得到证实，意味着与公共密钥相关联的实体是对报文签名的唯一实体。换言之，与公共密钥关联的实体不能否认自己的签名，这是数据签名的重要特性，称为不可抵赖。
还有其他机制可以实现数据签名，而R SA是其中应用最广泛的，并且已在大多数Internet产品中实现。

        2.2 安全性关联

        安全性关联是( SA ) IPsec的基本概念。安全性关联包含能够唯一标识一个安全性连接的数据组合。连接是单方向的，每个SA由目的地址和安全性参数索引( SPI )来定义。其中SPI是对RFC 1825修改后的Internet草案中所要求的标识符，它说明使用SA的IP头类型，如AH或ESP。SPI为3 2位，用于对SA进行标识及区分同一个目的地址所链接的多个SA。进行安全通信的两个系统有两个不同的SA，每个目的地址对应一个。

        每个SA还包括与连接协商的安全性类型相关的多个信息。这意味着系统必须了解其SA、与SA目的主机所协商的加密或身份验证算法的类型、密钥长度和密钥生存期。

        2.3 密钥管理

        如何管理密钥是Internet安全性专业人士面临的最复杂的问题之一。密钥管理不仅包括使用密钥协议来分发密钥，还包括在通信系统之间对密钥的长度、生存期和密钥算法进行协商。Internet工作组和研究团体对此已进行了大量工作，但是由于尚未达成一致，目前还没有发表任何RFC。

        Internet安全性关联密钥管理协议( I SA K M P )为密钥的安全交换定义了整个基本构架。I SA K M P实际上是一个应用协议，协议中定义了用于系统之间协商密钥交换的不同类型报文，它在传输层使用U D P。但是I SA K M P只是特定机制所使用的框架，而没有定义实际完成交换的机制和算法。这些年来在不同的建议中定义了大量的交换机制，通常以D i ff i e – H e l l m a n密钥交换为基础。主要的提案包括：P h o t u r i s。此提案基于D i ffie-Hellman 算法，但增加了要求，即要求节点首先发送一个c o o k i e (一个随机数)，然后服务器给予应答，这样减少了否认服务攻击的威胁(否认服务攻击是由攻击者伪造源地址而导致的)。P h o t u r i s也要求通信各方都必须对协商好的密钥签名，以减少中间者攻击的危害(所谓中间者攻击，是指某个攻击者对系统的A l i c e冒充自己是B o b，又对另一个系统的B o b冒充自己是A l i c e )。

        S u n公司的Internet协议的简单密钥管理( S K IP )。S K IP也是以D i ff i e – H e l l m a n密钥交换为基础，但是它并不要求通信各方使用随机数来计算其密钥，而是要求使用静态的密码表。各方查找密码表中的秘密值，然后基于查到的秘密值来计算，并传送所算出的值。O A K L E Y。此机制与P h o t u r i s有某些相似特性，但在不考虑否认服务攻击的情形下，它提供不同的密钥交换模式。1998年秋，基于O A K L E Y和S K E M E ( Internet的安全密钥交换机制)，Internet密钥交换最终在Internet密钥交换规范中得以定义。读者应该注意到，人工密钥管理也是一个重要选项，而且在很多情况下是唯一的选项。人工方法要求个人单独交付密钥，并使用密钥来配置网络设备。即使在开放标准已经充分确定并且实现之后，人工密钥管理仍将继续是一个重要选择，对于商业产品尤其如此。

        2.4 实现IPsec

        IP层安全性用于保护IP数据报。它不一定要涉及用户或应用。这意味着用户可以愉快地使用应用程序，而无需注意所有的数据报在发送到Internet之前，需要进行加密或身份验证，当然在这种情形下所有的加密数据报都要由另一端的主机正确地解密。

        这样就引入了如何实现IPsec的问题，有如下三种可能方法：

        将IPsec作为IPv4栈或IPv6栈的一部分来实现。这种方法将IP安全性支持引入IP网络栈，并且作为任何IP实现的一个必备部分。但是，这种方法也要求对整个实体栈进行更新以反映上述改变。

        将IPsec作为“栈中的一块” ( B I T S )来实现。这种方法将特殊的IPsec代码插入到网络栈中，在现有IP网络软件之下、本地链路软件之上。换言之，这种方法通过一段软件来实现安全性，该软件截获从现有IP栈向本地链路层接口传送的数据报，对这些数据报进行必要的安全性处理，然后再交给链路层。这种方法可用于将现有系统升级为支持IPsec的系统，且不要求重写原有的IP栈软件。

        将IPsec作为“线路的一块” ( B I T W )来实现。这种方法使用外部加密硬件来执行安全性处理功能。该硬件设备通常是作为一种路由器使用的IP设备，或者更确切一些，是安全性网关，此网关为位于它后面的所有系统发送的IP数据报服务。如果这样的设备只用于一个主机，其工作情况与B I T S方法类似，但如果一个B I T W设备为多个系统服务，实现相对要复杂得多。

        上述各种方法的差别不在于字面上，而在于它们的适用情况不同。要求高级别安全性的应用最好使用硬件方法实现；而如果系统不具备与新的IPsec兼容的网络栈，应用最好选择B I T S方法。

       2.5 隧道模式与透明模式

        而对于IP安全性，隧道同样重要。两个系统建立了SA，以便在Internet上安全地通信。其中一个系统产生网络业务流，经过加密或者签名，然后发送给目的系统。而在接收方，首先对收到的数据报进行解密或者身份验证，把净荷向上传送给接收系统的网络栈，由使用数据的应用进行最后的处理。两个主机之间的通信如同没有安全性头一样简单，而且数据报实际的IP头必须要暴露出来以便在Internet选路，因此这种方法称为使用SA的透明模式。

        SA也可以用来将安全IP以隧道方式通过互联网络。来自系统A的所有IP包首先转发到安全性网关X，由X建立一条跨越Internet、目的地为安全性网关Y的隧道，由Y对经隧道方式传来的数据拆包并转发。安全性网关Y可能将包转发给本地互联网络内的任一主机B、C或D，也可能转发给外部主机，如M。这取决于源主机如何为这些包定向。如果SA目的节点是安全性网关，则称为隧道关联。即，隧道传送既可以在两个安全性网关之间进行，也可以在正规节点和安全性网关之间进行。

        3 IPv6安全性头

        如前所述， IPsec安全性服务完全通过AH和封装安全性净荷( ESP )头相结合的机制来提供，当然还要有正确的相关密钥管理协议。RFC 1826(IP身份验证头)中对AH进行了描述，而ESP头在RFC 1827(IP封装安全性净荷( ESP ) )中描述。上述RFC及IP安全性体系结构RFC仅仅是解决安全性问题的第一步。IPsec工作组各成员正继续对这些扩展头的规范进行改进，这些文档的当前草案的篇幅几乎是原RFC的两倍。这些草案保留了原RFC的语言和意图，并进行了扩充，对包头及其功能的描述更加完整，综合性更强。

        各安全性头可以单独使用，也可以一起使用。如果一起使用多个扩展头， AH应置于ESP头之前，这样，首先进行身份验证，然后再对ESP头净荷解密。使用IPsec隧道时，这些扩展头也可以嵌套。即，源节点对IP包进行加密和数字签名，然后发送给本地安全性网关，该网关则再次进行加密和数字签名，然后发送给另一个安全性网关。

        AH和ESP头既可以用于IPv4，也可以用于IPv6，这一点很重要。本节将讨论这些安全性扩展头在IPv6中如何使用，对于IPv4，这些扩展头作为选项加在正常的IPv4头中。

        3.1 身份验证头

        AH的作用如下：

        为IP数据报提供强大的完整性服务，这意味着AH可用于为IP数据报承载内容验证数据。

        为IP数据报提供强大的身份验证，这意味着AH可用于将实体与数据报内容相链接。

        如果在完整性服务中使用了公共密钥数字签名算法， AH可以为IP数据报提供不可抵赖服务。

        通过使用顺序号字段来防止重放攻击。

        AH可以在隧道模式或透明模式下使用，这意味着它既可用于为两个节点间的简单直接的数据报传送提供身份验证和保护，也可用于对发给安全性网关或由安全性网关发出的整个数据报流进行封装。

        1. 语义

        IPv6中的AH与其他扩展头一起使用时，必须置于那些将由中间路由器处理的扩展头之后，及那些只能由数据报目的地处理的扩展头之前。这意味着AH应置于逐跳扩展头、选路扩展头或分段扩展头之后。根据不同情况， AH可在目的地选项扩展头之前，也可在其后。
在透明模式中， AH保护初始IP数据报的净荷，也保护在逐跳转发中不变化的部分IP头，如跳极限字段或选路扩展头。

        2. AH字段

        与所有的IPv6扩展头一样，第一个字段是8位的下一个头字段，它表示后续的扩展头协议。其他字段包括：

        (1) 净荷长度。此8位字段指明AH的整个长度，其值以3 2位字为单位，并减去2 。正如初始的定义，AH包含6 4位，其余部分为身份验证数据(参见后续内容)。因此净荷长度字段只指出身份验证数据以32 位字为单位的长度。加入序列号字段(参见后续内容)后，此值等于身份验证数据加上序列号字段的长度。
        (2) 保留。净荷长度字段之后的1 6位为将来使用而保留。目前，此1 6位必须全部置为0。
        (3) 安全性参数索引( SPI )。此3 2位字段是一个任意数。与目的IP地址和安全性协议一起使用，SPI是AH使用的SA的唯一标识。若SPI值为0，则表示只用于本地而不予传送；值1 ~ 2 5 5被Internet分配号码授权机构( I A N A )保留作将来使用。
        (4) 序列号。此3 2位字段是一个必备的计数器，由发送者插入IP头，但不一定由接收者使用。从0开始，每发送一个数据报，该计数器增1，这可用于预防重放攻击。若接收者使用此字段来对抗重放攻击，对于序列号与已收到的数据报相同的数据报，接收者将予以丢弃。这意味着若计数器重新开始循环，即已经接收到23 2个数据报，则必须协商新的SA。否则，一旦计数器重新置位，接收系统将丢弃所有的数据报。
        (5) 身份验证数据。此字段包含完整性检查值( ICV )，这是AH的核心。其内容的长度必须是3 2位的整数倍，为满足这个条件，其中可能包含填充字段。下节将讨论该值的计算。

        3. 计算完整性检查值

        对于如何计算ICV以及使用什么机制来计算， RFC 1826的描述比较模糊。实际上，术语“完整性检查值”在该文档中并没有出现，而是出现在将要代替RFC 1826的后续草案中。预期适当的身份验证算法将导致ICV的产生。建议的算法包括：

        报文身份验证代码( M A C )，然后对其结果用适当的对称加密算法(如D E S )进行加密。
        安全散列功能，如M D 5或SHA的更新版SHA – 1。
       按照标准的约定，预计AH的任何实现将必须支持M D 5和SHA – 1密钥散列。身份验证数据针对整个IP数据报净荷以及IP头的不变部分或可预测部分来计算。

        3.2 封装安全性净荷头

        ESP头被用于允许IP节点发送和接收净荷经过加密的数据报。更确切一点， ESP头是为了提供几种不同的服务，其中某些服务与AH有所重叠。ESP头提供的服务包括：

• 通过加密提供数据报的机密性。
•  通过使用公共密钥加密对数据来源进行身份验证。
•  通过由AH提供的序列号机制提供对抗重放服务。
•  通过使用安全性网关来提供有限的业务流机密性。

        ESP头可以和AH结合使用。实际上，如果ESP头不使用身份验证的机制，建议将AH和ESP头一起使用。

        1. 语义

        ESP头必须跟随在去往目的节点所途经的中间节点需要处理的扩展头之后， ESP头之后的数据都可能被加密。实际上，加密的净荷是作为ESP头的最后一个字段。与AH类似，ESP既可用于隧道模式，也可用于透明模式。在透明模式中，如果有AH，IP头以及逐跳扩展头、选路扩展头或分段扩展头都在AH之前，其后跟随ESP头。任何目的地选项头可以在ESP头之前，也可以在ESP头之后，或者ESP头前后都有，而ESP头之后的扩展头将被加密。

        在很多方面，仅仅是常规数据报带着加密净荷从源端传送到目的端。某些情况下，适合在透明模式中使用ESP。但是，这种模式使攻击者有可能研究两个节点之间的业务流，留意正在通信的节点、节点之间交换的数据量、交换的时间等。所有这些信息都可能为攻击者提供有助于对通信双方进行攻击的信息。

类似前面描述的AH的情形，使用安全性网关是一种替代方法。安全性网关可以直接与节点连接，也可以链接到另一个安全性网关。单个节点可以在隧道模式中使用ESP，即加密所有出境包，并封装到单独的IP数据报流中，再发送给安全性网关。然后网关解密业务流，并重新将原始IP数据报发往目的地。

        使用隧道模式时，ESP头对整个IP数据报进行封装，并作为IP头的扩展将数据报定向到安全性网关。ESP头与AH的结合也有几种不同方式，例如以隧道方法传送的数据报可能有透明模式的AH。

        2. 字段

        ESP头与其他扩展头不同。其一，下一个头字段的位置接近ESP头的末端。其二， ESP头之前的扩展头将其下一个头字段值置为5 0，以指明随后是ESP头。ESP头的其余部分将可能包括如下字段：

        安全性参数索引( SPI )。与上节提到的AH中的3 2位SPI值相同。通信节点使用该值来指出SA，SA用于确定数据应如何加密。

        序列号。32位，从0开始，每发送一个数据报，该值加1。如前所述，序列号可用于防御重放攻击，在循环用完所有23 2个值之前，必须建立新的SA。

        净荷数据。此字段长度可变，它实际上包含数据报的加密部分以及加密算法需要的补充数据，例如初始化数据。

        填充。头的加密部分(净荷)必须在正确的边界终止，因此有时需要填充。

        填充长度。此字段指明净荷数据所需要填充的数据量。

        下一个头：此字段像其他IPv6扩展头中的字段一样操作，但是它不位于扩展头的开始，而是靠近扩展头末端。

        身份验证数据。此字段是一个ICV，它对除身份验证数据本身之外的整个ESP头进行计算。这种身份验证计算是可选的。

        3. 进行封装

        预计一个兼容的ESP实现至少要求支持DES加密和SHA-1身份验证。它也可以支持其他算法，但支持上述两个算法是最低要求。