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

Jouni Korhonen <jouni.nospam@gmail.com> Tue, 25 March 2014 12:38 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 1BDAC1A00DD for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 05:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MNJaPtC3WvIj for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 05:38:25 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C03CE1A00BE for <dime@ietf.org>; Tue, 25 Mar 2014 05:38:24 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id y1so307859lam.6 for <dime@ietf.org>; Tue, 25 Mar 2014 05:38:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wq5gBS23WupPq/2NquoxePRYORh1qEoNun/RxjZQ+N4=; b=owHnL5jcPtJoxoligGxc/3ZCa4TcZ8LNvWfGMQt3igDdsRRri7LgWIfA3MwdJ+iR6m /dKVNa2o7WSFy8ZfrYp3si+/yGK7u+nh7MjHU02F+ta0PcahYWtxxg1xTvMoPJFuflqk UTAu5t3XgmVQF+E9BMnrIwfIcOQCsAxIai8PjPgIxK92/p8uP7qX6xagyToHJB9KTOLp ePP3HzxkYhyVuMES6xsyDY0CrWDsJGIeIk7JSdX3iT4nkOlCaNfSOZQ7BHCbWcFkUi68 UE0eMHm8wdOhW7cE36i8rRkGlNPE7kEy0wE0ba/LQvJdotlv1Ahc0rBr2WcnDm+WjxKw DNVw==
X-Received: by 10.112.51.202 with SMTP id m10mr137342lbo.63.1395751102845; Tue, 25 Mar 2014 05:38:22 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:fdd8:8cad:e27:1d18? ([2001:1bc8:101:f101:fdd8:8cad:e27:1d18]) by mx.google.com with ESMTPSA id q4sm11693556lbh.20.2014.03.25.05.38.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 05:38:16 -0700 (PDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <E194C2E18676714DACA9C3A2516265D202672B74@FR712WXCHMBA12.zeu.alcatel-lucent.com>
Date: Tue, 25 Mar 2014 14:38:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <98C36821-0110-4A8C-9CFB-FDC2C1D88768@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> <53302397.7020006@usdonovans.com> <E194C2E18676714DACA9C3A2516265D202672B74@FR712WXCHMBA12.zeu.alcatel-lucent.com>
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YNigAVuTJMZQ8jBem2YidJJh0NA
Cc: "dime@ietf.org" <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: Tue, 25 Mar 2014 12:38:28 -0000

Hi,

On Mar 25, 2014, at 10:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:

> Hi
>  
> Effectively we should be cautious with M bit for AVPS inside a grouped AVP such as OC-OLR AVP, and as Ben proposed, I am also rather in favour of not using the Mbit inside a DOC group AVP, including application specific AVPs.
>  
> In the thread discussion it  was mentioned the use of OC-feature and  also relay node that is application  independent.
>  
> Hereafter my  case:
>  
> After our IETF draft having become a RFC, IETF standardizes an extension,  which adds a new flag in OC-feature AVP. This extension is not specific to a Diameter application
> -          A  relay oonly supporting our IETF draft, will observe that OC-feature value does not fit to what it knows. I expect here that relay will do nothing about DOC as the meaning of the OC-OLR may be different of what it knows. OK? I als othink it applies to a proxy DA

I would expect the behaviour be like this.. otherwise there will be issues.

> -          If the relay supports the extension, it will recognize  the OC-feature value and will behave according this value. So OK. Should we have some text in the IETF draft?

By default relays should not even look into DOIC stuff.. since relays are only supposed to route requests. But we cannot prohibit some relay implementations doing "enhanced" processing on requests. For that part I think there is no need to say anything.

>  
> Now, this is a Diameter  application (eg a 3GPP one) that will define an extension for its own use . Is this application is allowed to use bits of OC-Features AVP to indicate this application specific feature (or even algorithm). How to avoid the application to use the same bits as future IETF extensions? Will we be driven to use 

If you define a new application, you are still supposed to register your feature bits. Otherwise, there will be a mess. I see no reason why someone would like to go this road other than for the pleasure of having incompatibility issues to fight with..

> another OC-Application-Specific-Feature AVP, or have bits  in OC-Feature reserved for application specific extensions., or other?  A constraint is that  a relay (application unaware) should nevertheless  detect there is application specific extensions (without knowing their meaning) so to not do DOC actions.  

The process of registering a new feature flag is made so easy with IANA that there should not be a reason not to do so. Feature flags are not application specific per se, or that is how its use was designed to begin with. They could be but then relays definitely should not look into those..


>  
> I understand this is not directly linked to our immediate scope, but we may try  to be future proof allowing application specific extensions and Relay node supporting the generic DOC.

If you want to be on the safe ground, you do these things with proxies.

>  
> Do you agree on this potential issue? If yes may be to analyse what to add in the IETF draft to be future proof.

I agree there will be issues if someone deliberately starts doing weird stuff with relays and also fooling around with feature flags.. We are already on the edge with feature flags in general, since they allow adding new functionality to applications without doing how Diameter was designed to do that - getting a new application-id.

- Jouni


>  
> Best regards
>  
> JJacques  
>   
>  
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoyé : lundi 24 mars 2014 13:23
> À : dime@ietf.org
> Objet : Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
>  
> Do we have proposed wording to be included in the -02 version of the draft on this issue?
> 
> Steve
> 
> On 3/22/14 12: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.
>  
>  
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>  
>  
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime