idnits 2.17.1 draft-gont-tcpm-tcp-seccomp-prec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC793, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 29, 2012) is 4410 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2475 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions F. Gont 3 (tcpm) UTN-FRH / SI6 Networks 4 Internet-Draft March 29, 2012 5 Updates: 793 (if approved) 6 Intended status: Standards Track 7 Expires: September 30, 2012 9 Processing of IP Security/Compartment and Precedence Information by TCP 10 draft-gont-tcpm-tcp-seccomp-prec-00.txt 12 Abstract 14 This document discusses the security and interoperability problems 15 that may arise as a result of the processing of IP security/ 16 compartment and precedence information by TCP. Additionally, it 17 formally updates RFC 793 such that these issues are mitigated. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 30, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Updating RFC 793 . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 Section 3.9 (page 71) of RFC 793 [RFC0793] states that if the IP 66 security/compartment and precedence of an incoming segment does not 67 exactly match the security/compartment in the TCB, a RST segment 68 should be sent, and the connection should be aborted. 70 A discussion of the IP security options relevant to this section 71 can be found in Section 3.13.2.12, Section 3.13.2.13, and Section 72 3.13.2.14 of [RFC6274]. 74 This certainly provides another attack vector for performing 75 connection-reset attacks, as an attacker could forge TCP segments 76 with a security/compartment that is different from that recorded in 77 the corresponding TCB and, as a result, the attacked connection would 78 be reset. 80 It is interesting to note that for connections in the ESTABLISHED 81 state, this check is performed after validating the TCP Sequence 82 Number and checking the RST bit, but before validating the 83 Acknowledgement field. Therefore, even if the stricter validation 84 of the Acknowledgement field (described in Section 3.4) was 85 implemented, it would not help to mitigate this attack vector. 87 Resetting a connection due to a change in the Precedence value could 88 also have a negative impact on interoperability. For example, the 89 packets that correspond to a TCP connection could temporarily take a 90 different internet path, in which some middle-box could re-mark the 91 Precedence field (due to administration policies at the network to be 92 transited). In such a scenario, an implementation following the 93 advice in RFC 793 would abort the connection, when the connection 94 would have otherwise probably survived. 96 While the IPv4 Type of Service field (and hence the Precedence field) 97 has been redefined by the Differentiated Services (DS) field 98 specified in RFC 2474 [RFC2474], RFC 793 [RFC0793] was never formally 99 updated in this respect. We note that both legacy systems that have 100 not been upgraded to implement the differentiated services 101 architecture described in RFC 2475 [RFC2475] and current 102 implementations that have extrapolated the discussion of the 103 Precedence field to the Differentiated Services field may still be 104 vulnerable to the connection reset vector discussed in Section 1. 106 Section 2 formally updates RFC 793 [RFC0793] such that these issues 107 are mitigated. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Updating RFC 793 115 If the IP security/compartment field of an incoming TCP segment does 116 not match the value recorded in the corresponding TCB, TCP MUST NOT 117 abort the connection, but simply discard the corresponding packet. 118 Additionally, this whole event SHOULD be logged as a security 119 violation. 121 If the IP Differentiated Services field of an incoming TCP segment 122 does not match the value recorded in the corresponding TCB, TCP MUST 123 NOT abort the corresponding connection. 125 3. IANA Considerations 127 This document has no IANA actions. The RFC Editor is requested to 128 remove this section before publishing this document as an RFC. 130 4. Security Considerations 132 This document discusses the processing of the IP security/compartment 133 and precedence information, and the interoperability and security 134 implications that arise from it. It updates RFC 793 such that the 135 aforementioned issues are eliminated. 137 5. Acknowledgements 139 This document is based on the technical report "Security Assessment 140 of the Transmission Control Protocol (TCP)" [CPNI-TCP] written by 141 Fernando Gont on behalf of the UK CPNI. 143 Fernando Gont would like to thank the UK CPNI for their continued 144 support. 146 6. References 148 6.1. Normative References 150 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 151 RFC 793, September 1981. 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, March 1997. 156 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 157 "Definition of the Differentiated Services Field (DS 158 Field) in the IPv4 and IPv6 Headers", RFC 2474, 159 December 1998. 161 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 162 and W. Weiss, "An Architecture for Differentiated 163 Services", RFC 2475, December 1998. 165 6.2. Informative References 167 [CPNI-TCP] 168 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 169 of the Transmission Control Protocol (TCP)", 2009, . 173 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 174 Version 4", RFC 6274, July 2011. 176 Author's Address 178 Fernando Gont 179 UTN-FRH / SI6 Networks 180 Evaristo Carriego 2644 181 Haedo, Provincia de Buenos Aires 1706 182 Argentina 184 Phone: +54 11 4650 8472 185 Email: fgont@si6networks.com 186 URI: http://www.si6networks.com