IETF Logo Mail Archive

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

Jouni <jouni.nospam@gmail.com> Sun, 23 March 2014 09:48 UTC

Return-Path: <jouni.nospam@gmail.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 B2F6D1A0654 for <dime@ietfa.amsl.com>; Sun, 23 Mar 2014 02:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 HdL8iP7nKTJz for <dime@ietfa.amsl.com>; Sun, 23 Mar 2014 02:48:13 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id D829F1A6F58 for <dime@ietf.org>; Sun, 23 Mar 2014 02:48:06 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id c11so2779958lbj.26 for <dime@ietf.org>; Sun, 23 Mar 2014 02:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aQsl6lu+A/Hr5CbQVp2eyu1w8jbjbZH15PAGirgeVLI=; b=Ti09G4PWgXK4iy74rB+ocBDJLzH5df33a6+QfF4DJZib8qrw3x5x095q/RDFfUcl2w 9Vbs0pU7jRdqWGSyIkWm/iczXE/3Fkjd+4HTYVWL6aQ3ntCY3cSY9sTM8ZB2m5PmMj2O gzB1fdxghRmPx7aTLlTPlL/16ElgN6XXlCO4q8HA3BT0hfx0empsUkWR/r+GwHgdKj4D /bACkpw9jBIrP6LQZX50ipDYyFjfqWobBVD7tI7nbaZpNh9fXLRoUORFrdeSziMXh2UE rOGwwPYNTUdb6BejcZyYtmL3j7Crm6L0mWYiQHGUA18PCtstEu7hXkSo1zvBjV4OmGtL sy/Q==
X-Received: by 10.112.128.131 with SMTP id no3mr65197lbb.57.1395568085410; Sun, 23 Mar 2014 02:48:05 -0700 (PDT)
Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id jh4sm7071716lbb.26.2014.03.23.02.48.00 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Mar 2014 02:48:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Jouni <jouni.nospam@gmail.com>
In-Reply-To: <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com>
Date: Sun, 23 Mar 2014 11:47:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AAF7A957-D596-4FC7-8624-4C54298D00D5@gmail.com>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com> <E25B5473-253C-44B8-BF99-5A2F86328E09@nostrum.com> <ED6F296B-F167-4007-87C3-DB8D75D35964@gmail.com> <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/d1W48uuFkcYzJd1GkbRryckB1Ac
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: Sun, 23 Mar 2014 09:48:16 -0000

On Mar 22, 2014, at 7:36 AM, Ben Campbell wrote:

> 
> On Mar 21, 2014, at 9:33 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
> 
>> 
>> Ben,
>> 
>> On Mar 22, 2014, at 2:44 AM, Ben Campbell <ben@nostrum.com> wrote:
>> 
>>> 
>>> 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.
>> 
>> Ah, I see your point. But if one adds AVPs to the default algorithm
>> that change he behaviour and does not a) declare it as a new algorithm
>> or b) add a new supported feature flag, then that is a proprietary
>> (broken) implementation. We cannot really protect against those..
> 
> I think that's reasonable. My original point was that extensions should not try to use the m-bit for that purpose. If they have something that is not backwards compatible, it needs to be negotiated in the feature vector.

Agree on that!

- Jouni


> 
>

v2.23.0 | Report a Bug | By Email