idnits 2.17.1 draft-ietf-tram-measurement-rtt-loss-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 (June 16, 2016) is 2870 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 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 T. Reddy 4 Intended status: Standards Track D. Wing 5 Expires: December 18, 2016 Cisco 6 V. Singh 7 callstats.io 8 June 16, 2016 10 Measurement of Round Trip Time and Fractional Loss Using STUN 11 draft-ietf-tram-measurement-rtt-loss-00 13 Abstract 15 A host with multiple interfaces needs to choose the best interface 16 for communication. Oftentimes, this decision is based on a static 17 configuration and does not consider the path characteristics, which 18 may affect the user experience. 20 This document describes a mechanism for an endpoint to measure the 21 path characteristics fractional loss and RTT using Session Traversal 22 Utilities for NAT (STUN) messages. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 18, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 60 3. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . 3 61 3.1. TRANSACTION_TRANSMIT_COUNTER attribute . . . . . . . . . 4 62 3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 5 64 3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 This document extends STUN [RFC5389] to make it possible to correlate 76 STUN responses to specific request when re-transmits occur. This 77 assists the client in determining path characteristics like round- 78 trip time (RTT) and fractional packet loss. 80 The TRANSACTION_TRANSMIT_COUNTER attribute introduced in section 81 Section 3.1 can be used in ICE [RFC5245] connectivity checks (STUN 82 Binding request and response). It can also be used with TURN 83 [RFC5766] by adding this attribute to Allocate requests and responses 84 to measure loss and RTT between the client and respective TURN 85 server. 87 ICE is a mechanism commonly used in VoIP applications to traverse 88 NATs, and it uses a static prioritization formula to order the 89 candidate pairs and perform connectivity checks, in which the most 90 preferred address pairs are tested first and when a sufficiently good 91 pair is discovered, that pair is used for communications and further 92 connectivity tests are stopped. 94 When multiple paths are available for communication, the endpoint 95 sends ICE connectivity checks across each path (candidate pair). 96 Choosing the path with the lowest round trip time is a reasonable 97 approach, but re-transmits can cause an otherwise good path to appear 98 flawed. However, STUN's retransmission algorithm [RFC5389] cannot 99 determine the round-trip time (RTT) if a STUN request packet is re- 100 transmitted, because each request and retransmission packet is 101 identical. Further, several STUN requests may be sent before the 102 connectivity between candidate pairs are ascertained (see Section 16 103 of [RFC5245]). To resolve the issue of identical request and 104 response packets in a STUN transaction, this document changes the 105 retransmission behavior for idempotent packets. In addition to 106 determining RTT, it is also possible to get a hint regarding which 107 path direction caused packet loss. This is achieved by defining a 108 new STUN attribute and requires compliant STUN (TURN, ICE) endpoints 109 to count request packets. 111 The mechanisms described in this document can be used by the 112 controlling agent to influence the ICE candidate pair selection. How 113 ICE actually will use this information to improve the active 114 candidate pair selection is outside the scope of this document. 116 2. Notational Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 This specification uses terminology defined in ICE [RFC5245] and STUN 123 [RFC5389]. 125 3. Measuring RTT and Fractional Loss 127 This document defines a new comprehension-optional STUN attribute 128 TRANSACTION_TRANSMIT_COUNTER with a STUN Type TBD-CA. This type is 129 in the comprehension-optional range, which means that STUN agents can 130 safely ignore the attribute. If ICE is in use it will fallback to 131 normal procedures. 133 If a client wishes to measure RTT, it inserts the 134 TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. In this 135 attribute the client sends the number of times the STUN request is 136 transmitted with the same Transaction ID. The server would echo back 137 the transmission count in the response so that client can distinguish 138 STUN responses from the re-transmitted requests. Hence, the endpoint 139 can use the STUN requests and responses to determine the round-trip 140 time (RTT). The server may also convey the number of responses it 141 has sent for the STUN request to the client. Further, this 142 information enables the client to get a hint regarding what direction 143 the packet loss occurred. In some cases, it is impossible to 144 distinguish between packet reordering and packet loss. However if 145 this information is collected as network metrics from several clients 146 over a longer time period it will be easier to detect a pattern that 147 can provide useful information. 149 3.1. TRANSACTION_TRANSMIT_COUNTER attribute 151 The TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a 152 32-bit value. This document updates one of the STUN message 153 structuring rules explained in Section 6 of [RFC5389] wherein resends 154 of the same request reuse the same transaction ID and are bit-wise 155 identical to the previous request. For idempotent packets, the Req 156 and Resp fields in the TRANSACTION_TRANSMIT_COUNTER attribute will be 157 incremented by 1 by the client or server for every transmission with 158 the same transaction id. Any re-transmitted STUN request MUST be 159 bit-wise identical to the previous request except for the values in 160 the TRANSACTION_TRANSMIT_COUNTER attribute. 162 The IANA assigned STUN type for the new attribute is TBD-CA. 164 The format of the value in TRANSACTION_TRANSMIT_COUNTER attribute in 165 the request is: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Reserved (Padding) | Req | Resp | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: TRANSACTION_TRANSMIT_COUNTER attribute in request 175 The fields is described below: 177 Req: Number of times request is transmitted with the same 178 transaction ID to the server. 180 Resp: Number of times a response with the same transaction ID is 181 sent from the server. MUST be set to zero in requests and ignored 182 by the receiver. 184 The padding is necessary to hit the 32-bit boundary needed for STUN 185 attributes. The padding bits are ignored, but to allow for future 186 reuse of these bits they MUST be set to 0. 188 3.2. Usage in Requests 190 When sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER 191 Attribute allows a client to indicate to the server that it wants to 192 measure RTT and get a hint of the direction of any packet loss. 194 The client MUST populate the Req value in the 195 TRANSACTION_TRANSMIT_COUNTER. This value MUST reflect the number of 196 requests that have been transmitted to the server. Initial value for 197 the first request sent is therefore 1. The first re-transmit will 198 set the value to 2 and so on. 200 The Resp filed in the attribute MUST be set to zero in the request. 202 3.3. Usage in Responses 204 When a server receives a STUN request that includes a 205 TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as 206 per the STUN protocol [RFC5389] plus the specific rules mentioned 207 here. The server checks the following: 209 o If the TRANSACTION_TRANSMIT_COUNTER attribute is not recognized, 210 ignore the attribute because its type indicates that it is 211 comprehension- optional. This should be the existing behavior as 212 explained in section 3.1 of [RFC5389]. 214 o The server that supports TRANSACTION_TRANSMIT_COUNTER attribute 215 MUST echo back the Req field in the response using a 216 TRANSACTION_TRANSMIT_COUNTER attribute. 218 o If the server is stateless or does not want to remember the 219 transaction ID then it would populate value 0 for the Resp field 220 in TRANSACTION_TRANSMIT_COUNTER attribute sent in the response. 221 If the server is stateful then it populates the Resp field with 222 the number of responses it has sent for the STUN request. 224 A client that receives a STUN response with a 225 TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to 226 accurately calculate the RTT if retransmits are occurring. 228 If the server sending the STUN response is stateless the value of the 229 Resp field will always be 0. If the server keeps state of the 230 numbers of STUN request with that same transaction id the value will 231 reflect how many packets the server have seen and responded to. This 232 gives the client a hint of which direction loss occurred. See 233 section Section 3.4 for more details. 235 3.4. Example Operation 237 Example operation, when a server is stateful, is described in 238 Figure 2. In the first case, all the requests and responses are 239 received correctly. 241 In the upstream loss case, the first request is lost, but the second 242 one is received correctly, the client on receiving the response notes 243 that while 2 requests were sent, only one was received by the server. 244 The server also realizes that the value in the Req field does not 245 match the number of received requests, therefore 1 request was lost. 246 This may also occur at startup in the presence firewalls or NATs that 247 block unsolicited incoming traffic. 249 In the downstream loss case, the responses get lost, client expecting 250 multiple responses, notes that while the server responded to 3 251 requests but only 1 response was received. 253 In the both loss case, requests and responses get lost in tandem, the 254 server notes one request packet was not received, while the client 255 expecting 3 responses received only one, it notes that one request 256 and response packets were lost. 258 | Normal | Upstream loss | Downstream loss | Both loss | 259 | Client Server | Client Server | Client Server | Client Server | 260 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 261 | 1 1,1 | 1 x | 1 1,1 | 1 x | 262 | 1,1 | | x | | 263 | | 2 2,1 | 2 2,2 | 2 2,1 | 264 | | 2,1 | x | x | 265 | | | 3 3,3 | 3 3,2 | 266 | | | 3,3 | 3,2 | 268 Figure 2: Retransmit Operation between client and Server 270 Another example could be the client sends two requests but the second 271 request arrives at the server before the first request because of out 272 of order delivery. In this case, the stateful server populates value 273 1 for the Resp field in TRANSACTION_TRANSMIT_COUNTER attribute sent 274 in response to the second request and value 2 for the Resp field in 275 TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the first 276 request. 278 The intention with this mechanism is not to carry out comprehensive 279 and accurate measurements regarding in what direction loss is 280 occurring. In some cases, it might not be able to distinguish the 281 difference between downstream loss and packet reordering. 283 4. IANA Considerations 285 [Paragraphs in braces should be removed by the RFC Editor upon 286 publication] 288 [The TRANSACTION_TRANSMIT_COUNTER attribute requires that IANA 289 allocate a value in the "STUN attributes Registry" from the 290 comprehension-optional range (0x8000-0xBFFF), to be replaced for TBD- 291 CA throughout this document] 293 This document defines the TRANSACTION_TRANSMIT_COUNTER STUN 294 attribute, described in Section 3. IANA has allocated the 295 comprehension-optional codepoint TBD-CA for this attribute. 297 5. Security Considerations 299 Security considerations discussed in [RFC5389] are to be taken into 300 account. STUN requires the 96 bits transaction ID to be uniformly 301 and randomly chosen from the interval 0 .. 2**96-1, and be 302 cryptographically strong. This is good enough security against an 303 off-path attacker. An on-path attacker can either inject a fake 304 response or modify the values in TRANSACTION_TRANSMIT_COUNTER 305 attribute to mislead the client and server. This attack can be 306 mitigated using STUN authentication. As TRANSACTION_TRANSMIT_COUNTER 307 is expected to be used between peers using ICE, and ICE uses STUN 308 short-term credential mechanism the risk of on-path attack 309 influencing the messages is minimal. If TRANSACTION_TRANSMIT_COUNTER 310 is used with Allocate request then STUN long-term credential 311 mechanism or STUN Extension for Third-Party Authorization [RFC7635] 312 or (D)TLS connection can be used between the TURN client and the TURN 313 server to prevent attackers from trying to impersonate a TURN server 314 and sending bogus TRANSACTION_TRANSMIT_COUNTER attribute in the 315 Allocate response. However, an attacker could corrupt, remove, or 316 delay an ICE request or response, in order to discourage that path 317 from being used. 319 The information sent in any STUN packet if not encrypted can 320 potentially be observed passively and used for reconnaissance and 321 later attacks. 323 6. Acknowledgements 325 Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin 326 Thomson, Oleg Moskalenko, Ram Mohan R, Spencer Dawkins, Suresh 327 Krishnan, Ben Campbell, Mirja Kuhlewind, Lionel Morand, Kathleen 328 Moriarty and Alissa Cooper for valuable inputs and comments. 330 7. References 332 7.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 336 RFC2119, March 1997, 337 . 339 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 340 (ICE): A Protocol for Network Address Translator (NAT) 341 Traversal for Offer/Answer Protocols", RFC 5245, DOI 342 10.17487/RFC5245, April 2010, 343 . 345 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 346 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 347 DOI 10.17487/RFC5389, October 2008, 348 . 350 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 351 Relays around NAT (TURN): Relay Extensions to Session 352 Traversal Utilities for NAT (STUN)", RFC 5766, DOI 353 10.17487/RFC5766, April 2010, 354 . 356 7.2. Informative References 358 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 359 "Session Traversal Utilities for NAT (STUN) Extension for 360 Third-Party Authorization", RFC 7635, DOI 10.17487/ 361 RFC7635, August 2015, 362 . 364 Authors' Addresses 366 Paal-Erik Martinsen 367 Cisco Systems, Inc. 368 Philip Pedersens vei 22 369 Lysaker, Akershus 1325 370 Norway 372 Email: palmarti@cisco.com 373 Tirumaleswar Reddy 374 Cisco Systems, Inc. 375 Cessna Business Park, Varthur Hobli 376 Sarjapur Marathalli Outer Ring Road 377 Bangalore, Karnataka 560103 378 India 380 Email: tireddy@cisco.com 382 Dan Wing 383 Cisco Systems, Inc. 384 170 West Tasman Drive 385 San Jose, California 95134 386 USA 388 Email: dwing@cisco.com 390 Varun Singh 391 Nemu Dialogue System Oy 392 Itaemerenkatu 5 393 Helsinki 00150 394 Finland 396 Email: varun@callstats.io