主模式第六包(收包)：main_inR3
1. 序言
main_inR3()函数是ISAKMP协商过程中第一阶段的最后一个报文的接收处理函数，它的作用同main_inI3_outR3()部分功能相同：完成对对端身份的认证。他们的不同之处在于不在需要响应报文（如果不考虑第二阶段的话）。此包处理完毕后，发起端便成功建立了ISAKMP SA, 完成了第一阶段主模式的协商。后续便是第二阶段的协商。这里我们主要说明main_inR3的函数调用关系、处理流程以及对源码的注释分析，关于main_inR3的上下文环境暂不叙述，留给后面的文章进行更新。
ISAKMP协商报文的处理流程都比较复杂，此函数在协商的报文处理函数中比较复杂的，因此个人学习期间难免有遗漏和理解错误的地方，请大家多多批评指正。
目前主要是整理源码中的处理里流程和实现逻辑，尚未深入比较细节的处理；后续在我整理完毕使用主模式协商的9个报文后，我再次结合代码整理每一个报文的详细流程，到时把每一个报文的注意事项、作用，处理方式做一个整体上的把握。同时结合书本上的描述来解释代码层的实现。
ISAKMP主模式协商流程如下：
本文要说明的便是第⑥包的接收函数：main_inR3();
2. 函数调用关系
main_inR3()函数的调用层次少了很多（如果不考虑加解密、证书认证的话），它的调用关系图如下所示
3. 第⑥个报文接收流程图
第⑥个报文的接收流程main_inR3的功能可以分为三类(如果把建立ISAKMP SA也看作一类的话)：
- 解析对方的身份标识(ID)和证书载荷，匹配对方的身份标识
- 身份验证
- 预共享秘钥
- 数字证书
- 建立ISAKMP SA
流程图下图：
4. 源码分析
由于main_R3()的处理流程和main_inI3_outR3()中的部分处理流程调用了相同的函数接口，因此无需再进行说明，如果有疑问可以查看main_inI3_outR3()的中的源码部分。
5. 总结
openswan的源码确实难度很高，虽然用了很长的时间来看主模式的6个报文7个主要的函数接口，前后花费了一个月时间吧（之前陆陆续续看过部分接口），但是学习的时候比较浅，没有深层次的理解。最主要包括以下几个方面：
-
报文的加解密
报文加密、解密是在第⑤⑥个报文中才有的，关于这部分的功能（加密、哈希、数字证书签名验签、预共享密钥等），只知道它是在做这种处理，基本没有深入去分析代码。这个主要是由于看不懂，内心里有种抵触心理；其次是不想直接深入学习这部分，先学习整体处理框架，然后再慢慢深入学习这部分功能。即“先广度优先搜索，再深度优先搜索”
-
算法相关的操作
这里的算法相关，我是想表达对于策略的配置解析存储算法、如何与报文中的载荷相对应、支持的算法类型、协商时处理对方建议载荷的原则等等问题。这部分有的可能已经在协商流程中有所涉及，但是关于算法的存储等是在这部分之前的流程中处理的(
whack_handle())，因此没有过多学习。后面再补充whack命令相关的知识。 -
连接和状态之间的联系
主要的疑惑是不清楚他们成员之间的关系，可能是特别大，同时关系有比较复杂的缘故。状态是一个动态的概念，即协商过程中的参数；连接是我们的隧道配置信息，基本是个固定的结构。他们是如何维护、以及协商过程中如何联系起来，这部分没有系统整理和分析过。举个简单的例子：NAT-T在ISAKMP中是如何完成协商的？ 这个我之前处理过一个bug,因此可能分析过协商过程中的联系，但是其他的我就不得而知了。
任重而道远，继续努力吧。