Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19
Brian Weis <bew@cisco.com> Wed, 05 May 2010 22:19 UTC
Return-Path: <bew@cisco.com>
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 AFEEF3A6CE6; Wed, 5 May 2010 15:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Sm-iyq96t66K; Wed, 5 May 2010 15:19:27 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7D6243A6D26; Wed, 5 May 2010 15:19:26 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALKL4UurR7Hu/2dsb2JhbACdU3GkbplggnWCHgSDPg
X-IronPort-AV: E=Sophos;i="4.52,336,1270425600"; d="scan'208";a="193113202"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 May 2010 22:19:13 +0000
Received: from dhcp-128-107-163-73.cisco.com (dhcp-128-107-163-73.cisco.com [128.107.163.73]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o45MJDei021060; Wed, 5 May 2010 22:19:13 GMT
Message-Id: <A9D92877-BDDC-4C7B-A5A2-1BC1A7E2C2C9@cisco.com>
From: Brian Weis <bew@cisco.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
In-Reply-To: <4BE1EAE3.6030304@gmx.net>
Content-Type: text/plain; charset="WINDOWS-1252"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 05 May 2010 15:19:11 -0700
References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> <C4D24A64-D9A8-433A-9F7C-E809824FB227@cisco.com> <4BE1B678.8020805@gmx.net> <BC319CB1-8B68-4D4B-BCB0-94132FF43838@cisco.com> <4BE1EAE3.6030304@gmx.net>
X-Mailer: Apple Mail (2.936)
Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org, secdir@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: Wed, 05 May 2010 22:19:31 -0000
Hi Hannes, You new wording looks good to me. I have no further comments. Thanks, Brian On May 5, 2010, at 3:02 PM, Hannes Tschofenig wrote: > Hi Brian, > > > Brian Weis wrote: >> Hi Hannes, >> >> The expanded authorization paragraph is very clear to me, thanks. >> >> Regarding protection of the RESERVE` and RESPONSE` hop-by-hop >> security: >> >>>> 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. >> >> Thanks for the clarification of what constitutes a "hop". So if I >> understand correctly, only Ingress and Egress routers share a >> security association for protecting RESERVE and RESPONSE messages. > Yes. > >> >>> 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? >> >> >> My point was that transport security of RESERVE` and RESPONSE` >> messages between Interior nodes would also be helpful to protect >> each Interior node from on-path attackers between themselves. I >> assume they may have adversaries between them. > Well. There is actually no other entity between the participating > interior nodes. In RMD all the nodes in the domain have to > participate. > >> >> But I think I understand now that the Security Considerations >> section is written assuming that only Ingress and Egress devices >> participate in any kind of security association. > > Yes. > >> You're not trusting the Interior nodes at all, so they themselves >> have no security considerations. > Normally, with a QoS signaling protocol you have to essentially > trust every node that understands the protocol. In RMD I thought > that it would be interesting to exploit the fact that you can do > better than that. > >> Could you please clarify the following points in the INTRODUCTION, >> which would make that clearer? >> - What is a "hop" with respect to security associations >> - The security of RMD-QOSM does not depend on interior nodes. (It >> does say "The focus on intra-domain QoS signaling simplifies trust >> management and reduces overall complexity." but that's doesn't >> really go far enough.) >> - Because the security of RMD-QOSM does not depend on interior >> nodes, protection of RESERVE` and RESPONSE` messages is not >> specified. >> > Sure. Makes sense. Here is my proposal: > > 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. QNE > Ingress and > QNE Egress nodes share a security association and utlize GIST > security > for protection of their signaling messages. Intra-domain signaling > messages used for RMD signaling do not use GIST security and > therefore > they do not store security associations. > > 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. The security of RMD-QOSM > does not > depend on interior nodes and hence the cryptographic protection of > intra-domain messages via GIST is not utilized. > > 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. Note that for the E2E message, such as > the RESERVE and the RESPONSE message, a single "hop" refers to > the communication between the QNE Ingress and the QNE Egress > since QNE Interior nodes do not participate in the exchange. > > Ciao > Hannes > >> Thanks, >> Brian >> >> On May 5, 2010, at 11:18 AM, Hannes Tschofenig wrote: >> >>> 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 >>>>> >>>>> 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. >>>> >>>> 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. >>> " >>> >>>> >>>>> >>>>> >>>>> 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 >>>> >>>> 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. >>>>> >>>>> >>>>> 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 >>>> >>>> Nit: should be "IV." >>> Yup. >>> >>>> >>>>> >>>>> 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. >>> >>> Ciao >>> Hannes >>> >>>> 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` | | >>>>> +-------------->| 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 >>>>> >>>> >>>> >>> >> >> > -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com
- [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