Subject: Re: [AAA-DOCTORS] [Dime] "Fail unless processed successfully" Bit

From: <[email-masked]>
Date: Wed, 3 Dec 2008 10:45:47 +0100

In order to restrict the discussion for now, I use the aaa-doctors ML.

On the same topic, I think that some guidelines should be provided on the handling of the M-bit when it is set for an optional AVP in a command answer.
We know how to deal with AVP with M-bit set not understood in the request (e.g. use of the permanent failure error value DIAMETER_AVP_UNSUPPORTED).
But it is not described what should be the behavior of the client when it receives such optional AVP in the answer.

In Diameter extensibilty DT, my proposal was to provide some text to clarify this point:

*If the AVP is received in the command (request AND/OR answer) and the M-bit is not set
--> AVP used only for information or optional behaviour i.e. nice-to-have but not critical if not understand, and may be therefore ignored.

*If the AVP is received in the command (request only) and the M-bit is set
--> if not understood, the request fails and a Failure indication (Result-code) must be sent back sent back to the sender along with the Failed-AVP AVP

*If the AVP is received in the command (answer only) and the M-bit is set
--> the handling of anwer fails and a specific command must be sent back to the responder (e.g. STR or ASR) with a specific reason code (if possible).

For STR/ASR generating after such error case, I was thinking about using Termination-Cause AVP in STR and ASR to provide specific value indication (to provide a way for the server/client to know why the session is terminated)

Do you think that such understanding/clarification is correct and required?
If yes, should this clarification be included in the RFC3588bis?

Lionel 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Jouni Korhonen
> Envoyé : mardi 2 décembre 2008 22:12
> À : Asveren, Tolga
> Cc : [email-masked]
> Objet : Re: [Dime] "Fail unless processed successfully" Bit
> 
> 
> I would echo what Tolga/Lionel/Victor said.
> 
> Cheers,
> 	Jouni
> 
> 
> On Dec 2, 2008, at 8:29 PM, Asveren, Tolga wrote:
> 
> > I agree that this is an application layer thing. IMHO it would be a 
> > major abuse to use any message header bits for this purpose.
> >
> > Thanks,
> > Tolga
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf
> > Of
> >> Victor Fajardo
> >> Sent: Tuesday, December 02, 2008 8:34 AM
> >> To: Tschofenig, Hannes (NSN - FI/Espoo)
> >> Cc: [email-masked]
> >> Subject: Re: [Dime] "Fail unless processed successfully" Bit
> >>
> >> Hi Hannes,
> >>
> >>> When setting this flag for an AVP there are no requirements
> > regarding
> >>> the creation of a Diameter application. When an AVP has 
> the flag set
> > and
> >>> the receiving end cannot process it successfully then an error
> > message
> >>> is returned.
> >>>
> >>> So, here are my questions:
> >>>
> >>> * Does my mail make sense to you? Is this a useful mechanism?
> >>>
> >>> * If so, where should it be added?
> >>>
> >>
> >> Is there a lot of application interested in such mechanism 
> that there
> > is
> >> a need to generalize it ? Should'nt this mechanism be specified in 
> >> the application requiring it ? Especially if you you want 
> to convey 
> >> more granular and context specific error messages/codes 
> back to the 
> >> server.
> >> In this case, we may not need an additional flag, just 
> specify a well 
> >> defined behavior in the doc.
> >>
> >> regards,
> >> victor
> >>
> >>> Ciao
> >>> Hannes
> >>>
> >>> PS: The M-bit cannot be used for this purpose because of several 
> >>> reasons, including the fact that it requires a Diameter 
> application
> > to
> >>> be created when AVPs have the M-bit set. The semantic of the M-bit
> > as we
> >>> define it today is very different from what is being 
> asked here. We 
> >>> define the M-bit as a way for the specification author to indicate
> > that
> >>> the receiving side has to implement a certain AVP.
> >>>
> >>> _______________________________________________
> >>> DiME mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/dime
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dime
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
> 
_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 3 Dec 2008 12:43:31 +0200

Hi Lionel, 

This is good input. 

Comments below: 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext 
>[email-masked]
>Sent: 03 December, 2008 11:46
>To: [email-masked]
>Subject: Re: [AAA-DOCTORS] [Dime] "Fail unless processed 
>successfully" Bit
>
>On the same topic, I think that some guidelines should be 
>provided on the handling of the M-bit when it is set for an 
>optional AVP in a command answer.
>We know how to deal with AVP with M-bit set not understood in 
>the request (e.g. use of the permanent failure error value 
>DIAMETER_AVP_UNSUPPORTED).
>But it is not described what should be the behavior of the 
>client when it receives such optional AVP in the answer.
>
>--> AVP used only for information or optional behaviour i.e. 
>nice-to-have but not critical if not understand, and may be 
>therefore ignored.

This approach is a bit different to what we previously agreed on. 

In the design team we agreed that the Command ABNF and the M-bit setting is totally independent. Here you provide different treatement when the AVP had the status of not-required in the ABNF of the Command Code. 

In some sense you bypass the extensibility rules since now you would be allowed to add optional AVPs that have the M-bit set and the current extensibility rules say that you have 

As such, I would "delete" this case. 

>--> if not understood, the request fails and a Failure indication 
>--> (Result-code) must be sent back sent back to the sender along with 
>--> the Failed-AVP AVP

In this case the  DIAMETER_AVP_UNSUPPORTED would be returned. 

>--> the handling of anwer fails and a specific command must be 
>sent back to the responder (e.g. STR or ASR) with a specific 
>reason code (if possible).

This sounds reasonable to me. 

>
>For STR/ASR generating after such error case, I was thinking 
>about using Termination-Cause AVP in STR and ASR to provide 
>specific value indication (to provide a way for the 
>server/client to know why the session is terminated)
>

I think you have a valid point. This should be clarified in RFC 3588bis. 

Ciao
Hannes

>> De : [email-masked] [mailto:[email-masked]] De la part 
>> de Jouni Korhonen Envoyé : mardi 2 décembre 2008 22:12 À : Asveren, 
>> Tolga Cc : [email-masked] Objet : Re: [Dime] "Fail unless processed 
>> successfully" Bit
>> 
>>

---

From: <[email-masked]>
Date: Wed, 3 Dec 2008 11:55:10 +0100

Hi Hannes,

See below. 

> provided on 
> >the handling of the M-bit when it is set for an optional AVP in a 
> >command answer.
> >We know how to deal with AVP with M-bit set not understood in the 
> >request (e.g. use of the permanent failure error value 
> client when 
> >it receives such optional AVP in the answer.
> >
> >*If the AVP is received in the command (request AND/OR 
> answer) and the 
> >M-bit is not set
> therefore 
> >ignored.
> In the design team we agreed that the Command ABNF and the 
> M-bit setting is totally independent. Here you provide 
> different treatement when the AVP had the status of 
> not-required in the ABNF of the Command Code. 

I agree with that. ABNF and M-bit setting are independent.

> 
> In some sense you bypass the extensibility rules since now 
> you would be allowed to add optional AVPs that have the M-bit 
> set and the current extensibility rules say that you have 
> 

All along the text, I'm assuming that we are dealing with optional AVP (in the command ABNF) that may have the M-bit set or cleared.
Here, I'm just saying that optional AVP (in the command ABNF) with the M-bit not can be simply ignored.
Sorry it was not so clear.

> 
> >
> >*If the AVP is received in the command (request only) and 
> the M-bit is 
> >set

Yes, as stated in the beginning of my mail.

> 
> >
> >*If the AVP is received in the command (answer only) and the 
> M-bit is 
> >set
> >sent back to the responder (e.g. STR or ASR) with a specific reason 
> >code (if possible).
> 
> >For STR/ASR generating after such error case, I was thinking about 
> >using Termination-Cause AVP in STR and ASR to provide specific value 
> >indication (to provide a way for the server/client to know why the 
> >session is terminated)
> >

Thx for your quick feedback.

Lionel

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 02 Dec 2008 18:09:09 -0500

Hi,

>> M-bit is set

Looks good to me as well.

-- victor

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Dec 2008 06:56:42 -0800

Some questions:

a. Does the processing in any way change based on the ABNF of the application?  For example, what happens if:

1. An AVP listed as "mandatory" in the ABNF of a Request does not have the M-bit set.
2. An AVP listed as "optional" in the ABNF of a Request has the M-bit set.
3. An AVP listed as "mandatory" in the ABNF of a Response does not have the M-bit set.
4. An AVP listed as "optional" in the ABNF of a Response does not have the M-bit set. 

b. How are RADIUS Attributes handled?  For example, how is the M-bit set if:

1. A RADIUS VSA is received. 
2. A standard RADIUS attribute is received (other than Service-Type). 
3. A RADIUS Service-Type attribute is received. 

 EMAILING FOR THE GREATER GOOD
Join me

> Date: Wed, 3 Dec 2008 10:45:47 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: Re: [AAA-DOCTORS] [Dime] "Fail unless processed successfully" Bit
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 3 Dec 2008 17:15:49 +0200

Hi Bernard, 

Let me briefly respond to the first part of your question:

Some questions:
	
a. Does the processing in any way change based on the ABNF of the
application?  For example, what happens if:
	
1. An AVP listed as "mandatory" in the ABNF of a Request does not have
the M-bit set.
2. An AVP listed as "optional" in the ABNF of a Request has the M-bit
set.
3. An AVP listed as "mandatory" in the ABNF of a Response does not have
the M-bit set.
4. An AVP listed as "optional" in the ABNF of a Response does not have
the M-bit set. 

The ABNF and the M-bit setting (+ the text around it) essentially tell
you two things: 

* What AVPs have to be transmitted in a specific command code 
  (ABNF provides that info to some extend) 

* What AVPs have to be understood on the receiving side 
  (M-bit indicates that) 
	
So, in your example (2) from above. Consider an application that says
that AVP foo is optional  ([foo] in the ABNF) in command X and that the
M-bit is set then this means that the sender may include it (typically
in certain conditions or based on configurations, or in specific
deployment situations) when sending command X. The receiver must
understand it when it receives it. 

Hence, when the receiver implementation is broken and does not recognize
the AVP (although it has to according to the specification) then an
error is generated. 

Does my response make sense to you? 

Ciao
Hannes

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Dec 2008 07:20:22 -0800

> Does my response make sense to you? 

Yes, it does.  IMHO this would be a useful thing to explain in RFC 3588bis. 
_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 3 Dec 2008 17:52:01 +0200

We have updated our desciption regarding the rules in RFC3588bis. 
I hope we did a good job. 
 
We also plan to add more text with examples in the Diameter Guidelines
document. 
I plan to have an updated version of the guidelines document within this
month. 

Ciao
Hannes
________________________________

	From: ext Bernard Aboba [mailto:[email-masked]] 
	Sent: 03 December, 2008 17:20
	To: Tschofenig, Hannes (NSN - FI/Espoo);
[email-masked]; [email-masked]
	Subject: RE: [AAA-DOCTORS] [Dime] "Fail unless processed
successfully" Bit

	> Does my response make sense to you? 
	
	Yes, it does.  IMHO this would be a useful thing to explain in
RFC 3588bis.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 3 Dec 2008 10:57:42 -0500

Bernard Aboba writes...

> 3. A RADIUS Service-Type attribute is received.

The general-case RADIUS gateway question is a bit more complicated.

The only implicitly always-mandatory attribute is Service-Type, and all
compliant RADIUS client implementations MUST treat unsupported or unknown
Service-Type values as if the packet were an Access-Reject.

There are recent I-Ds and RFCs that introduce new attributes with the
following caveats about "mandatory" behavior.

Of course, the first caveat is that the rules only apply to implementations
conforming to the document in question.  That basically means that the new
attribute is "known".  That likely means that the attribute can be supported
(enforced), at least in some use cases.  There is probably little motivation
for NAS vendors to add code to reject attributes they don't care to
implement, even though that would be a very Good Thing (tm).  Best practice
in this regard is to have a local policy configuration to control such
behavior.

The second caveat is that some attributes are explicitly mandatory whenever
the implementation "knows" them.  The NAS MUST treat the packet as if it
were an Access-Reject when the attribute cannot be [correctly] applied to
the current session (connection).

We had an interesting discussion about mandatory attributes during the early
RADIUS Design Guidelines and Extended Attributes design team
teleconferences.  The classical example is filter rules.  Any filter can be
applied if (a) the code implements that behavior and (b) when filtering is
always done in hardware, the hardware supports filtering on the requisite
fields of the packet.  Assuming there are implementations of interest
wherein filtering in "slow path" is not a viable option, for performance
reasons, then in a heterogeneous NAS population there can easily be
variability in filtering capability based on the hardware used.

If the NAS software is updated to implement a new set of filtering rules, it
may know that the hardware can only support a subset of the universe of
possible rule values.  In such cases, when a filter rule attribute is listed
as explicitly mandatory in its defining document (RFC), then compliant
software might well treat an Access-Accept packet containing a filter rule
attribute that specifies filtering behavior not supported in the hardware as
if it were an Access-Reject.

Given this kind of expectation on NAS behavior, how would such "explicitly
mandatory when known" attributes be treated when translated to Diameter?