Last Call Review of draft-ietf-dime-diameter-qos-
review-ietf-dime-diameter-qos-secdir-lc-weis-2009-08-18-00

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

Review
review-ietf-dime-diameter-qos-secdir-lc-weis-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.




Thanks,
Brian

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