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

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