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

Alissa Cooper <alissa@cooperw.in> Wed, 04 May 2016 18:26 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3E412D122 for <dime@ietfa.amsl.com>; Wed, 4 May 2016 11:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=fTt9E4nz; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JEqcW4mZ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehnwhuLa71y0 for <dime@ietfa.amsl.com>; Wed, 4 May 2016 11:26:48 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAB212D5B0 for <dime@ietf.org>; Wed, 4 May 2016 11:26:44 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 664CC20A7A for <dime@ietf.org>; Wed, 4 May 2016 14:18:46 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 04 May 2016 14:18:46 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=MXcLM GxlQJGLsEp3DuGot3g/PEs=; b=fTt9E4nzDAO+Kaz27SJkYkM+dl7/FYlzsFM8l G1b0IOTWpDM3D2DD0zALPjmwrPfkZ7Cyqq502T+vROniciIdsBjrlZIzcq3uwMuq 338KuSlPmhDINlSF2Z89qOu4/4XJgQD3m7glSBx0IafdNlY3XKXudF6gqVblJ4br T/qYGo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=MXcLMGxlQJGLsEp3DuGot3g/PEs=; b=JEqcW 4mZKKAluMDvoNQXL0A6n4ewSll8CyKgqYmVnbmnz0ycB6v2a9EATcMShBXiFrZQW kJc4j0lpWAOzNL1nVEw18kbM5oN13U+OU8mBRXpznwNa3g5EfrczwVQyll6/jcuE phZV3nR2PgDlWIHX2navGvEdRok/UZj1SUyjvA=
X-Sasl-enc: 8gfcBynJn6//3W2Zd0G82d0ATs7eAaVUxs2Gw24t0M7T 1462385925
Received: from dhcp-171-68-20-190.cisco.com (dhcp-171-68-20-190.cisco.com [171.68.20.190]) by mail.messagingengine.com (Postfix) with ESMTPA id 2840CC00017; Wed, 4 May 2016 14:18:45 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBA5C409-9128-4BA6-8739-DEDA138A9A4C"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <572A1C14.5020907@usdonovans.com>
Date: Wed, 04 May 2016 11:18:43 -0700
Message-Id: <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in>
References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/t6GXX84ujx10jtNbSIGaCzZ3Jgc>
Cc: "draft-ietf-dime-drmp@ietf.org" <draft-ietf-dime-drmp@ietf.org>, "dime-chairs@ietf.org" <dime-chairs@ietf.org>, "dime@ietf.org" <dime@ietf.org>, IESG <iesg@ietf.org>
Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2016 18:26:51 -0000

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 <srdonovan@usdonovans.com> wrote:
> 
> Responding to both Alissa's comments and Lionel's responses.
> 
> Regards,
> 
> Steve
> 
> On 5/3/16 6:42 PM, lionel.morand@orange.com <mailto:lionel.morand@orange.com> 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:alissa@cooperw.in>
>> Envoyé : ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31
>> À : iesg@ietf.org <mailto:iesg@ietf.org>
>> Cc : draft-ietf-dime-drmp@ietf.org <mailto:draft-ietf-dime-drmp@ietf.org>, Lionel MORAND <mailto:lionel.morand@orange.com>, dime-chairs@ietf.org <mailto:dime-chairs@ietf.org>, Lionel MORAND <mailto:lionel.morand@orange.com>, dime@ietf.org <mailto:dime@ietf.org>
>> 
>> 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 <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/ <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.

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.

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

WFM

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

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.


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

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

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