Last Call Review of draft-ietf-dime-diameter-qos-

Request Review of draft-ietf-dime-diameter-qos
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-08-11
Requested 2009-07-25
Authors Tina Tsou, Avri Doria, Hannes Tschofenig, Dong Sun, Pete McCann, Glen Zorn
Draft last updated 2009-08-18
Completed reviews Secdir Last Call review of -?? by Brian Weis
Assignment Reviewer Brian Weis 
State Completed
Review review-ietf-dime-diameter-qos-secdir-lc-weis-2009-08-18
Review completed: 2009-08-18


I have reviewed this document as part of the security directorate's  

ongoing effort to review all IETF documents being processed by the  

IESG. These comments were written primarily for the benefit of the  

security area directors. Document editors and WG chairs should treat  

these comments just like any other last call comments.

This document describes a Diameter Quality of Service (QoS)  

application, which allows network elements to interact with Diameter  

servers when allocating QoS resources in the network. It re-uses the  

Diameter Base Protocol (RFC 3588) packet formats for this new  

application. New message flows between Network Elements (acting as  

Diameter Clients) and Authorizing Entities (acting as Diameter  

Servers) are defined. Examples are given as to how the new flows fit  

into various QoS methods.

This document seems to be mature. I have some detailed comments/ 

questions, but they are primarily suggesting additional topics for the  

Security Considerations section and a suggestion to better clarify how  

"identities" are used.

The Security Considerations section of this document describes various  

threats to Diameter messaging, which are accurate, but more precisely  

apply to the Base Protocol rather than the use case presented in this  

I-D. That is, the need for authentication, authorization, integrity  

and confidentiality is no different for this I-D than for RFC 3588. I  

see no problem with the existing text, but a statement that the  

Security Considerations in RFC 3588 also apply would also be  

appropriate (especially as that document discusses mitigations to the  

threats described here).

I don't believe there is a sufficient discussion in the Security  

Considerations regarding the threats to the QoS application itself.  

Let me try to explain. If I'm not mistaken, the traditional Diameter  

Base Protocol use case consists of a login service on an access port  

and a Diameter Client that provide no access to the user until the  

Diameter Server returns positive results. As such, mitigating threats  

to the messages (using some form of transport security) is the primary  

consideration to the Base Protocol -- it is understood that the actual  

device trying to access the network is being denied access by the  

login service until the Diameter exchange finishes. However, the QoS  

application brings two new dynamic actors into the solution: the  

Resource Requesting Entity (RRE) (using unspecified and possibly  

unsecured QoS request protocols), and a potential man-in-the-middle  

actor between the RRE and the Network Element. I understand that how  

those messages are protected between an RRE and a Network Element is  

outside the scope of this document, but because the Network Element/ 

Diameter Client acts on those messages there are additional threats to  

the QoS application that should be described. Here are some threats  

that occur to me:

1. In some (if not all) cases, the the Diameter Client translates  

information provided by the RRE (as shown in Figure 3), and includes  

it in a QoS-Request (described in Section 5.1) sent to the Diameter  

Server. In particular, the the QoS-Request may include a number of  

identification fields that, if blindly accepted from an RRE QoS  

Request message, could be cause the Diameter QoS service to allow  

authorizations that it should not (or conversely, deny authorizations  

unnecessarily). Of course, the same is true for the QoS parameters. I  

would expect the security consideration section to discuss the risks  

of the Network Element acting on these fields. For example,  

recommending that adequate transport security be used between the RRE  

and the Network Element to mitigate the man-in-the-middle threat.

2. A Token-based Three Party Scheme (Figure 4) may mitigate the threat  

of an RRE lying about its own identity. However, I see no means  

described by which the Diameter Client can have assurance that the RRE  

presenting the token was actually the RRE given that particular  

token.  Perhaps there is an assumption that the Network Client will  

have previously authenticated the RRE and can verify the Username in a  

token to a Username associated with an access port. A discussion of  

how the Network Element maps the token to an identity would be useful.

Here are a few comments on the rest of the document:

3. Figures 3, 4, and 5 show a "financial settlement" line between an  

an "Entity authorizing resource request" and a Network Element. It is  

odd to think of a Network Element (e.g., router) participating in a  

financial transaction. Wouldn't it be more likely that the "Entity  

authorizing resource request" would be a proxy device in the home  

network that speaks back-end protocols for both authorization and  

financial settlement to a visited network device?

4. Section 3.4 includes requirements titled "Identity-based Routing"  

and "Associating QoS Reservations and Application State", which  

essential require that the Diameter Server must be given identities  

that it trusts. Comments 1 and 2 above really are questioning how this  

requirement is actually met. Since this is a critical point, it would  

be worth adding some discussion in the text regarding how accurate   

identities can be obtained by the Diameter Client. By the way, what  

identity types does the Diameter QoS application expect to use?  

Username, IP address, and/or Hostname? Is mapping an IP address to a  

Username important? This might be valuable discussion to add.

5. Section 4.2.3. The term "Diameter QoS application node" is used  

exclusively in this section. Does it refer to a Diameter QoS client,  

server, or both? Clarifying this would be good.


Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew at