Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 13 Jun 2002 15:52:31 -0400

I think a point Randy made is being missed -- one I've heard before in the
SIP arena.  It's OK for VSAs to be marked mandatory, and it's OK for the
receiver to send back an error indicating a VSC or VSA was not understood.
What is then required is that, under these circumstances, the message
originator is able to fall back to an operation where it does not use the
VSA or VSC concerned.  Yes, this means loss of service, but that is the gist
of what Randy said would be required.

-----Original Message-----
From: Warren, Daniel [MDN05:EP10:EXCH] 
Sent: Thursday, June 13, 2002 10:30 AM
To: 'Bernard Aboba'
Cc: [email-masked]
Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's

> > Case 1 - Extending an IETF defined command by adding a Vendor Specific
AVP 
> > In this case, the AVP has to be optional.  Setting the Mandatory AVP bit

> > would mean that all implementations would have to support this AVP in
the 
> > command and so that would no longer be vendor specific, but would rather
be 
> > a requirement. 
> 
> Why is this true? Vendor extensions relating to security need to be 
> mandatory or security is compromised. We saw this with RADIUS when vendors

> added support for explicit filters, and NASes that didn't understand them 
> did a silent discard, resulting in networks being provisioned without 
> filters, with no error message to the AAA server. 
An example.  Vendor A implements a Vendor Specific AVP.  For whatever
reason, this AVP gets sent to a peer made by Vendor B, which does not
understand or recognise this AVP (because it is identified with Vendor A's
vendor-id).  For interoperability, Vendor A's AVP must not affect the
successful undertanding of the command by Vendor B's equipment.  Therefore,
the AVP must be optional so that Vendor B's equipment is allowed to ignore
it - if it were mandatory, Vendor B (and any other vendor's) equipment would
have to be able to understand the AVP else the command would fail.  That
means the AVP is no longer vendor specific, because every vendor has to
implement it because it is a mandatory requirement.
> 
> > Case 2 - Vendor defines a Vendor Specific Command 
> > Within this command, the vendor is able to set Mandatory AVP's. 
> No! Vendor Specific Commands are a last resort 
I agree! 
> , since they require new 
> code on the AAA server, whereas vendor-specific AVPs (mandatory or not) 
> can often be added to the dictionary. So the result of using a VSC instead

> of a mandatory vendor-specific AVP is that only the vendor's Diameter 
> server can be used with their NAS. 
Not if the command is optional.  Again, if vendor A's server has implemented
a command that it uses towards vendor A's NAS and also towards vendor B's
NAS as well, it will advertise that capability in the CER.  Vendor A's NAS
will respond with the command code confirming support of the VSC, whilst
vendor B's NAS will not. The VSC is not allowed to affect interoperability,
so Vendor A's server and Vendor B's NAS still have to be able to work
without the VSC of vendor A.  Therefore the VSC has to be optional.
> 
> > That would 
> > indicate that if the Command is supported on an implementation, the AVP
has 
> > to be present.  However, the command as a whole has to be optional so
that 
> > it does not violate interoperability with other vendor's
implementations. 
> 
> I don't see how a legitimate VSC can be optional. If it truly represents a

> new kind of service, then either the AAA supports that service or not. 
> However, I can see an unsolicited VSC sent from AAA server to NAS being 
> optional. 
For interoperability, operation has to be able to continue when VSC or VSAVP
are ignored by the receiving node if that node does not understand them.
Therefore they must be optional.
> 
> > These two points seem obvious to me, but I think the discussions of the
last 
> > few days have shown some confusion about what a vendor can and cannot 
> > reasonably define and implement in terms of extensions to Diameter. 
> 
> 
> > Fundamentally, the rule has to be that no peer is obliged to implement
any 
> > vendor specific extension, be it an AVP, Command, or entire application.

> 
> I don't agree with this interpretation - the spec allows (and even 
> encourages) use of vendor-specific AVPs instead of vendor-specific 
> commands and applications. VSAs can be mandatory. 
If a VSA is mandatory, then every vendor's equipment has to be able to
receive it and understand it's meaning.  If every vendor has to implement
the VENDOR SPECIFIC AVP, then it isn't vendor specific anymore, it is vendor
agnostic.
The only other way I can conceive of making my point is to ask what the
situation is with an AVP, marked as mandatory, which is defined in an IETF
Diameter Application.  If a server sends this to a NAS, the server must be
able to expect the NAS to understand it.  If the NAS doesn't understand the
AVP, then because the AVP is essential to the operation (else it would not
be marked as mandatory), the command would fail.  Similarly, by allowing a
VSA to be mandatory, the server  must be able to expect the NAS to
understand the VSA.  If the NAS does not understand the VSA, again it has to
fail the command, because if the VSA was not essential to the operation, it
would not be mandatory.  But to maintain interop, the NAS has to be able to
complete the command without the VSA.  Hence there is a contradiction in the
logic.  Mandatory implies understanding, but interop requires it to be
ignored.  You can't have both.

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Jun 2002 13:07:00 -0700

> I think a point Randy made is being missed -- one I've heard
> before in the SIP arena.  It's OK for VSAs to be marked
> mandatory, and it's OK for the receiver to send back an error
> indicating a VSC or VSA was not understood.  What is then
> required is that, under these circumstances, the message
> originator is able to fall back to an operation where it does not
> use the VSA or VSC concerned.  Yes, this means loss of service,
> but that is the gist of what Randy said would be required.

the iesg was willing to eat this particular bit of dog food a few
years back.  while i can not promise it will meet their appetites
today, it's worth a try.  the point is that blame for failure MUST
clearly be with the requestor of the non-ietf standard extension.
and making this very clear, with no weasel words, just could squeak
by.

"do you do frobnitz?"
"nope, sorry, i do not"
"oops!  sorry, did not mean to offend"

randy

---

From: David Frascone <[email-masked]>
Date: Thu, 13 Jun 2002 15:29:49 -0500

I think such a requirement is very reasonable.

-- 
David Frascone

         Put the cat out? I didn't know it was burning!

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 14 Jun 2002 09:59:03 +0200

It's reasonable and isn't it something we have today.

If a vendor A sends a Vendor specific AVP with the 'M'-bit marked to vendor
B, vendor B either understands it and is happy or doesn't understand it and
sends an error back and denies the service. In the latter case, Vendor A is
then the one to blame and has the option to try to request the service
without the AVP (ofcourse with a different service as result) or to give up.

/fredrik

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> David Frascone
> Sent: den 13 juni 2002 22:30
> To: Tom-PT Taylor
> Cc: Daniel Warren; 'Bernard Aboba'; [email-masked]
> Subject: Re: [AAA-WG]: Mandatory Vendor-specific AVP's
>
>
> before in the

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Jun 2002 05:45:48 -0700 (PDT)

I agree that this is worthwhile, and it is something that is possible in
Diameter that was not possible in RADIUS (since RADIUS had no error
messages). It preserves interoperability, and yet also enables
extensibility.