6. QoS Application State Machine
The QoS application defines its own state machine that is based on
the authorization state machine defined in Section 8.1 of the
Diameter base protocol ([RFC3588]). The QoS state machine uses its
own messages, as defined in Section 5, and QoS AVPs, as defined in
Section 7.
6.1. Supplemented States for Push Mode
Using the Diameter base protocol state machine as a basis, the
following states are supplemented to the first two state machines in
which the session state is maintained on the server. These MUST be
supported in any QoS application implementations in support of
server-initiated Push mode (see Section 4.2.2).
The following states are supplemented to the state machine on the
server when state is maintained on the client, as defined in Section
8.1 of the Diameter base protocol[RFC3588]:
SERVER, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle An application or local Send Pending
event triggers an initial QIR initial
QoS request to the server request
Pending Received QIA with a failed Clean up Idle
Result-Code
Pending Received QIA with Result-Code Update Open
= SUCCESS session
Pending Error in processing received Send Discon
QIA with Result-Code = SUCCESS ASR
The following states are supplemented to the state machine on the
client when state is maintained on the server, as defined in Section
8.1 of the Diameter base protocol [RFC3588]:
CLIENT, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle QIR initial request Send Open
received and successfully QIA initial
processed answer,
reserve
resources
Idle QIR initial request Send Idle
received but not QIA initial
successfully processed answer with
Result-Code
!= SUCCESS
7. QoS Application AVPs
Each of the AVPs identified in the QoS-Authorization-Request/Answer
and QoS-Install-Request/Answer messages and the assignment of their
value(s) is given in this section.
7.1. Reused Base Protocol AVPs
The QoS application uses a number of session management AVPs, defined
in the base protocol ([RFC3588]).
Attribute Name AVP Code Reference [RFC3588]
Origin-Host 264 Section 6.3
Origin-Realm 296 Section 6.4
Destination-Host 293 Section 6.5
Destination-Realm 283 Section 6.6
Auth-Application-Id 258 Section 6.8
Result-Code 268 Section 7.1
Auth-Request-Type 274 Section 8.7
Session-Id 263 Section 8.8
Authorization-Lifetime 291 Section 8.9
Auth-Grace-Period 276 Section 8.10
Session-Timeout 27 Section 8.13
User-Name 1 Section 8.14
The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to
Diameter applications. The value of the Auth-Application-Id for the
Diameter QoS application is 9.
7.2. QoS Application-Defined AVPs
This document reuses the AVPs defined in Section 4 of [RFC5777].
This section lists the AVPs that are introduced specifically for the
QoS application. The following new AVPs are defined: Bound-Auth-
Session-Id and the QoS-Authorization-Data AVP.
The following table describes the Diameter AVPs newly defined in this
document for use with the QoS Application, their AVP code values,
types, possible flag values, and to determine whether the AVP may be
encrypted.
+-------------------+
| AVP Flag rules |
+----------------------------------------------|----+--------+-----+
| AVP Section | | SHLD| MUST|
| Attribute Name Code Defined Data Type |MUST| NOT| NOT|
+----------------------------------------------+----+--------+-----+
|QoS-Authorization-Data 579 7.2 OctetString| M | | V |
|Bound-Auth-Session-Id 580 7.2 UTF8String | M | | V |
+----------------------------------------------+----+--------+-----+
|M - Mandatory bit. An AVP with the "M" bit set and its value MUST |
| be supported and recognized by a Diameter entity in order for |
| the message, which carries this AVP, to be accepted. |
|V - Vendor-specific bit that indicates whether the AVP belongs to |
| an address space. |
+------------------------------------------------------------------+
QoS-Authorization-Data
The QoS-Authorization-Data AVP (AVP Code 579) is of type
OctetString. It is a container that carries application-session
or user-specific data that has to be supplied to the AE as input
to the computation of the authorization decision.
Bound-Authentication-Session-Id
The Bound-Authentication-Session AVP (AVP Code 580) is of type
UTF8String. It carries the ID of the Diameter authentication
session that is used for the network access [RFC4005]. It is used
to tie the QoS authorization request to a prior authentication of
the end-host done by a co-located application for network access
authentication ([RFC4005]) at the QoS NE.
8. Accounting
An NE MAY start an accounting session by sending an Accounting-
Request (ACR) message after successful QoS reservation and activation
of the data flow (see Figures 6 and 7). After every successful re-
authorization procedure (see Figures 8 and 9), the NE MAY initiate an
interim accounting message exchange. After successful session
termination (see Figures 10 and 11), the NE may initiate a final
exchange of accounting messages for the termination of the accounting
session and report final records for the use of the QoS resources
reserved. It should be noted that the two sessions (authorization
and accounting) have independent management by the Diameter base
protocol, which allows for finalizing the accounting session after
the end of the authorization session.
The detailed QoS accounting procedures are out of scope in this
document.
The communication starts with SIP signaling between the two endpoints
and the SIP proxy for negotiation and authorization of the requested
service and its parameters (see Figure 12). As a part of the
process, the SIP proxy verifies whether the user at Host A is
authorized to use the requested service (and potentially the ability
to be charged for the service usage). Negotiated session parameters
are provided to the end-host.
Subsequently, Host A initiates a QoS signaling message towards Host
B. It sends a QoS NSLP Reserve message, in which it includes
description of the required QoS (QSPEC object) and authorization data
for negotiated service session (part of the POLICY_DATA object).
Authorization data includes, as a minimum, the identity of the AE
(e.g., the SIP proxy) and an identifier of the application-service
session for which QoS resources are requested.
A QoS NSLP reserve message is intercepted and processed by the first
QoS-aware Network Element. The NE uses the Diameter QoS application
to request authorization for the received QoS reservation request.
The identity of the AE (in this case, the SIP server that is co-
located with a Diameter server) is put into the Destination-Host AVP,
any additional session authorization data is encapsulated into the
QoS-Authorization-Data AVP, and the description of the QoS resources
is included into the QoS-Resources AVP. These AVPs are included into
a QoS Authorization Request message, which is sent to the AE.
A QAR message will be routed through the AAA network to the AE. The
AE verifies the requested QoS against the QoS resources negotiated
for the service session and replies with a QoS-Authorization-Answer
(QAA) message. It carries the authorization result (Result-Code AVP)
and the description of the authorized QoS parameters (QoS-Resources
AVP), as well as duration of the authorization session
(Authorization-Lifetime AVP).
The NE interacts with the Traffic Control function and installs the
authorized QoS resources and forwards the QoS NSLP reserve message
farther along the data path. Moreover, the NE may serve as a
signaling proxy and process the QoS signaling (e.g., initiation or
termination of QoS signaling) based on the QoS decision received from
the Authorizing Entity.
9.2. Example Call Flow for Pull Mode (Failure Case)
This section repeats the scenario outlined in Section 9.1; however,
in this case, we show a session authorization failure instead of
success. Failures can occur in various steps throughout the protocol
execution, and in this example, we assume that the Diameter QAR
request processed by the Diameter server leads to an unsuccessful
result. The QAA message responds, in this example, with a permanent
error "DIAMETER_AUTHORIZATION_REJECTED" (5003) set in the Result-Code
AVP. When the NE receives this response, it discontinues the QoS
reservation signaling downstream and provides an error message back
to the end-host that initiated the QoS signaling request. The QoS
NSLP response signaling message would in this case carry an INFO_SPEC
object indicating the permanent failure as "Authorization failure"
(0x02).
..|.............................................|..............|..
. | | | | .
. | | | 200 OK (SDP)| .
. | | <-.-.-.....-.-.+ .
. | | +--------+-----------+ | .
. | | | Activate Session | | .
. | | | Parameters | | .
. | | +--------+-----------+ | .
. | 200 (SDP) | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
..|.............................................|..............|..
| <- - - - - - RAR - - - - - + |
| +---------+--------+ | |
| |Activate QoS State| | |
| +---------+--------+ | |
| +- - - - - - RAA - - - - - > |
| | |
/------------------+-----Data Flow---------------------------\
\------------------+-----------------------------------------/
| | |
.-.-.-.-. SIP signaling
- - - - - Diameter QoS Application messages
Figure 14: QoS Authorization Example - Push Mode
The communication starts with SIP signaling between the two endpoints
and the SIP proxy for negotiation and authorization of the requested
service and its parameters (see Figure 14). As a part of the
process, the SIP proxy verifies whether the user at Host A is
authorized to use the requested service (and potentially the ability
to be charged for the service usage).
A few implementation choices exist regarding the decision about when
to initiate the QoS reservation. [MMUSIC-MEDIA] discusses this
aspect with a focus on firewalling. In the example above, the DQA
server is triggered to authorize the QoS request based on session
parameters from the Session Description Protocol (SDP) payload. It
will use a QIR message to do so. For this example message flow, we
assume a two-stage commit, i.e., the SIP proxy interacts with the NE
twice. First, it only prepares the QoS reservation, and then, with
the arrival of the 200 OK, the QoS reservation is activated.
This example does not describe how the DQA server learns which DQA
client to contact. We assume pre-configuration in this example. In
any case, the address of the DQA client is put into the Destination-
Host AVP, the description of the QoS resources is included into the
QoS-Resources AVP, and the duration of the authorization session is
carried in the Authorization-Lifetime AVP.
When the DQA client receives the QIR, it interacts with the Traffic
Control function and reserves the authorized QoS resources
accordingly. At this point in time, the QoS reservation is not yet
activated.
When a 200 OK is returned, the DQA server may verify the accepted QoS
against the pre-authorized QoS resources and send a Diameter RAR
message to the DQA client in the NE for activating the installed
policies and commit the resource allocation.
10. IANA Considerations
This section contains the namespaces that have either been created in
this specification or had their values assigned to existing
namespaces managed by IANA.
10.1. AVP Codes
IANA has allocated two AVP codes to the registry defined in
[RFC3588]:
Registry:
AVP Code AVP Name Reference
-----------------------------------------------------------
579 QoS-Authorization-Data Section 7.2
580 Bound-Auth-Session-Id Section 7.210.2. Application IDs
IANA has allocated the following application ID from the registry
defined in [RFC3588] (using the next available value from the
7-16777215 range).
Registry:
ID values Name Reference
-----------------------------------------------------------
9 Diameter QoS application Section 5
10.3. Command Codes
IANA has allocated command code values from the registry defined in
[RFC3588].
Registry:
Code Value Name Reference
-----------------------------------------------------------
326 QoS-Authorization-Request (QAR) Section 5.1
326 QoS-Authorization-Answer (QAA) Section 5.2
327 QoS-Install-Request (QIR) Section 5.3
327 QoS-Install-Answer (QIA) Section 5.411. Security Considerations
This document describes a mechanism for performing authorization of a
QoS reservation at a third-party entity. The Authorizing Entity
needs sufficient information to make such an authorization decision
and this information may come from various sources, including the
application-layer signaling, the Diameter protocol (with its security
mechanisms), policy information stored available with a AAA server,
and a QoS signaling protocol.
Below there is a discussion about considerations for the Diameter QoS
interaction between an Authorizing Entity and a Network Element.
Security between the Authorizing Entity and the Network Element has a
number of components: authentication, authorization, integrity, and
confidentiality.
Authentication refers to confirming the identity of an originator for
all datagrams received from the originator. Lack of authentication
of Diameter messages between the Authorizing Entity and the Network
Element can seriously jeopardize the fundamental service rendered by
the Network Element. A consequence of not authenticating the message
sender by the Network Element would be that an attacker could spoof
the identity of a "legitimate" Authorizing Entity in order to
allocate resources, change resource assignments, or free resources.
The adversary can also manipulate the state at the Network Element in
such a way that it leads to a denial-of-service attack by, for
example, setting the allowed bandwidth to zero or allocating the
entire bandwidth available to a single flow.
A consequence of not authenticating the Network Element to an
Authorizing Entity is that an attacker could impact the policy-based
admission control procedure operated by the Authorizing Entity that
provides a wrong view of the resources used in the network. Failing
to provide the required credentials should be subject to logging.
Authorization refers to whether a particular Authorizing Entity is
authorized to signal a Network Element with requests for one or more
applications, adhering to a certain policy profile. Failing the
authorization process might indicate a resource theft attempt or
failure due to administrative and/or credential deficiencies. In
either case, the Network Element should take the proper measures to
log such attempts.
Integrity is required to ensure that a Diameter message has not been
maliciously altered. The result of a lack of data integrity
enforcement in an untrusted environment could be that an imposter
will alter the messages exchanged between a Network Entity and an
Authorizing Entity potentially causing a denial of service.
Confidentiality protection of Diameter messages ensures that the
signaling data is accessible only to the authorized entities. When
signaling messages from the Application Server (via the Authorizing
Entity towards the Network Element) traverse untrusted networks, lack
of confidentiality will allow eavesdropping and traffic analysis.
Additionally, Diameter QoS messages may carry authorization tokens
that require confidentiality protection.
Diameter offers security mechanisms to deal with the functionality
demanded in the paragraphs above. In particular, Diameter offers
communication security between neighboring Diameter peers using
Transport Layer Security (TLS) or IPsec. Authorization capabilities
are application specific and part of the overall implementation.
12. Acknowledgements
The authors would like to thank John Loughney and Allison Mankin for
their input to this document. In September 2005, Robert Hancock,
Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis,
and Elwyn Davies provided a detailed review. Robert also provided us
with good feedback earlier in 2005. Jerry Ash provided us review
comments in late 2005/early 2006. Rajith R provided some inputs to
the document in early 2007.
We would also like to thanks Alexey Melnikov, Adrian Farrel, and
Robert Sparks for their IESG reviews.
13. Contributors
The authors would like to thank Tseno Tsenov and Frank Alfano for
starting the Diameter Quality of Service work within the IETF, for
their significant contributions and for being the driving force for
the first few draft versions.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application",
RFC 4005, August 2005.
[RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality
of Service Parameters for Usage with Diameter",
RFC 5624, August 2009.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M.,
Jones, M., and A. Lior, "Traffic Classification and
Quality of Service (QoS) Attributes for Diameter",
RFC 5777, February 2010.
14.2. Informative References
[MMUSIC-MEDIA] Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication
along the Media Path", Work in Progress, March 2009.
[NSIS-NTLP] Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", Work in Progress,
June 2009.
[NSIS-QOS] Manner, J., Karagiannis, G., and A. McDonald, "NSLP
for Quality-of-Service Signaling", Work in Progress,
January 2010.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service",
RFC 2212, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
Framework for Policy-based Admission Control",
RFC 2753, January 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3313] Marshall, W., "Private Session Initiation Protocol
(SIP) Extensions for Media Authorization", RFC 3313,
January 2003.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
"Session Authorization Policy Element", RFC 3520,
April 2003.
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for
Session Set-up with Media Authorization", RFC 3521,
April 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
"The Network Access Identifier", RFC 4282,
December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
