📄 rfc2475.txt
字号:
(例如,可以防止基于DS编码点修改的窃取服务攻击)。任何检查出的错误都是审查事件,
而应被记录。记录项包括接收到数据包的日期/时间,源和目的IP地址,和导致未通过此检查
的DS编码点值。实际中,需要在这类检查的好处和它们对系统性能的影响之间做出权衡,确
定内部节点处到底需做哪些检查。
如果一条链路不能充分保证其安全性,即是说,不能防止DS编码点修改或者注入不合法
业务流,那么就应该被当作边界连接对待(即,任何从此链路到达的业务流都象从入口节点处
进入DS域的业务流那样进行各种检查)。局部安全策略提供关于“充分安全”的定义。“充
分安全”定义中应给出一个DS编码点修改和/或业务流注入的危险和后果,与对链路的采取额
外安全措施的平衡点。链路安全性可以通过物理接入控制和/或软件方法,如确保数据包完整
性的隧道技术,得到提高。
6.2 IPsec和隧道交互
在IPsec协议中,如[ESP,AH]描述,不含有对IP头DS段任何形式的加密(在隧道
中,外层IP头的DS段未被加密)。因此,网络节点对DS段的修改不会影响IPsec端到端的
安全性,因为这种修改不会引起IPsec完整性检查失败。其结果是,IPsec不能提供任何措施
防止对DS段的修改(如,中间人攻击man-in-the-middle attach),因为攻击者的修改不
会破坏IPsec的端到端完整性。在有些环境,这种修改DS段而不影响IPsec完整性检查的能
力,可以组成一个隐蔽通道;如果有必要消除这样的通道或减少其带宽,可以把DS域配置
为,可以在业务流离开更高安全性域的DS出口节点处进行所需的处理(如,将敏感业务流的
所有DS段置为同一个值)。
IPsec的隧道模式为封装的IP头DS段提供了安全性支持。隧道模式下的IPsec包含有两
个IP头:由隧道入口节点提供的外层包头和由数据包源节点提供的被封装的内层包头。当一条
IPsec隧道(部分或全部的)经过分类业务网络时,中间的网络节点会对外层包头中的DS段
进行操作。在隧道出口节点处,IPsec会去掉外层包头,并(如果需要)使用内层包头转发数
据包。如果内层IP头没有被隧道出口节点所在DS域的某个DS入口节点处理过,那么隧道出
口节点就作为离开隧道的业务流进入DS域的入口节点,也因此,此节点必须履行相应的业务
量调节策略(参见6.1节)。如果IPsec对所封装数据包有足够强壮的密码完整性检查(这里
的“足够”取决于局部安全策略),那么隧道出口节点就可以安全的假设内层包头的DS段值
与在隧道入口时相同。这就允许与隧道入口节点位于同一DS域的隧道出口节点,可以象对待
从同一DS域其它节点来的数据包一样(即是说,省略DS入口节点业务量调节处理)处理从
隧道流出的数据包,并保证安全性。这样做的一个重要后果就是,局部于DS域的其它不安全
链路可以使用足够强壮的IPsec隧道使其安全。
此分析和隐含适用于任何进行完整性检查的隧道协议,只是对内层包头DS段的确保水平
依赖于隧道协议进行的完整性检查力度。在隧道可能穿越当前DS域之外的节点时,如果缺少
对这类隧道足够的信任,封装的数据包就必须象对待从域外到达DS入口节点的数据包同样处
理。
当前IPsec协议不允许在隧道出口节点处除IPsec封装时改变内层包头的DS段。这保证
了不能利用修改DS段的方法穿越IPsec隧道终点实施窃取服务或拒绝服务攻击,因为任何这
类修改都会在隧道终点处丢弃。本文档不对IPsec做任何修改。
如果IPsec的未来版本允许在隧道出口节点处根据外层包头DS段值修改内层包头DS段
值(例如,复制外层DS段的部分或全部内容到内层DS段),那么就还需对由此而来的安全
性问题额外考虑。当一条隧道完全处于一个DS域中,并且这条链路绝对安全,外层DS段不
会被修改,在修改内层DS段时的唯一限制来自于域服务提供策略。另外,进行这种修改的隧
道出口节点对流出隧道的业务流来说,应是DS入口节点,必须实施必要的业务量调节功能,
包括防止窃取服务和拒绝服务攻击(参见6.1节)。如果隧道不是在其出口节点处进入DS
域,那么隧道出口节点就依靠上游的DS入口节点确保外层DS段值是可接受的。即使在这种
情况下,也有某些检查是必须由隧道出口节点实施的(例如,加密隧道内层和外层DS段值一
致性检查)。任何检查出的错误都必须留有审查记录,记录内容包括数据包到达的日期/时
间,源和目的IP地址,和所携带的不可接收DS编码点。
从体系结构角度,至少可以有两种不同的方式看待IPsec隧道。如果隧道被看作逻辑上只
有一跳的“虚链路”,那么隧道中间节点转发隧道中数据流的行为,对隧道终点来说就应该是
不可见的,并且在解除封装过程中也不应该修改DS段值。相反的,如果隧道被看作是多跳
的,那么在隧道解除封装的过程中修改DS段值,就是可以的了。后一种情况的具体例子如
下。隧道终止于DS域内部节点,而域管理者并不想在此节点安装业务量调节功能(例如,为
了简化业务量管理)。一种解决方案是,根据外层IP包头的DS编码点(根据此值在DS入口
节点处进行业务量调节)设置内层IP包头DS编码点。这样就有效将业务量调节功能从IPsec
隧道出口节点转移到了适当的上游DS入口节点(DS入口节点必须已经对未解除封装的业务
流进行了业务量调节)。]
6.3 审查
并不是所有支持分类业务的系统都要实现审查功能。然而,如果分类业务支持融入了一个
提供审查功能的系统中,那么分类业务实现也必须支持审查。如果支持审查功能,那么就必须
允许系统管理者整体性的开启或禁止分类业务审查功能,并且允许部分的开启或禁止这类审
查。
大多数情况下,审查功能的粒度是局部问题。然而,本文档中定义了一些审查事件,以及
每一事件记录应包括的最小信息集。额外信息(如,引起此审查事件的数据包本身)也可被包
括在记录信息中。并未在本文档中提到的其他事件,也可以导致一条审查记录。检测到审查事
件后,并不要求接收者向发送者传送任何的消息,因为回传任何消息都有可能导致包括拒绝服
务攻击在内的危险。
7 感谢
本文档得益于早期由Steven Blake, David Clark, Ed Ellesson, Paul Ferguson,
Juha Heinanen, Van Jacobson, Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John
Wroclawski, 和Lixia Zhang撰写的初稿。
很多人为本文档提供了有帮助的建议和意见,作者在此向他们表示感谢:Kathleen Nichols,
Brian Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, Marty Borden,
Yoram Bernet, Ronald Bonica, James Binder, Borje Ohlman, Alessio Casati, Scott Brim, Curtis
Villamizar, Hamid Ould- Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O'Neill,
James Fu, 和 Bob Braden.
8 参考文献
[802.1p] ISO/IEC Final CD 15802-3 Information technology -
Telecommunications and information exchange between systems - Local and
metropolitan area networks - Common specifications - Part 3: Media Access Control
(MAC) bridges, (current draft available as IEEE P802.1D/D15).
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[ATM] ATM Traffic Management Specification Version 4.0 <af-tm-0056.000>,
ATM Forum, April 1996.
[Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K.Nichols, and M.
Speer, "A Framework for Use of RSVP with Diff-serv Networks", Work in Progress.
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December,1998.
[EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort Packet
Delivery Service", IEEE/ACM Trans. on Networking, vol. 6, no. 4, August 1998, pp.
362-373.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998.
[FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC
1349, July 1992.
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the
Internet Architecture: An Overview", RFC 1633, July 1994.
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205,
September 1997.
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services
Architecture for the Internet", ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November
1997.
[TR] ISO/IEC 8802-5 Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area networks -
Common specifications - Part 5: Token Ring Access Method and Physical Layer
Specifications, (also ANSI/IEEE Std 802.5- 1995), 1995.
9 作者联系地址
Steven Blake
Torrent Networking Technologies
3000 Aerial Center, Suite 140
Morrisville, NC 27560
Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.com
David L. Black
EMC Corporation
35 Parkwood Drive
Hopkinton, MA 01748
Phone: +1-508-435-1000 x76140
EMail: black_david@emc.com
Mark A. Carlson
Sun Microsystems, Inc.
2990 Center Green Court South
Boulder, CO 80301
Phone: +1-303-448-0048 x115
EMail: mark.carlson@sun.com
Elwyn Davies
Nortel UK
London Road
Harlow, Essex CM17 9NA, UK
Phone: +44-1279-405498
EMail: elwynd@nortel.co.uk
Zheng Wang
Bell Labs Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
EMail: zhwang@bell-labs.com
Walter Weiss
Lucent Technologies
300 Baker Avenue, Suite 100
Concord, MA 01742-2168
EMail: wweiss@lucent.com
10 完整版
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -