@ju1900
2017-08-15T09:20:26.000000Z
字数 6158
阅读 1998
日志
IKE是一种混和协议，混和协议的复杂性使其不可避免地带来一些安全及性能上的缺陷，导致其成为整个IP-Sec实现中的瓶颈。为此，IETF一直对现有版本不合理部分积极征集修改意见，陆续推出了新的IKE草案，并于2005年12月26日正式推出了新的IKE协议标准--IKEv2。为了提高IKE的实现效率，简化实现的复杂度，IKEv2对原有版本进行了以下几个方面的改进：
(1)单一文档的定义
IKEv2将整个IKE协议的定义放在一个单一的文档中，这个文档代替了原有的RFC2407，2408以及2409，并且还包含了后来对IKE的各种修改，例如对NAT穿越，可扩展认证，以及远程地址获取等的支持。
(2)简化IKE的会话消息交换
在IKE第一版本中，对消息交换的定义非常复杂。为了使得IKE的定义更加简洁，实现的速度更快，IKEv2将原来IKE第一阶段的8种不同的初始化交换简化为一种交换方式，并且将原先在主模式下需要的6条消息减化为4条消息，还将原版本中第二阶段快速交换模式的3条消息简化为2条。
(3)降低IKE的延时
在IKEv2的初始化交换中，由于通信双方只需要两轮交换(即4条消息)，降低了实施IKE的时间，又由于IKEv2在初始化交换完成后就能建立起第一个Child SA(如IPsecSA)，如果用户程序只需要新建一个IPSec-SA的话，就不需要再进行第二阶段为创建Child SA而发起的交换，这样减少了消息交换的次数，从而进一步降低了延迟。
IKEv2使用由请求一应答对组成的交换来完成协议的协商，协商分为2个阶段：第一阶段称为初始化交换；第二阶段为创建子SA(CREATE一CHILD-SA)交换。另外还有信息交换，用于向对方通知一些出错、配置、删除等消息。下面简要说明IKEv2的交换过程及主要工作原理：
初始交换定义如下：
Initiator Responder-------------------------------------------------------------------HDR, SAi1, KEi, Ni --><-- HDR, SAr1, KEr, Nr, [CERTREQ]HDR, SK {IDi, [CERT,] [CERTREQ,][IDr,] AUTH, SAi2,TSi, TSr} --><-- HDR, SK {IDr, [CERT,] AUTH,SAr2, TSi, TSr}
两个IKEv2实现之间的通信总是以IKE-SA-INIT交换和IKE-AUTH交换开始的，这两个交换被总称为初始交换。这一过程对应于第一版协议中的阶段一，他包含4条消息，头2条消息构成一个初始化交换(IKE-SA-INIT交换)，为IKEv2本身协商安全策略和密钥，用于协商加密算法、交换Nonces并且进行一次Difile一Hellman交换；紧接着2条消息构成了一个验证交换(IKE-AUTH交换)，这2条消息除了通用头部外其余的部分都是利用头2条消息协商的密钥进行加密过的，从而保证其身份信息无法被第三方获取。IKE-AUTH交换需要对IKE-SA_INIT交换中的所有内容进行认证(内容认证可以防止第1/2个消息传输过程中被修改, 导致使用了一个较弱的 proposal)，并对对方的身份信息进行验证，为IKEv2生成安全关联，同时还需要完成对IP-Sec：安全策略和流量选择器的协商，并为IPSec：生成安全关联。成功完成初始交换之后，发起者和应答者都可以发起CREATE-CHIID一SA交换和INFORMATIONAL交换，这两个交换受到初始交换所协商的安全关联的保护。
CREATE-CHILD_SA交换定义如下：
Initiator Responder-------------------------------------------------------------------HDR, SK {SA, Ni, [KEi,]TSi, TSr} --><-- HDR, SK {SA, Nr, [KEr,]
他包含2条消息，对应第一版协议中的阶段二。所谓子SA其实就是第一版协议中提到的IPSec SA。在前面的初始交换结束后，通信双方的任一方均可发动这轮交换。类似于阶段一的后2条消息，阶段二的这2条消息也经过加密保护。通信任意一方作为新的发起方发送一个创建子SA的请求(作为可选项)，这条请求消息可以包含一个新的KE载荷，由此开始再进行一次Diffie-Hellman交换，从而加强安全性。CREATE-CHILD一SA完成的功能有3个：为IKE_SA进行密钥更新(rekey)；协商新的IP-Sec一SA；为IKE-SA所生成的IPSec一SA进行密钥更新rekey。
INFORMATIONAL交换定义如下：
Initiator Responder-------------------------------------------------------------------HDR, SK {[N,] [D,][CP,] ...} --><-- HDR, SK {[N,] [D,][CP,] ...}
通信双方在密钥协商期间，需要传送控制消息，告知对方发生的错误或通知某些事件。为了完成这些操作，IKE定义了信息交换。信息交换中的消息包含0个或多个通知载荷、删除载荷或配置载荷(Configuration Pay-loads)。INFORMATIONAL交换用来传递控制信息给对方，如删除特定的安全关联、请求配置、通知特定事件等。其与第一版协议不同的是，对方收到消息请求后必须做出响应(否则发送者将假定消息在网络中已丢失，并重复发送该消息)，新版协议规定通信节点必须拒绝一切半关闭(Half-open)的连接。这类交换的消息也可以不含任何的载荷，比如一方在探寻对方是否仍在网络中处于存活状态时，就可以发送空消息。需要注意的是，信息交换必须在进行过初始交换后才能进行，并且消息的内容也是经过加密的。在IKEv2中，发起方对在等待时间到达后消息的重传负责，响应方则不必主动重传消息，除非收到对方的一个重传请求。这样发起方必须能够记住每个请求，直到收到请求对应的响应消息为止。在未能确认对方身份的情况下，新协议允许响应者不对发起者的消息做出响应，从而也在一定程度上减少了不必要的通信损耗。
在IKE-SA和CHILDl-SA中所有加密算法的密钥材料，都使用伪随机函数(prf)生成。通信双方中的任意一方均可以生成密钥的种子(SKEYSEED)，对应于本阶段，SKEYSEED值的计算取自IKE-SA-INIT交换期间的Nonces值和Difile-Hellman共享秘密。SKEYSEED用于计算5个其他秘密值：建立第二阶段SA所需要的SK-d，SK-d用来提取用于子SA的密钥；SK-ai和SK-ar被用作验证后续交换的完整性的密钥；用于对后续交换进行加密和解密的SK-ei和SK-er；SK-pi和SK-Pr用于生成身份认证AUTH值。通信的双方各自使用不同的密钥，即用SK-ai和SK-ei保护发起方的消息，而用SK-ar和SK-er保护响应方的消息。
在IKE的协商过程中，由于响应者在接收到第l条消息时即创建状态。因此恶意攻击者可以通过发大量的初始消息使响应者不停地创建状态、耗费内存资源，最终导致内存耗尽、系统崩溃，这就是IKE容易受到的损耗内存资源的DoS攻击。
另外，IKE需要通过Dffie一Hellman交换进行密钥协商，其中的模幂运算会占用较大的计算资源。1个DoS攻击者会通过IP欺骗的方法发起大量虚假交换请求，如果系统不能分辨出这些伪造的请求包，则不得不对伪造的请求进行大量模幂运算，这就是损耗CPU资源的DoS攻击。
IKE提供Cookie的交换，可以提供一定程度的抗DoS攻击，只要发起者确定响应者Cookie域中的Cookie和以前从响应者那里接收到的Cookie不同，他将抛弃消息；相似地，如果响应者确定发起者Cookie域中的Cookie和以前从发起者那里接收到的Cookie不同，他将抛弃消息，不再进行处理。对于IKEv2的初始交换来说，由于发起者事先不知道响应者的Cookie，在发往响应者的第1条消息中响应者的Cookie将被置为O，因此响应者就不可能知道这个创建IKE-SA的请求是否是1个虚假交换请求，因此IKEv2的初始交换也易受到DoS攻击。 IKEv2协议使用nonce交换、无状态的cookie交换、标签技术等保证了所生成密钥的安全性和新鲜性，但是由于该协议基于LIDP(user datagram protoc01)协议，本身无法防止基于分片的DoS攻击。大UDP数据包在网络中传输时会被分片，并且在接收端被重组，基于分片的DoS攻击正是利用这一点向被攻击者发送大量的大数据包，造成被攻击者的IP包重组资源耗尽，从而阻止正常的数据包到达上层应用，最终形成对上层应用的DoS攻击。
为了抵抗DoS攻击对IKEv2的初始交换交换过程再作定义如下：
Initiator Responder-------------------------------------------------------------------HDR(A,0), SAi1, KEi, Ni --><-- HDR(A,0), N(COOKIE)HDR(A,0), N(COOKIE), SAi1,KEi, Ni --><-- HDR(A,B), SAr1, KEr,Nr, [CERTREQ]HDR(A,B), SK {IDi, [CERT,][CERTREQ,] [IDr,] AUTH,SAi2, TSi, TSr} --><-- HDR(A,B), SK {IDr, [CERT,]AUTH, SAr2, TSi, TSr}
通常情况下，发起者和响应者只进行1次交换，发送2条消息：消息①和④。然而，当响应者检测到有大量消息①发送过来时，他不接收这些消息，而是发送1个不受保护的通知载荷作为响应(消息②)，并在其中包括他的Cookie。发起者在接收到这条消息时，重新发送1条发起消息给响应者(消息③)，并在发送的消息中包含他接收到的响应者的Cookie，响应者接收到消息，确认其中包括自己的Cookie时才进行处理，否则丢弃。采用这种方式的交换可以有效地抵御损耗内存资源的DoS攻击。因为在第1次的交换过程中，发起者和响应者都不需要更新状态。这样，如果攻击者发送大量的消息①给攻击目标，但是响应者在接收到这些消息以后，并不会创建新的状态，也就不会为保存状态参数在内存中分配空间，从而使得损耗内存资源的DoS攻击失去作用。而且在第1次交换过程中，发起者的计算量要大于响应者，发起者必须提供SAil，KEi和Ni载荷，而响应者只是简单地计算一个Cookie值作为回应，这样即使有攻击者要进行损耗CPU资源的DoS攻击，在被攻击目标的CPU资源耗尽之前，自己的CPU资源也早已耗尽，从而能有效地抵御这种耗尽内存资源型攻击。
RFC7296 对cookie定义如下
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
<secret> 只有responder知道的周期变化随机密钥| 连接符<VersionIDofSecret> 当重新生成时改变SPIi进行计算可以保证如果并行发起多个IKE SAs, 它们可以得到不同的cookies(假设使用唯一的SPI), 同时可以防止攻击者从一个cookie中获取, 然后使用这个cookie初始化所有IKE_SA_INITNi, 可以防止当攻击者只是获取到message 2 的时候不能伪造message 3对IKEv2协议攻击者可以使用如下方法来构造IKE_SA_INIT请求数据：请求信息包括IKEv2信息头、由10个提议组成的SA载荷、使用8192b Difile-Hellman组的密钥交换载荷和包含256 B随机值的时间载荷，总长度为1884 B。实验表明该长度的数据包在发送时被分片，而以每秒50个左右的速率发送这种分片包就可以使IP包重组代码失效，最终阻止合法的请求数据被路由器中的IKEv2收到。攻击者可以任意生成并发送大数据包给被攻击者，而被攻击者不可避免地要对被分片的数据包进行重组，实现对IKEv2的攻击。
针对这种情况的改进方案是为IKEv2构建IP地址分片重组列表，并将该地址列表与IP包重组代码共享。IP包重组代码在重组数据之前检查数据包的源地址，如果该地址不在列表中则丢弃该包，否则进行包重组。IP地址分片重组列表的构造方法如下：在构造IKEv2的访问控制列表过程中，如果身份类型是IPv4或IPv6地址则直接将地址放入列表；对于其他形式的ID，则需要经过特定转换或者由管理员直接输入，如：使用全称域名时可以通过域名系统获得IP地址，使用电子邮件地址或者证书形式时则可以由管理员直接将IP地址输入。
IP包重组代码在将分片IP包放入重组队列之前，需要对分片IP包进行预处理。对于第1个分片IP包，IP包重组代码会根据IP包所包含的UDP报文中的端口号，判断该IP包所包含的UDP报文是否属于IKEv2协议，若属于则IP包重组代码会将报文的IP地址与IP地址分片重组列表进行匹配，匹配成功则将该IP包放人重组队列并记录IP包标识号(适用于IPv4协议)／分段标识值(适用于IPv6协议)；并将后续的具有相同的源IP地址和IP包标识号／分段标识值的分片IP包放入重组队列进行处理。匹配失败则直接丢弃该包和后续的具有相同IP包标识号／分段标识值的分片IP包。
如果UDP报文不属于IKEv2协议，则分片IP报文按照正常流程进行处理。IP地址分片重组列表中的地址是有限的，重组队列不会因为IKEv2报文分片而溢出，该方案可防止伪造源IP地址的基于分片的DoS攻击。 如果DoS攻击者使用了合法的IP地址，即被攻击者收到了大量使用合法IP地址的IKEv2类型的分片IP包，则被攻击者的IP重组代码需要释放重组队列中具有相同源IP地址的IKEv2类型的分片IP报文及其后续分片，并将后到的IKEv2类型的分片lP报文及其后续分片放入重组队列，这样重组队列也不会因为DoS攻击而溢出，可以防止使用合法IP源地址的基于分片的DoS攻击。该改进方案无需对协议进行修改，也无需其他IKEv2实现的支持，仅需在协议实现时构造IP地址分片重组列表并通知IP重组代码即可。
由于该方案使用底层的IP重组代码来实现对基于分片的DoS攻击的防范，也适用于其他上层协议，具有较好的实用性。