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

From: Ben Campbell <[email-masked]>
Date: Mon, 17 Mar 2014 12:59:32 -0500

Hi,

In the London meeting, I agreed that this issue was invalid based on statements in the room that the 6733 correct treatment of an unknown mandatory AVP inside a grouped AVP was to ignore the grouped AVP.

On rereading that section of RFC 6733, I disagree with that interpretation. Section 4.4 says:

> Receivers of a Grouped AVP that
>    does not have the 'M' (mandatory) bit set and one or more of the
>    encapsulated AVPs within the group has the 'M' (mandatory) bit set
>    MAY simply be ignored if the Grouped AVP itself is unrecognized.

That text only applies for _unrecognized_ grouped AVPs. The case in question is when you _recognize_ an optional grouped AVP, but do not recognize a mandatory AVP imbedded in it. The exception in 4.4 does not seem to cover that case.

So I no longer believe that the issue is invalid. I think the best option is to simply forbid setting of the m-bit on any DOIC related AVP.

To address other comments on the issue:

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.

On Feb 7, 2014, at 4:10 PM, dime issue tracker <[email-masked]> wrote:

> #48: Setting M-Bit gives wrong semantics
> 
> Multiple sections indicate that a new application that incorporates DOIC
> can set the M-Bit on DOIC sub-avps. I don't think this ever does the right
> thing.
> 
> IIUC, If a node that otherwise supports DOIC encounters a DOIC avp that it
> doesn't understand, and has the M-Bit set, it will cause a failure of the
> application command. I don't think we want the lack of support of some
> DOIC feature or extension to ever cause an application-level failure.  I
> think we are looking for something that would just cause the OLR to be
> ignored.
> 
> -- 
> -------------------------+-------------------------------------------------
> Reporter:               |      Owner:  draft-docdt-dime-
>  [email-masked]        |  [email-masked]
>     Type:  defect       |     Status:  new
> Priority:  major        |  Milestone:
> Component:  draft-       |    Version:  1.0
>  docdt-dime-ovli        |   Keywords:
> Severity:  Active WG    |
>  Document               |
> -------------------------+-------------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/48>
> dime <http://tools.ietf.org/wg/dime/>
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 22 Mar 2014 01:43:52 +0800

Ben,

> 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 AV…

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.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Mar 2014 13:44:03 -0500

> situation. The implementation is already bending the rules in that

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.

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 22 Mar 2014 10:33:31 +0800

Ben,

> 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…

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..

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Sat, 22 Mar 2014 00:36:15 -0500

> (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.

---

From: Jouni <[email-masked]>
Date: Sun, 23 Mar 2014 11:47:58 +0200

> 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…

Agree on that!

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 07:22:47 -0500

Do we have proposed wording to be included in the -02 version of the
draft on this issue?

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 25 Mar 2014 08:07:25 +0000

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

-          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?

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 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.

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.

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

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 24 mars 2014 13:23
À : [email-masked]
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 Mar 21, 2014, at 9:33 PM, Jouni Korhonen <[email-masked]><mailto:[email-masked]> wrote:

Ben,

On Mar 22, 2014, at 2:44 AM, Ben Campbell <[email-masked]><mailto:[email-masked]> wrote:

On Mar 21, 2014, at 12:43 PM, Jouni Korhonen <[email-masked]><mailto:[email-masked]> wrote:

case.

Hi Jouni,

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 25 Mar 2014 14:38:17 +0200

Hi,

> -          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-OL…

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

---

From: <[email-masked]>
Date: Wed, 26 Mar 2014 17:38:30 +0000

In another word, I don't see something specific to say in this draft.
The M-bit setting is something that any diameter application should take care when extending an existing application or creating a new one. It is not tied to the overload control mechanism itself.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : mardi 25 mars 2014 13:38
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : [email-masked]
Objet : Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics

Hi,

- Jouni

_________________________________________________________________________________________________________________________

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: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Mar 2014 18:34:54 +0000

Hi Jouni

Thanks for your detailed answers about my questioning regarding the OC-features AVP  (I propose  to do another thread as not related to #48) 

About relays, I have not asked for relay to support DOIC, but Ben several times mentioned the relays that may act as a DOIC node . So I try to see consequences of this assuimption. From you answer, I think it should be clarified.

Then there are my questions about an application introducing new features, your answer is that new flags in the OC-features AVP must be declared to IANA. OK for this; I would think it should be written in the draft? 
Have we other possibilities: I think that in the OC-features AVP a part of the bit mask could be "common" meaning anew flag added in this part is declared to IANA. Another part is fully specific to an application, which is compatible with the fact that an OC-feature AVP (and its content) when sent  is always associated to a specific application. Other possibilities?

I currently have no religion on the way to do, only to have a way on how an application can add new feature bits without creating issues, and this way described in the draft. 

In 3GPP, there is the Supported-Features AVP of which the whole bit mask content  is fully specific to a Diameter application and this OK. This AVP may be understood by a Proxy DA application aware.

Best regards

JJacques 

-----Message d'origine-----
De : Jouni Korhonen [mailto:[email-masked]] 
Envoyé : mardi 25 mars 2014 13:38
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : [email-masked]
Objet : Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics

Hi,

>  
> 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

- Jouni

> Envoyé : lundi 24 mars 2014 13:23 À : [email-masked] Objet : Re: [Dime] 
> [dime] #48: Setting M-Bit gives wrong semantics
>  
> processing. If a relay supports DOIC and does something goofy that is 
> left for implementation, we should no care nor try to fix the

---

From: <[email-masked]>
Date: Wed, 26 Mar 2014 19:09:51 +0000

Hi JJ,

Relay is just a relay and application-agnostic. Overload control is designed to be used only on top of applications, not at the base level.
Everything done below the application level is then implementation specific.

As soon as there is a registry in IANA in which you can safely declare any new mechanism, the OC-Feature-Vector AVP is the mechanism to know what to do with the received OLR (when speaking about the generic solution). The Supported-Features AVP defined in 3GPP is another way. And to be able to understand these AVP, you will have to be at the application level in any case.

Regards,

Lionel 
 
-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : mercredi 26 mars 2014 19:35
À : Jouni Korhonen
Cc : [email-masked]
Objet : [Dime] OC-Supported features and application specific flags

Hi Jouni

Best regards

JJacques 

-----Message d'origine-----

Hi,

- Jouni