zoukankan      html  css  js  c++  java
  • [ike][ipsec] child sa rekey机制的细节分析

    子标题:ipsec rekey是否会导致丢包

    author: classic_tong

    前言

    什么叫rekey。

    rekey是指ipsec的通信两端定期更换加密信道秘钥的机制。

    为了安全性考虑,随着秘钥使用时间的延迟,对称秘钥被破解的可能性会逐渐增大。所以,定期更换

    对称秘钥,是保证ipsec安全性的必要手段。

    我们知道key有两个key,IKE sa的key和child sa(ipsec sa)的key。所以rekey也有两个,ike rekey

    和child rekey。

    这里只讨论child sa的rekey。

    所有内容,都来自这里:https://tools.ietf.org/html/rfc7296#section-2.8

    一 概念

    rekey是指,一旦满足rekey条件(soft条件)时,会向另一端发送一个CREATE_CHILD_SA请求消息,另一个端回复

    一个CREATE_CHILD_SA响应消息。从而协商出一个新的sa的过程。

    这个时候,旧的SA并没有被删除,一旦瞒住删除条件(hard条件)时,旧的SA会被满足条件的一段,通过INFORMATION条件触发删除。

    rekey的触发条件分三种,时间触发,报数触发,字节数触发。其中各又被分为soft和hard两种条件。用来分别触发上边的描述。

    例如:设置了时间触发为100秒。就是指child sa在协商建立之后的100秒,会启动rekey流程。

    在这个例子里,已strongswan的实现为例,hard = 100秒 + random秒。soft = hard × 90%

    也就是在soft秒的时候,一端会建立新的sa。到hard秒的时候会删掉旧的sa。

    报数与字节数同理,soft永远会先于hard条件到达。

    这里。请注意这个时间差(hard - soft),这是rekey机制的一个潜在的条件。在这个时间段内,必须做好两件事情,才能保证

    rekey过程的平滑,也就是ESP包不丢失。

    第一件事情是完成两端的新SA的建立。

    第二件事情是两端都完成流量从旧SA到新SA的切换。

    在ikev2中,以上触发条件是在ipsec的两端本地设置的。彼此不协商。谁先到底条件,谁就会发起rekey。

    在ikev1中,以上条件是协商处理的。我们只讨论ikev2.

    二 流程

    rekey的常规流程逻辑是不会导致丢包的,利用下图,做详情讲解:

     该图的左边是首先发生rekey的一方,右边是ipsec链接的另一方。

    1. 左边到达rekey的soft触发条件。

    2. 左边发送新建sa的请求消息。

    3. 右边收到消息后,开始在本地创建新的SA。

    4. 右边发送新建sa的响应消息。但是这里有一个条件就是在发送这个包之前,必须保证本地的新SA已经完全就绪,并且随时可用。

      在这之后,右边必须仍旧使用旧的SA发送ESP消息。

    5. 左边收到响应消息后,在本地完成新SA的创建过程。

      新的SA建立好之后,右边将切换使用新的SA给对端发送ESP消息。

    6. 右边收到的新SA发送过来的消息之后,并且解密成功。这个时候说明左边的新SA已经就绪了。

      于是右边将流量从旧的SA切换到新的SA上面去。

    7. 右边可以使用新的SA发送ESP消息了。

    至此,新的SA已经完成了建立和切换的过程,并且不会导致丢包。

    8. 左边到达rekey的hard条件

    9. 左边发送删除旧SA的请求。

    10,右边回应删除旧SA的请求。

    至此,rekey过程完成。

    需要特别说明的是,又可以在rekey期间,左边并没有需要发给对方的ESP报文时。它会发一个假的过去,触发对方切换SA。

    或者,当右边没有收到任何新SA的ESP报文,但是却收到了旧SA的删除请求时,它也会进行SA的切换。(也就是说没有收到图中的5,直接收到了9)

    总结一下,这里边两个关键的逻辑在4和6上面。

    只要是正确的ipsec实现,4上面都不会有问题。所以在6的一些特殊情况下,会导致rekey期间的丢包。

    比如,hard减去soft的时间过短,短到左边的sa创建流程没有及时完成,便触发了右边的流量切换。

    三 多出来的SA

    第一小节中random的作用是为了防止两端同时rekey的出现。

    例如我们一般在配置两边的ipsec隧道时,通常会采用相同的配置,如rekey time=3600秒。

    这个时候如果没有random时间,两边会同时发起rekey。

    同时发起rekey的情况下,两侧的新建sa都会成功,这个时候会出现三个SA。

    每一端都会各自独立检测这个场景,然后发现同时rekey的出现。然后会由发起的人来删除nonce比较小的那个一个SA。

    以此到达删除重复sa的目的。

    四 其他

    RFC里,读到一句话,也不知道什么情况下会出现TS和算法会和就的SA不同。

    Note that, when rekeying, the new Child SA SHOULD NOT have different Traffic Selectors and algorithms than the old one.
  • 相关阅读:
    MySQL常见错误解决方案
    mybatis连接MySQL8出现的问题
    mybatis逆向工程出现的问题
    linux学习——基础命令
    java excel导入oracle数据库
    关于layer弹框点击关闭按钮的问题
    java was started but return exit code=-805306369
    设计模式入门学习笔记----装饰者模式
    设计模式入门学习笔记----观察者模式
    设计模式入门学习笔记----策略模式
  • 原文地址:https://www.cnblogs.com/hugetong/p/11511021.html
Copyright © 2011-2022 走看看