最新IPSecVPN两个阶段协商过程分析李心春Word格式.docx
- 文档编号:22641695
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:22
- 大小:1.10MB
最新IPSecVPN两个阶段协商过程分析李心春Word格式.docx
《最新IPSecVPN两个阶段协商过程分析李心春Word格式.docx》由会员分享,可在线阅读,更多相关《最新IPSecVPN两个阶段协商过程分析李心春Word格式.docx(22页珍藏版)》请在冰豆网上搜索。
(一十九)协商IPSecSA使用的安全参数,创建IPSecSA(SA可以加密两个对等体之间的数据,这才是真正的需要加密的用户数据),使用AH或ESP来加密IP数据流。
至此IPSecVPN隧道才真正建立起来。
(二十)综上,有如下结论:
(二十一)第一阶段作用:
对等体之间彼此验证对方,并协商出IKESA,保护第二阶段中IPSecSA协商过程;
(二十二)第二阶段作用:
协商IPSec单向SA,为保护IP数据流而创建;
(二十三)举例验证:
以主模式,AH协议来简单分析一下IPSecVPN链接建立的过程(附带报文):
(二十四)第一个阶段三个任务,分别用6个消息来完成,每两个为一组,这些消息的具体格式取决于使用的对等体认证方法,使用预共享密钥进行验证的主模式(6条)协商过程使用ISAKMP消息格式来传递(基于UDP,端口号为500)。
6条消息如下:
(二十五)
(二十六)
(二十七)
(1)准备工作:
(二十八)在前2条消息发送之前,发送者和接受者必须先计算出各自的cookie(可以防重放和DOS攻击),这些cookie用于标识每个单独的协商交换消息。
(二十九)cookie——RFC建议将源目的IP、源目的端口、本地生成的随机数、日期和时间进行散列操作。
Cookie成为留在IKE协商中交换信息的唯一标识,实际上cookie是用来防止DOS攻击的,它把和其他设备建立IPSec所需要的连接信息不是以缓存的形式包存在路由器里,而是把这些信息HASH成个cookie值。
(三十)
(2)1&
2消息:
(三十一)消息1:
由发送方(协商发起端)发起,携带一些参数,发送方向接收方发送一条包含一组或多组策略提议(Raisecom工业路由器中是多组),在策略提议中包括5元组信息:
(三十二)加密算法——DES;
(三十三)散列算法——MD5-HMAC;
(三十四)DH——Diffie-Hellman组-2;
(三十五)认证方式——预共享;
(三十六)IKESA寿命。
(三十七)如下是Raisecom中高级选项配置的策略:
(三十八)
(认证方式采用“预共享”方式)
(三十九)
(对于DPD,具体作用不知道,默认是关闭)
(四十)下面简要介绍一下上述五元组信息:
(四十一)(a)协商模式:
可以选择主模式(MainMode)或者野蛮模式(Aggressive)。
当选择主模式时,只能使用IP地址作为ID的类型。
当用户端设备的IP地址为动态获取的情况时,需要选择野蛮模式。
IKE野蛮模式相对于主模式来说更加灵活,可以选择根据协商发起端的IP地址或者ID来查找对应的身份验证字,并最终完成协商。
(四十二)(b)验证方法AH(AuthenticationHeader):
(四十三)身份验证确认通信双方的身份。
目前在IKE提议中,仅可用pre-shared-key(预共享密钥)身份验证方法,使用该验证方法时必须配置身份验证字,并且两端的密钥要完全一致。
(四十四)(c)加密算法:
(四十五)包括DES和3DES加密算法;
DES算法采用56bits的密钥进行加密,3DES算法采用168bits的密钥进行加密;
AES128(AdvancedEncryptionStandard,即高级加密标准)采用Rijndael中的128bits的密钥进行加密;
AES192(AdvancedEncryptionStandard,即高级加密标准)采用Rijndael中的192bits的密钥进行加密;
AES256(AdvancedEncryptionStandard,即高级加密标准)采用Rijndael中的256bits的密钥进行加密;
(四十六)一般来说,密钥越长的算法强度越高,受保护数据越难被破解,但消耗的计算资源会更多。
(四十七)(d)Diffie-Hellman组标识(DH):
(四十八)用户可以选择Group1即768bit或Group2即1024bit。
(四十九)(e)ISAKMP-SA生存周期:
(五十)IKE使用了两个阶段为IPSec进行密钥协商并建立安全联盟。
第一阶段,通信各方彼此间建立了一个已通过身份验证和安全保护的通道,即ISAKMP安全联盟(ISAKMPSA);
第二阶段,用在第一阶段建立的安全通道为IPSec协商安全服务,即为IPSec协商具体的安全联盟,建立IPSecSA,IPSecSA用于最终的IP数据安全传送。
ISAKMP-SA生存周期可以设定为60-604800之间的一个整数。
(五十一)(f)定时发送keepalive报文(不是必须携带):
(五十二)IKE通过ISAKMPSA向对端定时发送KeepAlive报文维护该条ISAKMPSA的链路状态。
当对端在配置的超时时间内未收到此KeepAlive报文时,如该ISAKMPSA带有timeout标记,则删除该ISAKMPSA及由其协商的IPSecSA;
否则,将其标记为timeout。
(五十三)如下是抓包获取到的信息(设备为Raisecom工业路由器):
(五十四)
由上图可知,模式为主模式,载荷类型为SA。
SA的数目和内容详见下图:
(五十五)将载荷类型SA展开如下:
(五十六)由下图可知,该SA中携带了三组策略,正好Raisecom中web页面配置的三组策略:
(五十七)
(五十八)
(五十九)第一组TypePayload:
Transform(3)#0展开如下:
(六十)
SA生存时间为10800;
加密机制为DES;
认证算法为SHA;
认证方法选择PSK(预共享密钥);
DH为Group2;
(六十一)第二组TypePayload:
Transform(3)#1展开如下:
(六十二)
第三组
(六十三)TypePayload:
Transform(3)#2展开如下:
(六十四)
报文中的组顺序和web页面上组顺序不一致,这个无所谓,只要能对上即可,因为实际中只要这三个组能匹配上即可。
(六十五)消息2:
由响应者(即对端设备)回应,内容基本一样,主要与发起者比较,是否与发起者的IKE策略匹配,不匹配则进行下一组比较,如果最终都找不到匹配,隧道就停止建立;
(六十六)(note:
发起者将其所有IKE策略发给接受者,接受者则在自己的策略中寻找与之匹配的策略;
对比顺序从优先级号小的到大的;
默认策略实际就是个模板没作用,如果认证只配置预共享的话,其他参数就会copy默认策略里的)
(六十七)报文如下:
(六十八)
由上图可知,接受端回应的消息中,匹配了发送端的一条策略,如果有一条匹配,则不需要匹配其他策略。
(六十九)在消息1和消息2中报错可能出现的原因:
(七十)(a)peer路由不通(即,外层的IP地址不通,这里对应的是发送发10.1.1.3和接收方10.1.1.2这两个地址不通,这里配置简单属于直连,而实际大型组网中,中间会有很多其他网元,往往是通过配置动态路由);
(七十一)(b)cryptoiskmpkey没有设置(即,没有配置预共享密钥);
(七十二)(c)一阶段的策略不匹配(这时需要检查两端设备的策略有不一致地方么)
(七十三)
(七十四)(3)3&
4消息:
密钥交换过程
(七十五)消息3:
由发起者(即,隧道建立的发起者)发出,但是在发出消息3之前,有个过程必须要完成,就是Diffie-Hellman算法过程。
(七十六)Diffie-Hellman算法过程目的:
在消息1和消息2中所协商的算法,它们必须需要一个KEY(即,共享密钥中设置的密码),这个KEY在两个对等体上必须一样,但同时这个KEY不能在链路中传递,因为传递KEY是一个不安全的手段。
所以,该过程的目的是分别在两个对等体间独立地生成一个DH公共值,该公共值有什么作用?
因为两个对等体上都生成该DH公共值后,它们会在接下来的消息3和消息4中传送给对方,打个比方,A收到了B的DH公共值,B收到了A的DH公共值。
当A、B都收到了对方的该公共值后,问题就好解决了。
因为有一个公式在数学中被论证成立,那么现在借助公式,就可以在两个对等体上生成一个只有它们两个对等体知道的相同的KEY,该公式为:
(七十七)发起者密钥=(Xb)amodp=(Xa)bmodp=响应者密钥
(七十八)note:
这个密钥不是最终算法中使用的KEY,但两个对等体通过该KEY材料来生成另外三个密钥,分别是:
(七十九)SKEYID_d——此密钥被用于计算后续IPSec密钥资源;
(八十)SKEYID_a——此密钥被用于提供后续IKE消息的数据完整性以及认证;
(八十一)SKEYID_e——此密钥被用于对后续IKE消息进行加密;
(八十二)所以,由发起者发起的第三条消息主要是向对等体发送自己的DH公共值和Nonce随机数;
(八十三)实际报文如下:
(八十四)
由上述报文可知,发送方开始向接收方发送自己的DH公共值以及随机数;
(八十五)对端收到后,可以根据“消息1&
消息2”中协商的DH算法,以及发送端在消息3中给出的DH和nonce值来生成SKEYID_d、SKEYID_a、SKEYID_e三个密钥;
(八十六)消息4:
同消息3,告知发送端自己的DH公共值和Nonce随机数;
(八十七)报文如下:
(八十八)
由上述报文可知,接受方开始向发送方发送自己的DH公共值以及随机数;
(八十九)对端收到后,可以根据“消息1&
消息2”中协商的DH算法,以及接受端在消息4中给出的DH和nonce值来生成SKEYID_d、SKEYID_a、SKEYID_e三个密钥;
(九十)
(九十一)(3)5&
6消息:
用于双方彼此验证。
由“于消息1&
消息2”的算法,以及“消息3&
消息4”生成的三个KEY,所以在后续的“消息5&
消息6”就能被加密传送,这个过程是受SKEYID_e加密保护的。
(九十二)预共享密钥的作用:
为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时,由于ID还没到,彼此先用HASH来彼此验证对方)HASH认证成分——SKEYID_a、cookieA、cookieB、preshare_key、SApayload、转换集和策略。
(九十三)消息5:
由发起者向响应者发送,主要是为了验证对端自己就是自己想要与之通信的对端。
这可以通过预共享、数字签名、加密临时值来实现。
(九十四)
(九十五)消息6:
由响应者向发起者发送,主要目的和第五条一样:
(九十六)
(九十七)在消息5和消息6中报错可能出现的原因:
(九十八)
(1)cryptoiskmpkey设置错了;
(即,两端的预共享密钥值设置的不一样)
(九十九)第二阶段:
(一百)第2阶段用三个消息来完成,目标是协商IPSecSA,而且只有一种模式,快速模式(QuickMode),快速模式的协商是受IKESA保护的。
(一百零一)
(一百零二)对应设备上需要配置的参数(以R202i-VM为例):
(一百零三)
(一百零四)
(1)1&
发送IPSecSA的属性,协商IPSecSA
(一百零五)消息1:
发起者会在第一条消息中发送IPSecSA的转换属性。
其中包含:
HASH、IPSec策略提议、Nonce可可选的DH以及身份ID。
(一百零六)(a)HASH:
是用于给接受方作为完整性检验的,用于再次认证对等体(必须)HASH的成分和5-6阶段一样;
(一百零七)(b)IPSec策略提议:
其中包括了安全协议(AH、ESP或AH-ESP)、SPI、散列算法、模式(隧道模式或传输模式)、IPSecSA生命周期(必选);
(一百零八)(c)Nonce:
用于防重放攻击,还被用作密码生成的材料,仅当启用PFS时用到;
(一百零九)(d)ID:
描述IPSecSA是哪些地址、协议和端口建立的,即感兴趣流中的IP地址;
(一百一十)
(一百一十一)(e)PFS(利用DH交换,可选):
用了PFS后,就会在第二阶段重新DH出一个数据加密KEY,这个KEY和以前IKE协商出来的KEY没有任何关系,然后由这个新KEY来加密数据,只有到这个IPSecSA的生命周期后,会再次DH出新的KEY,这样,安全性就提高了(普通IPSecSA过期或密钥超时时,重新生成的数据加密密钥还是根据第一阶段DH出来的SKEYID_d衍生出来的),PFS启用后,数据加密部分使用的密钥就没有了衍生的过程。
(一百一十二)(f)DH:
重新协商IPSecSA时使用的密钥(正常情况下,IPSec阶段使用的密钥都是由SKEYID_d衍生而来的,密钥之间都有一定的关系,就算IPSecSA超时,新的KEY还是和SKEYID_d有一定的关系)。
(一百一十三)
以上数据均被加密处理;
(一百一十四)
(一百一十五)基于以上,第二阶段有几个概念需要理清:
(一百一十六)(a)封装模式:
包括传输模式(Transport)和隧道模式(Tunnel)。
(一百一十七)传输模式:
不使用新的IP头部,IP头部中的源/目的IP为通信的两个实点(当通信点等于加密点时,使用传输模式);
(一百一十八)隧道模式:
需要封装一个新的IP头部,新的IP头部中源/目的IP为中间的VPN网关设备地址(当通信点不等于加密点时使用隧道模式);
(一百一十九)
二者比较:
(一百二十)从安全性来讲,隧道模式优于传输模式,隧道模式可以完全地对原始IP数据报进行验证和加密以及可以使用IPSec对等体的IP地址来隐藏客户机的IP地址;
(一百二十一)从性能来讲,隧道模式比传输模式占用更多带宽,一个额外的IP头;
(一百二十二)因此,到底使用哪种模式需要按照实际的应用场景进行权衡。
(一百二十三)
(一百二十四)(b)安全联盟生存周期:
(一百二十五)所有在安全策略视图下没有单独配置生存周期的安全联盟,都采用全局生存周期。
IKE(因特网密钥交换协议)为IPSec协商建立安全联盟(SA)时,采用本地设置的和对端提议的生存周期中较小的一个(即,当两端配置的生存周期不一致时,那么就用最小的那个值)。
安全联盟生存周期的输入范围:
30~604800;
(一百二十六)所以,两端设备配置的生存周期不一致不会导致隧道无法建立。
(一百二十七)(c)采用的安全协议:
(一百二十八)安全提议中需要选择所采用的安全协议,用于为IP数据包提供安全。
目前可选的安全协议有AH(验证报头)和ESP(封装安全有效负载),也可以指定同时使用AH和ESP(AH-ESP)。
安全隧道两端所选择的安全协议必须一致。
(一百二十九)所以,第二阶段协商不起来,两端协议是否一致是一个排查重点。
(一百三十)AH协议:
类似于ICMP、TCP、UDP的IP协议,分配给它的协议号为51。
提供如下安全功能:
数据完整性服务、提供抗数据回放攻击、不提供数据加密性(不加密)。
(一百三十一)
(一百三十二)(note:
AH是不提供数据的加密的,所以在报文中可以看到完整的DATA部分)
(一百三十三)AH报文头格式:
(一百三十四)
(一百三十五)AH在两种模式下的封装:
(一百三十六)
(一百三十七)ESP协议:
协议号为50,提供如下功能:
提供数据加密性(支持加密)、提供数据完整性、提供抗回放攻击能力;
(一百三十八)ESP的数据验证和完整性服务只包括ESP的头和有效载荷(不包括外部的IP头部)
(一百三十九)(note:
ESP是提供加密的,所以抓取的ESP报文,是看不到原来被封装的数据部分)
(一百四十)
(一百四十一)
(一百四十二)ESP在两种模式下的封装:
(一百四十三)
(一百四十四)AH-ESP共用:
(一百四十五)隧道模式下:
(一百四十六)
(d)ESP协议加密算法:
(一百四十七)ESP能够对IP报文内容进行加密保护,防止报文内容在传输过程中被窥探。
加密算法的实现主要通过对称密钥系统,即使用相同的密钥对数据进行加密和解密。
(一百四十八)一般来说IPSec使用两种加密算法:
DES和3DES。
(一百四十九)(e)ESP协议即AH协议的验证算法:
(一百五十)AH和ESP都能够对IP数据包的完整性进行验证,以判别报文在传输过程中是否被篡改。
(一百五十一)一般来说IPSec使用两种验证算法:
MD5和SHA-1
(一百五十二)MD5:
MD5输入任意长度的消息,产生128bit的消息摘要;
(一百五十三)SHA-1:
SHA-1输入长度小于2的64次方比特的消息,产生160bit的消息摘要。
SHA-1的摘要长于MD5,因而是更安全的。
(一百五十四)(f)使用NAT穿越:
(一百五十五)在IPSec/IKE组建的VPN隧道中,若存在NAT安全网关设备,则必须配置IPSec/IKE的NAT穿越功能。
(一百五十六)消息2:
响应者向发起者发送第二条消息,同意第一条消息中的属性,同时,也能起到确认收到对端消息的作用。
(一百五十七)
(一百五十八)在消息1和消息2中报错可能出现的原因:
(一百五十九)
(1)双方的模式不匹配(即,可能一端用传输模式,另一端用隧道模式);
(一百六十)
(2)感兴趣流不对称(如上述消息1中的(d));
(一百六十一)
(一百六十二)消息3:
发送方发送第三条消息,其中包含一个HASH,其作用是确认接收方的消息以及证明发送方处于Active状态(表示发送方的第一条消息不是伪造的)
(一百六十三)
(一百六十四)这一步一旦完成,隧道就建立起来了,用户的数据就能被放入隧道中传递。
(一百六十五)
(一百六十六)本文参考资料:
(一百六十七)
英文信件格式
英语信件的种类比较多,有一般信件,邀请信,推荐信等。
但几乎所有信件的格式都大同小异。
书写英语信件要注意下面几点:
(一)英语书信结构、书写款式及要求:
1.书信结构
英语书信结构一般有以下几个部分组成:
1)信封(envelope)。
英语的信封和中文的一样,有三部分组成,即发信人地址、收信人地址和邮票。
只不过英语信封的格式除了邮票所贴的位置(信封的右上角)和中文的一样外,英语信封上要写的发信人和收信人的地址和中文的大不一样。
发信人的地址应写在信封的左上角,收信人的地址应写在信封偏中右偏下处,如下:
2)信头(heading),即写发信人的地址和日期(右上角)。
3)信内姓名地址(inside
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 最新 IPSecVPN 两个 阶段 协商 过程 分析 李心春
![提示](https://static.bdocx.com/images/bang_tan.gif)