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

Alissa Cooper <alissa@cooperw.in> Thu, 05 May 2016 04:36 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 6460912B01C for <dime@ietfa.amsl.com>; Wed, 4 May 2016 21:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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_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=VYTEh53y; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=WZUOwUBS
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 4r9fQukE7onq for <dime@ietfa.amsl.com>; Wed, 4 May 2016 21:36:46 -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 5287412D0B0 for <dime@ietf.org>; Wed, 4 May 2016 21:36:45 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9C59A20993 for <dime@ietf.org>; Thu, 5 May 2016 00:31:30 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 05 May 2016 00:31:30 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=RCjcq/X92t7xRGAPeve3ZzV5my4=; b=VYTEh5 3yJiYtv+nGBYA9jChOhJpssFWxuL64vwXohk2ym2pxwawe6lgVG3l2gDwuNqWUa0 ToXrtlTP34/S/WEMXJmWH/Hg0PBlPxG7k/pPWv6YCyWob5M9fxMPwd9rksR34lMX SfI5dZDvR4EE5Ca9/7X6ZxOuluafLgUmwxtsw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=RCjcq/X92t7xRGA Peve3ZzV5my4=; b=WZUOwUBSAPTq5Uou2x1rGf1FvRWgo0C6Dnz9MVky8ETOl3m rX02+EsagyhQkNoNFsdtnXv1rGViEZ5kk3UvWwluu4M1eWKhou81oE3f2/lmQbSW vFx7R+2KSGihKVxPpS6U1hQvPqKO1Dv1DQNj1OwXaEeqJdYqXzumHLJ+h/h8=
X-Sasl-enc: y+dioK7LX8YvSai3xunCy54dfYE+Jw//phajhvBekKXT 1462422690
Received: from sjc-alcoop-88110.cisco.com (unknown [128.107.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E289C00018; Thu, 5 May 2016 00:31:29 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <572A4520.5090101@cs.tcd.ie>
Date: Wed, 04 May 2016 21:31:29 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <90C95598-F68D-4F94-8AE3-FAFF403F560E@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> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/fsfWorzPSU2oNIe0zXL755AuUNQ>
Cc: "dime-chairs@ietf.org" <dime-chairs@ietf.org>, "dime@ietf.org" <dime@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-dime-drmp@ietf.org" <draft-ietf-dime-drmp@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: Thu, 05 May 2016 04:36:47 -0000

> On May 4, 2016, at 11:53 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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.

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