ipsec-ike debug信息分析

H3CDebug信息详解——ipsec-ikedebug信息分析IPSec/IKEdebug信息分析华为三康技术有限公司Huawei-3ComTechnologiesCo.,Ltd.文档编号DocumentID密级Confidentialitylevel内部公开文档状态DocumentStatus共10页Total10pages拟制Preparedby李雪峰Date日期2006-7-27评审人ReviewedbyDate日期yyyy-mm-dd批准ApprovedbyDate日期yyyy-mm-dd修订记录RevisionRecord日期DateDateDateDate修订版本RevisionRevisionRevisionRevisionVersionVersionVersionVersion修改章节SecSecSecSecNo.No.No.No.修改描述ChangeChangeChangeChangeDescriptionDescriptionDescriptionDescription作者AuthorAuthorAuthorAuthor2006-7-271.0初稿完成initialtransmittal李雪峰目录目录目录目录1．IKE交换过程................................................................................................................................................................52．ISAKMP格式介绍........................................................................................................................................................73．IPSec/IKEdebug信息分析.........................................................................................................................................14附录：...............................................................................................................................................................................34总结...................................................................................................................................................................................45关键字：IKE、载荷、安全联盟1111．．．．IKEIKEIKEIKE交换过程交换过程交换过程交换过程对IPSec而言，已定义的密钥交换就是IKE—即Internet密钥交换。IKE利用ISAKMP语言来定义密钥交换，是对安全服务进行协商的手段。事实上，IKE定义了为数众多的交换方式，以及相关的选项。IKE交换的最终结果是一个通过验证的密钥以及建立在双方同意基础上的安全服务—亦即所谓的“IPSec安全联盟（IPSecSA）”。IKE使用了两个阶段的ISAKMP。第一阶段建立IKE安全联盟，第二阶段利用这个既定的安全联盟，为IPSec协商具体的安全联盟。在IKE阶段1交换中，两个ISAKMP端点建立一个安全的、经过认证的通道。该通道常常称为ISAKMPSA或IKESA。当阶段1完成时，两个IPSec中只建立一个单独的SA。该IKESA可以用两种方式来创建：主要模式（mainmode）或野蛮模式(aggressivemode)，但不能同时使用。主模式包含6个报文类型。通过下面交换来建立IKESA:•发送消息1、2的准备：在消息被发送前，协商发起者和响应者必须计算产生cookie，用于唯一的标识每个单独的协商交换，cookie使用源/目的IP地址、随机数字、日期和时间进行MD5运算得出，并且将其放入消息1的ISAKMP头中，用以标识一个单独的协商交换。•发送消息1、2在消息1、2中通过转换载荷双方协商IKE的散列类型、加密算法、认证方法、IKESA协商的时间限制。•发送消息3、4的准备:需要生成用于在它们之间产生Diffie-Hellman共享密钥的DH值，生成方法是双方各自使用一个随机数字，通过DH算法对随机数字进行运算得出一个DH值Xa和Xb(Xa是发起方的DH值，Xb是响应方的DH值)，然后双方再根据DH算法各得出一个临时值Ni和Nr(Ni是发起方的临时值，Nr是响应方的临时值。这个临时值用于以后的密钥计算)，双方交换这个DH值以后通过自己计算的DH值和交换得到的DH值进行运算就可以产生一个只有双方知道的密钥，注意密钥并不进行传输，传输的是DH值，即使第三方得到了这个DH值也无法计算出密钥。•发送消息3消息3为发起方发送的。消息3的ISAKMP头和消息1、2相同，但是载荷不同，消息3的载荷为密钥交换载荷和临时值载荷，其中密钥交换载荷包含了Xa或者Xb，临时值载荷包含了Ni或者Nr。•发送消息4消息4是响应方发送的，格式和消息3相同，只是Xa换成了Xb，Ni换成了Nr。•发送消息5、6的准备双方根据Xa和Xb计算出双方的DH共享密钥，基于Ni和Nr计算出的DH秘密，以及两个IKE对等体的事先配置的预共享密钥组成了三组密钥，这三组密钥用于两个IKE对等体的认证和后续IKE交换的加密。每个对等体产生3个密钥，对等体的密钥是相同的，这些密钥被称为会话密钥(SKey)。•发送消息5消息5是发起者发送的，消息5的ISAKMP头还是和前面的一样，但是载荷不同，消息5中的载荷包含标识载荷和散列载荷。标识载荷包含了发起者的标识信息，IP地址或者主机名。散列载荷包含对上一过程中产生的三组密钥进行Hash运算得出的值。这两个负载使用SKEY_e进行加密。•发送消息6消息6是响应者发送的，信息和消息5一样，包含了响应者相应的信息。•使用预共享的密钥完成IKE阶段1如果双方在消息5和消息6中的散列载荷中的hash值相同，那么双方的认证成功。IKE第一阶段也就完成了。消息中的负载格式IKE阶段2使用快速模式来建立IPSec隧道，每个端点可以发起阶段2交换。发送消息1消息1中的头部和其他消息头部一样，载荷有了很大区别。负载中包含了如下的载荷(部分载荷)：散列载荷：第一阶段计算出的SKEYID_a以及第二阶段产生的Xa’等信息组成，这样可以再次认证对等体。SA载荷：包含DOI和环境信息。安全提议和转换对：安全提议包含用于协商IPsec所使用的安全协议(AH、ESP)、以及包含SPI。转换用于协商模式(隧道还是传输)，算法是SHA还是MD5以及IPsecSA生存期。Key载荷：包含要交换的Xa’Nonce载荷：包含要交换的Ni’ID载荷：由ACL定义的需要保护的感兴趣流，响应方要求该ID载荷必须是本地配置ACL的子集或者镜像，如果是交集或者没有交集，则响应方回应ID错误的错误消息。发送消息2消息2是响应者回应的数据发送消息3的准备对等体双方通过交换的Xa’和Xb’生成一个新的DH共享密钥，将其和IKE第一阶段生成的SKEYID_d共享密钥以及Ni’和Nr’还有SPI等信息生成最终用于IPsec加密的密钥。此时发送者和接受者各有两个SA。发送消息3发起者发送消息3，用于验证响应者是否可以通信，相当于确认信息，响应者收到该信息以后就知道发起者已经接受到它在IKE第二阶段发送的消息2，然后IPsecIKE第二阶段结束。(在不可靠的网络中，该机制容易导致IPSec协商的错误)2222．．．．ISAKMPISAKMPISAKMPISAKMP格式介绍格式介绍格式介绍格式介绍让我们再来学习一下几个关于isakmp的格式，以便于容易分析debug信息。Isakmp头格式12301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!Initiator!!Cookie!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!Responder!!Cookie!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!NextPayload!MjVer!MnVer!ExchangeType!Flags!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!MessageID!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!Length!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+SAPayload12301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!NextPayload!RESERVED!PayloadLength!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!DomainofInterpretation(DOI)!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!!~Situation~!!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+NextPayload（1个八位字节）--消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段位0。当它们作为安全联盟协商的一部分时，此字段绝不能包含提议或转换载荷的值。例如，在交换的第一条消息中，此字段将包含值“10”（Nonce载荷的类型），在标识保护交换中的第一条消息中，此字段将包含值“0”。Reserved（1个八位字节）――未用，置为0PayloadLength（2个八位字节）――以八位字节为单位，整个安全联盟载荷的长度，包括SA载荷，所有提议载荷，和所有与被提议安全联盟相连的传输载荷。DOI（4个八位字节）――有了它协商才可以进行。DOI是一个32位无符号整数。在阶段1的交换中DOI的值如果为0，说明ISAKMPSA可在第二阶段中用于任何协议，如果ISAKMPSA在第二阶段用于IPSec，则DOI的值指定为1。所有其它的DOI值留给IANA以备后用。在没有参考一些公开规范，如InternetRFC之前，是不会随便指定一个DOI值的。这个字段必须在安全联盟载荷之内。Situation（可变长度）――由DOI字段定义，用于标识协商发生在什么环境下。环境用来做出关于所协商的安全属性的策略决定。此字段必须包含在安全联盟载荷之内。ProposalPayload报文格式123012345