Subject: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 03 May 2016 14:31:39 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Given the two key security threats identified in Section 11 -- that
authorized nodes can issue requests with artificially high priority in
order to get better treatment, and that unauthorized intermediaries can
modify the priorities that senders set -- I don't see how it is
legitimate to claim that either 5.1 or 5.2 are appropriate use cases for
DRMP. The spec seems to assume that this mechanism will only be used in
scenarios where nodes and agents have some out-of-band trust relationship
established with each other (the shepherd write-up talks about a "trusted
environment"), but that is certainly not the case in many disaster and
emergency scenarios. If that really is a limitation on the scope of
applicability of this mechanism, that should be stated in the document,
and those use cases should either be removed or modified to explain the
limitations on their applicability.  

(2) Section 6 says:

	   "The mechanism for how the agent determines which requests are
       throttled is implementation dependent and is outside the scope of
       this document."

How is a node supposed to determine how to set its priorities if each
agent makes implementation-specific decisions about what those priorities
mean? I understood the document to be saying that Diameter applications
would have to define what he priority levels mean within their own
contexts, but then I would have expected the interpretation of priorities
amongst all nodes and agents implementing the same application to be the
same. 

(3) Section 8 says: 

	"Diameter nodes SHOULD use the PRIORITY_10 priority as this default
value."
   
If the determination of the priority schemes are all
application-specific, how is it appropriate for this spec to define what
the default priority should be for all applications? Shouldn't
applications specify their own defaults?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 11 says: "DRMP gives Diameter nodes the ability to influence
which requests are throttled during overload scenarios." But the
information is not limited to use during overload scenarios, and the spec
specifically allows its use for prioritized routing in absence of
overload. This should be stated here too.

---

From: <[email-masked]>
Date: Tue, 3 May 2016 23:42:46 +0000

Hi Alissa,

Thank you for your review.
Please find below some clarifications, waiting for authors feeback.

Regards,

Lionel

Envoyé depuis Surface

De : Alissa Cooper<mailto:[email-masked]>
Envoyé : ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>, Lionel MORAND<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, Lionel MORAND<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

[LM] I think that what is missing is that Diameter is mainly (if not only) used in mobile operator networks. The text makes reference to the RFC7683 where the overoload contgrol mechanism is introduced to solve overload situations in telco networks. This additional mechanism is seen as a complement of this overload control mechanism. Now, if it is understood that it is a mechanism defined for “trusted environment” i.e. mobile networks, the use of priority indications in emergency and disaster scenarios seems legitimate.

(2) Section 6 says:

[LM] I understand. I think that the text should say “The mechanism for how the agent determines which requests are c(candidates) to be throttled”. And, when there are requests to throttle, the priority indication is used to determine “which requests to route first, which requests to throttle and where the request is routed.  For instance, requests with higher  priority might have a lower probability of being throttled. ”.

(3) Section 8 says:

[LM] it is needed to take into account that the use of priority indication in Diameter will be optional and that legacy implementation will not include any priority indication in Diameter requests. After discussion, it was decided that requests without priority should be handled as with a priority set to 10. This makes the difference with requests with an explicit lower priorities and other with higher priorities. 10 is used as “average” priority, with the possibility of specific operator policies to use another value.

[LM] right.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 4 May 2016 07:52:55 +0100

Hi Alissa,

> On 3 May 2016, at 22:31, Alissa Cooper <[email-masked]> wrote:
> 
> (3) Section 8 says: 
> 

I think it is perfectly acceptable for this spec to recommend a default in the middle of the allowed range. I read this as a requirement on application policies. I think it would be bad if different applications pick different values as the default, as this would be confusing to implementors and deployers.

---

From: "Trottin, Jean-Jacques (Nokia - FR)" <[email-masked]>
Date: Wed, 4 May 2016 09:35:49 +0000

Hi all

I also agree with Lionels’ comments and clarifications.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 4 mai 2016 01:43
À : Alissa Cooper; [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

Hi Alissa,

Regards,

Lionel

Envoyé depuis Surface

(2) Section 6 says:

(3) Section 8 says:

[LM] right.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 May 2016 10:58:12 -0500

Responding to both Alissa's comments and Lionel's responses.

Regards,

Steve

On 5/3/16 6:42 PM, [email-masked] wrote:
> *De :* Alissa Cooper <mailto:[email-masked]>
> *Envoyé :* ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31
> *À :* [email-masked] <mailto:[email-masked]>
> *Cc :* [email-masked] 
> <mailto:[email-masked]>, Lionel MORAND 
> <mailto:[email-masked]>, [email-masked] 
> <mailto:[email-masked]>, Lionel MORAND 
> <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
>
> [LM] I think that what is missing is that Diameter is mainly (if not 
> only) used in mobile operator networks. The text makes reference to 
> the RFC7683 where the overoload contgrol mechanism is introduced to 
> solve overload situations in telco networks. This additional mechanism 
> is seen as a complement of this overload control mechanism. Now, if it 
> is understood that it is a mechanism defined for “trusted environment” 
> i.e. mobile networks, the use of priority indications in emergency and 
> disaster scenarios seems legitimate.
SRD> I would state it a little differently, but I agree that there needs 
to be some clarification here.  We intentionally did not specify how 
priorities are set in this document as those priorities need to take 
into account application specific knowledge.  This document is, instead, 
focused on how priority information is transported and used by nodes 
receiving the priority.  The thing that is missing is a statement that 
this mechanism only works when the definition of priority values is done 
in a consistent manner for all applications used by a Diameter network.  
It is my understanding that 3GPP will be defining priorities across its 
set of applications and that this will make sure that one application 
does not improperly take advantage of the mechanism at the expense of 
other applications.  I also expect that 3GPP will factor in the 5.1 and 
5.2 use cases when doing this work.

SRD> This does beg the question of whether or not we need to support 
interworking between multiple "DRMP priority schemes", where one 
Diameter network assumes priority scheme 1 and another assumes priority 
scheme 2 and the two priority schemes were defined completely 
independently.  The 3GPP priority definition would be an example of a 
priority scheme.  The mechanism, as currently defined, does not support 
this use case.

SRD> We could fix this by using a name-space concept similar to that 
used by SIP.  Or we could say that this mechanism only works in a 
trusted environment.  The working group should decide which approach to 
take.

> [LM] I understand. I think that the text should say “The mechanism for 
> how the agent determines which requests are c(candidates) to be 
> throttled”. And, when there are requests to throttle, the priority 
> indication is used to determine “which requests to route first, which 
> requests to throttle and where the request is routed.  For instance, 
> requests with higher  priority might have a lower probability of being 
> throttled. ”.
SRD> I agree with Lionel's suggestion here.
> [LM] it is needed to take into account that the use of priority 
> indication in Diameter will be optional and that legacy implementation 
> will not include any priority indication in Diameter requests. After 
> discussion, it was decided that requests without priority should be 
> handled as with a priority set to 10. This makes the difference with 
> requests with an explicit lower priorities and other with higher 
> priorities. 10 is used as “average” priority, with the possibility of 
> specific operator policies to use another value.
SRD> As stated by Alexey in a separate email, I don't see the issue with 
a default value.  Alexey and Lionel have explained why, so I won't repeat.
SRD> This is already addressed in the paragraph following the one above:

    The DRMP mechanism can also be used to influence the order in which
    Diameter messages are handled by Diameter nodes.  The above attacks
    have a potentially greater impact in this scenario as the priority
    indication impacts the handling of all requests at all times,
    independent of the overload status of Diameter nodes in the Diameter
    network.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 4 May 2016 11:18:43 -0700

Responding to Steve because there is an issue here to unpack more, and he quotes Lionel ...

> On May 4, 2016, at 8:58 AM, Steve Donovan <[email-masked]> wrote:
> 
> On 5/3/16 6:42 PM, [email-masked] <mailto:[email-masked]> wrote:
>> Hi Alissa,
>> 
>> De : Alissa Cooper <mailto:[email-masked]>
>> À : [email-masked] <mailto:[email-masked]>
>> Cc : [email-masked] <mailto:[email-masked]>, Lionel MORAND <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, Lionel MORAND <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ <https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/>
>> 
>> 
>> 
> SRD> I would state it a little differently, but I agree that there needs to be some clarification here.  We intentionally did not specify how priorities are set in this document as those priorities need to take into account application specific knowledge.  This document is, instead, focused on how priority information is transported and used by nodes receiving the priority.  The thing that is missing is a statement that this mechanism only works when the definition of priority values is done in a consistent manner for all applications used by a Diameter network.  It is my understanding that 3GPP will be defining priorities across its set of applications and that this will make sure that one application does not improperly take advantage of the mechanism at the expense of other applications.  I also expect that 3GPP will factor in the 5.1 and 5.2 use cases when doing this work.

I’m glad you pointed this out, because this is different from my understanding of how DRMP is intended to be used. And I will admit to not being super familiar with Diameter. I saw this in Section 4:

"Note: There are a number of application specific definitions
      indicating various views of application level priority for
      different requests.  Using these application specific priority
      Attribute Value Pairs (AVPs) as input to throttling and other
      Diameter routing decisions would require Diameter agents to
      understand all applications and do application specific parsing of
      all messages in order to determine the priority of individual
      messages.  This is considered an unacceptable level of complexity
      to put on elements whose primary responsibility is to route
      Diameter messages.”

I was thinking that the implication from this is that a Diameter agent would be scoped such that it would only receive requests from clients all using the same application. But you say that is not the case. If an agent is supposed to make sense of priorities received from multiple different applications, then it seems problematic for each application to independently define its own priority semantics with any expectation about what those semantics are supposed to effectuate. For example, consider if people go off and work on the EAP application and decide that they really only need two priority levels, so they decide to use 10 and 11. Then people go off and work on the SIP application and they decide they really only need two priority levels, so they decide to use 1 and 2. Should all SIP application traffic really always be prioritized over all EAP application traffic?

> 
> SRD> This does beg the question of whether or not we need to support interworking between multiple "DRMP priority schemes", where one Diameter network assumes priority scheme 1 and another assumes priority scheme 2 and the two priority schemes were defined completely independently.  The 3GPP priority definition would be an example of a priority scheme.  The mechanism, as currently defined, does not support this use case.
> 
> SRD> We could fix this by using a name-space concept similar to that used by SIP.  Or we could say that this mechanism only works in a trusted environment.  The working group should decide which approach to take.

I agree that some sort of fix is needed here. And I’m not sure that the trusted environment thing is necessarily enough, because that doesn’t give guidance to those defining priority schemes about what they need to do.

I also think this is a distinct issue from the one I raised about the use cases and inability to trust clients. Even if only a single application ever defines a priority scheme, a network where clients can’t be trusted could fall victim to an attacker who inflates the priority of his traffic to try to prevent emergency calls/first responders from getting priority treatment.

> SRD> I agree with Lionel's suggestion here.

WFM

> SRD> As stated by Alexey in a separate email, I don't see the issue with a default value.  Alexey and Lionel have explained why, so I won't repeat.

This ties into my interpretation described above, where I thought agents would be handling requests specific to one application. I see the value of this if they are handling requests from multiple applications.

>    independent of the overload status of Diameter nodes in the Diameter

Actually that is a bunch of paragraphs further down, in 11.1. I was commenting on just the first sentence of 11. I know the reader can keep reading and get to the part you quote, but I think it’s important not to gloss over the other uses of this in the intro to 11 either.

Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 May 2016 19:53:20 +0100

Hiya,

Please do continue the discussion all, but just on one aspect of
this...

On 04/05/16 19:18, Alissa Cooper wrote:
> Even if only a single application ever defines a priority scheme, a 
> network where clients can’t be trusted could fall victim to an 
> attacker who inflates the priority of his traffic to try to prevent 
> emergency calls/first responders from getting priority treatment.

My understanding of Diameter deployments is that they are pretty
much all done so that any node can play all sorts of games and
there are no protocol mechanisms other than hop-by-hop TLS or IPsec
to control that. I'm not even sure how much those are deployed, even
in cases where cryptographic keys are passed in Diameter messages.
(And that's when the base protocol spec says you MUST use TLS in
such cases. [1])

So DRMP and DOIC are by far not the most attractive target here.
The DIME WG are attempting to address that via [2] but I'm not
sure if we ought be hugely hopeful of that being implemented
or deployed either.

It might help if someone more familiar with deployments can
correct or confirm the above.

That doesn't affect the issue of potentially un-coordinated uses
of different priorities across multiple Diameter applications,
which seems like it is worth saying more about, but I'd have to
say that uses of DRMP as an attack vector aren't that compelling
from what I know, and the WG are attempting to at least document
mechanisms that would provide relevant protocol countermeasures
for the base protocol.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc6733#section-13.3
[2] https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 May 2016 13:57:44 -0500

On 5/4/16 1:18 PM, Alissa Cooper wrote:
>> On May 4, 2016, at 8:58 AM, Steve Donovan <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> On 5/3/16 6:42 PM,[email-masked]:
>>> Hi Alissa,
>>>
>>> <mailto:[email-masked]>,Lionel MORAND 
>>> <mailto:[email-masked]>,[email-masked] 
>>> <mailto:[email-masked]>,Lionel MORAND 
>>> <mailto:[email-masked]>,[email-masked] <mailto:[email-masked]>
>>>
>>> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
>>> solve overload situations in telco networks. This additional 
>>> mechanism is seen as a complement of this overload control 
>>> mechanism. Now, if it is understood that it is a mechanism defined 
>>> for “trusted environment” i.e. mobile networks, the use of priority 
>>> indications in emergency and disaster scenarios seems legitimate.
>> SRD> I would state it a little differently, but I agree that there 
>> needs to be some clarification here.  We intentionally did not 
>> specify how priorities are set in this document as those priorities 
>> need to take into account application specific knowledge. This 
>> document is, instead, focused on how priority information is 
>> transported and used by nodes receiving the priority.  The thing that 
>> is missing is a statement that this mechanism only works when the 
>> definition of priority values is done in a consistent manner for all 
>> applications used by a Diameter network.  It is my understanding that 
>> 3GPP will be defining priorities across its set of applications and 
>> that this will make sure that one application does not improperly 
>> take advantage of the mechanism at the expense of other 
>> applications.  I also expect that 3GPP will factor in the 5.1 and 5.2 
>> use cases when doing this work.
>
> I’m glad you pointed this out, because this is different from my 
> understanding of how DRMP is intended to be used. And I will admit to 
> not being super familiar with Diameter. I saw this in Section 4:
>
> I was thinking that the implication from this is that a Diameter agent 
> would be scoped such that it would only receive requests from clients 
> all using the same application. But you say that is not the case. If 
> an agent is supposed to make sense of priorities received from 
> multiple different applications, then it seems problematic for each 
> application to independently define its own priority semantics with 
> any expectation about what those semantics are supposed to effectuate. 
> For example, consider if people go off and work on the EAP application 
> and decide that they really only need two priority levels, so they 
> decide to use 10 and 11. Then people go off and work on the SIP 
> application and they decide they really only need two priority levels, 
> so they decide to use 1 and 2. Should all SIP application traffic 
> really always be prioritized over all EAP application traffic?
SRD> This is why I talked about a "priority scheme" and applications 
defining priorities in a consistent fashion.
>> Diameter network assumes priority scheme 1 and another assumes 
>> priority scheme 2 and the two priority schemes were defined 
>> completely independently.  The 3GPP priority definition would be an 
>> example of a priority scheme.  The mechanism, as currently defined, 
>> does not support this use case.
>>
>> trusted environment.  The working group should decide which approach 
>> to take.
>
> I agree that some sort of fix is needed here. And I’m not sure that 
> the trusted environment thing is necessarily enough, because that 
> doesn’t give guidance to those defining priority schemes about what 
> they need to do.
SRD> Agreed, its not enough to be a trusted environment.  There needs to 
be coordinated priority definition across all of the applications used 
in the environment.
>
> I also think this is a distinct issue from the one I raised about the 
> use cases and inability to trust clients. Even if only a single 
> application ever defines a priority scheme, a network where clients 
> can’t be trusted could fall victim to an attacker who inflates the 
> priority of his traffic to try to prevent emergency calls/first 
> responders from getting priority treatment.
SRD> This is where the trusted environment comes in.  It's not an issue 
if all nodes are trusted.

SRD> We also need to factor in what it would take to starve the well 
behaving clients.  DRMP priority can be used to influence which messages 
are routed first or which messages are throttled first.  A misbehaving 
Diameter client would need to send enough messages to consume somewhere 
approaching 100% of the capacity of an agent to fully starve well 
behaving nodes.  This, to a large degree, boils down to a classical DOS 
attack.  DRMP maybe makes it a more effective DOS attack, but normal 
strategies for handling DOS attacks would be effective in dealing with a 
DRMP flavored DOS attack.
>>> [LM] I understand. I think that the text should say “The mechanism 
>>> for how the agent determines which requests are c(candidates) to be 
>>> indication is used to determine “which requests to route first, 
>>> which requests to throttle and where the request is routed.  For 
>>> instance, requests with higher priority might have a lower 
>>> probability of being throttled. ”.
>>> indication in Diameter will be optional and that 
>>> legacy implementation will not include any priority indication in 
>>> Diameter requests. After discussion, it was decided that requests 
>>> without priority should be handled as with a priority set to 10. 
>>> This makes the difference with requests with an explicit lower 
>>> priorities and other with higher priorities. 10 is used as “average” 
>>> priority, with the possibility of specific operator policies to use 
>>> another value.
>> SRD> As stated by Alexey in a separate email, I don't see the issue 
>> with a default value.  Alexey and Lionel have explained why, so I 
>> won't repeat.
>
> This ties into my interpretation described above, where I thought 
> agents would be handling requests specific to one application. I see 
> the value of this if they are handling requests from multiple 
> applications.
>
>
>>>
> Actually that is a bunch of paragraphs further down, in 11.1. I was 
> commenting on just the first sentence of 11. I know the reader can 
> keep reading and get to the part you quote, but I think it’s important 
> not to gloss over the other uses of this in the intro to 11 either.
SRD> I see it now.  I have no objection to adding appropriate text to 
that paragraph.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 4 May 2016 21:31:29 -0700

> On May 4, 2016, at 11:53 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

But my point was specifically about how the motivation for DRMP is tied to the first responder and emergency use cases. When a capability is defined specifically for those uses, people (or, say, regulators) tend to expect it to work. So if there is a class of cases where it won’t work at all — even if the net effect is just that requests get treated on a best efforts basis the same as they do today, not that some requests get starved — it’s worth being very explicit about that. I’m sure there are other attacks that could target these uses in the absence of DRMP, but that isn’t a reason to gloss over the DRMP-specific issue in this spec.

Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 May 2016 09:00:29 +0100

On 05/05/16 05:31, Alissa Cooper wrote:
>>> Even if only a single application ever defines a priority scheme,
>>> a network where clients can’t be trusted could fall victim to an
>>>  attacker who inflates the priority of his traffic to try to
>>> prevent emergency calls/first responders from getting priority
>>> treatment.
>> 
>> there are no protocol mechanisms other than hop-by-hop TLS or
>> IPsec to control that. I'm not even sure how much those are
>> deployed, even in cases where cryptographic keys are passed in
>> Diameter messages. (And that's when the base protocol spec says you
>> MUST use TLS in such cases. [1])
>> 
> But my point was specifically about how the motivation for DRMP is
> tied to the first responder and emergency use cases. When a
> capability is defined specifically for those uses, people (or, say,
> regulators) tend to expect it to work. So if there is a class of
> cases where it won’t work at all — even if the net effect is just
> that requests get treated on a best efforts basis the same as they do
> today, not that some requests get starved — it’s worth being very
> explicit about that. I’m sure there are other attacks that could
> target these uses in the absence of DRMP, but that isn’t a reason to
> gloss over the DRMP-specific issue in this spec.

Sure. But I'm not clear what's being glossed over. If what you mean
is that some more text is needed in section 11 to discuss emergency
use cases, that'd be fine, (and suggestions welcome) but I thought
that that potential attack was covered there already, even if not
explicitly called out.

Cheers,
S.

> 
> Alissa
> 
>> The DIME WG are attempting to address that via [2] but I'm not sure
>> if we ought be hugely hopeful of that being implemented or deployed
>> either.
>> 
>> It might help if someone more familiar with deployments can correct
>> or confirm the above.
>> 
>> That doesn't affect the issue of potentially un-coordinated uses of
>> different priorities across multiple Diameter applications, which
>> seems like it is worth saying more about, but I'd have to say that
>> uses of DRMP as an attack vector aren't that compelling from what I
>> know, and the WG are attempting to at least document mechanisms
>> that would provide relevant protocol countermeasures for the base
>> protocol.
>> 
>> Cheers, S.
>> 
>> [1] https://tools.ietf.org/html/rfc6733#section-13.3 [2]
>> https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req
>> 
>> 
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 May 2016 06:19:57 -0700

> On May 5, 2016, at 1:00 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

I think the gap is in Section 5, where it should be noted that in order for priority information to be reliably usable in the way that use cases 5.1 and 5.2 call for, the Diameter nodes sending and consuming it must have pre-established trust relationships of the sort described in Section 11.

Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 May 2016 14:21:22 +0100

On 05/05/16 14:19, Alissa Cooper wrote:
> I think the gap is in Section 5, where it should be noted that in
> order for priority information to be reliably usable in the way that
> use cases 5.1 and 5.2 call for, the Diameter nodes sending and
> consuming it must have pre-established trust relationships of the
> sort described in Section 11.

Sounds reasonable to me. Authors?

S.

---

From: <[email-masked]>
Date: Thu, 5 May 2016 13:50:59 +0000

Was also my proposal. Fine for me.

Envoyé de mon Orange Nura 2

Le 5 mai 2016 15:22, Stephen Farrell <[email-masked]> a écrit :

S.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 May 2016 09:25:59 -0500

I'm okay with this addition.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 May 2016 15:39:09 +0100

Great. I think we're maybe at the point where pushing out a
revised I-D that has the fixes we now know we want would be a
good plan and then we can go back around the discuss holders
and see where we're at.

Make sense? If not, then please continue the discussion to
get us there.

Cheers,
S.

---

From: "Gunn, Janet P" <[email-masked]>
Date: Thu, 5 May 2016 14:54:24 +0000

Looks good to me.

Janet

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Thursday, May 05, 2016 10:26 AM
To: Stephen Farrell <[email-masked]>; Alissa Cooper <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; IESG <[email-masked]>
Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

Steve

> Sounds reasonable to me. Authors?

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 6 May 2016 11:03:58 -0500

All,

I was on jury duty yesterday so I wasn't able to fully engage.

I agree that we are close to resolving issues and I will produce an 
updated draft that addresses IESG review comments, along with one change 
requested by IANA.

I also need to respond to Ben's last email.

My proposal, modulo Ben's comments, is to add the following to the draft:

- Emphasizing that the mechanism only works when one of the following is 
true:

   - Agents only handle a single DRMP application.
   - All Diameter applications that support DRMP used in a Diameter 
network must have consistent and synchronized priority definitions. I'll 
add some words around what is meant by consistent and synchronized.

- Strengthening wording indicating that this mechanism is designed to 
work in trusted environments.  This includes recommending stripping or 
modifying priority settings for requests received from untrusted 
sources.  The determination of what is a trusted and untrusted source 
would be out of the scope of the DRMP draft.

- Adding the other updates that have been agreed to as part of this 
review cycle.

This leaves as future work, should there be a need, the handling 
multiple "priority schemes" within a single network.  This is a very 
hard problem and not a use case that is currently needed by existing 
users of Diameter.

I'll wait for feedback, especially from the Dime working group, before I 
start updating the document.

Regards,

Steve

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 06 May 2016 15:03:31 -0500

I'm jumping in here because part of it also relates to some of my 
DISCUSS points:

On 6 May 2016, at 11:03, Steve Donovan wrote:

> updated draft that addresses IESG review comments, along with one 
> change requested by IANA.
>
> - Emphasizing that the mechanism only works when one of the following 
> is true:
>

What does that mean from a standards perspective? A "relay agent" is 
assumed to be application-agnostic. So in some ways, it supports all 
applications. Even ones that don't exist yet. A proxy, OTOH, is assumed 
to know application semantics--but I don't think that is what we are 
talking about, is it?

Or do this just mean that the operator makes sure that messages from 
only one application traverse the agent? (There's risk that they will 
forget that part when adding a 2nd application down the road.)  (But see 
next comment...)

> network must have consistent and synchronized priority definitions. 
> I'll add some words around what is meant by consistent and 
> synchronized.

Those would help, but I don't think handling a single DRMP application 
necessarily removes the need for consistent priority definitions.

As with DOIC, you may see cases where vendors and or operators wish to 
apply DRMP to applications even though the specifications for that 
application do not define its use. (or perhaps before the owners of the 
standard for legacy applications get around to doing so.) I'm not sure 
if the intent is to allow that, but if it is, then you need consistent 
policies across nodes.

If the expectation is that DRMP can only be used when documented in the 
"standard" for the application, then it would be good to include some 
high-level detail about what we expect to be documented.

> I'll wait for feedback, especially from the Dime working group, before 
> I start updating the document.
>
> Regards,
>
> Steve
>
>>> On May 5, 2016 8:21:22 AM Stephen Farrell 
>>> <[email-masked]>
>>> wrote:
>>>
>>>>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 10 May 2016 08:26:48 -0500

See inline.

On 5/6/16 3:03 PM, Ben Campbell wrote:
> applications. Even ones that don't exist yet. A proxy, OTOH, is 
> assumed to know application semantics--but I don't think that is what 
> we are talking about, is it?
>
> forget that part when adding a 2nd application down the road.)  (But 
> see next comment...)
SRD> It means that the network is set up so the relay, be it an agent or 
a proxy, only handles a single application.
>> I'll add some words around what is meant by consistent and synchronized.
>
> application do not define its use. (or perhaps before the owners of 
> the standard for legacy applications get around to doing so.) I'm not 
> sure if the intent is to allow that, but if it is, then you need 
> consistent policies across nodes.
SRD> The consistency mentioned above is across applications.  A nodes 
adherence to standards or operator policy addresses consistency across 
nodes.
>
> If the expectation is that DRMP can only be used when documented in 
> the "standard" for the application, then it would be good to include 
> some high-level detail about what we expect to be documented.
SRD> This is reasonable.  Although its not going to be much more than 
documenting what priority to use in which situations.
>> work in trusted environments.  This includes recommending stripping 
>> or modifying priority settings for requests received from untrusted 
>> I'll wait for feedback, especially from the Dime working group, 
>> before I start updating the document.
>>
>> Regards,
>>
>> Steve
>>