英语原文共 28 页，剩余内容已隐藏，支付完成后下载完整资料
1 介绍
在1999年2月，我们根据1998年11月的RFC[KA98c，KA98a，MG98a，MG98b，MD98，KA98b，Pip98，MSST98，HC98，GK98，TDG98，PA98]对IPsec进行了评估。 我们的评估主要集中在IPsec的加密属性。 我们较少关注IPsec的整合方面，因为我们两个人都不熟悉典型的IP实现。
IPsec使我们感到非常失望。 鉴于从事此工作的人员的素质和所花费的时间，我们希望得到更好的结果。并不只有我们是这么认为的。通过与相关人员的各种讨论，我们了解到几乎没有人对此过程或结果感到满意。 IPsec的发展似乎已经被其不得不使用的委员会程序所负担，并在结果中表明了这一点。
即使我们在IPsec上遇到了严重的批评，它也可能是目前可用的最佳IP安全协议。 过去，我们以与研究IPsec几乎相同的方式研究了其他功能相似的协议（包括PPTP [SM98，SM99]）。 这些协议中没有一个接近目标，但其他协议都比IPsec差很多。 从安全的角度来看，这种差异不那么重要。 确保绝对的安全性几乎没有意义。 从营销的角度来看，这很重要。 IPsec是当前的“最佳实践”，无论它在多大程度上反映了我们创建良好安全标准的能力。
我们对IPsec的主要批评点是其复杂性。 IPsec包含太多选项和太多灵活性。 通常有几种方法可以做相同或相似的事情。 这是典型的委员会效应。 委员会因添加功能，选项和额外的灵活性来满足委员会中的各个派系而臭名昭著。 众所周知，这种额外的复杂性和膨胀严重损害了正常（功能）标准。 但是，它对安全标准具有毁灭性影响。
将其与NIST用于开发AES [NIST97a，NIST97b]的方法进行比较很有启发性。 NIST通过组织竞赛去代替委员会。 几个小组各自创建了自己的提案，并且该过程仅限于选择其中一个。 在撰写本文时，已经有一个淘汰的阶段，剩下的五名候选人中的任何一个将提出比任何委员会都可以制定的更好的标准。
第一节
密码协议不应该由委员会开发。 我们强调，我们的分析绝不是全面的安全审查。 我们仅研究了系统中最明显的方面。 有很多地方根本没有被审查过，并且我们没有在审查中包括所有评论。 解决我们列出的问题将改善IPsec，但不会产生一个安全的系统。
2 概述
在讨论IPsec的细节之前，我们先简要评价一下整个系统。
2.1 复杂性
我们首先介绍一个新的经验法则，我们将其称为“复杂性陷阱”：
复杂性陷阱：安全的最大敌人就是复杂性。
这似乎是一个奇怪的说法，尤其是考虑到许多显示出严重安全故障的简单系统。 尽管如此，这是真的。 简单的故障很容易避免，而且往往很容易解决。 在这些情况下，问题不在于缺乏正确做法的知识，而是拒绝（或无能力）运用这种知识。 然而，复杂性却是另一回事。 我们真的不知道该如何处理。 复杂的系统表现出更多的故障以及更复杂的故障。 这些故障很难修复，因为系统更加复杂，而且在您不了解之前，系统是无法管理的。
设计任何软件系统始终是权衡和协调的问题
不同的要求：功能，效率，政治可接受性，安全性，
向后兼容性，截止日期，灵活性，易用性等等。这
不言而喻的要求通常是简单的。如果系统变得太复杂，它会-
制造和维护起来太困难且太昂贵。
【注一】想象一下委员会形式的AES流程。RC6是最优雅的密码，因此我们
从那开始。它已经使用了乘法和依赖于数据的循环。我们
从DFC添加四个解相关模块以获得可证明的安全性，并添加一个外部
由类似Rijndael的弹药制成的混合层（如MARS），添加依赖于键的S-
盒（Twofish），将轮数增加到32（Serpent），并包括一个
某处的CAST-256 S-box的数量。然后，我们将大量任意
改变，直到每个人都同样不高兴。最终结果是一个可怕的密码
结合了许多原始提案中的巧妙想法，并且最有可能
包含严重的弱点，因为没有人愿意花时间去真正地分析
最终结果。
因为完成更多的其他要求通常涉及更复杂的设计，
系统最终的设计与设计者一样复杂，
应用者可以合理地处理。（其他系统最终的设计也
处理起来很复杂，并且该项目相应地失败了。）
实际上，所有软件都是使用“尝试并修复”方法开发的。小的
对各个部分进行实施，测试，修复和再次测试。这些小几个
件组合成一个更大的模块，然后对该模块进行测试，固定和
再次测试。最终结果是，软件或多或少地发挥了预期的功能，
尽管我们都熟悉频繁发生的功能故障
软件系统。
制作相当复杂的系统并使用
尝试和修复方法对安全性具有毁灭性影响。中心原因
是您无法轻松测试安全性；安全不是系统的功能方面的一部分
。因此，在开发过程中，安全漏洞不会像功能性漏洞一样被检测到并修复。
假设一个合理大小的程序的开发在开发过程中没有任何测试和
质量控制。我们有信心说结果将是完全
无用的程序；最有可能无法正确地执行任何所需的功能。
但这正是我们出于对安全的尊重从尝试修复方法中获得的结果。
“测试”系统安全性的唯一合理方法是对它执行
安全审查。安全审查是一个手动过程；这非常贵
在时间和精力上。正如功能测试无法证明
没有错误，安全审查不能表明该产品实际上是安全的。
系统越复杂，安全性评估就越难。一种
更复杂的系统将在规范、设计与实施中包含更多与安全性相关的错误。
我们声称错误的数量和评估难度
的复杂度并不是呈线性相关，事实上它增长的更快。
为了简单起见，让我们假设系统有n个不同的选项，
每个都有两个可能的选择。（我们使用n作为复杂度的度量；这
似乎是合理的，因为系统规范和实现的长度
则与n成正比。）然后一共有n（n- 1）/ 2 = O（n 2）对不同的
可能以意想不到的方式交互的选项和2 n种不同的配置。
每种可能的交互都可能导致安全漏洞，并且
涉及多个选项的可能的复杂交互的数量是巨大的。
因此，我们期望实际的安全漏洞数量
随着复杂性的提高而变得非常多。
在安全评估中，有可能发生的交互的数量的增加会引起更多的工作量。
对于选项数量适中的系统，检查
所有两种选择的交互需要大量工作量。检查每个
可能的配置实际上是不可能的。因此执行安全评估的难度
也随着复杂性的提高而迅速增长。其他（潜在）弱点和更困难的安全分析的结合
不可避免地导致系统不安全。
在实际的系统中，情况并没有那么糟糕。经常有选择
它们是“正交的”，因为它们彼此之间没有任何关系或交互作用。
例如，如果选项位于通信系统的不同层面，并且各层之间通过定义明确的不会在两侧“显示”选项的接口分开。由于这个原因，这样的
将系统分为相对独立的模块，并明确定义
接口是良好设计的标志。良好的模块化可以显着
降低系统的有效复杂性，而无需消除重要的因素。
当然，单个模块中的选项仍然可以进行需要分析的交互，因此每个模块的选项数量应尽可能少，
细化。如果正确使用模块化，效果很好，但是大多数实际系统
仍然包含交叉依赖关系，其中不同模块中的选项会相互影响。
一个更复杂的系统在所有方面都将失败。它包含更多的缺点。
首先，它很难分析，也很难
在实施中不引入对安全性至关重要的错误去实施。
安全漏洞数量的增加和与安全性最弱的链接属性互相影响：
整个系统的安全性受其最薄弱环节的安全性限制。任何一个弱点都会破坏
整个系统的安全性。
复杂性不仅使创建安全系统几乎成为不可能，
这也使系统极难管理。运行实际系统的人通常对系统以及涉及的安全问题没有足够的了解。
因此，配置选项应保持在最少，选项应该为用户提供一个非常简单的模型。
选项的多重组合很可能被错误地配置，
这将会导致失去安全性。[Kah67，Wri87和And93b]中的故事说明了
复杂系统的管理通常是最薄弱的环节。
因此，我们重复一遍：安全的最大敌人是复杂性。安全系统
应当成为切肤之痛，并尽可能简单。简单性无可替代。
IPsec的复杂性
在我们看来，IPsec太复杂而无法保证安全。这
设计显然试图通过不同的设置选项来支持许多不同的情况。
我们非常强烈地感到，最终的系统的复杂度远远超出了
可以使用当前方法进行分析或适当实施的程度-。
因此，没有IPsec系统会达到提供高级别安全性的目标。
2.2 IPsec文档
查看IPsec时注意到的第一件事是文档
很难理解。没有概述或介绍，读者
必须组装所有片段并自己建立概览。这很令人不满意；毕竟，文档旨在传达给读者信息。我们认为期待任何人从IPsec文档中学习IPsec都是不合理的。
IPsec文档的各个部分很难阅读。例如，ISAKMP规范[MSST98]包含许多错误，
缺少必不可少说明，并且该文档在各个地方都相互矛盾。
陈述的目标
该文档未指定IPsec应该做到什么。没有明确的目标，就没有可以分析的标准。虽然
一些目标或多或少是显而易见的，我们经常只能从设计本身推论出
设计者的目标，然后检查设计是否
实现了这些目标。这当然是非常不可取的，任何关于
结果的讨论可能会恶化成关于IPsec应该达到的目标的讨论中。
缺乏规范也使得使用IPsec非常困难。
希望将IPsec用作系统的一部分的设计师无法确定
IPsec系统提供的功能。说IPsec提供数据包级别
安全就像是说一辆汽车会将您从A运送到B一样。
在适当的情况下两者都可实现，但在两种情况下，
有很多其他先决条件和限制。尝试在不知道所有前提条件和最终功能的情况下使用IPsec的设计师
实际上一定会创建一个无法实现其安全目标的系统。
这个问题已经很明显了。IPsec提供IP级别的安全性，
因此本质上是VPN协议。但是我们听说有人试图将其用于
应用程序级别的安全性，例如在用户尝试获取她的电子邮件时进行身份验证。
IPsec对数据包身份验证，认为其来自知道一个特定的密钥的人，
但许多人似乎认为它可以对原始IP地址进行身份验证-
因为这是他们可以在防火墙中进行过滤的原因。这种对IPsec的滥用只会导致问题。
基本原理
IPsec文档均未提供任何关于任何做出的选择的基本原理。
尽管这并不比明确说明目标重要，我们仍然将其视为至关重要的信息。
如果审阅者要对设计发表评论（RFC毕竟是请求评论），应告知他每种选择要实现的目标。
不需要任何基本原理，审阅者可以对此进行猜测，然后
根据猜想的原理对设计进行审阅。
第2课
系统的文档应包括入门资料，
初学者概述，既定目标，基本原理等。
如果不包括此类额外材料的原因是希望确保
没有矛盾，那么通常的
将文档的某些部分标记为规范性内容，将其他部分作为信息性内容的标准化做法可以
使用。
3批量数据处理
现在，我们将更详细地讨论IPsec的各个部分。为此，我们假设
读者熟悉IPsec的详细信息。
IPsec的核心由提供身份验证和IP包保密服务的功能组成。
IP封包[KA98c，KA98a，MG98a，MG98b，MD98，
KA98b，PA98，GK98，TDG98]。例如，这些可用于在不受信任的网络创建VPN
，或保护在本地网络上的任意两台计算机之间的数据包安全。
3.1复杂性
IPsec具有两种操作模式：传输模式和隧道模式。
有两个协议：AH和ESP。AH提供身份验证，ESP提供认证，
加密或两者兼而有之。这带来了很多额外的复杂性：两个
希望对数据包进行身份验证的计算机可以总共使用四个不同的数据包
模式：传输/ AH，隧道/ AH，传输/ 不加密的ESP和
通道/ 不加密的ESP。这些选项之间的差异，两者
在功能和性能方面，都是次要的。该文档也很清楚的表明，
在某些情况下，可以考虑使用两种协议：进行身份验证的AH，进行加密的ESP。
模式
据我们所知，隧道模式的功能是传输模式功能超集。
（从网络角度来看，可以将隧道模式视为传输模式的特例，但从安全角度考虑
从这个角度来看，情况并非如此。）我们注意到端口模式的唯一优势是
是它可以让带宽开销稍微变小。然而，
隧道模式可以使用我们将在稍后说明的特殊的标题压缩方案直接扩展。这样可以达到
实际上与传输模式具有相同的性能，而不需要完全引入
新模式。因此，我们建议取消运输模式。
建议1消除运输方式。
没有任何成文的依据，我们不知道为什么IPsec有两个
模式。我们认为，这需要一个非常
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[405504]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
