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

[Brian Weis <[e-mail]>]

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


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