draft-ietf-dime-diameter-qos-06.txt   draft-ietf-dime-diameter-qos-07.txt 
Diameter Maintenance and D. Sun, Ed. Diameter Maintenance and D. Sun, Ed.
Extensions (DIME) Alcatel-Lucent Extensions (DIME) Alcatel-Lucent
Internet-Draft P. McCann Internet-Draft P. McCann
Intended status: Standards Track Motorola Labs Intended status: Standards Track Motorola Labs
Expires: January 14, 2009 H. Tschofenig Expires: June 21, 2009 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
T. Tsou T. Tsou
Huawei Huawei
A. Doria A. Doria
Lulea University of Technology Lulea University of Technology
G. Zorn, Ed. G. Zorn, Ed.
Aruba Networks Aruba Networks
July 13, 2008 December 18, 2008
Diameter Quality of Service Application Diameter Quality of Service Application
draft-ietf-dime-diameter-qos-06.txt draft-ietf-dime-diameter-qos-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2009. This Internet-Draft will expire on June 21, 2009.
Copyright Notice
Copyright (c) 2008 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.
Abstract Abstract
This document describes the framework, messages and procedures for This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) application. The Diameter QoS the Diameter Quality of Service (QoS) application. The Diameter QoS
application allows network elements to interact with Diameter servers application allows network elements to interact with Diameter servers
when allocating QoS resources in the network. In particular, two when allocating QoS resources in the network. In particular, two
modes of operation -- Pull and Push -- are defined. modes of operation -- Pull and Push -- are defined.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Network Element Functional Model . . . . . . . . . . . . . 8 3.1. Network Element Functional Model . . . . . . . . . . . . . 9
3.2. Implications of Endpoint QoS Capabilities . . . . . . . . 10 3.2. Implications of Endpoint QoS Capabilities . . . . . . . . 11
3.2.1. Endpoint Categories . . . . . . . . . . . . . . . . . 10 3.2.1. Endpoint Categories . . . . . . . . . . . . . . . . . 11
3.2.2. Interaction Modes Between the Authorizing Entity 3.2.2. Interaction Modes Between the Authorizing Entity
and Network Element . . . . . . . . . . . . . . . . . 10 and Network Element . . . . . . . . . . . . . . . . . 11
3.3. Authorization Schemes . . . . . . . . . . . . . . . . . . 12 3.3. Authorization Schemes . . . . . . . . . . . . . . . . . . 13
3.3.1. Pull Mode Schemes . . . . . . . . . . . . . . . . . . 12 3.3.1. Pull Mode Schemes . . . . . . . . . . . . . . . . . . 13
3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 15 3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 16
3.4. QoS Application Requirements . . . . . . . . . . . . . . . 16 3.4. QoS Application Requirements . . . . . . . . . . . . . . . 17
4. QoS Application Session Establishment and Management . . . . . 20 4. QoS Application Session Establishment and Management . . . . . 21
4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 20 4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 21
4.2. Session Establishment . . . . . . . . . . . . . . . . . . 20 4.2. Session Establishment . . . . . . . . . . . . . . . . . . 21
4.2.1. Session Establishment for Pull Mode . . . . . . . . . 20 4.2.1. Session Establishment for Pull Mode . . . . . . . . . 21
4.2.2. Session Establishment for Push Mode . . . . . . . . . 23 4.2.2. Session Establishment for Push Mode . . . . . . . . . 24
4.2.3. Discovery and Selection of Peer Diameter QoS 4.2.3. Discovery and Selection of Peer Diameter QoS
Application Node . . . . . . . . . . . . . . . . . . . 26 Application Node . . . . . . . . . . . . . . . . . . . 27
4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 27 4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 28
4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 27 4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 28
4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 28 4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 29
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 30 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 31
4.4.1. Client-Side Initiated Session Termination . . . . . . 30 4.4.1. Client-Side Initiated Session Termination . . . . . . 31
4.4.2. Server-Side Initiated Session Termination . . . . . . 30 4.4.2. Server-Side Initiated Session Termination . . . . . . 31
5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 32 5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 33
5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 33 5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 34
5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 33 5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 34
5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 34 5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 35
5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 35 5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 36
5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 35 5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 36
5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 36 5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 37
6. QoS Application State Machine . . . . . . . . . . . . . . . . 37 6. QoS Application State Machine . . . . . . . . . . . . . . . . 38
6.1. Supplemented States for Push Mode . . . . . . . . . . . . 37 6.1. Supplemented States for Push Mode . . . . . . . . . . . . 38
7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 39 7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 40
7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 39 7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 40
7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 39 7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 40
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 42 9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 43
9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 44 9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 47 10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 48
10.2. AVP Specific Values . . . . . . . . . . . . . . . . . . . 47 10.2. AVP Specific Values . . . . . . . . . . . . . . . . . . . 48
10.3. AVP Flags . . . . . . . . . . . . . . . . . . . . . . . . 47 10.3. AVP Flags . . . . . . . . . . . . . . . . . . . . . . . . 48
10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 47 10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 48
10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 48 10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 49
11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . . 52 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 56
1. Introduction 1. Introduction
This document describes the framework, messages and procedures for This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) Application. The Diameter QoS the Diameter Quality of Service (QoS) Application. The Diameter QoS
Application allows Network Elements (NEs) to interact with Diameter Application allows Network Elements (NEs) to interact with Diameter
servers when allocating QoS resources in the network. servers when allocating QoS resources in the network.
Two modes of operation are defined. In the first, called "Pull" Two modes of operation are defined. In the first, called "Pull"
mode, the network element requests QoS authorization from the mode, the network element requests QoS authorization from the
skipping to change at page 49, line 8 skipping to change at page 50, line 8
Code Value Name Reference Code Value Name Reference
----------------------------------------------------------- -----------------------------------------------------------
to be assigned QoS-Authz-Request (QAR) Section 5.1 to be assigned QoS-Authz-Request (QAR) Section 5.1
to be assigned QoS-Authz-Answer (QAA) Section 5.2 to be assigned QoS-Authz-Answer (QAA) Section 5.2
to be assigned QoS-Install-Request (QIR) Section 5.3 to be assigned QoS-Install-Request (QIR) Section 5.3
to be assigned QoS-Install-Answer (QIA) Section 5.4 to be assigned QoS-Install-Answer (QIA) Section 5.4
11. Security Considerations 11. Security Considerations
This document describes a mechanism for performing authorization of a This document describes a mechanism for performing authorization of a
QoS reservation at a third party entity. Therefore, the QoS QoS reservation at a third party entity. Therefore, sufficient
signaling application carry sufficient information that the backend information needs to be made available to the Authorizing Entity to
AAA server can make a authorization decision. This functionality is can make such an authorization decision. Information may come from
particularly useful in roaming environments where the authorization various sources, including the application layer signaling, the
decision is most likely provided at an entity where the user can be Diameter protocol (with its security mechanisms), from policy
authenticated, such as in the home realm. information stored available with a AAA server and from a QoS
signaling protocol.
QoS signaling application MAY re-use the authenticated identities Below there is a discussion about considerations for the Diameter QoS
used for the establishment of the secured transport channel for the interaction between an Authorizing Entity and a Network Element.
signaling messages, e.g., TLS or IPsec between the end host and the Security between the Authorizing Entity and the Network Element has a
policy aware QoS NE. In addition, a collocation of the QoS NE with, number of components: authentication, authorization, integrity and
for example, the Diameter NASREQ application (see [RFC4005]) may confidentiality.
allow the QoS authorization to be based on the authenticated identity
used during the network access authentication protocol run. If a co-
located deployment is not desired then special security protection is
required to ensure that arbitrary nodes cannot reuse a previous
authentication exchange to perform an authorization decision.
Additionally, QoS authorization might be based on the usage of Authentication refers to confirming the identity of an originator for
authorization tokens that are generated by the AE and provided to the all datagrams received from the originator. Lack of authentication
end host via application layer signaling. 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.
The impact of the existence of different authorization models is A consequence of not authenticating the Network Element to an
(with respect to this Diameter QoS application) the ability to carry Authorizing Entity is that an attacker could impact the policy based
different authentication and authorization information. admission control procedure run by the Authorizing Entity to provide
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, Diamater QoS messages may carry authorization tokens
that require confidentiality protection.
Lastly, there can be security vulnerability to the applications
traversing a Network Element when a resource on a Network Element is
controlled by multiple Authorizing Entities. The operation of a
Network Element may be disrupted due to conflicting directives from
multiple Authorizing Entities. Care must be taken in deployment to
ensure that Network Elements are impacted by misconfiguration.
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 overal implementation.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank John Loughney and Allison Mankin for The authors would like to thank John Loughney and Allison Mankin for
their input to this document. In September 2005 Robert Hancock, their input to this document. In September 2005 Robert Hancock,
Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and
Elwyn Davies provided a detailed review. Robert also provided us Elwyn Davies provided a detailed review. Robert also provided us
with good feedback earlier in 2005. Jerry Ash provided us review with good feedback earlier in 2005. Jerry Ash provided us review
comments late 2005/early 2006. Rajith R provided some inputs to the comments late 2005/early 2006. Rajith R provided some inputs to the
document early 2007 document early 2007
skipping to change at page 52, line 12 skipping to change at page 54, line 12
your significant draft contributions and for being the driving force your significant draft contributions and for being the driving force
for the first few draft versions. for the first few draft versions.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-dime-qos-attributes] [I-D.ietf-dime-qos-attributes]
Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
and A. Lior, "Quality of Service Attributes for Diameter", and A. Lior, "Quality of Service Attributes for Diameter",
draft-ietf-dime-qos-attributes-07 (work in progress), draft-ietf-dime-qos-attributes-08 (work in progress),
June 2008. October 2008.
[I-D.ietf-dime-qos-parameters] [I-D.ietf-dime-qos-parameters]
Korhonen, J. and H. Tschofenig, "Quality of Service Korhonen, J. and H. Tschofenig, "Quality of Service
Parameters for Usage with the AAA Framework", Parameters for Usage with the AAA Framework",
draft-ietf-dime-qos-parameters-06 (work in progress), draft-ietf-dime-qos-parameters-07 (work in progress),
May 2008. November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
14.2. Informative References 14.2. Informative References
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-15 (work in Signalling Transport", draft-ietf-nsis-ntlp-17 (work in
progress), February 2008. progress), October 2008.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
(work in progress), February 2008. (work in progress), February 2008.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 56, line 4 skipping to change at line 2184
Email: avri@ltu.se Email: avri@ltu.se
Glen Zorn (editor) Glen Zorn (editor)
Aruba Networks Aruba Networks
1322 Crossman Avenue 1322 Crossman Avenue
Sunnyvale, CA 94089-1113 Sunnyvale, CA 94089-1113
USA USA
Email: gwz@arubanetworks.com Email: gwz@arubanetworks.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 16 change blocks. 
89 lines changed or deleted 140 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/