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

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