Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19
Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Tue, 04 May 2010 12:46 UTC
Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0463A6C09 for <secdir@core3.amsl.com>; Tue, 4 May 2010 05:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+-VeKtrp-bQ for <secdir@core3.amsl.com>; Tue, 4 May 2010 05:45:59 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5710628C0E9 for <secdir@ietf.org>; Tue, 4 May 2010 05:45:14 -0700 (PDT)
Received: (qmail invoked by alias); 04 May 2010 12:44:59 -0000
Received: from m500f36d0.tmodns.net (EHLO [10.223.99.52]) [208.54.15.80] by mail.gmx.net (mp018) with SMTP; 04 May 2010 14:44:59 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19QxtsVZllQfnbywWUZkgJbiefwrfgK26QaWdEWhJ 0iHeS6DuNeK02c
Message-ID: <4BE016C1.2030002@gmx.net>
Date: Tue, 04 May 2010 05:44:49 -0700
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net>
In-Reply-To: <4BDC0A38.20507@gmx.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.62
Cc: 'NSIS' <nsis@ietf.org>, secdir@ietf.org, nsis-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-nsis-rmd@tools.ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2010 12:46:01 -0000
Georgios told me that he did not see my response to your mail. Let me re-send it again. Ciao Hannes 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. > > 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 > > I. INTRODUCTION > > 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. > > QNE QNE QNE QNE > 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. > > > II. SECURITY THREATS > > 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 > 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. > > 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. > > > III. SECURITY REQUIREMENTS > > 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. > > III. SECURITY MECHANISMS > > 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 > 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` | | > +-------------->| 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 > RESPONSE`. > > 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 >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir > >
- [secdir] Secdir review of draft-ietf-nsis-rmd-19 Brian Weis
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Georgios Karagiannis
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Hannes Tschofenig
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Hannes Tschofenig
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Brian Weis
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Hannes Tschofenig
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Brian Weis
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Hannes Tschofenig
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Brian Weis
- Re: [secdir] Secdir review of draft-ietf-nsis-rmd… Sean Turner