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

Hannes Tschofenig <> Wed, 05 May 2010 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8195B3A6A55 for <>; Wed, 5 May 2010 11:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.457
X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NfkmKtMMtOjs for <>; Wed, 5 May 2010 11:19:41 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 84A4528C12A for <>; Wed, 5 May 2010 11:19:10 -0700 (PDT)
Received: (qmail invoked by alias); 05 May 2010 18:18:46 -0000
Received: from (EHLO []) [] by (mp071) with SMTP; 05 May 2010 20:18:46 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18SI7BlnZwSL8zzVz3ZZL9NptktT+CDLuOkEdjoAq gUO7oRqf2M2GJr
Message-ID: <>
Date: Wed, 05 May 2010 11:18:32 -0700
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
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: Wed, 05 May 2010 18:19:45 -0000

Hi Brian,

thanks for the quick response.

Brian Weis wrote:
> Hi Hannes,
> On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote:
>> 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.
> Thanks! Your re-written security considerations section is very much 
> improved. I do have a couple of comments/questions inline below.
>> 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 
>> triggered.
>> My proposed text can be found below (before Georgios adds it to the 
>> draft itself).
>> Ciao
>> Hannes
>> ---------------
>> 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 
>> protection
>> 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.
> I assume that it is implied that this authorization is done by the 
> Ingress router, as opposed to each Interior node in the path. It would 
> be helpful to say this.

That's true. I extended the paragraph to:

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. The end-to-end
reservation request arriving at the ingress node will
trigger the authorization procedure with the backend AAA
infrastructure. The end-to-end reservation is typically
triggered by a human interaction with a software application,
such as a voice-over-IP client when making a call. When
authorization is successful then no further user initiated
QoS authorization check is expected to be performed within
the RMD domain for the intra-domain reservation.

>> 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
> Is there a reference for these security mechanisms?
I added a reference to the security consideration section of GIST 
(Section 6 of [I-D.ietf-nsis-ntlp])..

>> 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
>> exchanges.
>> 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.
> Can this threat be generalized from "twice" to "N times", if the 
> message is retransmitted N times?
> If so, it seems like a serious threat. Can the mitigation for Replayed 
> Signaling Messages (i.e., storing values) be used here. Actually, from 
> the description a retransmitted signaling message seems 
> indistinguishable from a replayed signaling message.
For interior nodes it is not possible to distinguish replays. The only 
entities that detect the replays are edge devices. So, my proposal is to 
let the egress detect and to alert about the potential problem.

>> 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.
> Don't interior nodes protect RESERVE` and RESPONSE` messages using 
> hop-by-hop security, or is that just  RESERVE and RESPONSE messages? 
> It seems like that would be a simple measure to  mitigate threats (4) 
> and (5).
RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind that 
for these two messages the "hop" are ingress and egress; for the 
interior nodes these messages cannot be modified.

Using hop-by-hop security for RESERVE` and RESPONSE` messages does not 
help since the adversary model assumes that one of the interior nodes is 
acting maliciously.

Does this make sense to you?

>> 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.
> Nit: should be "IV."

>> 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.
> If the RESERVE/RESPONSE messages are protected hop-by-hop, why can't 
> RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that only the 
> ingress and egress devices are "hops" and share keys?
See response above.


> Thanks,
> Brian
>> GIST security mechanisms MUST be used
>> to offer authentication,
>> integrity, and replay protection. Furthermore, encryption MUST be used
>> to
>> 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