IPsec传输模式可休矣.docx

上传人:b****2 文档编号:2661111 上传时间:2023-05-04 格式:DOCX 页数:17 大小:635.92KB
下载 相关 举报
IPsec传输模式可休矣.docx_第1页
第1页 / 共17页
IPsec传输模式可休矣.docx_第2页
第2页 / 共17页
IPsec传输模式可休矣.docx_第3页
第3页 / 共17页
IPsec传输模式可休矣.docx_第4页
第4页 / 共17页
IPsec传输模式可休矣.docx_第5页
第5页 / 共17页
IPsec传输模式可休矣.docx_第6页
第6页 / 共17页
IPsec传输模式可休矣.docx_第7页
第7页 / 共17页
IPsec传输模式可休矣.docx_第8页
第8页 / 共17页
IPsec传输模式可休矣.docx_第9页
第9页 / 共17页
IPsec传输模式可休矣.docx_第10页
第10页 / 共17页
IPsec传输模式可休矣.docx_第11页
第11页 / 共17页
IPsec传输模式可休矣.docx_第12页
第12页 / 共17页
IPsec传输模式可休矣.docx_第13页
第13页 / 共17页
IPsec传输模式可休矣.docx_第14页
第14页 / 共17页
IPsec传输模式可休矣.docx_第15页
第15页 / 共17页
IPsec传输模式可休矣.docx_第16页
第16页 / 共17页
IPsec传输模式可休矣.docx_第17页
第17页 / 共17页
亲,该文档总共17页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

IPsec传输模式可休矣.docx

《IPsec传输模式可休矣.docx》由会员分享,可在线阅读,更多相关《IPsec传输模式可休矣.docx(17页珍藏版)》请在冰点文库上搜索。

IPsec传输模式可休矣.docx

IPsec传输模式可休矣

IPsec,传输模式可休矣

西电捷通安全协议技术研究

1.IPsec简介

IPsec(IPsecurity)是IETF(TheInternetEngineeringTaskForce,互联网工程任务组)制定的三层隧道加密协议,它为Internet上传输的数据提供了高质量、可互操作、基于密码学的安全保证。

特定的通信方之间在IP层通过加密与数据源认证等方式,提供了以下的安全服务:

、数据机密性(Confidentiality):

IPsec发送方在通过网络传输包前对包进行加密。

、数据完整性(DataIntegrity):

IPsec接收方对发送方发送来的包进行认证,以确保数据在传输过程中没有被篡改。

、数据源认证(DataOriginAuthentication):

IPsec在接收端可以认证发送IPsec报文的发送端是否合法。

、防重放(Anti-Replay):

IPsec接收方可检测并拒绝接收过时或重复的报文。

IPsec不是一个单独的协议,它给出了应用于IP层上网络数据安全的一整套体系构架,包括AH(AuthenticationHeader,认证头)、ESP(EncapsulatingSecurityPayload,封装安全载荷)、IKE(InternetKeyExchange,因特网密钥交换)和用于网络认证及加密的一些算法等。

其中,AH与ESP是用于提供安全服务的协议,IKE是用于密钥交换的协议。

IPsec具有以下优点:

a、支持IKE(InternetKeyExchange,因特网密钥交换),可实现密钥的自动协商功能,减少了密钥协商的开销。

可以通过IKE建立和维护SA(SecurityAssociation,安全联盟)的服务,简化了IPsec的使用和管理。

b、所有使用IP协议进行数据传输的应用系统和服务都可以使用IPsec,而不必对这些应用系统和服务本身做任何修改。

IPsec具有以下缺点:

a、安全服务协议AH和ESP所提供的功能重叠率非常高,虽然IPsec的最新版本规定AH为可选协议,但是并没有解决IPsec组合的复杂度问题。

从而导致IPsec的工程实现以及部署维护的成本仍旧非常高。

b、安全服务协议的工作模式众多:

传输模式、隧道模式;再加上两种协议的组合,导致IPsec的复杂度高。

协议包含有太多的选项和太多的灵活性,做同样或类似的事有几种方式,从而引入的复杂度会导致工程实现的系统非常复杂,存在的安全漏洞也就非常多,安全评估也就非常困难,从某种意义上来讲,复杂是安全的最大敌人。

由于历史原因(例如,在制定之初,有些技术还没有发展起来;或者有些应用场景还没有出现),IPsec在不断地打补丁、补漏洞导致IPsec到目前为止已然成为了复杂的难以分析其安全性的安全协议。

从工作模式的角度入手,IPsec的工作模式分为传输模式和隧道模式,而这两种工作模式结合AH与ESP以及AH和ESP的组合,又会衍生更多的工作模式,导致IPsec在工程实现、维护上大大加重了其复杂度。

系统越复杂,存在的安全漏洞就越多,安全评估就越困难,复杂性已然成了安全的敌人。

IPsec包含有太多的选项和太多的灵活性,实现同样的或类似的功能通常有好几种方式,这样的膨胀和复杂对于一个安全性的标准,将是毁灭性的危害。

随着技术的发展,根据IPsec设计工作模式的目标,结合工作模式的应用场景建议把IPsec的传输模式淘汰掉(此观点与在荷兰阿姆斯特丹工作的独立的密码学顾问尼尔斯.弗格森和国际知名的安全专家、CounterpaneInternetSecurityInc公司创始人布鲁斯·施奈尔合著的《ACryptographicEvaluationofIPsec》的文章观点不谋而合),以减少其工作模式选项,降低其复杂度,从而减少由于工作模式组合而产生的安全漏洞,提高其安全性。

2.IPsec传输模式已老矣

2.1IPsec应用场景

RFC4301文档《SecurityArchitecturefortheInternetProtocol》(《IP安全构架》)3.1节中描述:

【通过选择适当安全协议、密码算法和密钥,在IP层提供IPsec安全业务。

IPsec能够用于保护一条或多条“路径”,在(a)一对主机间,(b)一对安全网关间,或(c)安全网关和主机间。

这说明IPsec的应用环境为主机间、主机与网关间以及网关间。

图1IPsec主机应用场景

图2IPsec主机网关应用场景

图3IPsec网关应用场景

RFC4301文档4.1节的归纳中描述:

a)IPsec主机实现必须支持传输模式和隧道模式。

这对主机的本地、BITS和BITW实现都成立。

b)安全网关必须支持隧道模式,可以支持传输模式。

如果它支持传输模式,应当仅在安全网关充当主机时使用,例如,用于网络管理,或在路径上两个中间系统间提供安全。

】-注:

如果网关作为主机使用才能支持传输模式,那么最终不还是说明传输模式应该使用在主机间环境吗?

“IPsec安全协议操作模式具体适合在哪一种应用场景下工作”这一观点就没有RFC2401文档《SecurityArchitecturefortheInternetProtocol》(《IP安全构架》)阐述得明了和直接。

RFC2401文档中明确说明传输模式适合在主机间工作,隧道模式适合在带有网关的场景下工作(操作模式适应的场景,在RFC4301文档中的最终观点与RFC2401其实是一样的,只不过RFC4301阐述的更加复杂和模糊。

结合RFC2401和RFC4301文档对IPsec安全协议操作模式适应的应用场景可以得出结论:

1、传输模式适用于主机间应用场景;

2、隧道模式适用于带有网关的应用场景。

在RFC2401和RFC4301文档中都有描述,隧道模式在主机间应用场景使用可行。

那么为什么还要增加传输模式呢?

增加这一模式的好处在哪里?

传输模式相比隧道模式有哪些无可比拟的优点?

这些答案在所有关于IPsec标准文档中都没有体现。

IPsec标准文档中没有任何证明来说明增加传输模式的必要理由,而且在主机间应用场景下可以使用隧道模式,在有网关的应用场景下不适合传输模式;再从增加一种模式的额外花费(针对增加的复杂性和导致的安全性损失)是很巨大的观点出发,增加传输模式实在是没有必要。

从RFC2401和RFC4301文档的IPsec操作模式应用场景的描述来看,传输模式适应的应用场景和完成的工作,隧道模式完全可以胜任。

所以,从应用场景的角度出发,为了简化IPsec的复杂选项,减少由于操作模式与其它选项组合而产生的安全漏洞,提高IPsec整体框架的安全性,建议IPsec安全协议操作模式中的传输模式淘汰。

2.2操作模式设计目标

在RFC4301文档中描述:

【每种协议支持两种应用模式:

传输模式和隧道模式。

在传输模式中,AH和ESP主要为下一层(高层)协议提供保护;在隧道模式中,AH和ESP应用于隧道化的IP分组。

从此段描述中不难看出:

传输模式是为高级协议提供保护而设计的,隧道模式是为整个IP分组提供保护而设计的。

那么问题来了,保护IP分组的同时是否就可以保护高级协议了?

如果是,那么隧道模式完全可以取代传输模式;如果不是,那么就应该在IPsec的相关标准文档中明确指出有哪些问题或点,亦或功能只可以在传输模式下完成,隧道模式下无法完成。

但是很遗憾,所有的IPsec标准文档都没有关于这方面的证明和描述。

IPsec标准文档中没有任何证明来说明在哪一种情况下只有传输模式可以完成的功能,而隧道模式无法完成。

从操作模式的设计目标来看,隧道模式的保护范围又完全包含了传输模式的保护范围。

隧道模式在实现保护高层协议这一目标的情况下又引入传输模式来专职保护高层协议,从而增加IPsec的复杂度,加大由于选项组合产生的安全漏洞风险。

鉴于隧道模式保护范围大于传输模式,所以建议淘汰传输模式,减少由于操作模式与其它选项组合而产生的安全漏洞,提高IPsec整体框架的安全性。

2.3操作模式技术实现

IPsec安全协议的封装格式为:

图4IPsec安全协议封装格式

从封装格式可以看出,传输模式与隧道模式的区别在于:

1、传输模式保护的是IP数据,安全协议头插在原IP头和IP数据之间;

2、隧道模式保护的是IP分组,安全协议的头前增加新的IP头。

但是我们不知道这样做的目的是什么。

如果把传输模式进行隧道化,那么隧道模式的封装就会出现如下特性:

新IP头=IP头

即如图5传输模式隧道化所示:

图5传输模式隧道化

显而易见,传输模式的隧道化封装与隧道模式封装形式上已经变成一模一样了,只是在带宽上,传输模式隧道化后会比原传输模式多消耗一个IP头的开销。

那么如果这样做了,从功能上和所保护的对象上来看都没有什么损失。

那么有些人可能会从网络传输性能上进行抨击:

传输模式在主机间进行工作,明显占用带宽要比隧道模式减少一个IP头的开销。

2.3.1网络传输性能

很多人提到传输模式在主机间进行工作,明显占用带宽要比隧道模式减少一个IP头的开销,意味着传输模式节省了带宽,但是随着传输媒介和技术的发展,该优势是否还存在?

首先:

假如主机间通信的传输媒介是有线,相互通信的设备IP地址必须在其间的网络可路由,例如内部网络的主机要安全的访问内部服务器资源;其网络带宽对流量不敏感,增加或减少一个IP头的开销并不会影响整个系统,在这种场景应用下,大家并不关心网络带宽的问题,那么这时隧道模式完全可以替代传输模式进行安全通信。

其次:

假如主机间通信的传输媒介是无线,且是收费的,其网络带宽对流量敏感,那么隧道模式的IP头压缩技术的应用是完全可以达到甚至优于传输模式对带宽开销的效果,如表1IP报头压缩增益所示。

表1IP报头压缩增益

报头类型

压缩前长度

压缩后最小长度

压缩增益

IPv4/TCP

40字节

4字节

90%

IPv4/UDP

28字节

1字节

96.4%

IPv6/TCP

60字节

4字节

93.3%

IPv6/UDP

48字节

3字节

93.75%

注:

通常IPv4报头长为20字节;IPv6报头长为40字节;TCP报头长20字节;UDP报头长8字节;

IP报头压缩,压缩的是IPv4/IPv6和TCP/UDP报头。

从表1中可以看出,隧道模式+IP报头压缩对网络带宽的开销远远小于传输模式对网络带宽的开销;传输模式对网络仅仅减少了一个IP头的开销(IPv4为20字节,IPv6为40字节);如图6所示(以IPv4,数据为TCP数据为例)

图6带IP压缩的隧道模式与传输模式网络开销对比

如图6,从对网络开销上来看,带IP压缩的隧道模式对网络的开销低于传输模式。

这时候,还会有人提到传输模式的IP数据报头如TCP/UDP报头也可以使用压缩技术实现网络带宽开销的减少呀!

这种观点也站不住脚,因为即使传输模式使用IP数据报头压缩技术也只能使带宽开销与隧道模式+IP压缩技术的带宽开销相当,例如IPv4/UDP的IP压缩最小为1个字节,而IP数据报头UDP的压缩最小也不会比1个字节小。

所以,从带宽开销方面来抨击隧道模式替换传输模式的思路实在是太牵强了。

2.3.2封解包性能

从网络开销方面抨击隧道模式替换传输模式的思路站不住脚,那么,隧道模式使用IP报头压缩技术是否会影响封包和解包的性能?

这其实是从工程实现角度来抨击隧道模式替换传输模式的思路。

首先,隧道模式封解包性能一开始就高于传输模式封解包性能,如图7所示:

图7隧道模式与传输模式封包过程对比

从图7可以看出,形成最终能够传输的安全报文时,传输模式封包比隧道模式多出一个拆封解析的过程,所以其组包性能肯定低于隧道模式(这一点,就已经是对抨击影响封解包性能论者的一个有力回击)。

其次,隧道模式引入IP报头压缩,应该会影响隧道模式封包/解包性能,如图8所示:

图8带IP头压缩的隧道模式与传输模式封包过程对比

从图8带IP头压缩的隧道模式与传输模式封包对比来看,原始IP报文以隧道模式进行封装时与传输模式封包所经历的步骤是一样的,区别在于重新封包的前一步骤:

带IP头压缩的隧道模式在重新组包前需要进行原IP报头压缩,而传输模式在重新组包前需要进行原IP报头的解析。

如果说隧道模式引入IP报头压缩后其封解包性能降低了,就应该是IP报头压缩本身的影响,那么IP报头压缩本身对性能的影响真的很大吗?

让我们来看看IP报头压缩原理。

报头之所以能够被压缩主要是因为报头字段之间存在很大的冗余度。

这种冗余度不但存在于同一个包的报头中,而且大量存在于属于同一包流中的连续包的报头字段之间。

报头的冗余分为三类:

保持不变的部分,如IP地址、版本号等;

通过其它方法可以推算出来的部分,如IP校验和、数据包长度等;

两相邻的数据包的某些字段是按增量变化的,并且变化量很小的部分,如TCP的序列号等。

剩余的部分是随机变化的部分。

取出上述三种冗余就是对报头进行压缩,在压缩和解压缩端建立压缩状态后,就只传输剩下的随机部分和增量了。

从IP报头的压缩原理可以看出,压/解压缩是根据一套规则进行IP报头解析,然后把相关信息保留在一个上下文中;上下文中的信息被用来压缩或解压缩后面的包;压缩器和解压缩器在某些事件的激励下更新它们的上下文信息。

那么根据这套原理不难发现,IP报头压缩/解压缩的过程就是报头解析、对比、恢复/删除/更新的过程,没有使用复杂的数学运算,因此开销并不大;随着技术的发展,这早已不是什么性能瓶颈了。

当然,隧道模式引入IP报头压缩,相比传输模式肯定会有封解包性能损失的,但是为了这一点点的性能提升,引入传输模式增加安全协议的复杂度从而导致IPsec成为了复杂得难以分析其安全性的安全协议实在是不合理的(安全协议却为了提升性能牺牲安全,是本末倒置的做法,不可取)。

2.3.3安全性

从封解包性能方面抨击隧道模式替换传输模式的思路的理由也不是很充分,那么,安全性呢?

是否在某种场合下,使用传输模式要比使用隧道模式更安全?

这一论调最起码在IPsec的标准文档中得不到证实;而且从设计的目标(2.2节操作模式的设计目标)来看,隧道模式的保护范围包含传输模式的保护范围;从整个IPsec系统来看,隧道模式涵盖了传输模式的安全能力。

在荷兰阿姆斯特丹工作的独立的密码学顾问尼尔斯.弗格森和国际知名的安全专家、CounterpaneInternetSecurityInc公司创始人布鲁斯·施奈尔合著的《ACryptographicEvaluationofIPsec》一文中有如下描述:

【在确定的模式中,隧道模式的功能是传输模式功能的扩展(从网络的角度出发,你可以把隧道模式看做是传输模式的特例,但是从安全的角度出发却不是这种情况。

)我们能看到的传输模式的唯一优点是一个较小的网络开销。

但是,隧道模式可以使用我们稍后说明的专业报头压缩方案进行直接扩展,这样就可以达到几乎与传输模式同样的功能,而不需要引进一个完全新的模式,因此我们建议将传输模式淘汰。

从以上尼尔斯.弗格森和布鲁斯·施奈尔的描述中,我们可以看出其与我们的观点相同:

隧道模式完全涵盖了传输模式的安全能力,传输模式确实可以淘汰了。

由于传输模式的存在,使得工程实现变得复杂,越复杂的工程实现,那么有可能安全漏洞就越多,存在着潜在的安全风险。

所以从安全的角度出发,我们也建议淘汰传输模式。

3.淘汰意义

IPsec的复杂是网络安全领域从业者都知道的事实。

由于复杂,才导致IPsec成为一种难以分析其安全性的安全协议。

IPsec包含有太多的选项和太多的灵活性,实现同样的或类似的功能通常有好几种方式(如:

主机间安全通信就有传输模式和隧道模式之选项,而且隧道模式完全可以代替传输模式工作),这样的膨胀和复杂对于一个安全性的标准,将是毁灭性的危害。

IPsec操作模式的分类就是导致IPsec复杂的一个原因。

根据前面的分析,传输模式可以废止,然后传输模式的工作全部由隧道模式来完成。

如果淘汰传输模式,那么意义非常大:

精简操作模式,减少由于传输模式与其它选项的组合而产生的安全漏洞,提高安全性;

精简协议格式,降低解析开销及难度;

增加IPsec标准文档易读性。

3.1精简操作模式

IPsec安全协议由AH、ESP组成,操作模式分为两类,那么再与安全协议组合,操作模式将达到六类之多,如图4;如果再加上UDP、TCP穿透NAT(NetworkAddressTranslation,网络地址转换)设备,那么操作模式的类型将更多。

如果淘汰传输模式(传输模式的工作完全由隧道模式来完成),操作模式选项组合至少要减少一半,如此操作,好处:

淘汰传输模式,将会减少由于传输模式与其它选项的组合而产生的安全漏洞,提高安全性;

淘汰传输模式,隧道模式完全代替其工作,IPsec的保护范围以及应用场景等不会因此而受影响;

淘汰传输模式,可以降低IPsec工程实现及维护过程中产生安全漏洞的可能性。

3.2精简协议格式

AH安全协议格式:

图9AH认证头格式

ESP安全协议格式:

图10ESP封装安全载荷格式

如图9与图10所示,各主要字段的意义:

SPI:

是安全参数索引;与目标地址及安全协议(AH或ESP)组合使用,以确保通信的正确安全关联;接收方使用该值确定数据包是使用哪一安全关联标识。

序列号:

为数据包提供抗重播保护;序数是32位、递增的数字(从1开始),它表示通过通信的安全关联所发送的数据包数;在生存期内序列号不能重复;接收方将检查该字段,以确认使用该数字的安全关联数据包还没有被接收过;如果一个已经被接收,则数据包被拒绝。

验证数据:

包含完整性校验值(ICV),也称为消息身份验证码,用于消息身份验证与完整性;接收方计算ICV值并对照发送方计算的值校验它,以验证完整性。

载荷长度:

表示AH报头的长度。

下一个头(或首部):

标识受保护数据的第一个头。

根据图4的封包格式可以看出,如果是传输模式,AH的“下一个首部”与ESP的“下一个头”都要填IP数据部分的TCP/UDP/ICMP等的类型;

由于在一个session(即一次IPsec应用)中,AH或ESP接下来的IP数据报头会随着业务的不同而不同(如,在这个session中,时而是TCP业务、时而是UDP业务、时而是ICMP业务等等),而且高级协议在未来的发展中很有可能出现新的协议类型,为了在一个session中区分不同的高级协议业务,而且对未来高级协议发展的兼容,传输模式(保护高级协议)有必要保留“下一个头(或首部)“这一字段。

但是如果是隧道模式,AH的“下一个首部”与ESP的“下一个头”必须要填4(IPv4)或41(IPv6),这是IP网络通信未来可以确定的事实。

如果现在及未来IP报文只有IPv4与IPv6(这已经是不争的事实),而且某一应用环境一旦确定将是长期的,所以在隧道模式下完全可以通过SA协商来确定是IPv4环境还是IPv6环境,没必要每一个报文都要携带“下一个头(或首部)”;如此操作,完全没有必要保留"下一个头(或首部)"字段而增加网络开销加大解析难度。

根据以上分析,淘汰传输模式,“下一个头(或首部)”字段只填写IP协议号;而且IP协议类型可以通过SA协议来确定;所以淘汰传输模式,安全协议格式就可以去掉“下一个头(或首部)”,减少解析开销及难度。

3.3去除通信主机分离

IPsec标准文档把通信主机分离成主机和安全网关,原因是安全网关可能不需要传输模式;如果淘汰传输模式,那么就没有必要进行这种分离;通信主机间是对等的,都是通过隧道进行端到端通信;标准文档在描述上就变得清晰易懂。

4.结论

我们假设系统有n个不同的选项,每个都有两个可能的选择,那么就有n(n-1)/2=O(n²)种不同对的选择以不可预料的方式进行互动,总共就有2n不同的配置。

每一种可能的互动都会导致安全漏洞,涉及几种选择的可能的复杂互动数目巨大,因此我们可以预见到实际的安全漏洞随着复杂性的不断增加会变得更多。

IPsec包含有太多的选项和太多的灵活性,实现同样的或类似的功能通常有好几种方式(如主机间安全通信既可以使用隧道模式也可以使用传输模式),这样的膨胀和复杂对于一个安全性的标准,将是毁灭性的危害。

淘汰传输模式,对于IPsec功能和安全并没有损失;但从复杂性的角度来看,有效提高了系统的安全性。

所以,根据以上的分析给出建议:

淘汰传输模式,传输模式的工作都由隧道模式来接管。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 党团工作 > 入党转正申请

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2