TCP Maintenance and Minor Extensions F. Gont (tcpm) UTN-FRH / SI6 Networks Internet-Draft March 29, 2012 Updates: 793 (if approved) Intended status: Standards Track Expires: September 30, 2012 Processing of IP Security/Compartment and Precedence Information by TCP draft-gont-tcpm-tcp-seccomp-prec-00.txt Abstract This document discusses the security and interoperability problems that may arise as a result of the processing of IP security/ compartment and precedence information by TCP. Additionally, it formally updates RFC 793 such that these issues are mitigated. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 30, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Gont Expires September 30, 2012 [Page 1]
Internet-Draft Processing of IP layer information March 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Updating RFC 793 . . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Gont Expires September 30, 2012 [Page 2]
Internet-Draft Processing of IP layer information March 2012 1. Introduction Section 3.9 (page 71) of RFC 793 [RFC0793] states that if the IP security/compartment and precedence of an incoming segment does not exactly match the security/compartment in the TCB, a RST segment should be sent, and the connection should be aborted. A discussion of the IP security options relevant to this section can be found in Section 3.13.2.12, Section 3.13.2.13, and Section 3.13.2.14 of [RFC6274]. This certainly provides another attack vector for performing connection-reset attacks, as an attacker could forge TCP segments with a security/compartment that is different from that recorded in the corresponding TCB and, as a result, the attacked connection would be reset. It is interesting to note that for connections in the ESTABLISHED state, this check is performed after validating the TCP Sequence Number and checking the RST bit, but before validating the Acknowledgement field. Therefore, even if the stricter validation of the Acknowledgement field (described in Section 3.4) was implemented, it would not help to mitigate this attack vector. Resetting a connection due to a change in the Precedence value could also have a negative impact on interoperability. For example, the packets that correspond to a TCP connection could temporarily take a different internet path, in which some middle-box could re-mark the Precedence field (due to administration policies at the network to be transited). In such a scenario, an implementation following the advice in RFC 793 would abort the connection, when the connection would have otherwise probably survived. While the IPv4 Type of Service field (and hence the Precedence field) has been redefined by the Differentiated Services (DS) field specified in RFC 2474 [RFC2474], RFC 793 [RFC0793] was never formally updated in this respect. We note that both legacy systems that have not been upgraded to implement the differentiated services architecture described in RFC 2475 [RFC2475] and current implementations that have extrapolated the discussion of the Precedence field to the Differentiated Services field may still be vulnerable to the connection reset vector discussed in Section 1. Section 2 formally updates RFC 793 [RFC0793] such that these issues are mitigated. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Gont Expires September 30, 2012 [Page 3]
Internet-Draft Processing of IP layer information March 2012 document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Updating RFC 793 If the IP security/compartment field of an incoming TCP segment does not match the value recorded in the corresponding TCB, TCP MUST NOT abort the connection, but simply discard the corresponding packet. Additionally, this whole event SHOULD be logged as a security violation. If the IP Differentiated Services field of an incoming TCP segment does not match the value recorded in the corresponding TCB, TCP MUST NOT abort the corresponding connection. 3. IANA Considerations This document has no IANA actions. The RFC Editor is requested to remove this section before publishing this document as an RFC. 4. Security Considerations This document discusses the processing of the IP security/compartment and precedence information, and the interoperability and security implications that arise from it. It updates RFC 793 such that the aforementioned issues are eliminated. 5. Acknowledgements This document is based on the technical report "Security Assessment of the Transmission Control Protocol (TCP)" [CPNI-TCP] written by Fernando Gont on behalf of the UK CPNI. Fernando Gont would like to thank the UK CPNI for their continued support. 6. References 6.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Gont Expires September 30, 2012 [Page 4]
Internet-Draft Processing of IP layer information March 2012 Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 6.2. Informative References [CPNI-TCP] Gont, F., "CPNI Technical Note 3/2009: Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http:/ /www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>. [RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, July 2011. Author's Address Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com Gont Expires September 30, 2012 [Page 5]