Last Call Review of draft-ietf-dime-diameter-qos-
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.
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew at cisco.com