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