RFC 7982

Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)

📅 published September 2016, from ietf

RFC 7982 📦 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)

okay bestie, RFC 7982 is an Internet Engineering Task Force (IETF) document 🎀. It's a Standards Track doc published in September 2016, with ISSN 2070-1721. The authors are P. Martinsen, T. Reddy, D. Wing, and V. Singh. The header lists Cisco and callstats.io as their affiliations. The header doesn't list anything it obsoletes or updates, but Section 3.1 says it updates one STUN message structuring rule, so keep that in mind 👀

Abstract ✨

so a host with more than one interface has to pick the best one to talk through 🦋. the annoying part is that this choice usually comes from a static config and ignores how the path is actually doing, even though path quality can totally wreck the user experience 😭

this doc describes a way for an endpoint to measure path characteristics, namely fractional loss and RTT, using STUN messages 💜

Status of This Memo 📜

this is an Internet Standards Track document 🌸

it's a product of the IETF, meaning it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 7841 🫶

for the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7982 ⭐

Copyright (c) 2016 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), as in effect on the date of publication. please read these carefully, because they spell out your rights and restrictions for this doc 💅

code components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🧚

Table of Contents 🗂️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   4
   3.  Measuring RTT and Fractional Loss . . . . . . . . . . . . . .   4
     3.1.  TRANSACTION_TRANSMIT_COUNTER Attribute  . . . . . . . . .   4
     3.2.  Usage in Requests . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Usage in Responses  . . . . . . . . . . . . . . . . . . .   5
     3.4.  Example Operation . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction 🌈

okay so this doc extends STUN [RFC5389] so you can match STUN responses to the specific requests they belong to, even when retransmits happen 💖. that's a big deal because it helps the client work out path stuff like round-trip time (RTT) and fractional packet loss 📈

the TRANSACTION_TRANSMIT_COUNTER attribute from Section 3.1 can be used in Interactive Connectivity Establishment (ICE) [RFC5245] connectivity checks, which are STUN Binding requests and responses 🦋. it can also be used with Traversal Using Relays around NAT (TURN) [RFC5766] by adding this attribute to Allocate requests and responses, so you can measure loss and RTT between the client and the TURN server 🎀

ICE is a mechanism people use a lot in Voice over IP (VoIP) apps to get through NATs. it uses a static prioritization formula to order the candidate pairs and run connectivity checks. the most preferred address pairs get tested first, and once a good enough pair turns up, that pair gets used for communication and further connectivity tests stop 🍓

when there are multiple paths, the endpoint sends ICE connectivity checks across each path (candidate pair). picking the path with the lowest RTT is a reasonable move, but retransmits can make a perfectly good path look bad 😭. the catch is that STUN's retransmission algorithm [RFC5389] can't figure out the RTT when a STUN request packet gets retransmitted, because each request and retransmission is identical 🙈. on top of that, several STUN requests might go out before the connectivity between candidate pairs is confirmed (see Section 16 of [RFC5245]) 🌸

so to fix the identical request and response problem inside a STUN transaction, this doc changes the retransmission behavior for idempotent packets 💅. with this mechanism, a client can work out RTT and also get a hint about which path direction caused the packet loss. it does this by defining a new STUN attribute, and it requires compliant STUN (TURN and ICE) endpoints to count request packets 🧚

the controlling agent can use the mechanisms here to influence ICE candidate pair selection 👑. how ICE will actually use this info to improve active candidate pair selection is outside the scope of this doc 🫶

2. Notational Conventions 📝

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜

this spec uses terminology defined in ICE [RFC5245] and STUN [RFC5389] ✨

3. Measuring RTT and Fractional Loss 📊

this doc defines a new comprehension-optional STUN attribute called TRANSACTION_TRANSMIT_COUNTER, with a STUN Type of 0x8025. it's in the comprehension-optional range, which means STUN agents can safely ignore it. if ICE is in use, it falls back to normal procedures 🦋

if a client wants to measure RTT, it puts the TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. in that attribute, the client sends the number of times the STUN request was transmitted with the same transaction ID 🎀. the server echoes that transmission count back in the response, so the client can tell apart STUN responses that came from retransmitted requests 💖. that means the endpoint can use the STUN requests and responses to work out the RTT 📈

the server may also tell the client how many responses it has sent for the STUN request 🌈. this info also lets the client get a hint about which direction the packet loss happened in 👀. in some cases it's impossible to tell packet reordering apart from packet loss 😭. but if this info is collected as network metrics from several clients over a longer period, it'll be easier to spot a pattern that gives useful info 🍓

3.1. TRANSACTION_TRANSMIT_COUNTER Attribute 🎀

the TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a 32-bit value 🔢. this doc updates one of the STUN message structuring rules explained in Section 6 of [RFC5389]. under that rule, retransmission of the same request reuses the same transaction ID and is bit-wise identical to the previous request 🙈. for idempotent packets, the Req and Resp fields in the TRANSACTION_TRANSMIT_COUNTER attribute get incremented by 1 by the client or server for every transmission with the same transaction ID 💅. any retransmitted STUN request MUST be bit-wise identical to the previous request, except for the values in the TRANSACTION_TRANSMIT_COUNTER attribute 🫶

the IANA-assigned STUN type for the new attribute is 0x8025 🌸

the format of the value in the TRANSACTION_TRANSMIT_COUNTER attribute in the request looks like this 👇

       0                   1                   2                   3
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Reserved (Padding)     |    Req        |     Resp      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1: TRANSACTION_TRANSMIT_COUNTER Attribute in Request

here's what each field means 🧚

  • Req: Number of times the request is transmitted with the same transaction ID to the server.
  • Resp: Number of times a response with the same transaction ID is sent from the server. It MUST be set to zero in requests and ignored by the receiver.

the padding is needed to hit the 32-bit boundary that STUN attributes require 💜. the padding bits are ignored, but so they can be reused in the future, they MUST be set to zero 🌈

3.2. Usage in Requests ✨

when sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER attribute lets a client tell the server that it wants to measure RTT and get a hint about the direction of any packet loss 🦋

the client MUST populate the Req value in the TRANSACTION_TRANSMIT_COUNTER. this value MUST reflect the number of requests that have been transmitted to the server 🎀. so the initial value for the first request sent is 1, the first retransmit sets the value to 2, and so on 🔢

the Resp field in the attribute MUST be set to zero in the request 💅

3.3. Usage in Responses 🫶

when a server gets a STUN request that includes a TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request according to the STUN protocol [RFC5389], plus the specific rules here. the server checks the following 👀

  • If the TRANSACTION_TRANSMIT_COUNTER attribute is not recognized, ignore it, because its type says it's comprehension-optional. This should be the existing behavior, as explained in Section 7.3 of [RFC5389] 🌸
  • The server that supports the TRANSACTION_TRANSMIT_COUNTER attribute MUST echo back the Req field in the response, using a TRANSACTION_TRANSMIT_COUNTER attribute 💖
  • If the server is stateless or doesn't want to remember the transaction ID, it fills in the value 0 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in the response. If the server is stateful, it fills in the Resp field with the number of responses it has sent for the STUN request 🧚

a client that gets a STUN response with a TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to accurately calculate the RTT if retransmits are happening 📈

if the server sending the STUN response is stateless, the Resp field will always be 0 🙈. if the server keeps state of how many STUN requests came in with that same transaction ID, the value reflects how many packets the server has seen and responded to 🌈. this gives the client a hint about which direction the loss happened in 🍓. see Section 3.4 for more details 🎀

3.4. Example Operation

Okay so, here's an example run for when the server is stateful 🧚 (check out Figure 2). In the first case, every request and response arrives totally intact 💖.

In the upstream loss case, the first request gets lost 💀, but the second one arrives safe. When the client gets the response, it's like "wait, I sent two but the server only got one?" 🙈 The server checks too: the value in the Req field doesn't match how many requests it actually received, so yep, one request went missing. This can also happen at startup when firewalls or NATs block unsolicited incoming traffic 🚧.

In the downstream loss case, the responses get lost. The client was expecting multiple responses, and while the server responded to three requests, only one response showed up 😭.

In the both-directions case, requests and responses get lost in tandem 💅. The server notices one request packet never arrived. The client, expecting three responses, only got one, so it figures out that one request and one response packet were lost 🫶.

   |     Normal    |  Upstream loss | Downstream loss | Both upstream &|
   |               |                |                 | downstream loss|
   | Client Server |  Client Server |  Client  Server |  Client Server |
   |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
   | 1        1,1  |  1        x    |  1         1,1  |  1        x    |
   |   1,1         |                |    x            |                |
   |               |  2        2,1  |  2         2,2  |  2        2,1  |
   |               |    2,1         |    x            |    x           |
   |               |                |  3         3,3  |  3        3,2  |
   |               |                |    3,3          |    3,2         |

Figure 2: Retransmit Operation between Client and Server 🎀

Another example is when the client sends two requests, but the second one reaches the server before the first because of out-of-order delivery 🌀. In this case, the stateful server puts value 1 in the Resp field of the TRANSACTION_TRANSMIT_COUNTER attribute it sends back in response to the second request, and value 2 in the Resp field of the attribute it sends in response to the first request ✨.

The point of this mechanism is not to do comprehensive and accurate measurements of which direction the loss is happening in 🙅. Sometimes it might not be able to tell the difference between downstream loss and packet reordering 🤷.

4. IANA Considerations ✨

This document defines the TRANSACTION_TRANSMIT_COUNTER STUN attribute, described in Section 3. IANA has allocated the comprehension-optional codepoint 0x8025 for this attribute 🔥.

5. Security Considerations 💀

Okay bestie, this part is SERIOUS 😤. The security considerations discussed in [RFC5389] are to be taken into account. STUN requires that the 96-bit transaction ID be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically strong. This is good enough security against an off-path attacker 🛡️.

An on-path attacker, though, can either inject a fake response or modify the values in the TRANSACTION_TRANSMIT_COUNTER attribute to mislead the client and the server 😈. This attack can be mitigated using STUN authentication. Since the TRANSACTION_TRANSMIT_COUNTER is expected to be used between peers using ICE, and ICE uses a STUN short-term credential mechanism, the risk of an on-path attack influencing the messages is minimal 💜.

If the TRANSACTION_TRANSMIT_COUNTER is used with an Allocate request, one of the following mechanisms can be used to stop attackers from pretending to be a TURN server and sending a bogus TRANSACTION_TRANSMIT_COUNTER attribute in the Allocate response: 1) the STUN long-term credential mechanism, 2) the STUN Extension for Third-Party Authorization [RFC7635], or 3) a TLS or DTLS connection between the TURN client and the TURN server.

Even so, an attacker could still corrupt, remove, or delay an ICE request or response, in order to discourage that path from being used 🥀.

Also, if it's not encrypted, the information sent in any STUN packet can potentially be observed passively and used for reconnaissance and later attacks 👀. So encrypt your stuff, periodt 🔐.

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 🫶

Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin Thomson, Oleg Moskalenko, Ram Mohan Ravindranath, Spencer Dawkins, Suresh Krishnan, Ben Campbell, Mirja Kuehlewind, Lionel Morand, Kathleen Moriarty, and Alissa Cooper for their valuable input and comments 💖.

Authors' Addresses 🌸

Paal-Erik Martinsen
Cisco Systems, Inc.
Philip Pedersens vei 22
Lysaker, Akershus  1325
Norway

Email: palmarti@cisco.com


Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka  560103
India

Email: tireddy@cisco.com


Dan Wing

Email: dwing-ietf@fuggles.com


Varun Singh
CALLSTATS I/O Oy
Runeberginkatu 4c A 4
Helsinki  00100
Finland

Email: varun@callstats.io
URI:   https://www.callstats.io/about
📦 where this page comes from