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

[Steve Donovan <[e-mail]>]

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

Regards,

Steve

On 5/3/16 6:42 PM, [e-mail] wrote:
> 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:[e-mail]>
> *Envoyé :* ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31
> *À :* [e-mail] <mailto:[e-mail]>
> *Cc :* [e-mail] 
> <mailto:[e-mail]>, Lionel MORAND 
> <mailto:[e-mail]>, [e-mail] 
> <mailto:[e-mail]>, Lionel MORAND 
> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>
>
> 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.
>
> [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.


>
> (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.
>
> [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.
>
> (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?
>
> [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.
>
> ----------------------------------------------------------------------
> 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.
>
> [LM] right.
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.
>
> _________________________________________________________________________________________________________________________
>
> 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.