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 13:20 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 70A5A12D63D for <dime@ietfa.amsl.com>; Thu, 5 May 2016 06:20:27 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=eHALRAzf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=CuzBvVsN
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 uATrtiQ3yUF1 for <dime@ietfa.amsl.com>; Thu, 5 May 2016 06:20:25 -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 0B81012D65B for <dime@ietf.org>; Thu, 5 May 2016 06:20:00 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7A98720950 for <dime@ietf.org>; Thu, 5 May 2016 09:19:59 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 05 May 2016 09:19:59 -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=XKS5JKfzSzJLWpa5bs0ECRSYMbo=; b=eHALRA zftFJEVkiw5GpXR+eovgDpKP7WK4akqEC4Cupz1tyCIJGuxcKaAimQOmBAaeJA8W GupIPmAF3EIiC8JrCx3iSBi2pliPyZfCAV7rwCGOYUOgmKRJfL/ew7u5PwJP74v5 iyNJvdEwCSm2M+KrHC8UTP+zw/pqEpWH7YYv8=
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=XKS5JKfzSzJLWpa 5bs0ECRSYMbo=; b=CuzBvVsN6b1uDVtw1fqJPn4eoeXSnqUuf0BGz0fnNyOwaEs K/MYw0ZZz9LGd8ndYPzHjnwFHkxTsMcBdLGIz2HsxUXM6awMZQ92OuJ50vK0CFxJ pXQxENWFqgOu9M/rv6gl2UwRs028upzmt/Qe8IO/XsKW+5QStuQGhkMC6r7k=
X-Sasl-enc: mz82zKP2/xW4THpD8wXr7MOW3/HEe3egfUqJYGmRFwJF 1462454399
Received: from sjc-alcoop-88110.cisco.com (unknown [128.107.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BF0EC00017; Thu, 5 May 2016 09:19:58 -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: <572AFD9D.7010909@cs.tcd.ie>
Date: Thu, 5 May 2016 06:19:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF2919CA-DE13-44C1-8430-DD5B8D8DB252@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> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@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/1RATSDx4PK-Lz3zGBOWEAOgztp4>
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 13:20:27 -0000

> On May 5, 2016, at 1:00 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> 
> On 05/05/16 05:31, Alissa Cooper wrote:
>> 
>>> 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.
> 
> 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.

I think the gap is in Section 5, where it should be noted that in order for priority information to be reliably usable in the way that use cases 5.1 and 5.2 call for, the Diameter nodes sending and consuming it must have pre-established trust relationships of the sort described in Section 11.

Alissa

> 
> Cheers,
> S.
> 
>> 
>> 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
>>> 
>>> 
>> 
>