Internet DRAFT - draft-thomson-mmusic-rtcweb-bw-consent
draft-thomson-mmusic-rtcweb-bw-consent
rtcweb M. Thomson
Internet-Draft B. Aboba
Intended status: Standards Track Microsoft
Expires: April 15, 2013 October 12, 2012
Bandwidth Constraints for Session Traversal Utilities for NAT (STUN)
draft-thomson-mmusic-rtcweb-bw-consent-00
Abstract
An attribute is defined for Session Traversal Utilities for NAT
(STUN) that allows for declarations of bandwidth limits on the
negotiated flow. The application of this attribute to reducing
denial of service attacks from internet telephony systems. Other
applications include negotiation of bandwidth at packet relays.
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 April 15, 2013.
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
described in the Simplified BSD License.
Thomson & Aboba Expires April 15, 2013 [Page 1]
Internet-Draft STUN Bandwidth October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The BANDWIDTH Attribute . . . . . . . . . . . . . . . . . . . . 4
4. Application . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. ICE Bandwidth Consent . . . . . . . . . . . . . . . . . . . 5
4.1.1. STUN Usage . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Bandwidth Limiting . . . . . . . . . . . . . . . . . . 5
4.1.3. Bandwidth Consent Revocation . . . . . . . . . . . . . 6
4.2. Relay Bandwidth Allocation . . . . . . . . . . . . . . . . 6
5. Bandwidth Measurement Considerations . . . . . . . . . . . . . 6
5.1. Rate Enforcement . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Thomson & Aboba Expires April 15, 2013 [Page 2]
Internet-Draft STUN Bandwidth October 2012
1. Introduction
A key security property that Interactivity Connectivity Establishment
(ICE) [RFC5245] establishes is that the subject of a flow of packets
consents to receive packets. This provides a measure of protection
against the Voice Hammer attack (see Section 18.5.1 of [RFC5245])
where an attacker with access to signaling induces valid clients to
send excessive amounts of data toward a victim.
ICE depends on the use of a Session Traversal Utilities for NAT
(STUN) Binding request and response to provide an indication of
consent. A host that provides a Binding response demonstrates that
they have seen the transaction ID and are therefore either on the
path between sender and receiver, or have an agent on the path.
As a result of the connectivity check, the sender determines that
either the receiving host consents to receiving packets, or some on-
path attacker has faked consent. In the latter case, the on-path
attacker is already in a position to generate packets toward the
receiving host, so this does not present an advantage to the attacker
and we discount the attack.
This basic consent mechanism only establishes that some data is
acceptable. It does not establish how much the receiver is prepared
to accept. In particular, where media multiplexing is negotiated,
consent cannot be provided for individual media; it must apply to all
potential streams received on a transport address. Given the wide
disparity in potential bandwidth usage by text, audio and video, this
enables a volume-based denial of service attack. In this attack a
service that is prepared to automatically accept real-time
communications can become the target of excessive bandwidth from
clients. This only requires that the client visits the attacker's
site, there is no user consent required.
This attack is only mitigated by measures such as continuing consent
[I-D.muthu-behave-consent-freshness]. Refusing to provide continuing
consent takes a non-trivial amount of time to effect changes in
senders. Thus, continuing consent can only limit the duration of an
attack, not prevent it, and only by refusing all media traffic.
This document defines a BANDWIDTH attribute for STUN that can be used
to prevent this attack. This attribute can also be used to request
and allocate bandwidth at a Traversal Using Relays around NAT (TURN)
relay.
This attribute is used for indicating a bandwidth limit that is set
in policy. The sender is not advised or required to utilize
bandwidth up to this limit; limits are usually set well in excess of
Thomson & Aboba Expires April 15, 2013 [Page 3]
Internet-Draft STUN Bandwidth October 2012
application needs. Senders also limit their use of bandwidth in
reaction to path congestion and "circuit breakers".
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
The term "sender" and "receiver" refer to peers that are respectively
sending or receiving packets on a given transport flow. In a typical
peer to peer transport flow, both peers act in both roles. ICE
terminology, specifically candidate, flow, and candidate are borrowed
from [RFC5245].
3. The BANDWIDTH Attribute
The BANDWIDTH attribute (identifier TBD) identifies the rate of
packet transmission in kilobits per second that is permitted for a
given transport flow. The BANDWIDTH attribute is a comprehension-
optional attribute (see Section 15 from [RFC5389]). Figure 1 shows
the format of this attribute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type (TBD) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Bandwidth Attribute Format
The value of this attribute is an unsigned integer that represents
the maximum bandwidth for the flow in kilobits per second (1 kilobit
= 1024 bits).
4. Application
Bandwidth limits are applied to both ICE connectivity checking and
TURN relay allocation.
Thomson & Aboba Expires April 15, 2013 [Page 4]
Internet-Draft STUN Bandwidth October 2012
4.1. ICE Bandwidth Consent
For a negotiated ICE flow, the BANDWIDTH attribute indicates the
bandwidth that a receiver consents to receive.
In the absence of a BANDWIDTH attribute, no bandwidth limits apply to
a flow.
4.1.1. STUN Usage
A sender that supports this attribute MUST include a BANDWIDTH
attribute in the STUN Binding requests it generates for connectivity
checks. The primary utility of this inclusion is to indicate support
for a parameter.
A receiver that supports this attribute includes the permitted
bandwidth in the STUN Binding response it generates. A receiver that
requires bandwidth consent MUST ignore Binding requests that do not
include the BANDWIDTH attribute. A receiver MAY use the value in the
Binding request as guidance on what bandwidth to permit.
4.1.2. Bandwidth Limiting
An ICE-capable sender MUST NOT exceed the allowed bandwidth that has
been indicated in connectivity checks for the specific flow.
Bandwidth limits for each flow are independent. That is, a bandwidth
limit learned from a connectivity check response only applies to
packets that are sent from the local candidate to the remote
candidate that were used in that connectivity check. An attacker
with access to signaling could otherwise insert a candidate that they
control. The attacker-controlled candidate could then indicate a
larger bandwidth limit that affects other flows.
Independent bandwidth limits for flows implies that where there are
multiple valid candidate pairs the overall bandwidth limit is
increased for each valid candidate pair. For an attacker, this
presents an opportunity to multiply the bandwidth that flows toward a
receiver by the number of valid candidate pairs. A receiver SHOULD
monitor the incoming bandwidth for a component and limit the
aggregate bandwidth to the expected maximum. This depends on
application-specific knowledge of how flows are expected to be used,
such as knowledge of how the ICE component relates to Session
Description Protocol (SDP) [RFC4566] "m=" lines. If an aggregate
limit is exceeded, the receiver SHOULD revoke consent (Section 4.1.3)
on one or more flows.
In ICE, a peer MAY choose to include a BANDWIDTH value of zero prior
to nominating a candidate pair. This implies that only STUN Binding
Thomson & Aboba Expires April 15, 2013 [Page 5]
Internet-Draft STUN Bandwidth October 2012
requests are permitted on the flow. The advantage of this is that
the bandwidth allowance is not increased by the number of valid
candidate pairs. This increases the latency of flow setup because
the controlled peer needs to perform a post-nomination connectivity
check to check if available bandwidth has increased to a usable
value.
4.1.3. Bandwidth Consent Revocation
During ongoing consent checks [I-D.muthu-behave-consent-freshness],
the BANDWIDTH attribute allows for a faster revocation of consent by
a receiver. Without the BANDWIDTH attribute, the receiver stops
responding to Binding requests. The sender only stops sending when
enough of these responses are lost. By responding with a BANDWIDTH
value of zero, a sender ceases packet transmission on the flow in a
much shorter time.
A sender MUST cease transmission of all packets toward a receiver
that indicates a bandwidth of zero. This is important even where
rates are averaged over time, where changes in the bandwidth limit
might otherwise take some time.
4.2. Relay Bandwidth Allocation
The BANDWIDTH attribute indicates a limit to available inbound
bandwidth for TURN [RFC5766] allocation. Inbound bandwidth is the
bandwidth of data sent from a peer toward the TURN server.
A BANDWIDTH attribute - when present in an Allocate request -
indicates that the given bandwidth is requested. A BANDWIDTH
attribute in an Allocate response indicates the limit that will be
applied by the TURN server. The value a TURN server provides could
be influenced by the value that a TURN client requests at the
discretion of server policy.
A TURN client can use the indicated bandwidth to limit the value that
it sends in ICE connectivity check responses.
Bandwidth that the TURN client sends toward the TURN server is not
governed by this attribute. A TURN server is able to terminate an
allocation if a TURN client generates excessive outbound bandwidth.
5. Bandwidth Measurement Considerations
Connectivity check and allocation messages (Binding and Allocate) are
exempt from any bandwidth measurement accounting. This allows
consent to be verified without being subject to delays due to
Thomson & Aboba Expires April 15, 2013 [Page 6]
Internet-Draft STUN Bandwidth October 2012
bandwidth throttling. Senders are expected to limit the rate of
outgoing connectivity checks using independent mechanisms.
In calculating bandwidth, the entire IP packet - including the header
- is measured. This is identical to the measurement performed by the
Real-Time Transport Protocol (RTP) [RFC3550]. At a TURN server,
bandwidth measurement is performed on the packets arriving at the
TURN server, prior to the encapsulation that occurs between TURN
server and TURN client.
Determining the rate requires that the bits be allocated to specific
intervals of time. How bits are allocated MAY vary between
implementations.
Measurement of bandwidth is imperfect and inconsistent. Packet
jitter can result in fluctuations in received packet rate so that a
receiver might see an instantaneous bandwidth that is different to
what the sender might have transmitted. Jitter can cause the
observed bandwidth of incoming packets to temporarily increase above
the permitted rate. At a minimum, implementations SHOULD allow for
short periods of excessive bandwidth to allow for these temporary
increases.
5.1. Rate Enforcement
[[Editor's Note: There are two approaches to this: Either make the
limit a hard limit (with a small jitter allowance), which would
necessitate fairly high bandwidth limits for normal usage lest there
be squeezing or dropping of video i-frames, which can significantly
affect a real-time experience. The other approach, taken here,
permits a more usage-aware limiting, taking the limit as more of a
"guideline", which allows latitude for temporary excess, enabling
more realistic limits (and probably some queueing somewhere), with
guarantees on compliance with the limit over longer periods.]]
Enforcement of bandwidth limits is a sender responsibility, though a
receiver or other middlebox MAY perform enforcement. Senders are
able to make temporary allowances for the data that is being
transmitted, by averaging bandwidth usage to account. This allows
for different bandwidth usage profiles. For example, real-time audio
typically uses a nearly constant rate, whereas bandwidth consumption
increases significantly for the transmission of intra-frames in real-
time video. In contrast, real-time application sharing has highly
unpredictable bandwidth consumption.
Enforcement of limits by nodes other than the sender SHOULD provide
an allowance for application usages that temporarily exceed the
limit. For example, assessing observed bandwidth usage as an average
Thomson & Aboba Expires April 15, 2013 [Page 7]
Internet-Draft STUN Bandwidth October 2012
over 10 seconds ensures that real-time video does not clip
unnecessarily; shorter durations could result in any enforcement
affecting valuable intra-frames.
6. Security Considerations
ICE negotiation potentially results in multiple candidate pairs for a
component becoming valid. If a non-zero bandwidth value is used
during the checking phase, the sender might be convinced that there
are multiple valid flows. Mitigation measures and considerations for
their use are described in Section 4.1.
7. IANA Considerations
IANA has allocated a code of (TBD) to the STUN BANDWIDTH attribute.
This attribute is registered in the "STUN Attribute" Registry
following the procedures of Section 18.2 of [RFC5389]. BANDWIDTH is
a comprehension-optional STUN attribute.
8. Acknowledgments
Humayun Khan, Tim Moore provided input and implementation experience.
9. References
9.1. Normative References
[I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for
Consent Freshness and Session Liveness",
draft-muthu-behave-consent-freshness-01 (work in
progress), July 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
Thomson & Aboba Expires April 15, 2013 [Page 8]
Internet-Draft STUN Bandwidth October 2012
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
9.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Authors' Addresses
Martin Thomson
Microsoft
3210 Porter Drive
Palo Alto, CA 94304
USA
Phone: +1 650-353-1925
Email: martin.thomson@outlook.com
Bernard Aboba
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Email: bernard_aboba@outlook.com
Thomson & Aboba Expires April 15, 2013 [Page 9]
