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

[Sean Turner <[e-mail]>]

I will clear my DISCUSS.

spt

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