Network Working Group                                            X. Xiao
Request for Comments: 2873                               Global Crossing
Category: Standards Track                                      A. Hannan
                                                                    iVMG
                                                               V. Paxson
                                                              ACIRI/ICSI
                                                               E. Crabbe
                                                   Exodus Communications
                                                               June 2000
        
Network Working Group                                            X. Xiao
Request for Comments: 2873                               Global Crossing
Category: Standards Track                                      A. Hannan
                                                                    iVMG
                                                               V. Paxson
                                                              ACIRI/ICSI
                                                               E. Crabbe
                                                   Exodus Communications
                                                               June 2000
        

TCP Processing of the IPv4 Precedence Field

IPv4优先字段的TCP处理

Status of this Memo

本备忘录的状况

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

Abstract

摘要

This memo describes a conflict between TCP [RFC793] and DiffServ [RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict.

本备忘录描述了TCP[RFC793]和DiffServ[RFC2475]在使用IPv4报头[RFC791]的TOS八位字节中最左边的三位时发生的冲突。在包含具有区分服务功能的节点的网络中,此类冲突可能导致建立TCP连接失败,或者可能导致某些已建立的TCP连接被不希望地重置。本备忘录建议修改TCP以解决冲突。

Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet.

由于IPv6[RFC2460]流量类八位字节除了RFC 2474中定义的内容外没有任何定义的含义,特别是没有定义优先级或安全参数位,因此TCP和DiffServ在使用IPv6流量类八位字节中的任何位时不存在冲突。

1. Introduction
1. 介绍

In TCP, each connection has a set of states associated with it. Such states are reflected by a set of variables stored in the TCP Control Block (TCB) of both ends. Such variables may include the local and remote socket number, precedence of the connection, security level

在TCP中,每个连接都有一组与之关联的状态。这种状态由存储在两端TCP控制块(TCB)中的一组变量反映。这些变量可能包括本地和远程套接字编号、连接优先级、安全级别

and compartment, etc. Both ends must agree on the setting of the precedence and security parameters in order to establish a connection and keep it open.

和隔室等。两端必须就优先级和安全参数的设置达成一致,以便建立连接并保持其打开。

There is no field in the TCP header that indicates the precedence of a segment. Instead, the precedence field in the header of the IP packet is used as the indication. The security level and compartment are likewise carried in the IP header, but as IP options rather than a fixed header field. Because of this difference, the problem with precedence discussed in this memo does not apply to them.

TCP标头中没有指示段优先级的字段。相反,IP数据包报头中的优先字段用作指示。安全级别和隔间同样在IP报头中携带,但作为IP选项,而不是固定的报头字段。由于这种差异,本备忘录中讨论的优先权问题不适用于他们。

TCP requires that the precedence (and security parameters) of a connection must remain unchanged during the lifetime of the connection. Therefore, for an established TCP connection with precedence, the receipt of a segment with different precedence indicates an error. The connection must be reset [RFC793, pp. 36, 37, 40, 66, 67, 71].

TCP要求连接的优先级(和安全参数)在连接的生存期内必须保持不变。因此,对于已建立的具有优先级的TCP连接,接收到具有不同优先级的段表示错误。必须重置连接[RFC793,第36、37、40、66、67、71页]。

With the advent of DiffServ, intermediate nodes may modify the Differentiated Services Codepoint (DSCP) [RFC2474] of the IP header to indicate the desired Per-hop Behavior (PHB) [RFC2475, RFC2597, RFC2598]. The DSCP includes the three bits formerly known as the precedence field. Because any modification to those three bits will be considered illegal by endpoints that are precedence-aware, they may cause failures in establishing connections, or may cause established connections to be reset.

随着DiffServ的出现,中间节点可以修改IP报头的区分服务码点(DSCP)[RFC2474]以指示所需的每跳行为(PHB)[RFC2475,RFC2597,RFC2598]。DSCP包括以前称为优先字段的三位。由于对这三个位的任何修改都将被具有优先级意识的端点视为非法,因此它们可能会导致建立连接失败,或者可能导致重置已建立的连接。

2. Terminology
2. 术语

Segment: the unit of data that TCP sends to IP

段:TCP发送到IP的数据单位

Precedence Field: the three leftmost bits in the TOS octet of an IPv4 header. Note that in DiffServ, these three bits may or may not be used to denote the precedence of the IP packet. There is no precedence field in the traffic class octet in IPv6.

优先字段:IPv4头的TOS八位字节中最左边的三位。注意,在DiffServ中,这三个位可能用于表示IP分组的优先级,也可能不用于表示IP分组的优先级。IPv6中的流量类八位字节中没有优先级字段。

TOS Field: bits 3-6 in the TOS octet of IPv4 header [RFC 1349].

TOS字段:IPv4头[RFC 1349]的TOS八位字节中的第3-6位。

MBZ field: Must Be Zero

MBZ字段:必须为零

The structure of the TOS octet is depicted below:

TOS八位组的结构如下所示:

                   0     1     2     3     4     5     6     7
                +-----+-----+-----+-----+-----+-----+-----+-----+
                |   PRECEDENCE    |          TOS          | MBZ |
                +-----+-----+-----+-----+-----+-----+-----+-----+
        
                   0     1     2     3     4     5     6     7
                +-----+-----+-----+-----+-----+-----+-----+-----+
                |   PRECEDENCE    |          TOS          | MBZ |
                +-----+-----+-----+-----+-----+-----+-----+-----+
        

DS Field: the TOS octet of an IPv4 header is renamed the Differentiated Services (DS) Field by DiffServ.

DS字段:IPv4标头的TOS八位字节被DiffServ重命名为区分服务(DS)字段。

The structure of the DS field is depicted below:

DS字段的结构如下所示:

                  0   1   2   3   4   5   6   7
                +---+---+---+---+---+---+---+---+
                |         DSCP          |  CU   |
                +---+---+---+---+---+---+---+---+
        
                  0   1   2   3   4   5   6   7
                +---+---+---+---+---+---+---+---+
                |         DSCP          |  CU   |
                +---+---+---+---+---+---+---+---+
        

DSCP: Differentiated Service Code Point, the leftmost 6 bits in the DS field.

DSCP:区分服务代码点,DS字段中最左边的6位。

CU: currently unused.

CU:目前未使用。

Per-hop Behavior (PHB): a description of the externally observable forwarding treatment applied at a differentiated services-compliant node to a behavior aggregate.

每跳行为(PHB):在符合区分服务的节点上应用于行为聚合的外部可观察转发处理的描述。

3. Problem Description
3. 问题描述

The manipulation of the DSCP to achieve the desired PHB by DiffServ-capable nodes may conflict with TCP's use of the precedence field. This conflict can potentially cause problems for TCP implementations that conform to RFC 793. First, page 36 of RFC 793 states:

通过具有区分服务功能的节点操纵DSCP以实现所需的PHB可能与TCP使用优先字段相冲突。此冲突可能会导致符合RFC 793的TCP实现出现问题。首先,RFC 793第36页规定:

If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent. If our SYN has not been acknowledged and the precedence level of the incoming segment is higher than the precedence level requested then either raise the local precedence level (if allowed by the user and the system) or send a reset; or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly (if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends, and the connection will be terminated then). If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.

如果连接处于任何非同步状态(LISTEN、SYN-SENT、SYN-RECEIVED),并且传入网段确认尚未发送的内容(网段带有不可接受的ACK),或者如果传入网段的安全级别或隔间与连接请求的级别和隔间不完全匹配,发送重置。如果我们的SYN未被确认,且传入段的优先级高于请求的优先级,则提高本地优先级(如果用户和系统允许)或发送重置;或者,如果传入段的优先级低于请求的优先级,则继续,如同优先级完全匹配一样(如果远程TCP无法提高优先级以匹配我们的优先级,则将在其发送的下一段中检测到该优先级,然后将终止连接)。如果我们的SYN已被确认(可能在此传入段中),则传入段的优先级必须与本地优先级完全匹配,如果没有,则必须发送重置。

This leads to Problem #1: For a precedence-aware TCP module, if during TCP's synchronization process, the precedence fields of the SYN and/or ACK packets are modified by the intermediate nodes,

这会导致问题#1:对于具有优先级意识的TCP模块,如果在TCP的同步过程中,中间节点修改了SYN和/或ACK数据包的优先级字段,

resulting in the received ACK packet having a different precedence from the precedence picked by this TCP module, the TCP connection cannot be established, even if both modules actually agree on an identical precedence for the connection.

由于接收到的ACK数据包的优先级与此TCP模块选择的优先级不同,因此无法建立TCP连接,即使两个模块实际上同意相同的连接优先级。

Then, on page 37, RFC 793 states:

然后,在第37页,RFC 793说明:

If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection, a reset is sent and connection goes to the CLOSED state.

如果连接处于同步状态(已建立、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSE、LAST-ACK、TIME-WAIT)、安全级别、或与级别不完全匹配的间隔、间隔和连接请求的优先级,则发送重置,连接进入关闭状态。

This leads to Problem #2: For a precedence-aware TCP module, if the precedence field of a received segment from an established TCP connection has been changed en route by the intermediate nodes so as to be different from the precedence specified during the connection setup, the TCP connection will be reset.

这导致了问题#2:对于具有优先级意识的TCP模块,如果中间节点在路由过程中更改了已建立TCP连接的接收段的优先级字段,使其与连接设置期间指定的优先级不同,则TCP连接将被重置。

Each of problems #1 and #2 has a mirroring problem. They cause TCP connections that must be reset according to RFC 793 not to be reset.

问题1和问题2都有镜像问题。它们导致必须根据RFC 793重置的TCP连接无法重置。

Problem #3: A TCP connection may be established between two TCP modules that pick different precedence, because the precedence fields of the SYN and ACK packets are modified by intermediate nodes, resulting in both modules thinking that they are in agreement for the precedence of the connection.

问题#3:可能在选择不同优先级的两个TCP模块之间建立TCP连接,因为中间节点修改了SYN和ACK数据包的优先级字段,导致两个模块都认为它们在连接优先级方面是一致的。

Problem #4: A TCP connection has been established normally by two TCP modules that pick the same precedence. But in the middle of the data transmission, one of the TCP modules changes the precedence of its segments. According to RFC 793, the TCP connection must be reset. In a DiffServ-capable environment, if the precedence of the segments is altered by intermediate nodes such that it retains the expected value when arriving at the other TCP module, the connection will not be reset.

问题4:TCP连接通常由两个选择相同优先级的TCP模块建立。但是在数据传输的中间,TCP模块中的一个改变了它的段的优先级。根据RFC 793,必须重置TCP连接。在支持区分服务的环境中,如果中间节点更改了段的优先级,使其在到达其他TCP模块时保持预期值,则连接不会重置。

4. Proposed Modification to TCP
4. 对TCP的拟议修改

The proposed modification to TCP is that TCP must ignore the precedence of all received segments. More specifically:

建议对TCP进行的修改是,TCP必须忽略所有接收段的优先级。更具体地说:

(1) In TCP's synchronization process, the TCP modules at both ends must ignore the precedence fields of the SYN and SYN ACK packets. The TCP connection will be established if all the conditions specified by RFC 793 are satisfied except the precedence of the connection.

(1) 在TCP的同步过程中,两端的TCP模块必须忽略SYN和SYN ACK数据包的优先级字段。如果满足RFC 793规定的所有条件(连接优先级除外),则将建立TCP连接。

(2) After a connection is established, each end sends segments with its desired precedence. The precedence picked by one end of the TCP connection may be the same or may be different from the precedence picked by the other end (because precedence is ignored during connection setup time). The precedence fields may be changed by the intermediate nodes too. In either case, the precedence of the received packets will be ignored by the other end. The TCP connection will not be reset in either case.

(2) 建立连接后,每一端发送具有所需优先级的段。TCP连接一端选择的优先顺序可能与另一端选择的优先顺序相同或不同(因为在连接设置期间优先顺序被忽略)。中间节点也可以更改优先级字段。在任何一种情况下,接收到的数据包的优先级都将被另一端忽略。无论哪种情况,TCP连接都不会重置。

Problems #1 and #2 are solved by this proposed modification. Problems #3 and #4 become non-issues because TCP must ignore the precedence. In a DiffServ-capable environment, the two cases described in problems #3 and #4 should be allowed.

问题#1和#2通过拟议的修改得以解决。问题#3和#4成为非问题,因为TCP必须忽略优先级。在支持区分服务的环境中,应该允许问题3和问题4中描述的两种情况。

5. Security Considerations
5. 安全考虑

A TCP implementation that terminates a connection upon receipt of any segment with an incorrect precedence field, regardless of the correctness of the sequence numbers in the segment's header, poses a serious denial-of-service threat, as all an attacker must do to terminate a connection is guess the port numbers and then send two segments with different precedence values; one of them is certain to terminate the connection. Accordingly, the change to TCP processing proposed in this memo would yield a significant gain in terms of that TCP implementation's resilience.

TCP实现在接收到具有错误优先级字段的任何段时终止连接,而不管该段标头中的序列号是否正确,都会造成严重的拒绝服务威胁,正如攻击者终止连接所必须做的,猜测端口号,然后发送两个具有不同优先级值的段;其中一个肯定会终止连接。因此,本备忘录中提出的对TCP处理的更改将在该TCP实现的恢复能力方面产生重大收益。

On the other hand, the stricter processing rules of RFC 793 in principle make TCP spoofing attacks more difficult, as the attacker must not only guess the victim TCP's initial sequence number, but also its precedence setting.

另一方面,RFC 793更严格的处理规则原则上使TCP欺骗攻击更加困难,因为攻击者不仅必须猜测受害者TCP的初始序列号,还必须猜测其优先级设置。

Finally, the security issues of each PHB group are addressed in the PHB group's specification [RFC2597, RFC2598].

最后,每个PHB组的安全问题在PHB组的规范[RFC2597,RFC2598]中得到了解决。

6. Acknowledgments
6. 致谢

Our thanks to Al Smith for his careful review and comments.

我们感谢艾尔·史密斯的仔细审查和评论。

7. References
7. 工具书类

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791]Postel,J.,“互联网协议”,标准5,RFC7911981年9月。

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC793]Postel,J.,“传输控制协议”,标准7,RFC 793,1981年9月。

[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.

[RFC1349]Almquist,P.,“互联网协议套件中的服务类型”,RFC1349,1992年7月。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2460]Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,RFC 2460,1998年12月。

[RFC2474] 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.

[RFC2474]Nichols,K.,Blake,S.,Baker,F.和D.Black,“IPv4和IPv6标头中区分服务字段(DS字段)的定义”,RFC 2474,1998年12月。

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[RFC2475]Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.和W.Weiss,“差异化服务架构”,RFC 24751998年12月。

[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2587, June 1999.

[RFC2597]Heinanen,J.,Baker,F.,Weiss,W.和J.Wroclawski,“保付PHB集团”,RFC 25871999年6月。

[RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.

[RFC2598]Jacobson,V.,Nichols,K.和K.Poduri,“快速转发PHB”,RFC 25981999年6月。

8. Authors' Addresses
8. 作者地址

Xipeng Xiao Global Crossing 141 Caspian Court Sunnyvale, CA 94089 USA

美国加利福尼亚州桑尼维尔里海法院141号西彭肖环球通道邮编94089

   Phone: +1 408-543-4801
   EMail: xipeng@gblx.net
        
   Phone: +1 408-543-4801
   EMail: xipeng@gblx.net
        

Alan Hannan iVMG, Inc. 112 Falkirk Court Sunnyvale, CA 94087 USA

Alan Hannan iVMG,Inc.美国加利福尼亚州桑尼维尔市法尔柯克法院112号,邮编94087

   Phone: +1 408-749-7084
   EMail: alan@ivmg.net
        
   Phone: +1 408-749-7084
   EMail: alan@ivmg.net
        

Edward Crabbe Exodus Communications 2650 San Tomas Expressway Santa Clara, CA 95051 USA

Edward Crabbe Exodus Communications 2650美国加利福尼亚州圣克拉拉市圣托马斯高速公路95051号

   Phone: +1 408-346-1544
   EMail: edc@explosive.net
        
   Phone: +1 408-346-1544
   EMail: edc@explosive.net
        

Vern Paxson ACIRI/ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198 USA

Vern Paxson ACIRI/ICSI 1947美国加利福尼亚州伯克利中心街600号套房,邮编94704-1198

   Phone: +1 510-666-2882
   EMail: vern@aciri.org
        
   Phone: +1 510-666-2882
   EMail: vern@aciri.org
        
9. Full Copyright Statement
9. 完整版权声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。