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

Stephen Farrell <> Thu, 05 May 2016 08:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D643612B021; Thu, 5 May 2016 01:00:37 -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 rov_Vq-baxGP; Thu, 5 May 2016 01:00:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3E8F12D17D; Thu, 5 May 2016 01:00:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEDC6BE50; Thu, 5 May 2016 09:00:34 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jHwrMDR6giRK; Thu, 5 May 2016 09:00:30 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 55CFFBE38; Thu, 5 May 2016 09:00:29 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1462435230; bh=Ut/Ff+TN5jtdbfl282a3yBtpBjpF88q678c9kXzgkZ8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qX6N3z0ojhxfe0dzE4PuAw6nqAYmT2NyY0OhGC4QdNeHv5lfar2qU0RvH9BnqL8tk e7PUl9KEEWQK+wvMJPSWyb5Kzr6F7NXDnc32fAwVUfMT2scd+Dv8STRLjqdUVzEboV jzpwf6E/99aBsYI0z7YlXBF700rkJsmPzmKHaC5I=
To: Alissa Cooper <>
References: <> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 05 May 2016 09:00:29 +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="------------ms020105030904040504040103"
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: Thu, 05 May 2016 08:00:38 -0000

On 05/05/16 05:31, Alissa Cooper wrote:
>> On May 4, 2016, at 11:53 AM, Stephen Farrell
>> <> wrote:
>> 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.
> 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.


> 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] [2]