[Dime] Proposed security section for DRMP
Steve Donovan <srdonovan@usdonovans.com> Mon, 01 February 2016 16:30 UTC
Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7DC1B3228 for <dime@ietfa.amsl.com>; Mon, 1 Feb 2016 08:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
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 JF3UryG5ZEEr for <dime@ietfa.amsl.com>; Mon, 1 Feb 2016 08:30:13 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE2B1B321F for <dime@ietf.org>; Mon, 1 Feb 2016 08:30:13 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:58451 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from <srdonovan@usdonovans.com>) id 1aQHMf-000Glu-DB for dime@ietf.org; Mon, 01 Feb 2016 08:30:13 -0800
To: "dime@ietf.org" <dime@ietf.org>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <56AF8811.5030106@usdonovans.com>
Date: Mon, 01 Feb 2016 10:30:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/_NqoHTJEBbgsOGZyGUqMSXlxiiY>
Subject: [Dime] Proposed security section for DRMP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 01 Feb 2016 16:30:15 -0000
All,
Here's the proposed security section for DRMP. It is based heavily on
Ben's words in the Diameter Overload RFC.
Regards,
Steve
-----
11. Security Considerations
DRMP gives Diameter nodes the ability to influence which requests are
are throttled during overload scenarios. Improper use of the DRMP
mechanism could result in the malicious Diameter node gaining
preferential treatment, by reducing the probability of its requests
being throttled, over other Diameter nodes. This would be achieved
by the malicious node inserting artificially high priority values.
Diameter does not include features to provide end-to-end
authentication, integrity protection, or confidentiality. This opens
the possibility that agents in the path of a request could modify the
DRMP AVP to reflect a priority different than that asserted by the
sender of the request.
11.1. Potential Threat Modes
The Diameter protocol involves transactions in the form of requests
and answers exchanged between clients and servers. These clients and
servers may be peers, that is, they may share a direct transport
(e.g., TCP or SCTP) connection, or the messages may traverse one or
more intermediaries, known as Diameter Agents. Diameter nodes use
TLS, DTLS, or IPsec to authenticate peers, and to provide
confidentiality and integrity protection of traffic between peers.
Nodes can make authorization decisions based on the peer identities
authenticated at the transport layer.
When agents are involved, this presents an effectively transitive
trust model. That is, a Diameter client or server can authorize an
agent for certain actions, but it must trust that agent to make
appropriate authorization decisions about its peers, and so on.
Since confidentiality and integrity protection occurs at the
transport layer, agents can read, and perhaps modify, any part of a
Diameter message, including the DRMP AVP.
There are several ways an attacker might attempt to exploit the DRMP
mechanism. A malicious or compromised Diameter node might insert
invalid priority values resulting in either preferential treatment,
Donovan Expires July 4, 2016 [Page 13]
Internet-Draft DOIC January 2016
resulting from higher values, or degraded treatment resulting from
lower values, for that node.
A similar attack involves a malicious or compromised Diameter agent
changing the priority value resulting in the sending Diameter node
getting either preferential or degraded service.
The DRMP mechanism can be used to aid in overload throttling
decisions. When this is the case then the above attacks are limited
in scope to when one or more Diameter nodes are in an overloaded
state.
The DRMP mechanism can also be used to influence the order in which
Diameter messages are handled by Diamter 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.
11.2. Denial of Service Attacks
The DRMP mechanism does not open direct denial of service attack
vectors. Rather, it introduces a mechanism where a node can gain
unwarranted preferential treatment. It also introduces a mechanism
where a node can get degrated service in the scenario where a rogue
agent changes the priority value included in messages.
11.3. End-to End-Security Issues
The lack of end-to-end integrity features makes it difficult to
establish trust in DRMP AVPs received from non-adjacent nodes. Any
agents in the message path may insert or modify DRMP AVPs. Nodes
must trust that their adjacent peers perform proper checks on
overload reports from their peers, and so on, creating a transitive-
trust requirement extending for potentially long chains of nodes.
Network operators must determine if this transitive trust requirement
is acceptable for their deployments. Nodes supporting DRMP MUST give
operators the ability to select which peers are trusted to deliver
DRMP AVPs, and whether they are trusted to forward the DRMP AVPs from
non-adjacent nodes. Diameter nodes MUST strip DRMP AVPs from
messages received from peers that are not trusted for DRMP purposes.
It is expected that work on end-to-end Diameter security might make
it easier to establish trust in non-adjacent nodes for DRMP purposes.
Readers should be reminded, however, that the DRMP mechanism allows
Diameter agents to modify AVPs in existing messages that are
originated by other nodes. If end-to-end security is enabled, there
is a risk that such modification could violate integrity protection.
Donovan Expires July 4, 2016 [Page 14]
Internet-Draft DOIC January 2016
The details of using any future Diameter end-to-end security
mechanism with DRMP will require careful consideration, and are
beyond the scope of this document.
- [Dime] Proposed security section for DRMP Steve Donovan