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

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 May 2010 14:02:16 +0300

Hey Brian,

thanks for your detailed review.

I have updated the security consideration section based on your 
comments. I have added text to describe security threats in more detail, 
discuss what the assumptions are (trust model), provide security 
requirements, and updated the part that talks about the specific 
solution mechanisms.

I also added a sentence about the authorization aspect you mentioned. 
There is nothing special about RMD that would require additional 
description beyond what is covered in the QoS NSLP and the solutions we 
had worked on in the context of the Diameter QoS application. The 
authorizatoin aspect largely happens before RMD signaling is actually 
triggered.

My proposed text can be found below (before Georgios adds it to the 
draft itself).

Ciao
Hannes

---------------

5. Security Considerations

I. INTRODUCTION

A design goal of the RMD-QOSM protocol is to be "lightweight" in terms
of the number of exchanged signaling message and the amount of state
established at involved signaling nodes (with and without reduced
state operation). A side-effect of this design decision is to introduce
second-class signaling nodes, namely QNE Interior nodes, that are restricted
in their ability to perform QoS signaling actions. Only the QNE Ingress and
the QNE Egress nodes are allowed to initiate certain signaling messages.
Moreover, RMD focuses on an intra-domain deployment only.

The above description has the following implications for security:

1) QNE Ingress and QNE Egress nodes require more security and fault 
protection
than QNE Interior nodes because their uncontrolled behavior has larger
implications for the overall stability of the network.

2) The focus on intra-domain QoS signaling simplifies trust management and
reduces overall complexity. See Section 2 of RFC 4081 for a more detailed
discussion about the complete set of communication models available for
end-to-end QoS signaling protocols.

It is important to highlight that RMD always uses the message exchange
shown in Figure 24
even if there is no end-to-end signaling session. If the RMD-QOSM is
triggered based on an E2E signaling exchange then the RESERVE message
is created by a node outside the RMD domain and will subsequently
travel further on (e.g., to the data receiver). Such an exchange is
shown in Figure 3. As such, an evaluation of RMD's security
always has to be seen as a combination of the two signaling sessions, (1)
and (2) of Figure 24.

QNE QNE QNE QNE
Ingress Interior Interior Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| RESERVE (1) | | |
+--------------------------------------------->|
| RESERVE` (2) | | |
+-------------->| | |
| | RESERVE` | |
| +-------------->| |
| | | RESERVE` |
| | +------------->|
| | | RESPONSE` (2)|
|<---------------------------------------------+
| | | RESPONSE (1) |
|<---------------------------------------------+

Figure 24: RMD Message Exchange.

Authorizing quality of service reservations is accomplished
using the AAA framework and the functionality is inherited from
the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp],
and not described again in this document. As a technical
solution mechanism Diameter QoS application
[I-D.ietf-dime-diameter-qos] may be used.

II. SECURITY THREATS

In the RMD-QOSM, the ingress node constructs both end-to-
end and intra-domain signaling messages based on the
end-to-end message initiated by the sender end node. The
Interior nodes within the RMD network ignore the end-to-end
signaling message, but process, modify, and forward the intra-domain
signaling messages towards the egress node. In the
meantime, resource reservation states are installed, modified
or deleted at each interior node along the data path according
to the content of each intra-domain signaling message. The
edge nodes of an RMD network are critical components
that require strong security protection. Therefore, they act
as security gateways for incoming and outgoing signaling
messages. Moreover, a certain degree of trust has to be placed
into Interior nodes within the RMD-QOSM network, such that
these nodes can perform signaling message processing and
take the necessary actions.

With the RMD-QOSM we assume that the
ingress and the egress nodes are not controlled by an adversary
and the communication between the ingress and the egress
nodes is secured using standard GIST security mechanisms
and experiences integrity, replay and confidentiality protection.
Note that this only affects messages directly addressed by
these two nodes and not any other message that needs to
be processed by intermediaries. The SESSION ID object
of the end-to-end communication is visible, via GIST, to the
Interior nodes.
In order to define the security threats that are associated
with the RMD-QOSM we consider that an adversary that may be located
inside the RMD domain and could
drop, delay, duplicate, inject, or modify signaling packets.
Depending on location of adversary, we speak about an on-path
adversary or an off-path adversary, see also RFC 4081 [RFC4081].

II-A. On-path Adversary

The on-path adversary is a node, which supports RMD-QOSM
and is able to observe RMD-QOSM signaling message
exchanges.

1) Dropping signaling messages

An adversary could drop any signaling messages after
receiving them. This will cause a failure of reservation
request for new sessions or deletion of resource units
(bandwidth) for on-going sessions due to states timeout.
It may trigger the ingress node to retransmit the
lost signaling messages. In this scenario the adversary
drops selected signaling messages, for example intra-domain reserve
messages. In the RMD-QOSM, the retransmission
mechanism can be provided at the ingress node
to make sure that signaling messages can reach the
egress node. However, the retransmissions triggered by
the adversary dropping messages may cause certain
problems. Therefore, it is recommended to disable the use
of retransmissions in the RMD-QOSM aware network.

2) Delaying Signaling Messages

Any signaling message could be delayed by an adversary.
For example, if RESERVE` messages
are delayed over the duration of the refresh period then the resource units
(bandwidth) reserved along the nodes for corresponding
sessions will be removed. In this situation, the ingress
node does not receive the RESPONSE within a certain
period, and considers that the signaling message is
failed, which may cause a retransmission of the ’failed’
message. The egress node may distinguish between the
two messages, i.e., the delayed message and the retransmitted
message, and it could take a proper response.
However, interior nodes suffer from this retransmission
and they may reserve twice the resource units (bandwidth)
requested by the ingress node.

3) Replaying Signaling Messages

An adversary may want to replay signaling messages.
It first stores the
received messages and decides when to replay these
message and at what rate (packets/per seconds).
When the RESERVE` message
carried a RII object, the egress will reply with a
RESPONSE` message towards the ingress node. The ingress
node can then detect replays by comparing the value of
RII in the RESPONSE` messages with the stored value.

4) Injecting Signaling Messages

Similar to the replay-attack scenario, the adversary may
store a part of the information carried by signaling
messages, for example, the RSN object. When the
adversary injects signaling messages, it puts the stored
information together with its own generated parameters
(Bandwidth, RII, etc.) into the injected messages and
then sends them out. Interior nodes will process these
messages by default, reserve the requested resource units
(bandwidth) and pass them to downstream nodes. It
may happen that the resource units (bandwidth) on the
Interior nodes are exhausted if these injected messages
consume much bandwidth.

5) Modifying Signaling Messages

On-path adversaries are capable of modifying any part
of the signaling message. For example, the adversary
can modify the <M>, <S> and <Overload %> parameters
of the RMD-QSPEC messages. The egress node
will then use the SESSION ID and subsequently the
BOUND SESSION ID objects to refer to that flow
to be terminated or set to lower priority. It is also
possible for the adversary to modify the <Bandwidth>
and/or <PHB Class> parameter, which could cause
a modification of an amount of the requested resource
units (bandwidth) changes.

II-B. Off-path Adversary

In this case the adversary is not located on-path and it
does not participate in the exchange of RMD-QOSM signaling
messages, and therefore is unable to eavesdrop signaling
messages. Hence, the adversary does not know valid RIIs,
RSNs, SESSION IDs. Hence, the adversary has to generate
new parameters and constructs new signaling messages. Since
Interior nodes operate in reduced state mode,
injected signaling messages are treated as new once, which
causes Interior nodes to allocate additional reservation state.

III. SECURITY REQUIREMENTS

The following security requirements are set as goals for the
intra-domain communication, namely:

* Nodes, which are never supposed to participate in the NSIS signaling
exchange, must not interfere with QNE Interior nodes. Off-path
nodes (off-path with regard to the path taken by a particular
signaling message exchange) must not be able to interfere with
other on-path signaling nodes.

* The actions allowed by a QNE Interior node should be minimal (i.e.,
only those specified by the RMD-QOSM). For example, only the QNE
Ingress and the QNE Egress nodes are allowed to initiate certain
signaling messages. QNE Interior nodes are, for example, allowed to
modify certain signaling message payloads.

Note that the term `interfere` refers to all sorts of security
threats, such as denial of service, spoofing, replay, signaling
message injection, etc.

III. SECURITY MECHANISMS

An important security mechanism that was
built into RMD-QOSM was the ability to tie the end-to-end
RESERVE and the RESERVE` messages
together using the BOUND SESSION ID and to allow the
ingress node to match the RESERVE`
with the RESPONSE` by using the
RII. These mechanisms enable the edge nodes to detect unexpected
signaling messages.

We assume that the RESERVE/RESPONSE is sent with hop-by-hop
channel security provided by GIST and protected between the QNE
Ingress and the QNE Egress. GIST security mechanisms MUST be used
to offer authentication,
integrity, and replay protection. Furthermore, encryption MUST be used
to
prevent an adversary located along the path of the RESERVE
message to learn information about the session that can later be used
to inject a RESERVE` message.

The following messages need to be mapped to
each other to make sure that the occurrence of one message is not
without the other one:

a) the RESERVE and the RESERVE` relate to each other at the QNE
Egress and

b) the RESPONSE and the RESERVE relate to each other at the QNE
Ingress and

c) the RESERVE` and the RESPONSE` relate to each other. The RII is
carried in the RESERVE` message and the RESPONSE` message that is
generated by the QNE Egress node contains the same RII as the
RESERVE`. The RII can be used by the QNE Ingress to match the
RESERVE` with the RESPONSE`. The QNE Egress is able to determine
whether the RESERVE` was created by the QNE Ingress node since the
intra-domain session, which sent the RESERVE`, is bound to an end-to-
end session via the BOUND_SESSION_ID value included in the intra-
domain QoS-NSLP operational state maintained at the QNE Egress.

The RESERVE and the RESERVE` message are tied together using the
BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end
QoS-NSLP operational states maintained at the QNE edges, see Section
4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a
corresponding RESERVE. The SESSION_ID can fulfill this purpose quite
well if the aim is to provide protection against off-path adversaries
that do not see the SESSION_ID carried in the RESERVE and the
RESERVE` messages.

If, however, the path changes (due to re-routing or due to mobility)
then an adversary could inject RESERVE` messages (with a previously
seen SESSION_ID) and could potentially cause harm.

An off-path adversary can, of course, create RESERVE` messages that
cause intermediate nodes to create some state (and cause other
actions) but the message would finally hit the QNE Egress node. The
QNE Egress node would then be able to determine that there is
something going wrong and generate an error message.

The severe congestion handling can be triggered by intermediate nodes
(unlike other messages). In many cases, however, intermediate nodes
experiencing congestion use refresh messages modify the <S> and
<O> parameters of the message. These messages are still
initiated by the QNE Ingress node and carry the SESSION_ID. The QNE
Egress node will use the SESSION_ID and subsequently the
BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational
state, to refer to a flow that might be terminated. The
aspect of intermediate nodes initiating messages for severe
congestion handling is for further study.

QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| REFRESH RESERVE` | |
+-------------->| REFRESH RESERVE` |
| (+RII) +-------------->| REFRESH RESERVE`
| | (+RII) +------------->|
| | | (+RII) |
| | | |
| | | REFRESH |
| | | RESPONSE`|
|<---------------------------------------------+
| | | (+RII) |

Figure 25: RMD REFRESH message exchange

During the refresh procedure a RESERVE` creates a RESPONSE`, see
Figure 25. The RII is carried in the RESERVE` message and the
RESPONSE` message that is generated by the QNE Egress node contains
the same RII as the RESERVE`.

The RII can be used by the QNE Ingress to match the RESERVE` with the
RESPONSE`.

A further aspect is marking of data traffic. Data packets can be
modified by an intermediary without any relationship to a signaling
session (and a SESSION_ID). The problem appears if an off-path
adversary injects spoofed data packets.

The adversary thereby needs to spoof data packets that relate to the
flow identifier of an existing end-to-end reservation that SHOULD be
terminated. Therefore the question arises how an off-path adversary
SHOULD create a data packet that matches an existing flow identifier
(if a 5-tuple is used). Hence, this might not turn out to be simple
for an adversary unless we assume the previously mentioned
mobility/re-routing case where the path through the network changes
and the set of nodes that are along a path changes over time.

Brian Weis wrote:
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG. These comments were written primarily for the benefit of the 
> security area directors. Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
> This document describes an NSIS QoS Model for networks that use the 
> Resource Management in Diffserv (RMD) concept. It describes RMD-QOSM, 
> which are new payloads sent using the GISP signaling mechanism, where 
> the new payloads request or reserve resources. A number of data flows 
> are discussed, depending on whether nodes within a network boundary 
> participate in the protocol or not.
>
> The Security Considerations section covers the following topics:
> - Byzantine adversaries (i.e., participants taken over by an 
> adversary) are a general problem, but this section intends to discuss 
> additional threats as a result of the new protocol. There is an 
> extensive discussion of on-path and off-path adversaries, which seems 
> to intend to be addressing Byzantine adversaries.
> - RMD-QOSM is claimed to be lightweight, with different routers 
> allowed certain operations dependant on the role a router plays in the 
> system. E.g., only Ingress/Egress nodes are allowed to initiate 
> certain signaling messages.
> - RMD-QOSM "relies on the security support that is provided by the 
> bounded end-to-end session, which is running between the boundaries of 
> the RMD domain", but doesn't mandate that security support.
>
> The existing text is helpful, but not sufficient. The following points 
> are suggestions to improve this section.
>
> 1. The statement at the beginning of Security Considerations discusses 
> adversaries taking over a router, but the new threats are not very 
> clear. Are the authors considering that security associations are 
> revealed, that reservation data routed to a particular router can be 
> changed or forged, or something else?
>
> 2. The trust model used by RMD-QOSM is hinted at in the discussion of 
> on-path and off-path adversaries, but a discussion of exactly what 
> devices are trusted and what they're trusted to do would be helpful. 
> For example, is every interior router in the network is trusted to 
> handle any particular RESERVE or RESERVE` message? If not, then how 
> are the paths setup so that only authorized routers will see a 
> particular message? On the other hand, if routing is used to route the 
> messages then it would seem that any router must be authorized to 
> handle messages happened to be routed to them -- but then it isn't 
> clear that there can be a difference between an "on-path" and 
> "off-path" adversary.
>
> 3. Another dimension of trust model is the fact that ingress/egress 
> routers seem to trust each other more than they trust interior nodes. 
> This seems evidenced by the fact that RESERVE messages (Figure 24) 
> don't seem to be intended to be modified by the interior routers. In 
> the case of probes, I would expect that this would be especially 
> important, but probes do not seem to be specifically discussed in this 
> section.
>
> 4. There don't seem to be any actual security requirements or 
> recommendations made on GIST messaging. As such, it isn't clear that 
> attackers that have not taken over a participant (i.e., a man in the 
> middle) are in any way foiled. I would expect to see more MUSTs and 
> SHOULDs in this section regarding message security. There are 
> statements in the I-D such as "In the situation a security association 
> exists" and "If we assume that the RESERVE/RESPONSE is sent with 
> hop-by-hop channel security". There should be some description of the 
> threats to the messaging by a non-participant, and stating what 
> available mechanisms MUST or SHOULD be used.
>
> 5. Since roles seem to be an important part of the security 
> considerations, it would be helpful to see discussion of the different 
> threats & requirements on the ingress/egress routers and the internal 
> routers in their different roles.
>
> 6. An important service of RMD-QOSM is admission control, but there 
> doesn't seem to be any discussion of how the ingress routers determine 
> whether or not reservation requests given to them are valid. I would 
> have thought that is of particular importance, but if it's considered 
> out of scope this section might mention that fact.

>
> Hope that helps,
> Brian
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 May 2010 05:44:49 -0700

Georgios told me that he did not see my response to your mail. Let me 
re-send it again.

Ciao
Hannes

Hannes Tschofenig wrote:
> 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.
>
> 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 
>> allowed certain operations dependant on the role a router plays in 
>> the system. E.g., only Ingress/Egress nodes are allowed to initiate 
>> 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?
>>
>> 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 
>> important, but probes do not seem to be specifically discussed in 
>> this section.
>>
>> 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.
>>
>> 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.
>>
>> 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

---

From: Brian Weis <[email-masked]>
Date: Tue, 4 May 2010 20:22:08 -0700

Hi Hannes,

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

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.

> nodes is secured using standard GIST security mechanisms

Is there a reference for these security mechanisms?

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

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

> threats, such as denial of service, spoofing, replay, signaling

Nit: should be "IV."

> Ingress and the QNE Egress.

If the RESERVE/RESPONSE messages are protected hop-by-hop, why can't  
RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that only the  
ingress and egress devices are "hops" and share keys?

Thanks,
Brian

> GIST security mechanisms MUST be used
> to offer authentication,
>> security area directors. Document editors and WG chairs should  
>> treat these comments just like any other last call comments.
>>
>> 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.
>>
>> 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.
>> 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.
>>
>> 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.
>>
>> 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  
>> description of the threats to the messaging by a non-participant,  
>> and stating what available mechanisms MUST or SHOULD be used.
>>
>> 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

-- 
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 05 May 2010 11:18:32 -0700

Hi Brian,

thanks for the quick response.

> Ingress router, as opposed to each Interior node in the path. It would 

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

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

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

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

>> threats, such as denial of service, spoofing, replay, signaling
Yup.

> ingress and egress devices are "hops" and share keys?
See response above.

Ciao
Hannes

>>> Resource Management in Diffserv (RMD) concept. It describes 
>>> RMD-QOSM, which are new payloads sent using the GISP signaling 
>>> 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.
>>> 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 
>>> (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.
>>>

---

From: Brian Weis <[email-masked]>
Date: Wed, 5 May 2010 12:06:51 -0700

Hi Hannes,

The expanded authorization paragraph is very clear to me, thanks.

Regarding protection of the RESERVE` and RESPONSE` hop-by-hop security:

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

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

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.

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. You're not trusting the Interior  
nodes at all, so they themselves have no security considerations.  
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.

Thanks,
Brian

On May 5, 2010, at 11:18 AM, Hannes Tschofenig wrote:

>> Thanks! Your re-written security considerations section is very  
>> much improved. I do have a couple of comments/questions inline below.
>>
>>>
>>> My proposed text can be found below (before Georgios adds it to  
>>> the draft itself).
>>>
>>> Ciao
>>> Hannes
>>>
>>> ---------------
>>>
>>>
>>> 1) QNE Ingress and QNE Egress nodes require more security and  
>>> fault protection
>> Ingress router, as opposed to each Interior node in the path. It  
>> would be helpful to say this.
>
>> 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.
>
>
>>>
>> 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.
>
>> 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
>>
>>>> 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  
>>>> 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.
>>>>
>>>> discusses adversaries taking over a router, but the new threats  
>>>> are not very clear. Are the authors considering that security  
>>>> 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  
>>>> 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.
>>>>
>>>> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 05 May 2010 15:02:11 -0700

Hi Brian,

Brian Weis wrote:
>>> It seems like that would be a simple measure to  mitigate threats 
>>> (4) and (5).
>>>
>> that for these two messages the "hop" are ingress and egress; for the 
Yes.

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

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

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

   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

>> proposal is to let the egress detect and to alert about the potential 
>> problem.
>>
>>
>>>>
>>> It seems like that would be a simple measure to  mitigate threats 
>>> (4) and (5).
>>>
>> that for these two messages the "hop" are ingress and egress; for the 
>>>>> the system. E.g., only Ingress/Egress nodes are allowed to 
>>>>> bounded end-to-end session, which is running between the 
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> there doesn't seem to be any discussion of how the ingress routers

---

From: Brian Weis <[email-masked]>
Date: Wed, 5 May 2010 15:19:11 -0700

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:

>>>> 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.
>>
>> understand correctly, only Ingress and Egress routers share a  
>> security association for protecting RESERVE and RESPONSE messages.
> Yes.
>
>>
>>> not help since the adversary model assumes that one of the  
>>> interior nodes is acting maliciously.
>>>
>> 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.
>> 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.
>
>> - 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.
>>
>     implications for the overall stability of the network. QNE  
> Ingress and
>>>>> 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.
>>>>>
>>>> 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.
>>>
>>>> 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.
>>>
>>> not help since the adversary model assumes that one of the  
>>> interior nodes is acting maliciously.
>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>> boundaries of the RMD domain", but doesn't mandate that  
>>>>>> security support.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>

---

From: Sean Turner <[email-masked]>
Date: Wed, 05 May 2010 18:21:46 -0400

I will clear my DISCUSS.

spt

Brian Weis wrote:
>>> Interior node from on-path attackers between themselves. I assume 
>>> they may have adversaries between them.
>> 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.
>>