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

[Brian Weis <[e-mail]>]

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.

>
>
> 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?

> 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.

>
> 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).

> 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."

>
> 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?

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secdir
>


-- 
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]