精华内容
下载资源
问答
  • ikev2
    千次阅读
    2022-05-12 10:41:30

    协商过程不同

    IKEv1

    IKEv1协商安全联盟主要分为两个阶段
            IKEv1阶段1的目的是建立IKE SA,它支持两种协商模式:主模式和野蛮模式。主模式用6条ISAKMP消息完成协商。野蛮模式用3条ISAKMP消息完成协商。野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式密钥交换与身份认证一起进行无法提供身份保护。
            IKEv1阶段2的目的就是建立用来传输数据的IPSec SA,通过快速交换模式(3条ISAKMP消息)完成协商。

    IKEv2

            IKEv2简化了安全联盟的协商过程。IKEv2正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA,如果要求建立的IPSec SA大于一对时,每一对SA只需额外增加1次交换,也就是2条消息就可以完成。

    认证方法不同

            IKEv2支持EAP身份认证。IKEv2可以借助认证服务器对远程接入的PC、手机等进行身份认证、分配私网IP地址。IKEv1无法提供此功能,必须借助L2TP来分配私网地址。

    IKE SA的完整性算法支持情况不同

            IKE SA的完整性算法仅IKEv2支持,IKEv1不支持。

    DPD中超时重传实现不同

            retry-interval参数仅IKEv1支持。表示发送DPD报文后,如果超过此时间间隔未收到正确的应答报文,DPD记录失败事件1次。当失败事件达到5次时,删除IKE SA和相应的IPSec SA。直到隧道中有流量时,两端重新协商建立IKE SA。
            对于IKEv2方式的IPSec SA,超时重传时间间隔从1到64以指数增长的方式增加。在8次尝试后还未收到对端发过来的报文,则认为对端已经下线,删除IKE SA和相应的IPSec SA。

    IKE SA超时时间手工调整功能支持不同

            IKEv2的IKE SA软超时为硬超时的9/10±一个随机数,所以IKEv2一般不存在两端同时发起重协商的情况,故IKEv2不需要配置软超时时间。
                            表12-1 IKE SA超时时间手工调整功能



    IPSec SA超时时间手工调整功能支持不同

            IKEv2的IKE SA软超时为硬超时的9/10±一个随机数,所以IKEv2一般不存在两端同时发起重协商的情况,故IKEv2不需要配置软超时时间。
    表12-2 IPSec SA超时时间手工调整功能

     

     

    更多相关内容
  • VC++开发的RAS拨号程序,支持PPTP L2TP IKEV2协议 。有问题或需要的兄弟或以私信。
  • 国内网络安全IKEv2技术标准,它主要是讲RFC文档做了一个中文的翻译,讲的内容也是很详细的,作为学习IKEv2标准学习的不二选择
  • Windows Server2016内置CA证书,不用域结构和DNS,实现IKEv2详细步骤的屏幕截图.
  • IKEv2-开源

    2021-05-13 05:47:51
    HELLMAN KEY ESTABLISHMENT.............................................................................132.1 Key Management.....................................................................132.2 Diffie...
  • EAP-IKEv2-开源

    2021-05-02 07:07:58
    该项目包含用于freeRADIUS和wpa_supplicant的库和补丁程序,它们实现草稿-tschofenig-eap-ikev2-12.txt Internet-Draft(http://tools.ietf.org/wg/eap/draft-tschofenig-eap-ikev2 -12.txt)
  • ietf-pq-ikev2

    2021-05-29 06:26:16
    IKEv2 的混合 PQ 密钥交换该存储库包含 IKEv2 协议的混合后量子密钥交换草案。
  • 针对IKEv2协议存在的对通信实体的身份保护不足和系统开销大等问题,提出了一种安全高效的改进的IKEv2协议。新协议采用了基于签密的可认证密钥协商来代替D-H密钥交换,在交换秘密信息的同时实现了对协议的发起者与...
  • 分析了IKEv1 中面临的一些问题,结合IKEv2 所做的改进工作,提出了对新版本IKE 的实现方案。
  • ikev2 RFC 5996 - Internet Key Exchange Protocol Version 2 (IKEv2) (ietf.org)https://datatracker.ietf.org/doc/html/rfc5996定义在RFC4306,更新于RFC5996 不兼容IKEV1,ikev1不支持认证,ikev2支持认证,eap...

    ikev2

    RFC 5996 - Internet Key Exchange Protocol Version 2 (IKEv2) (ietf.org)icon-default.png?t=M276https://datatracker.ietf.org/doc/html/rfc5996定义在RFC4306,更新于RFC5996

    不兼容IKEV1,ikev1不支持认证,ikev2支持认证,eap。

    支持nat穿越

    支持私密性、完整性、源认证

    工作在UDP500端口NAT-T时使用UDP4500端口。

    初始交换

    正常情况下,IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段,初始交换包含两次交换四条消息

     

     

    消息①和②属于第一次交换(称为IKE_SA_INIT交换),以明文方式完成IKE SA的参数协商,包括协商加密和验证算法,交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料,通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。

    消息③和④属于第二次交换(称为IKE_AUTH交换),以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP(Extensible Authentication Protocol)。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。

    RFC4306节选:

    使用 IKE 的通信总是从 IKE_SA_INIT 和 IKE_AUTH 交换开始(在 IKEv1 中称为阶段 1)。 这些初始交换通常由四个消息组成,但在某些情况下,数量可能会增加。 所有使用 IKE 的通信都由请求/响应对组成。 我们将首先描述基础交换,然后是变体。 第一对消息 (IKE_SA_INIT) 协商加密算法,交换随机数,并进行 Diffie-Hellman 交换 [DH]。

    第二对消息 (IKE_AUTH) 验证先前的消息,交换身份和证书,并建立第一个 CHILD_SA。 这些消息的一部分通过 IKE_SA_INIT 交换建立的密钥进行加密和完整性保护,因此对窃听者隐藏身份,并且所有消息中的所有字段都经过身份验证。

    初步交流如下:
    
           Initiator                          Responder
          -----------                        -----------
           HDR, SAi1, KEi, Ni   -->
                                <--    HDR, SAr1, KEr, Nr, [CERTREQ]
    

    HDR 包含各种安全参数索引 (SPI)、版本号和标志。 SAi1 载荷携带发起方为 IKE_SA 支持的加密算法。 KE 载荷携带发起者的 Diffie-Hellman 值(K值)。 Ni是发起者的nonce。

    响应者从发起者提供的选项中选择一个加密套件,并在 SAr1 有效负载中表达该选择,完成与 KEr 有效负载的 Diffie-Hellman 交换,并在 Nr 有效负载中发送其随机数。

      Notation    Payload
       -----------------------------------------
       AUTH        Authentication
       CERT        Certificate
       CERTREQ     Certificate Request
       CP          Configuration
       D           Delete
       EAP         Extensible Authentication
       HDR         IKE header (not a payload)
       IDi         Identification - Initiator
       IDr         Identification - Responder
       KE          Key Exchange,发起方提供的密钥交换材料,优先使用最高安全级别的dh组
       Ni, Nr      Nonce
       N           Notify
       SA          Security Association,发起方提供的密码学算法
       SK          Encrypted and Authenticated,负载被加密并且完整性保护
       TSi         Traffic Selector - Initiator,感兴趣流
       TSr         Traffic Selector - Responder,感兴趣流
       V           Vendor ID
     
    

    1.2消息用于初始交换,相当于ike v1主模式的1234消息。

     

    第一个包:发起方提供基本的ike sa参数和密钥交换材料

    responder cookie的值为0,flags位的init值置位,标志发起方,messageid的值也为0,该值和下一个回应方的message id值相同,用来标识一对request/response消息对。

    第二个包:响应方发送匹配的ike sa参数和密钥交换材料

    3.4个包是ike-auth

    ike-auth在ike-sa-init所创建的ike-sa之上,协商各种加密、验证、完整性校验协议,用于建立第一个child-sa。

    协商到达这一步,每一方都可以生成 SKEYSEED,从该 SKEYSEED 中为该 IKE_SA 派生所有密钥。 除了后面的所有消息的头部之外,所有消息都经过加密和完整性保护。 用于加密和完整性保护的密钥源自 SKEYSEED,称为 SK_e(加密)和 SK_a(身份验证,也称为完整性保护)。 为每个方向计算单独的 SK_e 和 SK_a。 除了从 DH 值导出的用于保护 IKE_SA 的密钥 SK_e 和 SK_a 之外,还导出了另一个数量 SK_d 并将其用于导出用于 CHILD_SA 的进一步密钥材料。 符号 SK { ... } 表示这些有效载荷是使用该方向的 SK_e 和 SK_a 加密和完整性保护的。

                     Initiator                                  Responder 
                    -----------                                -----------
     HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                      AUTH, SAi2, TSi, TSr}     -->
                                                <--    HDR, SK {IDr, [CERT,] AUTH,
                                                       SAr2, TSi, TSr}
    
    

    发起者用 IDi 有效载荷声明其身份,证明与 IDi 对应的秘密的知识,完整性保护使用 AUTH 有效载荷的第一条消息的内容。 它还可能在 CERT 有效负载中发送其证书,并在 CERTREQ 有效负载中发送其信任列表。 如果包含任何 CERT 有效负载,则提供的第一个证书必须包含用于验证 AUTH 字段的公钥。 可选的有效载荷 IDr 使发起者能够指定它想要与哪个响应者的身份进行交谈。 当运行响应程序的机器在同一个 IP 地址托管多个身份时,这很有用。 发起者使用 SAi2 有效负载开始协商 CHILD_SA。 最后的字段(从 SAi2 开始)在 CREATE_CHILD_SA 交换的描述中描述。

    响应者使用 IDr 有效负载声明其身份,可选地发送一个或多个证书(再次使用包含用于验证第一个列出的 AUTH 的公钥的证书),验证其身份并使用 AUTH 有效负载保护第二条消息的完整性,以及 使用 CREATE_CHILD_SA 交换中描述的附加字段完成 CHILD_SA 的协商。

    消息 3 和 4 的接收者必须验证所有签名和 MAC 的计算是否正确,并且 ID 有效负载中的名称与用于生成 AUTH 有效负载的密钥相对应。

    SK:负载被加密并且完整性保护

    AUTH:发起方认证数据,如果没有EAP就没有这个字段

    SAi2:发起方child sa转换集,描述create-child-sa的交换参数,指的是ipsec sa,而init中的SAi1指的是IKE SA

    TSi/TSr:child sa流量选择器,即感兴趣流,在ikev2中感兴趣流是可以进行协商的,协商得到交集。

    第三个包(加密):创建child sa相关的认证内容和参数

    相当于ikev1的主模式5和部分快速模式的内容

    第四个包(加密):创建与child sa相关的认证内容和参数

    相当于ikev1主模式的第6个包和部分快速模式的包

     

    创建子SA交换

    当一个IKE SA需要创建多对IPSec SA时,需要使用创建子SA交换来协商多于一对的IPSec SA。另外,创建子SA交换还可以用于IKE SA的重协商。

    创建子SA交换包含一个交换两条消息,对应IKEv1协商阶段2,交换的发起者可以是初始交换的协商发起方,也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行,交换消息由初始交换协商的密钥进行保护。

    类似于IKEv1,如果启用PFS,创建子SA交换需要额外进行一次DH交换,生成新的密钥材料。生成密钥材料后,子SA的所有密钥都从这个密钥材料衍生出来。

    rfc4306节选:

    创建子SA交换

    此交换由单个请求/响应对组成,在 IKEv1 中称为第 2 阶段交换。 它可以在初始交换完成后由 IKE_SA 的任一端发起。

    初始交换之后的所有消息都使用 IKE 交换的前两条消息中协商的加密算法和密钥进行加密保护。  所有后续消息都包含一个加密有效载荷。

    任何一个端点都可以启动CREATE_CHILD_SA交换,因此在本节中,术语“启动器”指启动此交换的端点。

    CHILD_SA 是通过发送 CREATE_CHILD_SA 请求来创建的。 CREATE_CHILD_SA 请求可以可选地包含一个 KE 有效负载,用于额外的 Diffie-Hellman 交换,以增强对 CHILD_SA 前向保密的保证。 CHILD_SA 的密钥材料是 IKE_SA 建立期间建立的 SK_d、CREATE_CHILD_SA 交换期间交换的 nonces 和 Diffie-Hellman 值的函数(如果 KE 有效负载包含在 CREATE_CHILD_SA 交换中)。

    在作为初始交换的一部分创建的 CHILD_SA 中,不得发送第二个 KE 有效负载和 nonce。 初始交换的随机数用于计算 CHILD_SA 的密钥。

       The CREATE_CHILD_SA request contains:
    
           Initiator                                 Responder
          -----------                               -----------
           HDR, SK {[N], SA, Ni, [KEi],
               [TSi, TSr]}             -->
       The CREATE_CHILD_SA response contains:
    
                                       <--    HDR, SK {SA, Nr, [KEr],
                                                   [TSi, TSr]}
    

    发起者在 SA 有效载荷中发送 SA 提议,在 Ni 有效载荷中发送随机数,在 KEi 有效载荷中发送可选的 Diffie-Hellman 值,以及在 TSi 和 TSr 有效载荷中建议的流量选择器。 如果这个 CREATE_CHILD_SA 交换正在更新除 IKE_SA 之外的现有 SA,则 REKEY_SA 类型的前导 N 有效负载必须标识正在更新密钥的 SA。 如果这个 CREATE_CHILD_SA 交换没有更新现有 SA 的密钥,则必须省略 N 有效载荷。 如果 SA 提议包含不同的 Diffie-Hellman 组,则 KEi 必须是发起方期望响应方接受的组的一个元素。 如果它猜错了,CREATE_CHILD_SA 交换将失败,它必须用不同的 KEi 重试。

    使用为IKE_SA协商的加密算法对标头后面的消息进行加密,并对包含标头的消息进行完整性保护。

    如果 KEi 包含在请求中并且所选加密套件包含该组,则响应者使用 SA 有效负载中接受的提议和 KEr 有效负载中的 Diffie-Hellman 值来回复(使用相同的消息 ID 进行响应)。 如果响应者选择了具有不同组的加密套件,它必须拒绝该请求。 发起者应该重复请求,但现在使用响应者选择的组中的 KEi 有效负载。

    在该 SA 上发送的流量的流量选择器在 TS 有效载荷中指定,它可能是 CHILD_SA 的发起者提议的内容的子集。 如果此 CREATE_CHILD_SA 请求用于更改 IKE_SA 的密钥,则忽略流量选择器。

     

     

     共享密钥计算如下。 一个称为 SKEYSEED 的数量是根据在 IKE_SA_INIT 交换期间交换的随机数和在该交换期间建立的 Diffie-Hellman 共享秘密计算得出的。 SKEYSEED 用于计算其他七个秘密: SK_d 用于为使用此 IKE_SA 建立的 CHILD_SA 导出新密钥; SK_ai 和 SK_ar 用作完整性保护算法的密钥,用于验证后续交换的组件消息; SK_ei 和 SK_er 用于加密(当然还有解密)所有后续交换; 以及 SK_pi 和 SK_pr,它们在生成 AUTH 有效负载时使用。

     SKEYSEED = prf(Ni | Nr, K)
    
           {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
                     (SKEYSEED, Ni | Nr | SPIi | SPIr )

    (表示量SK_d、SK_ai、SK_ar、SK_ei、SK_er、SK_pi、SK_pr从prf+的生成位开始依次取)。 K是来自短暂的 Diffie-Hellman 交换的共享秘密。 g^ir 表示为大端顺序的八位字节串,如有必要,用零填充以使其成为模数的长度。 Ni 和 Nr 是随机数,没有任何标题。 如果协商的 prf 采用一个固定长度的密钥,并且 Ni 和 Nr 的长度加起来不等于该长度,则一半的位必须来自 Ni,一半来自 Nr,取每个的第一个位。

    两个交通流方向使用不同的密钥。 用于保护来自原始发起者的消息的密钥是 SK_ai 和 SK_ei。 用于保护另一个方向的消息的密钥是 SK_ar 和 SK_er。 每个算法都采用固定数量的密钥材料,这是算法的一部分。 对于基于密钥散列的完整性算法,密钥大小始终等于底层散列函数的输出长度。

    通知交换

    运行IKE协商的两端有时会传递一些控制信息,例如错误信息或者通告信息,这些信息在IKEv2中是通过通知交换完成的。

    通知交换必须在IKE SA保护下进行,也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的,那么通知交换必须由该IKE SA来保护进行;也可能是某子SA的,那么该通知交换必须由生成该子SA的IKE SA来保护进行。

     

    ikev1默认不支持对远程接入者的认证机制,需要配置l2tp,形成l2tp over ipsec

    flags字段不同

    IKEv1与IKEv2的区别:

    可比较的角度:

    1. IPsec建立过程,报文角度

      阶段比较,IKEv1有两个阶段,IKEv2没有阶段。

      • IKEv1

        IKEv1协商安全联盟主要分为两个阶段。

        IKEv1阶段1的目的是建立IKE SA,它支持两种协商模式:主模式和野蛮模式。主模式用6条ISAKMP消息完成协商。野蛮模式用3条ISAKMP消息完成协商。野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式密钥交换与身份认证一起进行无法提供身份保护。

        IKEv1阶段2的目的就是建立用来传输数据的IPSec SA,通过快速交换模式(3条ISAKMP消息)完成协商。

      • IKEv2

        IKEv2简化了安全联盟的协商过程。IKEv2正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA,如果要求建立的IPSec SA大于一对时,每一对SA只需额外增加1次交换,也就是2条消息就可以完成。

    2. 载荷角度

      AUTH,TSi,TSr,EAP

    3. 认证方法

      IKEv2支持EAP身份认证。IKEv2可以借助认证服务器对远程接入的PC、手机等进行身份认证、分配私网IP地址。IKEv1无法提供此功能,必须借助L2TP来分配私网地址。

    4. 支持远程接入

      L2TP OVER IPSEC---------IKEV1解决方案

    5. 其他功能

      NAT -T DPD

      IKE SA的完整性算法支持情况不同。

      IKE SA的完整性算法仅IKEv2支持,IKEv1不支持。

    6. 配置不同

    • DPD中超时重传实现不同。

      retry-interval参数仅IKEv1支持。表示发送DPD报文后,如果超过此时间间隔未收到正确的应答报文,DPD记录失败事件1次。当失败事件达到5次时,删除IKE SA和相应的IPSec SA。直到隧道中有流量时,两端重新协商建立IKE SA。

      对于IKEv2方式的IPSec SA,超时重传时间间隔从1到64以指数增长的方式增加。在8次尝试后还未收到对端发过来的报文,则认为对端已经下线,删除IKE SA和相应的IPSec SA。

    • IKE SA超时时间手工调整功能支持不同。

      IKEv2IKE SA软超时为硬超时的9/10±一个随机数,所以IKEv2一般不存在两端同时发起重协商的情况,故IKEv2不需要配置软超时时间。

     

    总结:

    IKEv1的主要问题:

    • 不支持远程用户接入
    • 协商建立IPSec SA的时间太长

    IKEv2的改进:

    • IKEv1是一个混合型协议,其自身的复杂性不可避免地带来一些安全及性能上的缺陷,已经成为目前实现IPSec系统的瓶颈。
    • IKEv2协议保留了IKEv1的基本功能,并针对IKEv1研究过程中发现的问题进行修订,同时兼顾简洁性、高效性、安全性和见健壮性的需要,整合了IKEv1的相关文档,由RFC4306单个文档替代。通过核心功能最小化规定,新协议极大提高了不同IPSec VPN系统的互操作性。

    IKEv2与IKEv1相比有以下优点:

    • 简化了安全联盟的协商过程,提高了协商效率。

      IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA:第一阶段,通信双方协商和建立IKE本身使用的安全通道,建立一个IKE SA;第二阶段,利用这个已通过了认证和安全保护的安全通道,建立一对IPSec SA。IKEv2则简化了协商过程,在一次协商中可直接生成IPSec的密钥并建立IPSec SA。

    • 修复了多处公认的密码学方面的安全漏洞,提高了安全性能。

    • 加入对EAP(Extensible Authentication Protocol)身份认证方式的支持,提高了认证方式的灵活性和可扩展性。

      EAP是一种支持多种认证方法的认证协议,可扩展性是其最大的优点,即若想加入新的认证方式,可以像组件一样加入,而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。

    • 通过EAP协议解决了远程接入用户的认证问题,彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。

    展开全文
  • IKEv2-camellia.pcap

    2019-10-28 20:40:57
    IKEv2协议使用camellia加密算法的协商报文,交互流程。
  • IPSec IKEv1&IKEv2

    千次阅读 2021-02-04 13:05:37
    文章目录 IKE简介 IKE概述 IKE版本 IKE协商 IKE的三个组件 IKEv1协商安全联盟的过程 IKEv1协商阶段1 野蛮模式适用场景 IKEv1协商阶段2 IKEv2协商安全联盟的过程 初始交换 创建子SA交换 通知交换 IKE安全机制 IPSec...


    IKE简介

    IKE概述

    因特网密钥交换IKE(Internet Key Exchange)协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上,是基于UDP(User Datagram Protocol)的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务,能够简化IPSec的配置和维护工作。

    IKE与IPSec的关系如图1所示,对等体之间建立一个IKE SA完成身份验证和密钥信息交换后,在IKE SA的保护下,根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后,对等体间的数据将在IPSec隧道中加密传输。

    IKE SA是一个双向的逻辑连接,两个对等体间只建立一个IKE SA。

    在这里插入图片描述

    IKE版本

    IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点:

    • 简化了安全联盟的协商过程,提高了协商效率。
    • IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA:第一阶段,通信双方协商和建立IKE本身使用的安全通道,建立一个IKE SA;第二阶段,利用这个已通过了认证和安全保护的安全通道,建立一对IPSec SA。IKEv2则简化了协商过程,在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
    • 修复了多处公认的密码学方面的安全漏洞,提高了安全性能。

    IKE协商

    IKE的三个组件

    在这里插入图片描述

    • SKEME:定义如何通过公共密钥技术(DH算法)实现密钥交换。
    • Oakley:提供了IPSec对各种技术的支持,例如对新的加密与散列技术,但并没有具体的定义使用什么样的技术。
    • ISAKMP:定义了消息交换的体系结构,包括两个IPSec对等体间分组形态和状态转变(定义封装格式和协商包交换的方式)。

    IKEv1协商安全联盟的过程

    在这里插入图片描述

    采用IKEv1协商安全联盟主要分为两个阶段:第一阶段,通信双方协商和建立IKE协议本身使用的安全通道,即建立一个IKE SA;第二阶段,利用第一阶段已通过认证和安全保护的安全通道,建立一对用于数据安全传输的IPSec安全联盟。

    IKEv1协商阶段1

    IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证,这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。

    两个对等体间只有一个IKE SA,它是一个双向逻辑连接。

    IKEv1协商阶段1支持两种协商模式:主模式(Main Mode)和野蛮模式(Aggressive Mode)。

    主模式包含三次双向交换,用到了六条ISAKMP信息,协商过程如图1所示。这三次交换分别是:

    1. 消息①和②用于提议交换
      发起方发送一个或多个IKE安全提议,响应方查找最先匹配的IKE安全提议,并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
    2. 消息③和④用于密钥信息交换
      双方交换Diffie-Hellman公共值和nonce值,用于IKE SA的认证和加密密钥在这个阶段产生。
    3. 消息⑤和⑥用于身份和认证信息交换(双方使用生成的密钥发送信息),双方进行身份认证和对整个主模式交换内容的认证。
    • Efficient VPN仅支持野蛮模式。
    • IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
    • nonce是个随机数,用于保证IKE SA存活和抗重放攻击。

    野蛮模式只用到三条信息

    1. 消息①和②用于协商IKE安全提议,交换Diffie-Hellman公共值、必需的辅助信息(与密钥生成相关信息)以及身份信息。
    2. 消息②中对收到的第一个数据包进行确认,查找并返回匹配的参数,密钥生成信息和身份验证信息。
    3. 消息③用于响应方认证发起方,并建立IKE SA。

    IKEv1协商阶段1的协商过程如图1所示。

    图1 IKEv1协商阶段1的协商过程图
    在这里插入图片描述
    与主模式相比,野蛮模式减少了交换信息的数目,提高了协商的速度,但是没有对身份信息进行加密保护。

    野蛮模式适用场景

    与主模式相比,野蛮模式减少了交换信息的数目,提高了协商的速度,但是没有对身份信息进行加密保护。虽然野蛮模式不提供身份保护,但他可以满足某些特定的网络环境需求。

    • 当IPSec隧道中存在NAT设备时,需要用到NAT穿越功能,而NAT转换会改变对等体的IP地址,由于野蛮模式不依赖于IP地址标识身份,使得采用预共享秘钥验证方法时,NAT穿越只能在野蛮模式中实现。
    • 如果发起方的IP地址不固定或者无法预先知道,而双方都希望采用预共享秘钥的方法来创建IKE SA,则只能采用野蛮模式。
    • 如果发起方已知响应方的策略,或者对响应者的策略有全面的了解,采用野蛮模式更快。

    IKEv1协商阶段2

    IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA,并为数据传输衍生出密钥。这一阶段采用快速模式(Quick Mode)。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证,并对ISAKMP消息进行加密,故保证了交换的安全性。IKEv1协商阶段2的协商过程如图2所示。

    图2 IKEv1协商阶段2的协商过程图
    在这里插入图片描述
    IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立:

    1. 协商发起方发送本端的安全参数和身份认证信息。

      安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等,可以再次认证对等体。

    IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。

    1. 协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。

      IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出,以保证每个IPSec SA都有自己独一无二的密钥。

      如果启用PFS,则需要再次应用DH算法计算出一个共享密钥,然后参与上述计算,因此在参数协商时要为PFS协商DH密钥组。

    2. 发送方发送确认信息,确认与响应方可以通信,协商结束。

    IKEv2协商安全联盟的过程

    采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA,IKEv1需要经历两个阶段:“主模式+快速模式”或者“野蛮模式+快速模式”,前者至少需要交换9条消息,后者也至少需要6条消息。而IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立,如果要求建立的IPSec SA大于一对时,每一对IPSec SA只需额外增加1次创建子SA交换,也就是2条消息就可以完成。

    IKEv2定义了三种交换:初始交换(Initial Exchanges)、创建子SA交换(Create_Child_SA Exchange)以及通知交换(Informational Exchange)。

    IKEv2中所有消息都以 “请求-响应” 的形式出现,响应方对发起方的消息进行确认,如果在规定的时间内没有收到确认报文,发起方需要对报文进行重传处理,提高了安全性。

    IKEv2还可以防御拒绝服务Dos(Denial of service)攻击,在IKEv1中,当网络中攻击方一直重放消息,响应方需要通过计算后,对其进行响应而消耗设备资源,造成对响应方的Dos攻击,在IKEv2中,响应方收到请求后,并不急于计算,而是先向发起方发送一个Cookie类型的Notify载荷(即一个特定的数值),两者之后的通信必须保持Cookie与发起方之间的对应关系,有效防御了Dos攻击。

    初始交换

    正常情况下,IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段,初始交换包含两次交换四条消息,如图1所示。

    图1 初始交换过程图
    在这里插入图片描述
    消息①和②属于第一次交换(称为IKE_SA_INIT交换),以明文方式完成IKE SA的参数协商,包括协商加密和验证算法,交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料,通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。

    消息③和④属于第二次交换(称为IKE_AUTH交换),以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP(Extensible Authentication Protocol)。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。

    创建子SA交换

    当一个IKE SA需要创建多对IPSec SA时,需要使用创建子SA交换来协商多于一对的IPSec SA。另外,创建子SA交换还可以用于IKE SA的重协商。

    创建子SA交换包含一个交换两条消息,对应IKEv1协商阶段2,交换的发起者可以是初始交换的协商发起方,也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行,交换消息由初始交换协商的密钥进行保护。

    类似于IKEv1,如果启用PFS,创建子SA交换需要额外进行一次DH交换,生成新的密钥材料。生成密钥材料后,子SA的所有密钥都从这个密钥材料衍生出来。

    通知交换

    运行IKE协商的两端有时会传递一些控制信息,例如错误信息或者通告信息,这些信息在IKEv2中是通过通知交换完成的,如图2所示。

    通知交换必须在IKE SA保护下进行,也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的,那么通知交换必须由该IKE SA来保护进行;也可能是某子SA的,那么该通知交换必须由生成该子SA的IKE SA来保护进行。

    图2 通知交换过程图

    在这里插入图片描述

    IKE安全机制

    IKE具有一套自保护机制,可以在网络上安全地认证身份、分发密钥、建立IPSec SA:

    • 身份认证

      身份认证确认通信双方的身份(对等体的IP地址或名称),包括预共享密钥PSK(pre-shared
      key)认证、数字证书RSA(rsa-signature)认证。

    Efficient VPN仅支持预共享密钥认证。

    • 在预共享密钥认证中,通信双方采用共享的密钥对报文进行Hash计算,判断双方的计算结果是否相同。如果相同,则认证通过;否则认证失败。

      当有1个对等体对应多个对等体时,需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立,但安全性较低。

    • 在数字证书认证中,通信双方使用CA证书进行数字证书合法性验证,双方各有自己的公钥(网络上传输)和私钥(自己持有)。发送方对原始报文进行Hash计算,并用自己的私钥对报文计算结果进行加密,生成数字签名。接收方使用发送方的公钥对数字签名进行解密,并对报文进行Hash计算,判断计算结果与解密后的结果是否相同。如果相同,则认证通过;否则认证失败。

      使用数字证书安全性高,但需要CA来颁发数字证书,适合在大型网络中使用。

    IKE支持的认证算法有:SHA2-256。

    • 身份保护

      身份数据在密钥产生之后加密传送,实现了对身份数据的保护。

      IKE支持的加密算法有:3DES、AES-128、AES-192、AES-256。

    • DH

      DH是一种公共密钥交换方法,它用于产生密钥材料,并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后,两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候,通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。

    • PFS

      完善的前向安全性PFS(Perfect Forward Secrecy)通过执行一次额外的DH交换,确保即使IKE SA中使用的密钥被泄露,IPSec SA中使用的密钥也不会受到损害。

    身份认证

    • 在预共享密钥认证中,认证字作为一个输入来产生密钥,通信双方采用共享的密钥对报文进行Hash计算,判断双方的计算结果是否相同。如果相同,则认证通过;否则认证失败。
    • 在数字证书认证中,通信双方使用CA证书进行数字证书合法性验证,双方各有自己的公钥(网络上传输)和私钥(自己持有)。发送方对原始报文进行Hash计算,并用自己的私钥对报文计算结果进行加密,生成数字签名。接收方使用发送方的公钥对数字签名进行解密,并对报文进行Hash计算,判断结果与解密的结果是否相同,相同则认证通过;否则认证失败。
    • 在数字信封认证中,发送方首先随机产生一个对称密钥,使用接收方的公钥对此对称密钥进行加密(被公钥加密的对称密钥称为数字信封),发送方用对称密钥加密报文,同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥,再用对称密钥解密报文,同时根据发送方的公钥对数字签名进行解密,验证发送方的数字签名是否正确。如果正确,则认证通过;否则认证失败。

    DH(Diffie-Hellman)密钥交换算法

    DH算法是一种公开密钥算法。通信双方在不传送密钥的情况下通过交换一些数据,计算出共享的密钥。即时第三方截获了双方用于计算密钥的所有交换数据,也不足以计算出真正的密钥。DH保证了IKE不在网络上直接传输密钥,而是通过一系列数据交换,最终计算出双方共享的密钥。但DH没有提供双方身份的任何信息,不能确定交换的数据是否发送给合法方,第三方可以通过截获的数据与通信双方都协商密钥、共享通信,从而获取和传递信息,所以IKE需要身份认证对对等体身份进行认证。

    密钥材料交换完成后,IKE peer 双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程(预共享秘钥或数字证书都会参与到密钥计算过程中),最终会产生三个密钥(SKEYID为基础密钥,由其推导出其它三个密钥):

    • SKEYID_a:ISAKMP消息完整性验证密钥–谁也别想篡改ISAKMP消息了,只要消息稍微有改动,响应端完整性检查就会发现。

    • SKEYID_e:ISAKMP消息加密密钥–再也别想窃取ISAKMP消息了,窃取了也看不懂

      以上两个密钥保证了后续交换的ISAKMP消息的安全性。

    • SKEYID_d:用于衍生出IPSec报文加密和验证密钥–最终是由这个密钥保证IPSec封装的数据报文的安全性。

    整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期自动刷新,避免了密钥长期不变带来的安全隐患。

    IPSec增强原理

    IPSec多实例

    IPSec多实例主要用于向小企业提供防火墙租赁业务和实现企业内部网络隔离。

    如图1所示,三个小企业的总部共用一台VPN网关。三个企业之间需要保持网络独立,互相之间不会产生影响。三个企业的总部内部网络IP地址是各自规划的,可能出现IP地址重叠(即不同私网出现使用相同IP地址的情况),此时需要在网关上应用IPSec多实例功能,将三个企业的IPSec隧道与三个IPSec多实例绑定,保证相同IP地址的报文能够正确转发。

    图1 IPSec多实例典型组网
    在这里插入图片描述

    < Home

    Efficient VPN

    IPSec VPN技术以其高度的安全性、可靠性以及灵活性成为企业构建其VPN网络的首选。在包含大量分支的IPSec应用中,用户希望各个分支网关的配置能够尽量简单,而复杂的配置集中在总部网关上。Efficient VPN可以解决IPSec VPN分支配置复杂的问题。

    Efficient VPN采用Client/Server结构。它将IPSec及其它相应配置集中在Server端(总部网关),当Remote端(分支网关)配置好基本参数时,Remote端发起协商并与Server端建立起IPSec隧道,然后Server端将IPSec的其它相关属性及其他网络资源推送给Remote端,简化了分支网关的IPSec和其他网络资源的配置和维护。

    运行模式

    • Client模式

      1.Remote端向Server端申请IP地址,同时Remote端自动创建一个LoopBack接口,将从Server端获取的IP地址应用到该LoopBack接口上。

      LoopBack接口满规格时,设备无法自动创建一个LoopBack接口。

      2.Remote端用获取的IP地址与总部建立IPSec隧道。

      Client模式一般用于小的分支机构通过私网接入总部网络,如图1所示。

    图1 Client模式
    在这里插入图片描述

    • Network模式

      Network模式中Remote端不会向Server端申请IP地址。

      Network模式一般用于分支和总部IP地址已统一规划的场景,需要考虑IP地址的规划,各个区域的IP地址不能重叠。

    • Network-plus模式

      与Network模式相比,Network-plus模式中Remote端还会向Server端申请IP地址。这时分支和总部IP地址已统一规划,但Remote端仍会向Server端申请IP地址,获取的IP地址只用于总部对分支进行Ping、STelnet等管理维护。

    Server端除了推送IPSec隧道建立的参数,还可以实现以下资源的推送:

    • DNS域名、DNS服务器地址、WINS服务器地址等网络资源

      Server端通过对以上资源的推送,实现分支访问总部的服务器资源。

    • ACL推送

      Server端将使用ACL定义的总部网络信息推送给Remote端,限定了允许分支子网访问的总部子网范围,目的地不在ACL定义的网络信息范围内的分支子网流量将不会经过IPSec隧道,正常访问Internet。

    展开全文
  • 接上篇blog(59条消息) [RFC5996 翻译一] IKEv2 互联网密钥交换协议版本2_羊羊洒洒_Blog的博客-CSDN博客 3.15.配置负载 Configuration Payload 配置负载,在本文档中表示为 CP,用于在 IKE 对等体之间交换配置...

    rfc5996 (ietf.org)

    接上篇blog (59条消息) [RFC5996 翻译一] IKEv2 互联网密钥交换协议版本2_羊羊洒洒_Blog的博客-CSDN博客

    3.15.配置负载 Configuration Payload

    配置负载,在本文档中表示为 CP,用于在 IKE 对等体之间交换配置信息。交换是为了让 IRAC 从 IRAS 请求一个内部 IP 地址,并交换其他信息,如果 IRAC 直接连接到 LAN,则可以使用动态主机配置协议 (DHCP) 获取此类信息。

    配置负载定义如下:

    配置有效负载的有效负载类型为四十七 (47)。

    o CFG 类型(1 个八位字节) - 由配置属性表示的交换类型。 下表中的值仅是截至 RFC 4306 发布日期的最新值。 其他值可能自那时起添加,或者将在本文档发布后添加。 读者应参考 [IKEV2IANA] 了解最新值。

          CFG Type           Value

          --------------------------

          CFG_REQUEST        1

          CFG_REPLY          2

          CFG_SET            3

          CFG_ACK            4

    o 保留(3 个八位字节) - 必须以零形式发送;必须在收到时忽略。

    o 配置属性(可变长度) - 这些是特定于配置有效负载的类型长度值 (TLV) 结构,定义如下。 此负载中可能有零个或多个配置属性。

    3.15.1. 配置属性

    o 保留(1 位) - 此位必须设置为零,并且在收到时必须忽略。

    o 属性类型(15 位) - 每个配置属性类型的唯一标识符。

    o 长度(2 个八位字节,无符号整数)- 以值的八位字节为单位的长度。

    o 值(0 个或多个八位字节) - 此配置属性的可变长度值。 下面列出了属性类型。

    下表中的值仅是截至 RFC 4306 发布日期的最新值(本文档删除的INTERNAL_ADDRESS_EXPIRY和INTERNAL_IP6_NBNS除外)。 其他值可能自那时起添加,或者将在本文档发布后添加。 读者应参考 [IKEV2IANA] 了解最新值。

          Attribute Type           Value  Multi-Valued  Length

          ------------------------------------------------------------

          INTERNAL_IP4_ADDRESS     1      YES*          0 or 4 octets

          INTERNAL_IP4_NETMASK     2      NO            0 or 4 octets

          INTERNAL_IP4_DNS         3      YES           0 or 4 octets

          INTERNAL_IP4_NBNS        4      YES           0 or 4 octets

          INTERNAL_IP4_DHCP        6      YES           0 or 4 octets

          APPLICATION_VERSION      7      NO            0 or more

          INTERNAL_IP6_ADDRESS     8      YES*          0 or 17 octets

          INTERNAL_IP6_DNS         10     YES           0 or 16 octets

          INTERNAL_IP6_DHCP        12     YES           0 or 16 octets

          INTERNAL_IP4_SUBNET      13     YES           0 or 8 octets

          SUPPORTED_ATTRIBUTES     14     NO            Multiple of 2

          INTERNAL_IP6_SUBNET      15     YES           17 octets

    * 仅当请求了多个值时,这些属性才可以在返回时具有多个值。

    o INTERNAL_IP4_ADDRESS,INTERNAL_IP6_ADDRESS - 内部网络上的地址,有时称为红色节点地址或专用地址,它可能是Internet上的专用地址。  在请求消息中,指定的地址是请求的地址(如果没有请求特定地址,则为零长度地址)。 如果请求特定地址,则可能表示以前存在与此地址的连接,并且请求者希望重用该地址。 使用 IPv6,请求者可以提供它想要使用的低阶地址八位字节。 可以通过请求多个内部地址属性来请求多个内部地址。响应者最多只能发送请求的地址数。 INTERNAL_IP6_ADDRESS由两个字段组成:第一个是 16 个八位字节的 IPv6 地址,第二个是 [ADDRIPV6] 中定义的一个八位字节前缀长度。 只要请求该地址的此 IKE SA(或其重新键入的后续地址)有效,请求的地址就是有效的。 第 3.15.3 节对此有更详细的描述。

    o INTERNAL_IP4_NETMASK - 内部网络的网络掩码。 请求和响应消息中只允许使用一个网络掩码(例如,255.255.255.0),并且必须仅与INTERNAL_IP4_ADDRESS属性一起使用。 CFG_REPLY中的INTERNAL_IP4_NETMASK与包含相同信息INTERNAL_IP4_SUBNET大致相同("通过我向这些地址发送流量"),但也意味着链接边界。 例如,客户端可以使用自己的地址和网络掩码来计算链路的广播地址。 空INTERNAL_IP4_NETMASK属性可以包含在请求此信息CFG_REQUEST中(尽管网关可以发送信息,即使未请求)。 CFG_REQUEST中此属性的非空值没有意义,因此不得包含。

    o INTERNAL_IP4_DNS,INTERNAL_IP6_DNS - 指定网络中 DNS 服务器的地址。 可以请求多个 DNS 服务器。响应程序可以使用零个或多个 DNS 服务器属性进行响应。

    o INTERNAL_IP4_NBNS - 指定网络中 NetBios 名称服务器 (WINS) 的地址。 可以请求多个 NBNS 服务器。 响应程序可以使用零个或多个 NBNS 服务器属性进行响应。

    o INTERNAL_IP4_DHCP,INTERNAL_IP6_DHCP - 指示主机将任何内部 DHCP 请求发送到属性中包含的地址。 可以请求多个 DHCP 服务器。 响应程序可以使用零个或多个 DHCP 服务器属性进行响应。

    o APPLICATION_VERSION - IPsec 主机的版本或应用程序信息。 这是一个不以空值终止的可打印 ASCII 字符字符串。

    o INTERNAL_IP4_SUBNET - 此边缘设备保护的受保护子网。 此属性由两个字段组成:第一个是 IP 地址,第二个是网络掩码。可以请求多个子网络。 响应程序可以使用零个或多个子网属性进行响应。 第 3.15.2 节对此进行了更详细的讨论。

    o SUPPORTED_ATTRIBUTES - 在请求中使用时,此属性的长度必须为零,并指定对响应程序的查询,以使用它支持的所有属性进行回复。 响应包含一个属性,该属性包含一组属性标识符,每个属性标识符以 2 个八位字节表示。 长度除以 2(八位字节)将表示响应中包含的受支持属性的数量。

    o INTERNAL_IP6_SUBNET - 此边缘设备保护的受保护子网。 此属性由两个字段组成:第一个是 16 个八位字节的 IPv6 地址,第二个是 [ADDRIPV6] 中定义的一个八位字节前缀长度。 可以请求多个子网络。 响应者可以使用零个或多个子网属性进行响应。 第 3.15.2 节对此进行了更详细的讨论。

    请注意,本文档中没有关于实现如何实际计算出要在响应中发送哪些信息的建议。 也就是说,我们不建议使用 IRAS 的任何特定方法来确定应将哪个 DNS 服务器返回给发出请求的 IRAC。

    CFG_REQUEST和CFG_REPLY对允许 IKE 终结点从其对等方请求信息。 如果CFG_REQUEST配置负载中的某个属性的长度不是零,则会将其视为该属性的建议。 CFG_REPLY配置有效负载可能会返回该值或新值。 它还可能添加新属性,但不包括一些请求的属性。 在请求和响应中必须忽略无法识别或不受支持的属性。

    CFG_SET和CFG_ACK对允许 IKE 端点将配置数据推送到其对等方。 在这种情况下,CFG_SET配置有效负载包含发起者希望其对等方更改的属性。 如果响应者接受任何配置数据,则它必须返回配置有效负载,并且它必须包含响应程序接受的具有零长度数据的属性。它不接受的那些属性不得位于CFG_ACK配置有效负载中。 如果未接受任何属性,则响应程序必须返回空CFG_ACK有效负载或没有CFG_ACK有效负载的响应消息。 目前没有定义CFG_SET/CFG_ACK交换的用途,尽管它们可能与基于供应商 ID 的扩展结合使用。 此规范的实现可能会忽略CFG_SET有效负载。

    3.15.2. INTERNAL_IP4_SUBNET和INTERNAL_IP6_SUBNET的含义

    INTERNAL_IP4/6_SUBNET属性可以指示可以通过公布属性的网关访问的其他子网,即需要一个或多个单独 SA 的子网。 INTERNAL_IP4/6_SUBNET属性还可以表示网关关于应通过网关发送哪些流量的策略; 客户端可以选择是将其他流量(由 TSr 覆盖,但不在INTERNAL_IP4/6_SUBNET中)通过网关发送还是直接发送到目标。 因此,发往INTERNAL_IP4/6_SUBNET属性中列出的地址的流量应通过宣布属性的网关发送。 如果没有流量选择器覆盖相关地址的现有子 SA,则需要创建新的 SA。

    例如,如果有两个子网,则 198.51.100.0/26 和 192.0.2.0/24,并且客户端的请求包含以下内容:

      CP(CFG_REQUEST) =

         INTERNAL_IP4_ADDRESS()

       TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)

       TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

    则有效响应可以是以下内容(其中 TSr 和 INTERNAL_IP4_SUBNET包含相同的信息):

       CP(CFG_REPLY) =

         INTERNAL_IP4_ADDRESS(198.51.100.234)

         INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

         INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

       TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

       TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),

              (0, 0-65535, 192.0.2.0-192.0.2.255))

    在这些情况下,INTERNAL_IP4_SUBNET实际上并不携带任何有用的信息。

    另一种不同的可能反应是这样的:

       CP(CFG_REPLY) =

         INTERNAL_IP4_ADDRESS(198.51.100.234)

         INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

         INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

       TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

       TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

    该响应意味着客户端可以通过网关发送其所有流量,但网关不介意客户端是否将INTERNAL_IP4_SUBNET未包含的流量直接发送到目标(无需通过网关)。

    如果网关具有要求两个子网的流量在单独的 SA 中承载的策略,则会出现不同的情况。 然后,这样的响应将向客户端指示,如果它想要访问第二个子网,则需要创建一个单独的 SA:

       CP(CFG_REPLY) =

         INTERNAL_IP4_ADDRESS(198.51.100.234)

         INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

         INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

       TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

       TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

    如果客户端的 TSr 仅包含部分地址空间,则INTERNAL_IP4_SUBNET也很有用。 例如,如果客户端请求以下内容:

       CP(CFG_REQUEST) =

         INTERNAL_IP4_ADDRESS()

       TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)

       TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

    则网关的回应可能是:

       CP(CFG_REPLY) =

         INTERNAL_IP4_ADDRESS(198.51.100.234)

         INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

         INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

       TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

       TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

    由于CFG_REQUESTs中INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET的含义不明确,因此无法在CFG_REQUESTs中可靠地使用它们。

    3.15.3. IPv6 的配置有效负载

    IPv6 的配置有效负载基于相应的 IPv4 有效负载,并不完全遵循"正常的 IPv6 做事方式"。 特别是,不使用 IPv6 无状态自动配置或路由器通告消息,也不使用邻居发现。请注意,还有一个附加文档讨论了 IKEv2 中的 IPv6 配置 ,[IPV6CONFIG]。目前,它是一个实验性文件,但希望随着更多的实施经验,它将获得与本文档相同的标准待遇。

    可以使用INTERNAL_IP6_ADDRESS配置有效负载为客户端分配 IPv6 地址。 最小交换可能如下所示:

       CP(CFG_REQUEST) =

         INTERNAL_IP6_ADDRESS()

         INTERNAL_IP6_DNS()

       TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

       TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

       CP(CFG_REPLY) =

         INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)

         INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)

       TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)

       TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

    客户端可以在CFG_REQUEST发送非空INTERNAL_IP6_ADDRESS属性,以请求特定的地址或接口标识符。网关首先检查指定的地址是否可接受,如果可接受,则返回该地址。 如果地址不可接受,网关将尝试使用带有其他前缀的接口标识符;即使失败,网关也会选择另一个接口标识符。

    INTERNAL_IP6_ADDRESS属性还包含前缀长度字段。 在CFG_REPLY中使用时,这对应于 IPv4 情况下的INTERNAL_IP4_NETMASK属性。

    尽管这种配置 IPv6 地址的方法相当简单,但它有一些限制。 使用 IKEv2 配置的 IPsec 隧道在 IPv6 寻址体系结构意义上不是功能齐全的"接口"[ADDRIPV6]。 特别是,它们不一定具有链路本地地址,这可能会使使用假定它们的协议(如[MLDV2])复杂化。

    3.15.4. 地址分配失败

    如果在处理配置负载期间,响应程序在尝试将 IP 地址分配给启动器时遇到错误,则会使用INTERNAL_ADDRESS_FAILURE通知进行响应。即使由于此故障而无法创建初始子 SA,仍会创建 IKE SA。 如果在IKE_AUTH交换中生成此错误,则不会创建子 SA。 但是,还有一些更复杂的错误情况。

    如果响应程序根本不支持配置负载,则只需忽略所有配置负载即可。 这种类型的实现从不发送INTERNAL_ADDRESS_FAILURE通知。如果启动器要求分配 IP 地址,它将把不CFG_REPLY的响应视为错误。

    启动器可以请求响应程序不支持的特定类型的地址(IPv4 或 IPv6),即使响应程序支持配置有效负载也是如此。 在这种情况下,响应程序只是忽略它不支持的地址类型,并像往常一样处理请求的其余部分。

    如果发起方请求响应程序支持的类型的多个地址,并且某些(但不是全部)请求失败,则响应方仅使用成功的地址进行回复。 仅当无法分配地址时,响应程序才会发送INTERNAL_ADDRESS_FAILURE。

    如果启动器未收到其策略所需的 IP 地址,它可以保持 IKE SA 正常运行,并在适当的超时后将配置有效负载作为单独的信息交换重试,或者它可能会通过在单独的信息交换中发送删除有效负载来拆除 IKE SA,然后在超时一段时间后从头开始重试 IKE SA。

    这样的超时不应该太短(特别是如果 IKE SA 从头开始),因为这些错误情况可能无法快速修复;超时可能为几分钟。 例如,只有当其他客户端断开连接时,或者当响应程序重新配置了更大的地址池时,响应程序上的地址短缺问题才可能得到解决。

    3.16. 可扩展认证协议 (EAP) 有效负载

    可扩展身份验证协议有效负载(在本文档中称为 EAP)允许使用 RFC 3748 [EAP] 中定义的协议和该协议的后续扩展对 IKE SA 进行身份验证。使用 EAP 时,需要选择适当的 EAP 方法。已经定义了其中许多方法,指定了协议与各种身份验证机制的用法。 EAP 方法类型列在 [EAP-IANA] 中。 为清楚起见,此处包含 EAP 格式的简短摘要。

    EAP 有效负载的有效负载类型为四十八 (48)。

    o 代码(1 个八位字节)指示此消息是请求 (1)、响应 (2)、成功 (3) 还是失败 (4)。

    o 标识符(1 个八位字节)在 PPP 中用于区分重播消息和重复消息。 由于在 IKE 中,EAP 通过可靠的协议运行,因此它在这里没有任何作用。 在响应消息中,必须将此八位字节设置为与相应请求中的标识符匹配。

    o 长度(2 个八位字节,无符号整数)是 EAP 消息的长度,必须比封装有效负载的有效负载长度小 4 个。

    o 仅当代码字段为"请求(1)"或"响应"(2)时,才存在类型(1个八位字节)。 对于其他代码,EAP 消息长度必须为四个八位字节,并且"类型"和"Type_Data字段不得存在。

    在请求 (1) 消息中,Type 指示所请求的数据。在响应 (2) 消息中,键入必须为 Nak 或与所请求数据的类型匹配。 请注意,由于 IKE 在IKE_AUTH交换中的第一条消息中传递了发起方标识的指示,因此响应程序不应发送 EAP 标识请求(类型 1)。 但是,如果发起方收到此类请求,则发起方可以响应这些请求。

    o Type_Data(可变长度)因请求类型和相关响应而异。 有关 EAP 方法的文档,请参阅 [EAP]。

    请注意,由于 IKE 在IKE_AUTH交换中的第一条消息中传递了发起方标识的指示,因此响应程序不应发送 EAP 标识请求。 但是,如果发起人收到这些请求,它可以对它们作出回应。

    4. 一致性要求

    为了确保IKEv2的所有实现都可以互操作,除了其他地方列出的要求外,还有"必须支持"的要求。 当然,IKEv2是一种安全协议,其主要功能之一是只允许授权方成功完成SA的建立。

    因此,特定实现可以配置有关算法和可信权限的许多限制中的任何一个,这些限制将阻止通用互操作性。

    IKEv2 旨在允许可与所有兼容实现互操作的最小实现。 以下是在最小实现中可以省略的功能:

    o 能够通过 NAT 协商 SA,并通过 UDP 通过隧道传输生成的 ESP SA。

    o 能够在隧道的远程端请求(并响应请求)临时 IP 地址。

    o 能够支持基于 EAP 的身份验证。

    o 能够支持大于 1 的窗口大小。

    o 能够在单个 IKE SA 中建立多个 ESP 或 AH SA。

    o 能够重新生成 SA 密钥。

    为了确保互操作性,所有实现都必须能够解析所有有效负载类型(如果只是跳过它们),并忽略它不支持的有效负载类型,除非在有效负载标头中设置了关键位。 如果在不受支持的有效负载标头中设置了临界位,则所有实现都必须拒绝包含这些有效负载的消息。

    每个实现都必须能够执行四条消息IKE_SA_INIT和IKE_AUTH交换,从而建立两个SA(一个用于IKE,一个用于ESP或AH)。 如果适合其平台,实现可以是仅启动或仅响应。

    每个实现都必须能够响应 INFORMATIONAL 交换,但最小实现可以使用空响应来响应 INFORMATIONAL 交换中的任何请求(请注意,在 IKE SA 的上下文中,"空"消息由 IKE 标头后跟加密有效负载组成,其中不包含任何有效负载)。

    最小实现可能仅支持CREATE_CHILD_SA交换,以便识别请求并使用NO_ADDITIONAL_SAS类型的 Notify 有效负载拒绝请求。 最小的实现不需要能够启动CREATE_CHILD_SA或信息交换。当 SA 过期时(基于本地配置的生存期值或已传递的八位字节),并且实现可以尝试使用CREATE_CHILD_SA交换续订它,也可以删除(关闭)旧 SA 并创建新 SA。如果响应程序拒绝CREATE_CHILD_SA请求并发出NO_ADDITIONAL_SAS通知,则实现必须能够改为删除旧 SA 并创建新 SA。

    不需要实现来支持请求临时 IP 地址或响应此类请求。 如果实现确实支持发出此类请求,并且其策略要求使用临时 IP 地址,则它必须在IKE_AUTH交换中的第一条消息中包含 CP 有效负载,该有效负载至少包含类型为 INTERNAL_IP4_ADDRESS 或 INTERNAL_IP6_ADDRESS 的字段。所有其他字段都是可选的。 如果实现支持响应此类请求,则必须解析IKE_AUTH交换中第一条消息中类型为 CFG_REQUEST 的 CP 有效负载,并识别类型为 INTERNAL_IP4_ADDRESS 或 INTERNAL_IP6_ADDRESS 的字段。如果它支持租用适当类型的地址,则必须返回类型 CFG_REPLY 包含所请求类型的地址的 CP 有效负载。 响应程序可以包含任何其他相关属性。

    对于要调用符合此规范的实现,必须能够将其配置为接受以下内容:

    o 使用 X.509 (PKIX) 证书的公钥基础结构

    包含大小为 1024 位或 2048 位的 RSA 密钥并对其进行签名,其中传递的 ID 是 ID_KEY_ID、ID_FQDN、ID_RFC822_ADDR 或 ID_DER_ASN1_DN的任何一个。

    o 共享密钥身份验证,其中传递的 ID 是ID_KEY_ID、ID_FQDN或ID_RFC822_ADDR中的任何一个。

    o 身份验证,其中响应程序使用 PKIX 证书进行身份验证,启动器使用共享密钥身份验证进行身份验证。

    5. 安全注意事项

    虽然此协议旨在最大限度地减少向未经身份验证的对等方泄露配置信息,但某些此类披露是不可避免的。 一个对等体或另一个对等体必须首先识别自己,并首先证明其身份。 为避免探测,交易的发起方需要首先标识自身,并且通常需要先对自身进行身份验证。但是,发起方可以了解响应方是否支持 IKE 以及它支持哪些加密协议。 响应者(或模拟响应者的人)不仅可以探测启动器的身份,而且使用 CERTREQ 有效负载可以确定启动器愿意使用哪些证书。

    使用 EAP 身份验证会在一定程度上改变探测可能性。使用 EAP 身份验证时,响应程序会在启动器之前证明其身份,因此知道有效启动器名称的启动器可以向响应方查询其名称和证书。

    使用CREATE_CHILD_SA重复重新生成密钥,而无需额外的Diffie-Hellman交换,使所有SA都容易受到单个密钥的加密分析。 实现者应注意这一事实,并对幂之间的CREATE_CHILD_SA交换设置限制。 本文件没有规定这种限制。使用此处定义的任何群从 Diffie-Hellman 交换派生的键的强度取决于组的固有强度、所用指数的大小以及所使用的随机数生成器提供的熵。由于这些输入,很难确定任何已定义组的键的强度。Diffie-Hellman 群 2,当与强随机数生成器和不小于 200 位的指数一起使用时,通常与 3DES 一起使用。 组 5 提供比组 2 更高的安全性。 第一组仅用于历史目的,除了与DES一起使用外,不能提供足够的力量,DES也仅用于历史用途。实现在建立策略和协商安全参数时应注意这些估计值。

    请注意,这些限制仅限于Diffie-Hellman组本身。 IKE中没有任何内容禁止使用更强的组,也没有任何内容会稀释从较强组获得的强度(受包括PRF在内的其他算法的强度的限制)。 事实上,IKE的可扩展框架鼓励定义更多的群体;使用椭圆曲线组可以使用更小的数字大大增加强度。

    假设所有Diffie-Hellman指数在使用后都会从内存中删除。

    IKE_SA_INIT和IKE_AUTH交换发生在启动器经过身份验证之前。 因此,当部署在任何不安全的网络上时,此协议的实现需要完全可靠。 实现漏洞,特别是 DoS 攻击,可能被未经身份验证的对等方利用。此问题尤其令人担忧,因为基于 EAP 的身份验证中的消息数量不受限制。

    所有键的强度受协商的 PRF 输出大小的限制。 因此,输出小于 128 位的 PRF(例如,3DES-CBC)不得与此协议一起使用。该协议的安全性主要取决于随机选择的参数的随机性。  这些应由强随机或正确播种的伪随机源生成(参见[随机性])。 实现者应注意确保以不破坏密钥安全性的方式设计密钥和随机数的随机数。

    有关此协议中许多加密设计选择的基本原理的信息,请参阅 [SIGMA] 和 [SKEME]。 尽管协商的子 SA 的安全性不依赖于在 IKE SA 中协商的加密和完整性保护的强度,但实现不得协商 NONE 作为 IKE 完整性保护算法或ENCR_NULL作为 IKE 加密算法。

    使用预共享密钥时,一个关键的考虑因素是如何确保这些机密的随机性。 最强的做法是确保任何预先共享的密钥包含与正在协商的最强密钥一样多的随机性。 从密码、名称或其他低熵源派生共享机密是不安全的。 这些来源受到字典和社会工程学攻击等。

    NAT_DETECTION_*_IP通知包含地址和端口的哈希,试图隐藏 NAT 后面的内部 IP 地址。由于 IPv4 地址空间只有 32 位,并且通常非常稀疏,因此攻击者可以通过尝试所有可能的 IP 地址并尝试查找匹配的哈希值来找出 NAT 框后面使用的内部地址。 端口号通常固定为 500,并且可以从数据包中提取 SPI。这会将哈希计算的数量减少到 2^32。 通过对私有地址空间的使用进行有根据的猜测,哈希计算的数量要少得多。 因此,设计人员不应假设使用 IKE 不会泄露内部地址信息。

    当使用不生成共享密钥来保护后续 AUTH 有效负载的 EAP 身份验证方法时,某些中间人服务器模拟攻击是可能的 [EAPMITM]。当 EAP 也用于未受安全隧道保护的协议中时,会发生这些漏洞。 由于 EAP 是一种通用身份验证协议,通常用于提供单点登录功能,因此依赖于不生成共享密钥的 EAP 身份验证方法(也称为非密钥生成 EAP 方法)的已部署 IPsec 解决方案可能会受到威胁由于部署了一个完全不相关的应用程序,该应用程序也碰巧使用相同的非密钥生成EAP方法,但以不受保护的方式。 请注意,此漏洞不仅限于 EAP,还可能发生在重用身份验证基础结构的其他方案中。例如,如果 IKEv2 使用的 EAP 机制使用令牌身份验证器,则中间人攻击者可以模拟 Web 服务器,拦截令牌身份验证交换,并使用它来启动 IKEv2 连接。 因此,应尽可能避免使用非密钥生成 EAP 方法。在使用它们的情况下,这些 EAP 方法的所有用法都应使用受保护的隧道,在该隧道中,发起方在启动 EAP 身份验证之前验证响应方的证书,这一点非常重要。 实施者应在其实现文档中描述使用非密钥生成 EAP 方法的漏洞,以便部署 IPsec 解决方案的管理员了解这些危险。

    使用 EAP 的实现还必须在 EAP 身份验证开始之前对客户端使用基于公钥的服务器身份验证,即使 EAP 方法提供相互身份验证也是如此。 这样可以避免其他 IKEv2 协议变体,并保护 EAP 数据免受活动攻击者的攻击。

    如果 IKEv2 的消息足够长,需要 IP 级碎片,则攻击者可能会通过耗尽重组缓冲区来阻止交换完成。 通过使用哈希和 URL 编码而不是发送证书,可以最大程度地减少这种情况的发生(请参见第 3.6 节)。 [DOSUDPPROT] 中讨论了其他缓解措施。

    准入控制对于协议的安全性至关重要。 例如,用于标识 IKE 对等体的信任锚点可能不同于用于其他形式的信任(如用于标识公共 Web 服务器的信任锚)。此外,尽管 IKE 在为可信对等方的身份、凭据及其之间的相关性定义安全策略方面提供了很大的回旋余地,但显式定义此类安全策略对于安全实现至关重要。

    5.1. 流量选择器授权

    IKEv2 在确定允许对等方创建哪种子 SA 时,依赖于对等授权数据库 (PAD) 中的信息。此过程在 [IPSECARCH] 的第 4.4.3 节中进行了介绍。 当对等方请求使用某些流量选择器创建子 SA 时,PAD 必须包含"子 SA 授权数据",该数据链接由 IKEv2 验证的身份和流量选择器允许的地址。

    例如,可以将 PAD 配置为允许经过身份验证的标识"sgw23.example.com"为 192.0.2.0/24 创建子 SA,这意味着此安全网关是这些地址的有效"代表"。 主机到主机 IPsec 需要类似的条目,例如,将"fooserver4.example.com"与 198.51.100.66/32 链接起来,这意味着此标识是相关地址的有效"所有者"或"代表"。

    如 [IPSECARCH] 中所述,"有必要对子 SA 的创建施加这些限制,以防止经过身份验证的对等方欺骗与其他合法对等体关联的 ID"。 在上面给出的示例中,PAD 的正确配置可防止 sgw23 创建地址为 198.51.100.66 的子 SA,并阻止 fooserver4 创建地址为 192.0.2.0/24 的子 SA。

    请务必注意,仅使用某个特定地址发送 IKEv2 数据包并不意味着有权在流量选择器中使用该地址创建子 SA。 例如,即使 sgw23 能够将其 IP 地址欺骗为 198.51.100.66,它也无法创建与 fooserver4 的流量匹配的子 SA。

    IKEv2 规范未指定使用配置有效负载进行 IP 地址分配与 PAD 的确切交互方式。 我们的解释是,当安全网关使用配置有效负载分配地址时,它还会创建一个临时 PAD 条目,链接经过身份验证的对等标识和新分配的内部地址。

    人们已经认识到,在某些环境中正确配置PAD可能很困难。 例如,如果在一对使用 DHCP 动态分配地址的主机之间使用 IPsec,则很难确保 PAD 为每个 IP 地址指定正确的"所有者"。 这将需要一种机制来安全地传达来自 DHCP 服务器的地址分配,并将它们链接到使用 IKEv2 进行身份验证的身份。

    由于此限制,已知某些供应商会将其 PAD 配置为允许经过身份验证的对等方创建具有流量选择器的子 SA,该子 SA 包含用于 IKEv2 数据包的相同地址。 在可能进行 IP 欺骗的环境中(即几乎无处不在),这基本上允许任何对等方使用任何流量选择器创建子 SA。

    在大多数情况下,这不是一个适当或安全的配置。 有关此问题以及主机到主机 IPsec 的一般限制的广泛讨论,请参阅 [H2HIPSEC]。      

              

     6. IANA 注意事项

    [IKEV2] 定义了许多字段类型和值。 IANA 已经在 [IKEV2IANA] 中注册了这些类型和值,因此它们不会在此处再次列出。

    已从 IKEv2 配置有效负载属性类型表中删除两个项目:INTERNAL_IP6_NBNS和INTERNAL_ADDRESS_EXPIRY。

    此处定义了 IKEv2 参数"通知消息 - 错误类型"注册表中未定义的两个新添加项:

       43   TEMPORARY_FAILURE

       44   CHILD_SA_NOT_FOUND

    IANA 已将现有的 IKEv2 Payload Types 表从以下位置更改为:

       46        Encrypted                        E          [IKEV2]
    
       to
    
       46        Encrypted and Authenticated      SK    [This document]
    

    IANA 已更新所有对 RFC 4306 的引用,以指向本文档。

    展开全文
  • 本文档介绍了 Internet 密钥交换 (IKE) 协议的第 2 版。 IKE 是 IPsec 的一个组件,用于执行相互身份验证以及建立和维护安全关联 (SA)。本文档替换并更新了 RFC 4306,并包含了 RFC 4718 中的所有说明。 目录 1. ...
  • openwrt strongswan IPSec IKEV2

    千次阅读 2021-02-24 17:54:54
    ikev2不兼容IKEv1,IKEv1不支持认证,IKEv2支持认证,支持EAP认证。支持NAT穿越。IKEv2支持私密性、完整性、源认证。工作在UDP 的 500 /4500端口。NAT-T用的是UDP4500端口。 4.什么是strongswan? strongSwan是一个...
  • IPSec的IKEv1和IKEv2协议

    千次阅读 2021-02-23 21:44:03
    IPSec的IKEv1和IKEv2协议 IKE介绍 文章目录IPSec的IKEv1和IKEv2协议IKE介绍IKE与IPSec的关系IKEv1的三个模式主模式和野蛮模式野蛮模式与主模式对比野蛮模式使用场景快速模式IKEv2密钥协商和交换初始交换:IKE安全...
  • IPSec之IKEv2详解

    2022-09-10 22:37:37
    IKEv2协商IPSecSA的过程跟IKEvI有很大差别,最少4条消息就可以创建一对IPSecSA,效率奇高!IKEv2定义了三种交换:初始交换(Initial Exchanges)、创建子SA交换(Create_Child_SA Exchange)通知交换(Informational...
  • Linux下IKEv1和IKEv2协议的仿真分析.pdf
  • IKEv2与IKEv1的差异.doc

    2021-05-17 21:28:40
    IKEv2与IKEv1的差异IKEv2与IKEv1的差异IKEv2与IKEv1的差异摘自RFC4306, 附录 A 1 To define the entire IKE protocol in a single document, replacing?? RFCs 2407, 2408, and 2409 and incorporating subsequent ...
  • IKEv2的密钥计算方式

    2022-05-04 19:21:32
    IKEv2的头两个消息中,通信双方会协商一系列的安全参数。包括,一个加密算法,一个完整性算法,一个DH Group,以及一个PRF伪随机数算法。其中,PRF算法被通信双方用来生成即将被用到的各种密钥。 在讨论密钥...
  • 密钥交换协议之IKEv2

    万次阅读 2020-06-23 08:22:08
    1. IKEv2 1.1 IKEv2简介 IKEv2(Internet Key Exchange Version 2,互联网密钥交换协议第 2 版)是第 1 版本的 IKE 协议(本文简称 IKEv1)的增强版本。 IKEv2 与 IKEv1 相同,具有一套自保护机制,可以在不安全的...
  • 目录StrongSwan IKEv2 搭建Linux 与 Cisco的 GRE Tunnel over IPsec IKEv2环境效果图安装配置应用 StrongSwan IKEv2 搭建Linux 与 Cisco的 GRE Tunnel over IPsec IKEv2 环境 Linux: cat /proc/version Linux ...
  • 数字证书配置IKEv2
  • IKEv2子网之间秘钥重协商

    千次阅读 2019-12-09 21:17:30
    以下根据strongswan代码中的testing/tests/ikev2/net2net-rekey/中的测试环境,验证一下网络到网络的IKEv2协议的秘钥重协商过程。拓扑结构如下: 拓扑图中使用到的设备包括:虚拟网关moon和sun。 moon网关配置 moon...
  • 外部证书服务器充当IKEv2认证方式

    千次阅读 2022-01-19 11:57:52
    crypto ikev2 authorization policy Lxf-IKEv2-Author-Policy pool Lxf-Address-Pool route set access-list Server-Network =========================================================== ! crypto pki ...
  • openswan源码学习3.1 ikev2parent_outI1()3.2 ikev2parent_outI1_withstate()3.3 ikev2_parent_outI1_common()4. 注意事项4.1 关于此报文中涉及的对IKEv2引入的“新特性”说明4.2 在IKEv1与IKEv2在SA载荷结构上的...
  • IPSec IKEV2

    2021-05-18 11:56:34
    理论IKEv2介绍:定义在RFC4306 ,更新与 RFC 5996.不兼容IKEv1,IKEv1不支持认证,IKEv2支持认证,EAP。支持NAT穿越。IKEv2支持私密性、完整性、源认证。工作在UDP 的 500 /4500端口。NAT-T用的是UDP4500端口。 ...
  • crypto ikev2 authorization policy Lxf-IKEv2-Author-Win pool Win7Pool ! crypto pki certificate map Lxf-CertMap-Win 10 subject-name co cn = TCPIPWIN10 ! crypto ikev2 proposal Lxf-IKEv2-Proposal-...
  • IKEv2协议协商流程: (IKE-SA-INIT 交换)第二包 1. IKEv2 协商总体框架 IKEv1协议建立一对IPSec SA,使用主动模式需要9个报文,使用野蛮模式需要使用6个报文方能协商成功。IKEv2对IKEv1协议进行了优化,IKEv2只需要...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,428
精华内容 571
关键字:

ikev2