IETF Logo Mail Archive

Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics

Ben Campbell <ben@nostrum.com> Fri, 21 March 2014 18:44 UTC

Return-Path: <ben@nostrum.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 D34F91A0A38 for <dime@ietfa.amsl.com>; Fri, 21 Mar 2014 11:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 rOiadm_W1_Ft for <dime@ietfa.amsl.com>; Fri, 21 Mar 2014 11:44:27 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986F81A0A3A for <dime@ietf.org>; Fri, 21 Mar 2014 11:44:26 -0700 (PDT)
Received: from [172.20.10.9] (mobile-166-147-071-120.mycingular.net [166.147.71.120]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2LIi8mx083760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Mar 2014 13:44:10 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host mobile-166-147-071-120.mycingular.net [166.147.71.120] claimed to be [172.20.10.9]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>
Date: Fri, 21 Mar 2014 13:44:03 -0500
X-Mao-Original-Outgoing-Id: 417120243.331986-e45018d442cacca90b153f1a0dd54564
Content-Transfer-Encoding: quoted-printable
Message-Id: <E25B5473-253C-44B8-BF99-5A2F86328E09@nostrum.com>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O3uJ0ykoOaj77XRB53_AmzmRLrA
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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: <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: Fri, 21 Mar 2014 18:44:29 -0000

On Mar 21, 2014, at 12:43 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

>> 
>> Consider the case of a Diameter _relay_ that supports DOIC. It is not aware of any application-specific rules about m-bits. It receives an OC-Supported-Features or an OC-OLR that has a mandatory AVP that it doesn't recognize. Logically, it should probably ignore the entire OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject the message. Rather it's likely to try to apply the OC-Supported-Features or OC-OLR incorrectly.
> 
> RFC6733 also says that relays perform not do any application level
> processing. If a relay supports DOIC and does something goofy that
> is left for implementation, we should no care nor try to fix the
> situation. The implementation is already bending the rules in that
> case.

Hi Jouni,

I'm not talking about the case of the relay doing something goofy. Rather, I mean when a relay tries to perform basic DOIC processing of an OLR as described in the base DOIC spec, but ignores some extension AVP that changes the meaning of the OLR. It's not bending the rules so much as failing to recognize someone else changing the rules.

v2.23.0 | Report a Bug | By Email