[Dime] Proposed REQ 35 Text

Ben Campbell <ben@nostrum.com> Tue, 26 March 2013 20:30 UTC

Return-Path: <ben@nostrum.com>
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 26A5E21F8D7F for <dime@ietfa.amsl.com>; Tue, 26 Mar 2013 13:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkhZ+Y1uVQJs for <dime@ietfa.amsl.com>; Tue, 26 Mar 2013 13:30:51 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A08DF21F8D1E for <dime@ietf.org>; Tue, 26 Mar 2013 13:30:50 -0700 (PDT)
Received: from [10.0.1.7] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2QKUjwg041980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dime@ietf.org>; Tue, 26 Mar 2013 15:30:46 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DDAF9ABB-1199-4C97-8B8A-E571562EA223"
Message-Id: <E11F7859-5062-4FF4-A731-4E5B6E2826C9@nostrum.com>
Date: Tue, 26 Mar 2013 15:30:44 -0500
To: "dime@ietf.org" <dime@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Subject: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 26 Mar 2013 20:30:52 -0000

Hi,

We had a discussion about whether REQ 35 in the draft-ietf-dime-overload-reqs should stay a SHOULD or become a MUST.  We further discussed that any use of a MUST here would require some caveats about what sort of intermediaries could be traversed, and the potential security issues. The chairs directed us to take the discussion to the list due to time constraints. Here's my attempt to do so.

For reference, here's the original text:

> The mechanism SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism.
> 

Here's a proposed alternative for changing it to a MUST:

> The mechanism MUST provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism. The mechanism MAY place limitations on the nature of the non-supporting intermediaries that may be traversed. 
> 
> Nothing in this requirement should be construed to relax the security-related requirements elsewhere in this document, in particular REQs 28, 30, and 31. Maliciously constructed overload information can potentially shut down a Diameter network; it's critical that a node be able to confirm that received information came unaltered from an authorized source, whether the information comes from an immediate peer or crosses an intermediary.


Which general approach do people prefer? I kept the security aspects non-normative, since normative text already exists in 28,30, and 31.

Thanks!

Ben.