RFC 5866
Diameter Quality-of-Service Application
Pages: 51
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 34 to 51
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 != SUCCESS7. 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.
9. Examples
9.1. Example Call Flow for Pull Mode (Success Case)
This section presents an example of the interaction between the end- host and Diameter QoS application entities using Pull mode. The application-layer signaling is, in this example, provided using SIP. Signaling for a QoS resource reservation is done using the QoS NSIS Signaling Layer Protocol (NSLP). The authorization of the QoS reservation request is done by the Diameter QoS application (DQA). End-Host SIP Proxy Correspondent requesting QoS (DQA Server) Node | | | ..|....Application-layer SIP signaling.......|..............|.. . | Invite (SDP) | | . . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | . . | 100 Trying | | . . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| . . | +-.-.-.....-.-.> . . | | 180 SDP' | . . | <-.-.-.....-.-.+ . . | +--------+--------+ | . . | |Authorize session| | . . | | parameters | | . . | 180 (Session parameters) +--------+--------+ | . . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | . ..|..........................................|... ..........|.. | | | | +------------+ | | | | NE | | | | |(DQA Client)| | | | +------+-----+ | | | | | | |QoS NSLP Reserve | | | +------------------> QAR | | | (POLICY_DATA>v +- - - - -<<AAA>>- - - -> | | QSPEC) v >===>(Destination-Host, | | | v >=======>QoS-Authorization-Data++------------+ | | >===========>QoS-Resources) |Authorize | | | | |QoS resources| | | | ++------------+ | | | QAA | | | <- - - - -<<AAA>>- - - -+ | | |(Result-Code, | | | |QoS-Resources, | | | |Authorization-Lifetime)| |
| +---------+--------+ | | | |Install QoS state1| | | | |+ Authz session | | | | +---------+--------+ | | | |QoS NSLP Reserve | | +---------------..............---------> | | | | | QoS NSLP Response| |QoS NSLP Response <---------------..............---------+ <------------------+ | | | QoS NSLP Query| |QoS NSLP Query <---------------..............---------+ <------------------+ | |QoS NSLP Reserve | | +------------------> QAR | | | +- - - - -<<AAA>>- - - -> | | | +---+---------+ | | | |Authorize | | | | |QoS resources| | | | QAA +---+---------+ | | <- - - - -<<AAA>>- - - -+ | | +---------+--------+ | | | |Install QoS state2| | | |+ Authz session | | | +---------+--------+ | | | QoS NSLP Reserve | | +---------------..............---------> | | QoS NSLP Response| |QoS NSLP Response <---------------..............---------+ <------------------+ | | | | /------------------+--Data Flow---------------------------\ \------------------+--------------------------------------/ | | | .-.-.-.-. SIP signaling --------- QoS NSLP signaling - - - - - Diameter QoS Application messages ========= Mapping of objects between QoS and AAA protocol Figure 12: QoS Authorization Example - Pull 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 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).
End-Host SIP Proxy Correspondent requesting QoS (DQA Server) Node | | | ..|...................SIP Signaling..........|..............|.. . | Invite (SDP) | | . . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | . . | 100 Trying | | . . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| . . | +-.-.-.....-.-.> . . | | 180 SDP' | . . | <-.-.-.....-.-.+ . . | +--------+--------+ | . . | |Authorize session| | . . | | parameters | | . . | 180 (Session parameters) +--------+--------+ | . . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | . ..|..........................................|... ..........|.. | | | | +------------+ | | | | NE | | | | |(DQA Client)| | | | +------+-----+ | | | | | | |QoS NSLP Reserve | | | +------------------> QAR | | | (POLICY_DATA>v +- - - - -<<AAA>>- - - -> | | QSPEC) v >===>(Destination-Host, | | | v >=======>QoS-Authorization-Data++------------+ | | >===========>QoS-Resources) |Authorize | | | | |QoS resources| | | | ++------------+ | | | QAA | | | <- - - - -<<AAA>>- - - -+ | | |(Result-Code = 5003) | | | | | | |QoS NSLP Response | | | |(with error 0x02) | | | <------------------+ | | | | | | | | | | .-.-.-.-. SIP signaling --------- QoS NSLP signaling - - - - - Diameter QoS Application messages ========= Mapping of objects between QoS and AAA protocol Figure 13: QoS Authorization Example - Pull Mode (Failure Case)
9.3. Example Call Flow for Push Mode
This section presents an example of the interaction between the end- host and Diameter QoS application entities using Push mode. The application-layer signaling is, in this example, provided using SIP. Signaling for a QoS resource reservation is done using the QoS NSLP. The authorization of the QoS reservation request is done by the Diameter QoS application (DQA). End-Host NE SIP Proxy Correspondent requesting QoS (DQA Client) (DQA Server) Node | | | | ..|..................|...SIP Signaling..........|..............|.. . | Invite(SDP Offer)| | | . . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.->| . . | | | 180 | . . |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.-.| . ..|.............................................|..............|.. | | +---------+-------------+| | | | Authorize Request || | | | Keep Session Data || | | |/Authz-time,Session-Id/|| | | +---------+-------------+| | | | | | |<-- - -- - QIR - -- - -- -+ | | |(Initial Request,Decision | | | |(QoS-Resources,Authz-time)| | | +-------+---------+ | | | |Install QoS State| | | | | + | | | | | Authz Session | | | | | /Authz-time/ | | | | +-------+---------+ | | | + - - -- - QIA - - - - - ->| | | | (Result-Code, | | | | QoS-Resources) | | | | +----------+------------+ | | | | Successful | | | | | QoS Reservation | | | | +----------+------------+ |
..|.............................................|..............|.. . | | | | . . | | | 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.
Authors' Addresses
Dong Sun (editor) Alcatel-Lucent 600 Mountain Ave Murray Hill, NJ 07974 USA Phone: +1 908 582 2617 EMail: d.sun@alcatel-lucent.com Peter J. McCann Motorola Labs 1301 E. Algonquin Rd Schaumburg, IL 60196 USA Phone: +1 847 576 3440 EMail: pete.mccann@motorola.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Tina Tsou Huawei Shenzhen, P.R.C EMail: tena@huawei.com Avri Doria Lulea University of Technology Arbetsvetenskap Lulea, SE-97187 Sweden EMail: avri@ltu.se
Glen Zorn (editor) Network Zen 1310 East Thomas Street #306 Seattle, Washington 98102 USA Phone: +1 (206) 377-9035 EMail: gwz@net-zen.net