doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc2873.txt b/doc/rfc/rfc2873.txt
new file mode 100644
index 0000000..e81822c
--- /dev/null
+++ b/doc/rfc/rfc2873.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+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.
+
+   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.
+
+1. Introduction
+
+   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
+
+
+
+
+Xiao, et al.                Standards Track                     [Page 1]
+
+RFC 2873           TCP and the IPv4 Precedence Field           June 2000
+
+
+   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 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].
+
+   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.
+
+2. Terminology
+
+   Segment: the unit of data that TCP sends to 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.
+
+   TOS Field: bits 3-6 in the TOS octet of IPv4 header [RFC 1349].
+
+   MBZ field: Must Be Zero
+
+   The structure of the TOS octet is depicted below:
+
+                   0     1     2     3     4     5     6     7
+                +-----+-----+-----+-----+-----+-----+-----+-----+
+                |   PRECEDENCE    |          TOS          | MBZ |
+                +-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+
+
+
+Xiao, et al.                Standards Track                     [Page 2]
+
+RFC 2873           TCP and the IPv4 Precedence Field           June 2000
+
+
+   DS Field: the TOS octet of an IPv4 header is renamed the
+   Differentiated Services (DS) Field by DiffServ.
+
+   The structure of the DS field is depicted below:
+
+                  0   1   2   3   4   5   6   7
+                +---+---+---+---+---+---+---+---+
+                |         DSCP          |  CU   |
+                +---+---+---+---+---+---+---+---+
+
+   DSCP: Differentiated Service Code Point, the leftmost 6 bits in the
+   DS field.
+
+   CU:   currently unused.
+
+   Per-hop Behavior (PHB): a description of the externally observable
+   forwarding treatment applied at a differentiated services-compliant
+   node to a behavior aggregate.
+
+3. Problem Description
+
+   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:
+
+       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.
+
+   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,
+
+
+
+Xiao, et al.                Standards Track                     [Page 3]
+
+RFC 2873           TCP and the IPv4 Precedence Field           June 2000
+
+
+   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.
+
+   Then, on page 37, RFC 793 states:
+
+       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.
+
+   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.
+
+   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.
+
+   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.
+
+   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. Proposed Modification to TCP
+
+   The proposed modification to TCP is that TCP must ignore the
+   precedence of all received segments. More specifically:
+
+   (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.
+
+
+
+
+Xiao, et al.                Standards Track                     [Page 4]
+
+RFC 2873           TCP and the IPv4 Precedence Field           June 2000
+
+
+   (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.
+
+   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.
+
+5. Security Considerations
+
+   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.
+
+   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.
+
+   Finally, the security issues of each PHB group are addressed in the
+   PHB group's specification [RFC2597, RFC2598].
+
+6. Acknowledgments
+
+   Our thanks to Al Smith for his careful review and comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xiao, et al.                Standards Track                     [Page 5]
+
+RFC 2873           TCP and the IPv4 Precedence Field           June 2000
+
+
+7. References
+
+   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+             1981.
+
+   [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
+             793, September 1981.
+
+   [RFC1349] Almquist, P., "Type of Service in the Internet Protocol
+             Suite", RFC 1349, July 1992.
+
+   [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [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.
+
+   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
+             W.  Weiss, "An Architecture for Differentiated Services",
+             RFC 2475, December 1998.
+
+   [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
+             "Assured Forwarding PHB Group", RFC 2587, June 1999.
+
+   [RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
+             Forwarding PHB", RFC 2598, June 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xiao, et al.                Standards Track                     [Page 6]
+
+RFC 2873           TCP and the IPv4 Precedence Field           June 2000
+
+
+8. Authors' Addresses
+
+   Xipeng Xiao
+   Global Crossing
+   141 Caspian Court
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: +1 408-543-4801
+   EMail: xipeng@gblx.net
+
+
+   Alan Hannan
+   iVMG, Inc.
+   112 Falkirk Court
+   Sunnyvale, CA 94087
+   USA
+
+   Phone: +1 408-749-7084
+   EMail: alan@ivmg.net
+
+
+   Edward Crabbe
+   Exodus Communications
+   2650 San Tomas Expressway
+   Santa Clara, CA 95051
+   USA
+
+   Phone: +1 408-346-1544
+   EMail: edc@explosive.net
+
+
+   Vern Paxson
+   ACIRI/ICSI
+   1947 Center Street
+   Suite 600
+   Berkeley, CA 94704-1198
+   USA
+
+   Phone: +1 510-666-2882
+   EMail: vern@aciri.org
+
+
+
+
+
+
+
+
+
+
+Xiao, et al.                Standards Track                     [Page 7]
+
+RFC 2873           TCP and the IPv4 Precedence Field           June 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xiao, et al.                Standards Track                     [Page 8]
+