IPSEC实现分析

IPSec实现分析目 录1引言11.1编写目的11.2编写背景11.3预期读者和阅读建议11.4文档商定11.5参照资料12具体设计12.1IPSec简介12.2IPSec实现62.3IPSec发包和收包212.4内核与IKE进程通信253IKE协商简介273.1主模式（第一阶段）283.2野蛮模式（第一阶段）343.3迅速模式（第二阶段）353.4IKE进程状态转换及调用关系384哈希的计算414.1哈希计算414.2DH计算434.3加密材料(RFC2409 Appendix B)485IPSEC穿NAT505.1穿NAT讨论505.2NAT穿越原理535.3NAT穿越实现575.4两种模式对比591 引言1.1 编写目的编写该文档的目的是为了更好地理IPSec模块。为了能更好地理解IPSec，本具体设计报告描述了IPSec简介、数据构造、IPSec方略匹配、SA的查找&安全路由的安装、发包和收包过程和IPSec IKE。1.2 编写背景无1.3 预期读者和阅读建议本文档的预期读者涉及网关安全模块开发人员。开发人员应重点理解函数实现和数据构造之间的关系。1.4 文档商定IPSec Internet Protocol Security SASecurity Association （安全联盟）SPISecurity parameter index（安全参数索引）AHAuthentication Header （认证头）ESPEncapsulating Security Payload （加密安全载荷）IKEInternet Key Exchange HMAC Keyed-hash Message Authentication Code1.5 参照资料RFC 2401 Security Architecture for the Internet ProtocolRFC 2402 IP Authentication HeaderRFC 2406IP Encapsulating Security Payload (ESP)RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMPRFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409 The Internet Key Exchange (IKE) RFC 3947 Negotiation of NAT-Traversal in the IKERFC 3948 UDP Encapsulation of IPsec ESP Packets2 具体设计2.1 IPSec简介IPSEC(Internet Protocol Security)是IETF指定的一种IP层安全框架合同。它提供了在未提供保护的网络环境中传播敏感数据的保护。它定义了IP数据包格式和有关基本构造，以便为网络通信提供端对端、加强的身份验证、完整性、防重放和保密性等。IPSec究竟是如何起作用的呢？为了更直观的理解IPSec VPN，图2-1到图2-3阐明了：当两个机构通信的重要内容不想被中间人截获到，可以采用的措施。图2-1是最原始的措施，两个机构直接通过Internet进行通信，但是这样的话，很容易遭受中间黑客的截获和对内容的篡改，而两边都无法懂得，很也许会导致重要损失。图2-2，两边的机构通过架设自己的专用网络进行通信，这样的话，黑客不修改物理的连接是无法接触到两边的通信内容的，因此比较安全，但是这样的方式会耗费巨大的投资。图2-3，通过架设虚拟的VPN通道就可以使得：1.黑客能截获到报文，但也无法得知内容；2.即便是修改了内容，但两边机构是能检测到报文有无修改。图2-1 一般通信方式图2-2 架设专用网络图2-3 开辟虚拟通道固然VPN有多种，本文着重从IPSec VPN的角度简介IPSec的原理及实现。IPSec通过两种合同来实现对IP数据包的保护，分别是AH和ESP(下文简介)。IPSec既可以保护一种完整的IP载荷，也可以保护某个IP载荷的上层合同(例如TCP)。这两种方式的保护取决于两种不同的模式来提供的，如图2-4。图2-4 两种模式传播模式用来保护上层合同，而隧道模式则用来保护整个IP报文。两种合同均能使用两种模式进行数据传播。IPSec提供如下的安全特性： 数据机密性（Confidentiality）：IPsec发送方在通过网络传播包前对包进行加密。 数据完整性（Data Integrity）：IPsec接受方对发送方发送来的包进行认证，以保证数据在传播过程中没有被篡改。 数据来源认证（Data Authentication）：IPsec在接受端可以认证发送IPsec报文的发送端与否合法。 防重放（Anti-Replay）：IPsec接受方可检测并回绝接受过时或反复的报文。2.1.1 封装合同ESPESP(Encapsulating Security Payload)属于IPSec的一种合同，可用于保证IP数据包的机密性（未被别人看过）、数据的完整性以及对数据源的身份验证。ESP的合同号是50，ESP的合同头的格式如图2-5所示。图2-5 ESP头SPI是用于唯一标记SA的一种32比特数值，它在AH和ESP头中传播。在手工配备SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。Sequence Number是单调递增的数值，用来避免重放袭击。Payload Data可变长度，实际要传播的数据。Padding 填充数据，以字节为单位，为了保证数据的对齐。Pad length 填充长度Next Header 下一种头的合同号Authentication Data 可变长度，认证数据ESP同步提供了机密性以及完整性，因此在其SA中必须同步定义两套算法用来保证机密性的算法叫作一种cipher（加密器），而负责完整性的算法叫作authenticator（验证器）。ESP作用的方式，如图2-6。通过加密算法(对称加密DES/3DES/AES)对数据进行加密，然后使用散列函数MD5/SHA-1对报文进行摘要计算，最后把摘要放入ESP校验的部分。图2-6 ESP头的使用通过加密来实现数据的机密性，保证传播过程中，即便是有人截获报文，也无法得知报文的内容；通过ESP校验来实现数据的完整性，如果一旦在传播过程中对内容进行篡改，则校验不通过。当接受方收到包后来，一方面检查序列号(避免重放)，另一方面校验数据完整性，最后解密数据成明文。2.1.2 封装合同AHAH(AuthenticationHeader) 合同，用来向 IP通信提供数据完整性和身份验证,同步可以提供抗重播服务。AH的合同号是51，AH的合同头的格式如图2-7所示。图2-7 AH认证头Next Header 占8bit，下一种头的合同号；Payload Len 占8bit，表达AH头的长度，单位是4字节，计算完要减2为什么？；Reserved 占16bit，保存SPI 占32bit，安全参数索引，用来定位SASequence Number 占32bit，序列号，用来抗重播袭击Authentication Data 可变长度，认证数据AH提供了完整性校验、数据源认证及抗重播袭击的能力，但不提供机密性，传播过程中以明文方式进行。AH头作用的方式如图2-8所示。图2-8 AH头的使用跟ESP同样，通过对报文进行散列(MD5/SHA)计算来得到认证数据，有所不同的是加入了HMAC(Keyed-hashed Message Authentication Code，密钥化散列认证代码)的方式。图2-9所示是一般散列认证方式，第步是对明文进行散列计算得到一种散列值，并把散列值和明文一起传送给顾客B；第步，当顾客B收到信息后，也对明文进行散列计算；第步，用计算得到的散列值2与散列值1进行比较，如果发现不同样，则丢弃数据包（阐明传播过程中，有人改动数据包），如果发现一致，则数据包未被改动。但这样的方式，中间人可以篡改信息，并同样计算散列值来实现改动数据包的目的。图2-10所示是HMAC的方式，和图2-9不同样的是，通过加入共享密钥来计算散列值，这样的话，中间人是没有措施改动数据包的。同步HMAC的方式实现了完整性校验和源认证。图2-9 一般散列认证图2-10 HMAC方式认证2.1.3 IPSec应用场景IPSec VPN的应用场景分为3种：1. Site-to-Site（站点到站点或者网关到网关）：公司内网（若干PC）之间的数据通过这些网关建立的IPSec隧道实现安全互联。这种方式只能使用隧道模式。2. End-to-End（端到端或者PC到PC）： 两个PC之间的通信由两个PC之间的IPSec会话保护，而不是网关。这种方式既可使用传播模式也可使用隧道模式。3. End-to-Site（端到站点或者PC到网关）：两个PC之间的通信由网关和异地PC之间的IPSec进行保护。这种方式只能使用隧道模式。图2-11 应用场景从上图可以看出来，隧道模式可应用于任何场景，传播模式只合用于端到端的模式；但是 隧道模式会多一层IP头的开销，因此当使用端到端的状况，建议使用传播模式。2.2 IPSec实现2.2.1 IPSec大体实现思想SA(Security Association)：安全联盟。SA是构成IPSec的基本，是两个通信实体协商建立起来的一种协定。它决定了用来保护IPSec合同的加密算法、认证算法、密钥以及密钥存活时间等内容。SA 由三个元素定义：安全合同、唯一安全参数索引 (security parameter index, SPI) 和 IP 目的。SA是单向的，发送需要一种SA，接受也需要一种SA；SA由手工或者通过IKE自动协商两种方式创立。IPSec的重要解决流程，如图2-12所示。图2-12 解决流程图（左：发包 右：收包）安全方略是用来匹配看哪些流需要进行IPSec的解决，如果匹配上安全方略则进行IPSec解决。方略的意义在于，可以把想通过IPSec解决的流（感爱好流）辨别出来，其他的不解决。安全路由，如图2-13所示，以隧道模式（ESP+AH）为例来阐明安全路由，其实就是用路由构造体寄存某些解决函数（SA），然后每走一层解决一层，这样的话，扩展性会较好。被称之为安全路由，背面会具体简介这方面，因此到这里为止，先有个大体概念。图2-13 安全路由示意图图2-14 所示为IPSEC对于数据包的解决所通过的钩子点，本例中均为隧道模式，由于传播模式只支持点对点，网关上启用IPSEC的状况，基本上用不到传播模式。数据流通过FORWARDING的时候，会匹配IPSEC安全方略，然后会通过ESP/AH头的解决以及封装外层IP头，封装完后，属于本地发包（正常发包），然后通过LOCAL_OUT-POST_ROUTING发出当收到IPSEC包的时候，一方面收到本地进行解决，验证-解密-除去封装头，然后再放入到收包队列中进行再次收包这个时候，就是正常的转发包了图2-14 IPSEC解决流程2.2.2 IPSec方略IPSec方略重要是用来匹配爱好流（哪些数据包需要进行IPSec的解决）的，当匹配上IPSec方略后来，才会进一步操作，因此IPSec方略是IPSEC解决的基本。2.2.3 数据描述2.2.2.1 安全方略SP图2-15所示为IPSec方略构造体(安全方略SP)。其实方略就是用来定义某些条件和操作，当匹配上这些条件的时候，做些什么操作。有一种元素叫做“选择子”(元素selector)，这个选择子就是用来匹配爱好流(那些流该做IPSEC封装)的东西，因此叫做选择子；有一种元素叫做“状态模板”(元素xfrm_vec)，是用来匹配SA（就是当使用IPSEC的时候，如何加密，如何封装等内容）的；尚有一种元素是bundles，这个元素是用来安装安全路由的，这样的话，每次匹配上这个方略后，就不必再去查找bundle，不必再去查找SA了，是为了加速的作用。图2-15 IPSec方略这个时候，我们可以对着构造体来看IPSEC大体的流程：图2-16 流程（方略角度）状态选择子(selector)：从数据流的角度定义选择的数据流，被叫做感爱好流，其中匹配项有对端地址、本段地址、子网掩码、合同簇等信息；bundles：被用来安装安全路由（参照图2-11）；当查找不到绑定的安全路由的时候，就会先用来查找SA，由于如果要创立一种安全路由，需要使用SA作为材料。SA为其提供某些参数，例如某些解决函数、genid等。xfrm_vec：这个模板数组用来匹配SA方略的机构体struct xfrm_policy，如下：struct xfrm_policy#ifdef CONFIG_NET_NSstruct net*xp_net;#endif struct xfrm_policy*next; /* 下一种方略add by lxh for ipsec kernel, 12.13struct hlist_nodebydst;/*按目的地址HASH的链表，加入到全局链表中init_net-xfrm-policy_bydst有关*/struct hlist_nodebyidx;/*按索引号HASH的链表，加入全局链表中init_net-xfrm-policy_byidx*/struct xfrm_policy*child; /add by lxh for ipsec kernel, 04.13/* This lock only affects elements except for entry. */rwlock_tlock;atomic_trefcnt;/*引用次数*/struct timer_listtimer;/*方略定期器*/u32priority;/*方略优先级，如果多种匹配，则使用最高优先级的*/u32index;/*寄存policy_byidx的下标*/struct xfrm_selectorselector;/*选择子*/struct xfrm_lifetime_cfg lft;/*方略生命期*/struct xfrm_lifetime_cur curlft;/ 目前的生命期数据 struct dst_entry *bundles;/*安全路由链表*/struct xfrm_policy_walk_entry walk;/*加入init_net-xfrm-policy_all中*/u8type;u8action;/*接受/加密/阻塞等*/u8flags;/*标记*/u8xfrm_nr;/*有几种模板，相应本构造体中的数组xfrm_vec*/u16family;/*合同簇*/add by lxh for ipsec kernel, 04.13u32 inbound;/*入方向*/u32 outbound;/*出方向*/u32 pol_type;/*方略类型*/u32 pol_id;/*方略id*/u32 isdynamic;/*与否是动态？*/char tunnel_name32;/*隧道名字*/u32 outbound_sa_spi;/*出方向的spi*/end add by lxh for ipsec kernel, 04.13struct xfrm_sec_ctx*security;/*安全上下文 */struct xfrm_tmpl xfrm_vecXFRM_MAX_DEPTH;/*状态模板*/struct policy_entry *policy_entry;/add by lxh for ipsec kernel, 04.13/ added by liangxia for match peer gw ip, .4.11/ 隧道模式，保护子网不变，但对端地址变化/ 删除原隧道SA 引起新隧道不可用u32peer_ip;/ added by liangxia, .12.14s32dev_index;/接口ifindex ;2.2.2.2 安全联盟SA上文中多次提到的SA，究竟是以什么组织的，目前来揭开神秘的面纱。SA的构造体图如下图2-17。图2-17 SA的构造体内核中SA(Security Association)是用构造体struct xfrm_state 来定义，各个字段的含义如下：/* Full description of state of transformer. */struct xfrm_state#ifdef CONFIG_NET_NSstruct net*xs_net;#endifunion struct hlist_nodegclist;struct hlist_nodebydst;/按照目的地址HASH，与回收重用;struct hlist_nodebysrc;/按照源地址HASHstruct hlist_nodebyspi;/按照SPI值HASHatomic_trefcnt;/ 引用计数spinlock_tlock;/ 锁struct xfrm_idid;/ SA 索引，即目的地址，spi和合同号struct xfrm_selectorsel;/ 状态选择子u32genid;/生成id/* Key manager bits */struct xfrm_state_walkkm;/ KEY回调管理解决构造参数/* Parameters of this state. */struct u32reqid;/祈求IDu8mode;/ 模式: 传播/通道u8replay_window;/ 回放窗口u8aalgo, ealgo, calgo;/ 认证,加密,压缩算法ID值u8flags;/标记u16family;/ 合同族xfrm_address_tsaddr;/ 源地址（出口地址）intheader_len;/ 添加的合同头长度, ESP/AH 头(+IP头，隧道模式时)inttrailer_len;/ 添加的合同尾长度, ESP 才有 props;/ SA有关参数构造struct xfrm_lifetime_cfg lft;/生命周期/* Data for transformer */struct xfrm_algo*aalg;/ hash算法 struct xfrm_algo*ealg;/ 加密算法 struct xfrm_algo*calg;/ 压缩算法 struct xfrm_algo_aead*aead;/* Data for encapsulator */struct xfrm_encap_tmpl*encap;/NAT穿越有关信息/* Data for care-of address */xfrm_address_t*coaddr;/* IPComp needs an IPIP tunnel for handling uncompressed packets */struct xfrm_state*tunnel;/通道，事实上是另一种SA/* If a tunnel, number of users + 1 */atomic_ttunnel_users;/通道的使用数/* State for replay detection */struct xfrm_replay_state replay;/回放检测构造,涉及多种序列号掩码等信息 /* Replay detection state at the time we sent the last notification */struct xfrm_replay_state preplay;/ 上次的回放记录值 /* internal flag that only holds state for delayed aevent at the * moment*/u32xflags;/ 标志/* Replay detection notification settings */u32replay_maxage;/ 回放最大时间间隔u32replay_maxdiff;/ 回放最大差值/* Replay detection notification timer */struct timer_listrtimer;/ 回放检测定期器/* Statistics */struct xfrm_statsstats; / 记录值 struct xfrm_lifetime_cur curlft;/ 目前生存周期计数器struct timer_listtimer;/ SA 定期器/* Last used time */unsigned longlastused;/* Reference to data common to all the instances of this * transformer. */const struct xfrm_type*type;/ 类型, ESP / AH，解决指针struct xfrm_mode*inner_mode;/函数解决指针struct xfrm_mode*inner_mode_iaf;/struct xfrm_mode*outer_mode;/函数解决指针/* Security context */struct xfrm_sec_ctx*security;/ 安全上下文, 加密时使用/* Private data of this transformer, format is opaque, * interpreted by xfrm_type methods. */void*data;/ 内部私有数据, 将在esp_init_state/ ah_init_state 中被赋值;2.2.2.3 安全路由链表安全路由链表是用来解决IPSEC包，以及发送的时候用的，最大的好处是灵活。如图2-18和2-19所示。对于方略的匹配，SA的匹配，都是为了给数据包skb上添加解决指针，以便在发出的时候进行解决。当是隧道的模式的时候，最后一种dst_entry是通过查找一般路由得到的；而传播模式，则是直接从skb上拷贝就可以得到，由于当通过FORWARDING的时候，数据包已经是通过路由查找过的(PRE_ROUTING-路由-FORWARDING)。图2-18 安全路由（隧道模式）图2-19 安全路由（传播模式）构造体如下，忽视不关怀的部分：struct dst_entrystruct dst_entry *next;struct dst_entry*child; /关联需要解决的下一种安全路由 struct dst_entry*path;struct xfrm_state*xfrm; /关联SA;2.2.2.4 方略的有关合同解决构造图2-20 方略有关合同解决构造其中xfrm_policy_afinfo是一种数组，只需要调用封装好的函数，就可以找到相应的解决指针xfrm4_policy_afinfo和xfrm4_dst_ops。这些构造体定义了某些函数例如find_bundle就是用来查找安全路由的。2.2.2.5 状态的有关合同解决构造图2-21 状态有关合同解决构造同上，通过调用封装好的函数来获取需要的指针解决，同样是某些回调解决函数，提前初始化好的，例如封装或者解封装的函数。2.2.4 方略匹配方略匹配，如图2-22所示，当一种数据包来的时候，通过FORWARDING，通过访问控制后，就会去匹配安全方略，图2-22 安全方略匹配xfrm_decode_session _xfrm_decode_session(skb, fl, family, 0)afinfo-decode_session(skb, fl, 0)事实上是_decode_session4security_xfrm_decode_session(skb, &fl-secid)_decode_session4中，重要是从skb中解析IP头、四层合同头，并将其放入flowi构造体fl中。具体涉及如下某些：如果是UDP合同、TCP合同、SCTP合同或者DCCP合同的话，填充源端口和目的端口(fl-fl_ip_sport 和 fl-fl_ip_dport);如果是ICMP合同的话，填充icmp的类型和码(fl-fl_icmp_type和fl-fl_icmp_code);如果是ESP的话，填充IPSEC的SPI：fl-fl_ipsec_spi如果是AH的话，填充IPSEC的SPI：fl-fl_ipsec_spi如果是COMP的话，也是填充IPSEC的SPI：fl-fl_ipsec_spi其她合同的话，fl-fl_ipsec_spi=0fl-proto寄存ip头的合同号fl-fl4_dst寄存目的地址fl-fl4_src寄存源地址fl-fl4_tos寄存ip头中的tos字段值security_xfrm_decode_session是不是空的，取决于宏定义CONFIG_SECURITY_NETWORK_XFRM存不存在，通过查看内核的配备文献.config 并未发现，暂且当做是空的解决吧。xfrm_lookup_fw _xfrm_lookup_by_pol_id(net,&dst,&fl,NULL,0,pol_id)/函数原型是int _xfrm_lookup_by_pol_id(struct net *net, struct dst_entry *dst_p, struct flowi *fl,struct sock *sk, int flags,int pol_id) 。函数_xfrm_lookup_by_pol_id比较核心，波及到安全方略的匹配，绑定查找，SA的查找，发送SA的协商祈求告知IKE，生成安全路由等，都在这个函数中有所体现。如图2-23所示流程图。_xfrm_lookup_by_pol_id这个函数所做的一切工作都是环绕绑定来进行的，重要功能是对于给定的流fl，查找/创立一种bundle（所谓的安全路由）。图2-23 函数_xfrm_lookup_by_pol_id流程图下面一一简介这几种函数（安全方略匹配xfrm_policy_lookup、查找绑定xfrm_find_bundle、SA的匹配xfrm_tmpl_resolve、创立绑定xfrm_bundle_create）。安全方略的匹配（函数xfrm_policy_lookup），如图2-24所示：图2-24 函数xfrm_policy_lookup流程绑定查找函数xfrm_find_bundle流程，如图2-25所示。图2-25 绑定查找流程xfrm_find_bundlexfrm_policy_get_afinfo获取解决指针afinfo-find_bundle这个回调事实上是用的全局变量xfrm4_policy_afinfo的find_bundle指针指向的_xfrm4_find_bundle函数。_xfrm4_find_bundle这个函数就是遍历policy中挂载的bundle链表，每个元素与目前流进行匹配(出接口、目的地址、源地址、tos等)，如果查找到了，则返回dst的指针，否则返回NULL。临时还不懂得宏CONFIG_IPSEC_SUPPORT_PNAT相相应的功能是做什么，背面再进一步讨论。xfrm_tmpl_resolve函数比较简朴，对每一种方略执行一遍xfrm_tmpl_resolve_one。1. 祈求ID，reqid是怎么被赋值的？2. 为什么选择子匹配那么多次？3.图2-26 xfrm_tmpl_resolve流程xfrm_tmpl_resolve 解析模板（方略上的模板是个数组） xfrm_tmpl_resolve_one解析一种模板 xfrm_state_findSA查找 km_query发送SA祈求给IKE km-acquire (回调函数发送消息给IKE，需要协商SA,事实上的回调函数是xfrm_send_acquire)xfrm_tmpl_resolve_one通过循环每一种方略上的xfrm_vecXFRM_MAX_DEPTH，然后为调用state查找设立本地地址local，与对端网关的地址remote。注意到的是，一方面使用struct xfrm_tmpl构造体中的id.daddr和saddr；然后如果存在接口ifindex，则用其获取地址，来更新本地地址local；如果本地地址仍然没有，则直接查找路由(根据下一跳的网关地址)来获取源地址并赋值给local。然后调用函数xfrm_state_find函数。也需要注意的是，当第一条数据流来的时候，由于没有SA，xfrm_state_find函数设立的状态(struct xfrm_state_walk中的state)是XFRM_STATE_ACQ，因此，这里只执行到这里，循环就返回了，返回值是EAGAIN。xfrm_state_find重要是查找既有的xfrm_state，如果没有就新建一种，如果是新建的话，阐明SA还没有协商起来，则需要通过函数km_query告知IKE进行SA的协商。SA的状态：XFRM_STATE_ACQ：正在协商XFRM_STATE_VALID：SA有效，可以使用XFRM_STATE_ERROR：错误状态XFRM_STATE_EXPIRED：SA过期XFRM_STATE_DEAD：准备回收资源xfrm_tmpl_resolve的返回值可以是匹配的SA个数，并通过传入的参数返回SA；xfrm_tmpl_resolve的返回值还可以是错误信息，例如-EAGAIN，则_xfrm_lookup_by_pol_id函数也会返回- EREMOTE，当函数xfrm_lookup_fw收到返回值是-EREMOTE的时候，会将dst_p释放掉。当第一种包执行到这里的时候，数据包上的dst已有值了，是转发包，但是IPSEC这个时候的解决是将其释放掉了，然后再返回给方略-EAGAIN。然后xfrm4_route_forward 返回非0，ipsec_policy_entry_ok会将这个数据包丢弃掉。2.3 IPSec发包和收包2.3.1 转发包的IPSec封装解决流程图2-27 转发流程数据包通过FORWARDING这个HOOK点后，匹配过安全方略，此时已经更新过skb-_skb_dst，因此在ip_forward_finish会调用xfrm4_output。xfrm4_output会一方面过POST_ROUTING的钩子函数，最后调用xfrm4_output_finish函数，调用关系如上图所示，这些函数都是为了对于IPSEC头的解决，以及加密认证等功能，最后会转入LOCAL_OUT重新发包（隧道模式）。xfrm4_output函数，如图2-28，比较简朴，带条件进行POST_ROUTING上的钩子函数调用，如果!(IPCB(skb)-flags & IPSKB_REROUTED)为0，则但是该HOOK上的钩子函数；为1则调用钩子函数。换句话说，就是当skb的flags存在IPSKB_REROUTED标记的时候，但是钩子函数；当flags不存在IPSKB_REROUTED标记的时候，过钩子函数。图2-28 xfrm4_output代码在xfrm4_output_finish函数中，当发现是一般包的时候(没有SA)，就设立标记IPSKB_REROUTED；在ip_finish_output函数中，当发现是IPSec包的时候(路由上有SA)，就设立标记IPSKB_REROUTED。目前并未发现什么状况下会这样走？xfrm4_output_finish函数，设立标记IPSKB_XFRM_TRANSFORMED，然后更新skb-protocol为ETH_P_IP，然后调用函数xfrm_output。xfrm_output函数，解决传播模式下的分片重组，和校验检查解决，最后调用函数xfrm_output2。xfrm_output2没做别的操作，直接调用函数xfrm_output_resume。xfrm_output_resume函数，是最核心的函数之一，该函数按照安全路由链表对数据包skb进行解决，并重新过LOCAL_OUT这个hook上的钩子函数，最后调用按照一般包过POST_ROUTING，并最后将包发出去。图2-29 xfrm_output与xfrm_output_one流程图从安全路由的角度，以AH+ESP头为例看下封包流程：图2-30 封包流程图简介完了转发包，我们回过头来看下本地发包的状况。这里把本地发包和转发包放在一种图中，如图所示。阐明是转发包的途径；是本地发包的途径；是公共途径部分。本地发包的时候，会调用查找路由的函数ip_route_output_flow，在这个函数中，会调用_xfrm_lookup_by_pol_id（匹配安全方略，安装安全路由有关，上文已经简介过），因此当过完LOCAL_OUT这个HOOK点后，挂载skb上的函数是xfrm4_output，然后过POST_ROUTING点上挂载的钩子函数，过完钩子函数，然后调用xfrm4_output_finish函数解决IPSEC包，最后调用_ip_local_out函数将本数据包从本地发出：_ip_local_out LOCAL_OUT钩子函数ip_outputPOST_ROUTING钩子函数ip_finish_output 。图2-31 本地发包示意图此外，icmp_send和ip_xfrm_me_harder(nf_nat_out)待查也有对于IPSEC查找方略的调用，有待查明使用状况。2.3.2 IPSec收包解封装解决转发途径：ip_rcv()ip_rcv_finish()ip_local_deliver()ip_local_deliver_finish。图2-32 收包流程在函数ip_local_deliver_finish中，会取出IP头中的传播合同，然后根据数组inet_protos合同号得到解决指针，然后调用回调handlerip_local_deliver_finishipprot-handler(对于AH或者ESP来说，是xfrm4_rcv)图2-33 AH和ESP合同解决指针调用关系：xfrm4_rcv xfrm4_rcv_spi xfrm4_rcv_encap xfrm_inputxfrm_input函数是街封包的核心函数。见流程图2-32所示。图2-34 解封装流程2.4 内核与IKE进程通信2.4.1 方略的增删改方略的获取、添加、更新或者删除顾客态通过类型XFRM_MSG_NEWPOLICY、XFRM_MSG_UPDPOLICY或者XFRM_MSG_DELPOLICY告知内核添加Policy：netlink_raw_eroute (根据操作码辨别是增、改还是删除) netlink_policy对于获取来说，调用的地方有三个，这三个函数中，存在代码冗余：netlink_get_policy 、find_matched_policy、netlink_policy_expire2.4.2 祈求建立SA内核通过类型XFRM_MSG_ACQUIRE发送Netlink消息给顾客态的IKE进程，来告诉IKE进程，需要协商SA。build_acquire （内核态函数）netlink_acquire （顾客态函数）2.4.3 SA的添加IKE进程通过Netlink消息把协商好的SA告诉内核，消息类型是XFRM_MSG_UPDSA或者XFRM_MSG_NEWSA，见如下调用关系：install_inbound_ipsec_sa或者install_ipsec_sa setup_half_ipsec_sa kernel_ops-add_sa (netlink_add_sa 消息XFRM_MSG_UPDSA或者XFRM_MSG_NEWSA)2.4.4 SA的删除SA超时，内核会通过Netlink发送消息(消息类型是XFRM_MSG_EXPIRE)给IKE进程，IKE进程收到后删除SA：build_expire （内核态）netlink_expire delete_stateIKE接受到删除载荷，对方发过来删除SA的消息：accept_delete () delete_state delete_ipsec_sa teardown_half_ipsec_sa del_spi kernel_ops-del_sa (netlink_del_sa 消息XFRM_MSG_DELSA)扩展认证失败，则删除SA:xauth_inI0 或者 xauth_inI1 delete_state 扩展认证响应，错误状态，删除SA:xauth_inR1或者xauth_inR2 delete_state如果启动同步功能，顾客态通过监听netlink的socket进行SA同步syn_sa_states_funcdel_established_state (消息SYN_ESTABLISHED_STATE_DEL) clear_syn_sates_by_synid delete_state命令的方式清除SA (进程间通信IKE_CLEAR_SA):ike_clear_sa_cmd clear_states_by_id () find_same_conn_states_to_clearike_clear_sa_cmdclear_states_by_id_only () delete_stateclear_all_states清除所有的SAdelete_stateclear_sates_by_phase根据阶段去删除delete_stateclear_sates_by_phase2delete_stateclear_sates_by_phase3delete_statedelete_states_by_connection 根据连接删除SAdelete_statefind_phase2_state_to_cleardelete_state2.4.5 从内核读取SA检查在idle_max这段时间内，与否有流量。如果有流量，则不需要发送DPD(Dead Peer Detection RFC 3706)检测包，如果没有流量，则发送DPD检测包。dpd_init event_schedule (事件EVENT_DPD) dpd_outIwas_eroute_idle get_sa_info (Netlink 通过类型XFRM_MSG_GETSA获取)3 IKE协商简介IKE(Internet Key Exchange Portocol)，Internet密钥互换合同，是IPSec体系构造中的一种重要合同。IKE协商的成果为通信双方提供了加密算法、认证算法等信息，从而保证通信的安全性。因此IKE协商对于IPSec来说是至关重要的，协商分为两个阶段，第一阶段协商的成果为第二阶段协商提供了保护的功能，协商出来的SA称之为ISAKMP SA；第二阶段协商的成果才是最后通信双方使用的SA。第一阶段分为两种：主模式和野蛮模式，第二阶段是迅速模式。主模式应用于两端IP地址固定的状况，野蛮模式应用于一端地址不固定的状况下。阶段1重要用来协商出ISAKMP SA，该SA用来保证阶段2的通信安全；阶段2用来协商出通信使用的SA。下面从分别从主模式、野蛮模式、迅速模式的包的状况进行分析。包的封装载荷可以看RFC2408，而包互换过程可以参照RFC2409。3.1 主模式（第一阶段）主模式总共需要6个包（3对儿），都是通过载荷进行消息互换(RFC2408，RFC2409)。第1个包发起者发送一种SA，SA中涉及一种Proposal负载，Proposal负载中涉及三个Transform负载。在Transform负载中涉及某些属性：SA的生命周期、加密算法、哈希算法（用来做完整性校验）、认证方式（PSK是预共享的方式）、DH组的位数。如图3-1所示。这个包重要是提供应响应方某些选择方案（3个Transform负载），然后响应包就是拿这三个Transform负载与本地的方案进行比较，选择一种匹配的，然后发给发起者。消息是 isakmp headersa paloadproposal payloadtransform payload(涉及一组属性)图3-1 阶段1主模式第一种包第2个包响应者从中选择一种Transform负载（必须本地支持才行），如果没有与本地匹配的Transform负载，则返回一种错误信息。响应方随机生成一种Cookie，然后选择了一种Transform负载：生命周期：10800秒、加密算法：3DES-CBC、哈希算法：SHA、认证方式：预共享密钥、DH组的位数是：1024-bit 头和载荷：isakmp headersa paloadproposal payloadtransform payload(涉及一组特性)图3-2阶段1主模式第2个包（响应包）第3个包通过DH算法产生共享密钥：头和消息载荷：isakmp头KE(Key Exchange) PayloadnoncePayload图3-3阶段1主模式第3个包DH算法简朴描述如下：图3-3-1DH算法第3个包将Ya和Nonce（随机生成）发送给响应者。这里有点不解是：p和g难道是商定俗成的数据？不需要发起者发给响应者？ 需要再查阐明：即便别人懂得g、p、Ya、Yb，也没措施计算出K，由于不懂得私钥信息Xa或者Xb。第4个包通过DH算法互换密钥信息：头和消息载荷：isakmpKE(Key Exchange)PayloadNoncePayload图3-4阶段1主模式第4个包（响应包）这个时候，双方都可以计算出公共密钥信息K了，有K了，可以计算三个参数（在发送第5、6个消息前计算完毕的）：SKEYID_d是加密的材料，派生自非ISAKMP安全联盟。留在第二阶段使用，用来计算后续的IKE密钥资源；SKEYID_a是ISAKMP SA使用的加密材料，用来认证，提供IKE数据完整性和认证；SKEYID_e是ISAKMP SA使用的加密材料(keying material)，来保护它的消息的机密。用来加密下一阶段的message，data，preshared-key，涉及第二阶段。第5个包加密的消息（使用SKEYID_e对负载进行加密）：头和载荷：isakmpIdentity Payload：用于身份标记涉及什么内容呢？ip地址或者一种标记Hash Payload：用于认证涉及什么内容？根据公式计算出来的图3-5阶段1主模式第5个包身份标记负载的重要内容是涉及自己的IP地址或者是主机名称。散列负载重要的内容是使用SKEYID_a进行的散列计算，见后文中的HASH_I。第6个包加密的消息（使用SKEYID_e对负载进行加密）图3-6 阶段1主模式第6个包当接受方收到的时候进行确认，先解密，然后根据ID(标记)