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

Stephen Farrell <> Wed, 04 May 2016 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80D3512D1F0; Wed, 4 May 2016 11:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ERF1OCyI5oXe; Wed, 4 May 2016 11:53:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B00AF12D147; Wed, 4 May 2016 11:53:25 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0ECBDBE7C; Wed, 4 May 2016 19:53:23 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NttfoBr4d9XR; Wed, 4 May 2016 19:53:21 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id D5B69BE53; Wed, 4 May 2016 19:53:20 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1462388001; bh=lMc09rWlNFlzWFVC2vaRzWjlOxuIEnwrFeq1/atLUss=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qX8eLlrZh+s6Kcm8hBxmhxqgA3vVUXOIr4fLitLkHb1fz6juu2ZtOkSPVrrOxsgF+ JjaAmSPbTmpkFZ5J/+DkMUorJhgmS3iv3Z62u9Ucg1QhGQ8v/P80e94Zpd5bLxRogE FfWvlp91RStc6punRBq0VzVNduDbm4EtllLESJiA=
To: Alissa Cooper <>, Steve Donovan <>
References: <> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 04 May 2016 19:53:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030409050800050407070400"
Archived-At: <>
Cc: "" <>, "" <>, "" <>, IESG <>
Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 May 2016 18:53:28 -0000


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

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.