IKE协商过程中Commit位的作用_commit bit

Commit位的作用

在ISAKMP协议的头部中有一个commit标记位， 这个commit位是干什么用的？

这个问题比较有意思， 虽然做了2年的IPsec，但是这个标志位我并没有注意过。问题来源是这样的：

我看到第一张图的时候，注意到报文发送之间差了将近10s， 因此第一感觉是报文丢了(没更具体到最后一个包)，重发导致的。
但是当我看到第二个图的时候，好像出问题了：
这个明显不是由于报文丢弃重发的。

不过这个时候，我依然没有上心，只是感觉可能是环境或者抓包出错导致的；因为我以前也遇到过更奇葩的情况，例如：

这个协商流程并没有问题，只是我抓包位置的缘故，导致部分包抓了两次。 因此，当我看到发来的图片是也没有感觉有啥奇怪的，因为我这个更奇怪，见怪不怪了。但是接下来，这个细心的网友发了另一张截图：

中间经过一段没啥用的建议后，他问了一句：“为什么你抓的包中，快速模式三个包中flags字段中commit都是0.”

然后就引出了尘封已久的知识点，因为我之前并没有注意过commit。后来经过这位网友的锲而不舍的寻找，终于找到了相关的资料IBM 资料：Quick mode with commit bit ，然后发给了我。
几天后，我花了点时间仔细看了IBM文档中关于协商阶段commit位的介绍，感觉又学到了新的知识。特此记录下

正如文章中所说：commit位主要用在IKE协商的第二阶段，即快速模式中；当commit位置1的时候，响应端需要对快速模式的第三个报文进行确认。示意图如下：

相比较标准的快速模式协商，多了第四个报文。而第四个报文的目的是什么呢？

IKE协议目前是通过UDP来完成的，而UDP是一个不可靠的协议，它尽最大努力传输报文，但并不能保证报文顺利达到目的地址，因此IKE协商过程中任何一个协商报文都有可能被丢弃。那么协商报文被丢弃后该怎么办呢？ 目前在openswan中(其他实现没有看过，暂且不论)，当处于中间协商状态时，会设置相应的报文重发定时器：如果在未来确定时间内都没有收到对端的响应，则会重新发送协商报文。 不过对于快速模式第三个报文有一点点特殊：发起端收到第二个报文并且发送第三个报文的过程中，已经完成了IKE的协商，已经进入Established状态；而在等待报文超时重发的过程中，发起端可能已经使用新协商出的密钥加密业务流量了；但是由于响应端超时重发第二个报文(发起端认为已经协商完毕，不会触发超时重发操作)，发起端会重新发送第三个报文，而在这个过程中，响应端是不会处理任何业务流量的，而那些加密的业务流量会被丢弃。

因此第四个报文就是为了解决这种情况而引入的，触发第四个报文的条件是：协商双方都支持commit=1的情况。 协商过程中，一般由响应端在快速模式的第二个报文中将commit位设置成1，发起端收到第二个报文后，不会立马进入Established状态，而是进入等待Notify的状态，在收到相应端发送的第四个报文(其中包括Connected Notify)后，才会进入Established状态，之后才可以使用新的SA进行加解密。

熟悉TLS协议的应该知道：在TLS中也存在一个类似的报文：ChangeCipherSpec；它的作用就是在TLS协商完毕后，通知对方进行密钥切换，在此报文之后的所有报文都经过新协商的密钥进行加密通讯。 在TLS中这个载荷是必须的，但是在ipsec中，却是可选的。

如果需要继续了解commit位的详细信息，可以阅读IBM的官网文档。此外，已将文档下载并上传至IBM z/OS诊断手册, 其中关于IKE的commit相关内容位于P1013页（IKE version 1 protocol）。