Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19

Hannes Tschofenig <> Sat, 01 May 2010 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A1F73A67AC for <>; Sat, 1 May 2010 04:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EiOSaVpAPGaJ for <>; Sat, 1 May 2010 04:02:38 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 7425E3A6834 for <>; Sat, 1 May 2010 04:02:37 -0700 (PDT)
Received: (qmail invoked by alias); 01 May 2010 11:02:21 -0000
Received: from (EHLO []) [] by (mp063) with SMTP; 01 May 2010 13:02:21 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/leN9/ADHlYKdJlcUZ/eSVaf296qDK/kw6q1i94x ZMSH3ERiWtS2b5
Message-ID: <>
Date: Sat, 01 May 2010 14:02:16 +0300
From: Hannes Tschofenig <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: Brian Weis <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.62
Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 May 2010 11:02:40 -0000

Hey Brian,

thanks for your detailed review.

I have updated the security consideration section based on your 
comments. I have added text to describe security threats in more detail, 
discuss what the assumptions are (trust model), provide security 
requirements, and updated the part that talks about the specific 
solution mechanisms.

I also added a sentence about the authorization aspect you mentioned. 
There is nothing special about RMD that would require additional 
description beyond what is covered in the QoS NSLP and the solutions we 
had worked on in the context of the Diameter QoS application. The 
authorizatoin aspect largely happens before RMD signaling is actually 

My proposed text can be found below (before Georgios adds it to the 
draft itself).



5. Security Considerations


A design goal of the RMD-QOSM protocol is to be "lightweight" in terms
of the number of exchanged signaling message and the amount of state
established at involved signaling nodes (with and without reduced
state operation). A side-effect of this design decision is to introduce
second-class signaling nodes, namely QNE Interior nodes, that are restricted
in their ability to perform QoS signaling actions. Only the QNE Ingress and
the QNE Egress nodes are allowed to initiate certain signaling messages.
Moreover, RMD focuses on an intra-domain deployment only.

The above description has the following implications for security:

1) QNE Ingress and QNE Egress nodes require more security and fault 
than QNE Interior nodes because their uncontrolled behavior has larger
implications for the overall stability of the network.

2) The focus on intra-domain QoS signaling simplifies trust management and
reduces overall complexity. See Section 2 of RFC 4081 for a more detailed
discussion about the complete set of communication models available for
end-to-end QoS signaling protocols.

It is important to highlight that RMD always uses the message exchange
shown in Figure 24
even if there is no end-to-end signaling session. If the RMD-QOSM is
triggered based on an E2E signaling exchange then the RESERVE message
is created by a node outside the RMD domain and will subsequently
travel further on (e.g., to the data receiver). Such an exchange is
shown in Figure 3. As such, an evaluation of RMD's security
always has to be seen as a combination of the two signaling sessions, (1)
and (2) of Figure 24.

Ingress Interior Interior Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| RESERVE (1) | | |
| RESERVE` (2) | | |
+-------------->| | |
| | RESERVE` | |
| +-------------->| |
| | | RESERVE` |
| | +------------->|
| | | RESPONSE` (2)|
| | | RESPONSE (1) |

Figure 24: RMD Message Exchange.

Authorizing quality of service reservations is accomplished
using the AAA framework and the functionality is inherited from
the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp],
and not described again in this document. As a technical
solution mechanism Diameter QoS application
[I-D.ietf-dime-diameter-qos] may be used.


In the RMD-QOSM, the ingress node constructs both end-to-
end and intra-domain signaling messages based on the
end-to-end message initiated by the sender end node. The
Interior nodes within the RMD network ignore the end-to-end
signaling message, but process, modify, and forward the intra-domain
signaling messages towards the egress node. In the
meantime, resource reservation states are installed, modified
or deleted at each interior node along the data path according
to the content of each intra-domain signaling message. The
edge nodes of an RMD network are critical components
that require strong security protection. Therefore, they act
as security gateways for incoming and outgoing signaling
messages. Moreover, a certain degree of trust has to be placed
into Interior nodes within the RMD-QOSM network, such that
these nodes can perform signaling message processing and
take the necessary actions.

With the RMD-QOSM we assume that the
ingress and the egress nodes are not controlled by an adversary
and the communication between the ingress and the egress
nodes is secured using standard GIST security mechanisms
and experiences integrity, replay and confidentiality protection.
Note that this only affects messages directly addressed by
these two nodes and not any other message that needs to
be processed by intermediaries. The SESSION ID object
of the end-to-end communication is visible, via GIST, to the
Interior nodes.
In order to define the security threats that are associated
with the RMD-QOSM we consider that an adversary that may be located
inside the RMD domain and could
drop, delay, duplicate, inject, or modify signaling packets.
Depending on location of adversary, we speak about an on-path
adversary or an off-path adversary, see also RFC 4081 [RFC4081].

II-A. On-path Adversary

The on-path adversary is a node, which supports RMD-QOSM
and is able to observe RMD-QOSM signaling message

1) Dropping signaling messages

An adversary could drop any signaling messages after
receiving them. This will cause a failure of reservation
request for new sessions or deletion of resource units
(bandwidth) for on-going sessions due to states timeout.
It may trigger the ingress node to retransmit the
lost signaling messages. In this scenario the adversary
drops selected signaling messages, for example intra-domain reserve
messages. In the RMD-QOSM, the retransmission
mechanism can be provided at the ingress node
to make sure that signaling messages can reach the
egress node. However, the retransmissions triggered by
the adversary dropping messages may cause certain
problems. Therefore, it is recommended to disable the use
of retransmissions in the RMD-QOSM aware network.

2) Delaying Signaling Messages

Any signaling message could be delayed by an adversary.
For example, if RESERVE` messages
are delayed over the duration of the refresh period then the resource units
(bandwidth) reserved along the nodes for corresponding
sessions will be removed. In this situation, the ingress
node does not receive the RESPONSE within a certain
period, and considers that the signaling message is
failed, which may cause a retransmission of the ’failed’
message. The egress node may distinguish between the
two messages, i.e., the delayed message and the retransmitted
message, and it could take a proper response.
However, interior nodes suffer from this retransmission
and they may reserve twice the resource units (bandwidth)
requested by the ingress node.

3) Replaying Signaling Messages

An adversary may want to replay signaling messages.
It first stores the
received messages and decides when to replay these
message and at what rate (packets/per seconds).
When the RESERVE` message
carried a RII object, the egress will reply with a
RESPONSE` message towards the ingress node. The ingress
node can then detect replays by comparing the value of
RII in the RESPONSE` messages with the stored value.

4) Injecting Signaling Messages

Similar to the replay-attack scenario, the adversary may
store a part of the information carried by signaling
messages, for example, the RSN object. When the
adversary injects signaling messages, it puts the stored
information together with its own generated parameters
(Bandwidth, RII, etc.) into the injected messages and
then sends them out. Interior nodes will process these
messages by default, reserve the requested resource units
(bandwidth) and pass them to downstream nodes. It
may happen that the resource units (bandwidth) on the
Interior nodes are exhausted if these injected messages
consume much bandwidth.

5) Modifying Signaling Messages

On-path adversaries are capable of modifying any part
of the signaling message. For example, the adversary
can modify the <M>, <S> and <Overload %> parameters
of the RMD-QSPEC messages. The egress node
will then use the SESSION ID and subsequently the
BOUND SESSION ID objects to refer to that flow
to be terminated or set to lower priority. It is also
possible for the adversary to modify the <Bandwidth>
and/or <PHB Class> parameter, which could cause
a modification of an amount of the requested resource
units (bandwidth) changes.

II-B. Off-path Adversary

In this case the adversary is not located on-path and it
does not participate in the exchange of RMD-QOSM signaling
messages, and therefore is unable to eavesdrop signaling
messages. Hence, the adversary does not know valid RIIs,
RSNs, SESSION IDs. Hence, the adversary has to generate
new parameters and constructs new signaling messages. Since
Interior nodes operate in reduced state mode,
injected signaling messages are treated as new once, which
causes Interior nodes to allocate additional reservation state.


The following security requirements are set as goals for the
intra-domain communication, namely:

* Nodes, which are never supposed to participate in the NSIS signaling
exchange, must not interfere with QNE Interior nodes. Off-path
nodes (off-path with regard to the path taken by a particular
signaling message exchange) must not be able to interfere with
other on-path signaling nodes.

* The actions allowed by a QNE Interior node should be minimal (i.e.,
only those specified by the RMD-QOSM). For example, only the QNE
Ingress and the QNE Egress nodes are allowed to initiate certain
signaling messages. QNE Interior nodes are, for example, allowed to
modify certain signaling message payloads.

Note that the term `interfere` refers to all sorts of security
threats, such as denial of service, spoofing, replay, signaling
message injection, etc.


An important security mechanism that was
built into RMD-QOSM was the ability to tie the end-to-end
RESERVE and the RESERVE` messages
together using the BOUND SESSION ID and to allow the
ingress node to match the RESERVE`
with the RESPONSE` by using the
RII. These mechanisms enable the edge nodes to detect unexpected
signaling messages.

We assume that the RESERVE/RESPONSE is sent with hop-by-hop
channel security provided by GIST and protected between the QNE
Ingress and the QNE Egress. GIST security mechanisms MUST be used
to offer authentication,
integrity, and replay protection. Furthermore, encryption MUST be used
prevent an adversary located along the path of the RESERVE
message to learn information about the session that can later be used
to inject a RESERVE` message.

The following messages need to be mapped to
each other to make sure that the occurrence of one message is not
without the other one:

a) the RESERVE and the RESERVE` relate to each other at the QNE
Egress and

b) the RESPONSE and the RESERVE relate to each other at the QNE
Ingress and

c) the RESERVE` and the RESPONSE` relate to each other. The RII is
carried in the RESERVE` message and the RESPONSE` message that is
generated by the QNE Egress node contains the same RII as the
RESERVE`. The RII can be used by the QNE Ingress to match the
RESERVE` with the RESPONSE`. The QNE Egress is able to determine
whether the RESERVE` was created by the QNE Ingress node since the
intra-domain session, which sent the RESERVE`, is bound to an end-to-
end session via the BOUND_SESSION_ID value included in the intra-
domain QoS-NSLP operational state maintained at the QNE Egress.

The RESERVE and the RESERVE` message are tied together using the
BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end
QoS-NSLP operational states maintained at the QNE edges, see Section
4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a
corresponding RESERVE. The SESSION_ID can fulfill this purpose quite
well if the aim is to provide protection against off-path adversaries
that do not see the SESSION_ID carried in the RESERVE and the
RESERVE` messages.

If, however, the path changes (due to re-routing or due to mobility)
then an adversary could inject RESERVE` messages (with a previously
seen SESSION_ID) and could potentially cause harm.

An off-path adversary can, of course, create RESERVE` messages that
cause intermediate nodes to create some state (and cause other
actions) but the message would finally hit the QNE Egress node. The
QNE Egress node would then be able to determine that there is
something going wrong and generate an error message.

The severe congestion handling can be triggered by intermediate nodes
(unlike other messages). In many cases, however, intermediate nodes
experiencing congestion use refresh messages modify the <S> and
<O> parameters of the message. These messages are still
initiated by the QNE Ingress node and carry the SESSION_ID. The QNE
Egress node will use the SESSION_ID and subsequently the
BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational
state, to refer to a flow that might be terminated. The
aspect of intermediate nodes initiating messages for severe
congestion handling is for further study.

QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
+-------------->| REFRESH RESERVE` |
| (+RII) +-------------->| REFRESH RESERVE`
| | (+RII) +------------->|
| | | (+RII) |
| | | |
| | | REFRESH |
| | | RESPONSE`|
| | | (+RII) |

Figure 25: RMD REFRESH message exchange

During the refresh procedure a RESERVE` creates a RESPONSE`, see
Figure 25. The RII is carried in the RESERVE` message and the
RESPONSE` message that is generated by the QNE Egress node contains
the same RII as the RESERVE`.

The RII can be used by the QNE Ingress to match the RESERVE` with the

A further aspect is marking of data traffic. Data packets can be
modified by an intermediary without any relationship to a signaling
session (and a SESSION_ID). The problem appears if an off-path
adversary injects spoofed data packets.

The adversary thereby needs to spoof data packets that relate to the
flow identifier of an existing end-to-end reservation that SHOULD be
terminated. Therefore the question arises how an off-path adversary
SHOULD create a data packet that matches an existing flow identifier
(if a 5-tuple is used). Hence, this might not turn out to be simple
for an adversary unless we assume the previously mentioned
mobility/re-routing case where the path through the network changes
and the set of nodes that are along a path changes over time.

Brian Weis wrote:
> 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 an NSIS QoS Model for networks that use the 
> Resource Management in Diffserv (RMD) concept. It describes RMD-QOSM, 
> which are new payloads sent using the GISP signaling mechanism, where 
> the new payloads request or reserve resources. A number of data flows 
> are discussed, depending on whether nodes within a network boundary 
> participate in the protocol or not.
> The Security Considerations section covers the following topics:
> - Byzantine adversaries (i.e., participants taken over by an 
> adversary) are a general problem, but this section intends to discuss 
> additional threats as a result of the new protocol. There is an 
> extensive discussion of on-path and off-path adversaries, which seems 
> to intend to be addressing Byzantine adversaries.
> - RMD-QOSM is claimed to be lightweight, with different routers 
> allowed certain operations dependant on the role a router plays in the 
> system. E.g., only Ingress/Egress nodes are allowed to initiate 
> certain signaling messages.
> - RMD-QOSM "relies on the security support that is provided by the 
> bounded end-to-end session, which is running between the boundaries of 
> the RMD domain", but doesn't mandate that security support.
> The existing text is helpful, but not sufficient. The following points 
> are suggestions to improve this section.
> 1. The statement at the beginning of Security Considerations discusses 
> adversaries taking over a router, but the new threats are not very 
> clear. Are the authors considering that security associations are 
> revealed, that reservation data routed to a particular router can be 
> changed or forged, or something else?
> 2. The trust model used by RMD-QOSM is hinted at in the discussion of 
> on-path and off-path adversaries, but a discussion of exactly what 
> devices are trusted and what they're trusted to do would be helpful. 
> For example, is every interior router in the network is trusted to 
> handle any particular RESERVE or RESERVE` message? If not, then how 
> are the paths setup so that only authorized routers will see a 
> particular message? On the other hand, if routing is used to route the 
> messages then it would seem that any router must be authorized to 
> handle messages happened to be routed to them -- but then it isn't 
> clear that there can be a difference between an "on-path" and 
> "off-path" adversary.
> 3. Another dimension of trust model is the fact that ingress/egress 
> routers seem to trust each other more than they trust interior nodes. 
> This seems evidenced by the fact that RESERVE messages (Figure 24) 
> don't seem to be intended to be modified by the interior routers. In 
> the case of probes, I would expect that this would be especially 
> important, but probes do not seem to be specifically discussed in this 
> section.
> 4. There don't seem to be any actual security requirements or 
> recommendations made on GIST messaging. As such, it isn't clear that 
> attackers that have not taken over a participant (i.e., a man in the 
> middle) are in any way foiled. I would expect to see more MUSTs and 
> SHOULDs in this section regarding message security. There are 
> statements in the I-D such as "In the situation a security association 
> exists" and "If we assume that the RESERVE/RESPONSE is sent with 
> hop-by-hop channel security". There should be some description of the 
> threats to the messaging by a non-participant, and stating what 
> available mechanisms MUST or SHOULD be used.
> 5. Since roles seem to be an important part of the security 
> considerations, it would be helpful to see discussion of the different 
> threats & requirements on the ingress/egress routers and the internal 
> routers in their different roles.
> 6. An important service of RMD-QOSM is admission control, but there 
> doesn't seem to be any discussion of how the ingress routers determine 
> whether or not reservation requests given to them are valid. I would 
> have thought that is of particular importance, but if it's considered 
> out of scope this section might mention that fact.

> Hope that helps,
> Brian
> _______________________________________________
> secdir mailing list