IPsec传输模式可休矣.docx

IPsec传输模式可休矣.docx

《IPsec传输模式可休矣.docx》由会员分享，可在线阅读，更多相关《IPsec传输模式可休矣.docx（14页珍藏版）》请在冰豆网上搜索。

IPsec传输模式可休矣

IPsec，传输模式可休矣

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

1.IPsec简介

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

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

I、数据机密性（Confidentiality）：

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

II、数据完整性（DataIntegrity）：

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

III、数据源认证（DataOriginAuthentication）：

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

IV、防重放（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可以看出，形成最终能够传输的安全报文时，传输模式封包比隧道模式多出一个拆封解析的过程，所以其组包性能肯定低于隧道模式（这一点，就已经