Subject: [Dime] DOIC: Proposed Update to Security Considerations

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2014 16:37:26 -0600

Hi,

Here's some proposed text to update the security considerations. The main changes were to emphasize how certain decisions (OLRs only in answers, implicit determination of Realm, application, and host) partially mitigate certain attacks. I also added text on how a non-supporting agent might be falsely assumed to support DOIC, and made some general editorial changes.

------------------

9.  Security Considerations

   DOIC gives Diameter nodes the ability to request that downstream
   nodes send fewer Diameter requests.  Nodes do this by exchanging
   overload reports that directly effect this reduction.  This exchange
   is potentially subject to multiple methods of attack, and has the
   potential to be used as a Denial-of-Service (DoS) attack vector.

   Overload reports may contain information about the topology and
   current status of a Diameter network.  This information is
   potentially sensitive.  Network operators may wish to control
   disclosure of overload reports to unauthorized parties to avoid its
   use for competitive intelligence or to target attacks.

   Diameter does not include features to provide end-to-end
   authentication, integrity protection, or confidentiality.  This may
   cause complications when sending overload reports between non-
   adjacent nodes.

9.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 an overload report.

   There are several ways an attacker might attempt to exploit the
   overload control mechanism.  An unauthorized third party might inject
   an overload report into the network.  If this third party is upstream
   of an agent, and that agent fails to apply proper authorization
   policies, downstream nodes may mistakenly trust the report.  This
   attack is at least partially mitigated by the assumption that nodes
   include overload reports in Diameter answers but not in requests.
   This requires an attacker to have knowledge of the original request
   in order to construct an answer.  Such an answer would also need to
   arrive at a Diameter node via a protected transport connection.
   Therefore, implementations MUST validate that an answer containing an
   overload report is a properly constructed response to a pending
   request prior to acting on the overload report, and that the answer
   was received via an appropriate transport connection.

   A similar attack involves a compromised but otherwise authorized node
   that sends an inappropriate overload report.  For example, a server
   for the realm "example.com" might send an overload report indicating
   that a competitor's realm "example.net" is overloaded.  If other
   nodes act on the report, they may falsely believe that "example.net"
   is overloaded, effectively reducing that realm's capacity.
   Therefore, it's critical that nodes validate that an overload report
   received from a peer actually falls within that peer's responsibility
   before acting on the report or forwarding the report to other peers.
   For example, an overload report from a peer that applies to a realm
   not handled by that peer is suspect.

      This attack is partially mitigated by the fact that the
      application, as well as host and realm, for a given OLR is
      determined implicitly by respective AVPs in the enclosing answer.
      If a reporting node modifies any of those AVPs, the enclosing
      transaction will also be affected.

9.2.  Denial of Service Attacks

   Diameter overload reports, especially realm-reports, can cause a node
   to cease sending some or all Diameter requests for an extended
   period.  This makes them a tempting vector for DoS attacks.
   Furthermore, since Diameter is almost always used in support of other
   protocols, a DoS attack on Diameter is likely to impact those
   protocols as well.  Therefore, Diameter nodes MUST NOT honor or
   forward OLRs received from peers that are not trusted to send them.

   An attacker might use the information in an OLR to assist in DoS
   attacks.  For example, an attacker could use information about
   current overload conditions to time an attack for maximum effect, or
   use subsequent overload reports as a feedback mechanism to learn the
   results of a previous or ongoing attack.  Operators need the ability
   to ensure that OLRs are not leaked to untrusted parties.

9.3.  Non-Compliant Nodes

   In the absence of an overload control mechanism, Diameter nodes need
   to implement strategies to protect themselves from floods of
   requests, and to make sure that a disproportionate load from one
   source does not prevent other sources from receiving service.  For
   example, a Diameter server might throttle a certain percentage of
   requests from sources that exceed certain limits.  Overload control
   can be thought of as an optimization for such strategies, where
   downstream nodes never send the excess requests in the first place.
   However, the presence of an overload control mechanism does not
   remove the need for these other protection strategies.

   When a Diameter node sends an overload report, it cannot assume that
   all nodes will comply, even if they indicate support for DOIC.  A
   non-compliant node might continue to send requests with no reduction
   in load.  Such non-compliance could be done accidentally, or
   maliciously to gain an unfair advantage over compliant nodes.
   Requirement 28 [RFC7068] indicates that the overload control solution
   cannot assume that all Diameter nodes in a network are trusted, and
   that malicious nodes not be allowed to take advantage of the overload
   control mechanism to get more than their fair share of service.

9.4.  End-to End-Security Issues

   The lack of end-to-end security features makes it difficult to
   establish trust in overload reports that originate from non-adjacent
   nodes.  Any agents in the message path may insert or modify overload
   reports.  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
   Diameter overload control MUST give operators the ability to select
   which peers are trusted to deliver overload reports, and whether they
   are trusted to forward overload reports from non-adjacent nodes.
   DOIC nodes MUST strip DOIC AVPs from messages received from peers
   that are not trusted for DOIC purposes.

   The lack of end-to-end confidentiality protection means that any
   Diameter agent in the path of an overload report can view the
   contents of that report.  In addition to the requirement to select
   which peers are trusted to send overload reports, operators MUST be
   able to select which peers are authorized to receive reports.  A node
   MUST not send an overload report to a peer not authorized to receive
   it.  Furthermore, an agent MUST remove any overload reports that
   might have been inserted by other nodes before forwarding a Diameter
   message to a peer that is not authorized to receive overload reports.

      A DOIC node cannot always automatically detect that a peer also
      supports DOIC.  For example, a node might have a peer that is a
      non-supporting agent.  If nodes on the other side of that agent
      send OC-Supported-Features AVPs, the agent is likely to forward
      them as unknown AVPs.  Messages received across the non-supporting
      agent may be indistinguishable from messages received across a
      DOIC supporting agent, giving the false impression that the non-
      supporting agent actually supports DOIC.  This complicates the
      transitive-trust nature of DOIC.  Operators need to be careful to
      avoid situations where a non-supporting agent is mistakenly
      trusted to enforce DOIC related authorization policies.

   At the time of this writing, the DIME working group is studying
   requirements for adding end-to-end security features
   [I-D.ietf-dime-e2e-sec-req] to Diameter.  These features, when they
   become available, might make it easier to establish trust in non-
   adjacent nodes for overload control purposes.  Readers should be
   reminded, however, that the overload control mechanism encourages
   Diameter agents to modify AVPs in, or insert additional AVPs into,
   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.  The details of using any future
   Diameter end-to-end security mechanism with overload control will
   require careful consideration, and are beyond the scope of this
   document.

---

From: <[email-masked]>
Date: Fri, 28 Nov 2014 13:39:07 +0000

Ok with the content.
Just one proposed correction in section 9.4:

I assume that what you want to highlight is the lack of E2E integrity, right?
what about:

   The lack of end-to-end *integrity* features makes it difficult to
   establish trust in overload reports *received* from non-adjacent
   nodes.  Any agents in the message path may insert or modify overload

regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 25 novembre 2014 23:37
À : [email-masked] list
Objet : [Dime] DOIC: Proposed Update to Security Considerations

Hi,

------------------

9.3.  Non-Compliant Nodes

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 28 Nov 2014 09:43:39 -0600

I agree it should be more precise, but I think confidentially also might matter, since we have requirements to be able to authorize who can see overload information. I propose changing "security features" to "integrity and confidentiality protection", and "may insert or modify" to "may insert, read, or modify"

> On Nov 28, 2014, at 7:39 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Ok with the content.

---

From: <[email-masked]>
Date: Fri, 28 Nov 2014 16:31:35 +0000

My point was that integrity covers the case "insert/modify/remove".
The confidentiality aspects are covered in the next paragraph.

And so my proposal. 

Regards,

lionel 

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : vendredi 28 novembre 2014 16:44
À : MORAND Lionel IMT/OLN
Cc : [email-masked] list
Objet : Re: [Dime] DOIC: Proposed Update to Security Considerations

> Envoyé : mardi 25 novembre 2014 23:37 À : [email-masked] list Objet : 
> [Dime] DOIC: Proposed Update to Security Considerations
> 
> Hi,
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 28 Nov 2014 10:50:13 -0600

Oops, you are correct. I agree with your proposal.

> On Nov 28, 2014, at 10:31 AM, <[email-masked]> <[email-masked]> wrote:
>