idnits 2.17.1 draft-martinsen-tram-dscp-mangle-detection-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2016) is 2736 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Martinsen 3 Internet-Draft S. Nandakumar 4 Intended status: Experimental Cisco 5 Expires: April 24, 2017 October 21, 2016 7 DSCP mangle detection 8 draft-martinsen-tram-dscp-mangle-detection-00 10 Abstract 12 This document describes a mechanism for an endpoint to detect DSCP 13 "mangling" by the network path. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 24, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 51 3. Detecting DSCP mangling . . . . . . . . . . . . . . . . . . . 3 52 3.1. DSCP VALUE attribute . . . . . . . . . . . . . . . . . . 3 53 3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 3 54 3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 3 55 3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 In some use-cases is useful to know if the network path changes the 67 DSCP/TOS values in the IP header. 69 This document introduces a new STUN attribute that can carry the 70 original DSCP/TOS values. This enables the remote receiver to 71 compare the values in the IP header and the STUN attribute to detect 72 mangling. 74 The information in the STUN attribute is probably of little interest 75 for the remote receiver. The main use case is to collect metrics 76 regarding how often DSCP values are mangled. 78 ICE could potentially also use this information to prefer paths with 79 intact DSCP markings. 81 (Just assigning an attribute from IANA is possible, but we thought it 82 was better to have a draft describing the attribute so everyone knows 83 what it is) 85 2. Notational Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 This specification uses terminology defined in ICE [RFC5245] And STUN 92 [RFC5389]. 94 3. Detecting DSCP mangling 96 Both ICE ICE [RFC5245] connectivity checks and TURN ICE [RFC5766] 97 allocations can benefit from detecting if the DSCP bits survives the 98 rough journey across the Internet ocean. 100 3.1. DSCP VALUE attribute 102 The IANA assigned STUN type for the new attribute is TBD-CA. 104 The format of the value in DSCP_VALUE attribute in the request is: 106 0 1 2 3 107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Tx DSCP Value | Rx DSCP Value | Reserved | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 1: DSCP_VALUE attribute 114 The fields is described below: 116 Tx DSCP value: The DSCP/TOS field value if the IP header carrying 117 the transmitted STUN packet. 119 Rx DSCP value: The DSCP/DOS field value if the IP header in received 120 STUN packet on the same 5-tuple. 122 The padding is necessary to hit the 32-bit boundary needed for STUN 123 attributes. The padding bits are ignored, but to allow for future 124 reuse of these bits they MUST be set to 0. 126 3.2. Usage in Requests 128 When sending a STUN request in sets the Tx DSCP value field to the 129 same value as the DSCP/TOS field in the IP header of the packet that 130 is going to carry the STUN request. The Rx DSCP value MUST be set to 131 0. 133 3.3. Usage in Responses 135 This attribute MUST only be added to the response if it was present 136 in the request. 138 The Tx DSCP value field is populated with the value of the DSCP/TOS 139 field of the IP packet carrying the STUN response. the Rx DSCP value 140 is populated with the value from the DSCP/TOS field from the packet 141 carrying the original receiving STUN request. 143 3.4. Example Operation 145 When a client receives the response it can compare the values of in 146 the DSCP_VALUE attribute with values from the IP socket. The results 147 could be used to detect and collect metrics regarding DSCP 148 "survivability" on the Internet. It could potentially also influence 149 ICE path decisions. 151 4. IANA Considerations 153 [Paragraphs in braces should be removed by the RFC Editor upon 154 publication] 156 [The TRANSACTION_TRANSMIT_COUNTER attribute requires that IANA 157 allocate a value in the "STUN attributes Registry" from the 158 comprehension-optional range (0x8000-0xBFFF), to be replaced for TBD- 159 CA throughout this document] 161 This document defines the DSCP_VALUE STUN attribute, described in 162 Section 3. IANA has allocated the comprehension-optional code-point 163 TBD-CA for this attribute. 165 5. Security Considerations 167 Security considerations discussed in [RFC5389] are to be taken into 168 account. STUN requires the 96 bits transaction ID to be uniformly 169 and randomly chosen from the interval 0 .. 2**96-1, and be 170 cryptographically strong. This is good enough security against an 171 off-path attacker. An on-path attacker can either inject a fake 172 response or modify the values in DSCP_VALUE attribute to mislead the 173 client and server. This attack can be mitigated using STUN 174 authentication. As DSCP_VALUE is expected to be used between peers 175 using ICE, and ICE uses STUN short-term credential mechanism the risk 176 of on-path attack influencing the messages is minimal. If DSCP_VALUE 177 is used with Allocate request then STUN long-term credential 178 mechanism or STUN Extension for Third-Party Authorization [RFC7635] 179 or (D)TLS connection can be used between the TURN client and the TURN 180 server to prevent attackers from trying to impersonate a TURN server 181 and sending bogus DSCP_VALUE attribute in the Allocate response. 183 The information sent in any STUN packet if not encrypted can 184 potentially be observed passively and used for reconnaissance and 185 later attacks. 187 6. Acknowledgements 189 Someone that provided feedback? 191 7. References 193 7.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 197 RFC2119, March 1997, 198 . 200 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 201 (ICE): A Protocol for Network Address Translator (NAT) 202 Traversal for Offer/Answer Protocols", RFC 5245, DOI 203 10.17487/RFC5245, April 2010, 204 . 206 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 207 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 208 DOI 10.17487/RFC5389, October 2008, 209 . 211 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 212 Relays around NAT (TURN): Relay Extensions to Session 213 Traversal Utilities for NAT (STUN)", RFC 5766, DOI 214 10.17487/RFC5766, April 2010, 215 . 217 7.2. Informative References 219 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 220 "Session Traversal Utilities for NAT (STUN) Extension for 221 Third-Party Authorization", RFC 7635, DOI 10.17487/ 222 RFC7635, August 2015, 223 . 225 Authors' Addresses 227 Paal-Erik Martinsen 228 Cisco Systems, Inc. 229 Philip Pedersens vei 22 230 Lysaker, Akershus 1325 231 Norway 233 Email: palmarti@cisco.com 234 Suhas Nandakumar 235 Cisco Systems, Inc. 236 170 West Tasman Drive 237 San Jose, California 95134 238 USA 240 Email: snandaku@cisco.com