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

From: "Daniel Warren" <[email-masked]>
Date: Thu, 13 Jun 2002 15:29:58 +0100

> > 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: Pete McCann <[email-masked]>
Date: Thu, 13 Jun 2002 10:09:25 -0500

Daniel Warren writes:
 > receive it and understand it's meaning.

Not true.  Don't confuse the 'M bit' with a "MUST implement"
requirement.  The 'M bit' only means, "if you don't understand the
VSA, you must fail the command."

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

I think Bernard's point was that failing a command is a perfectly
valid way to interop, especially for security-related commands.  If
the sender gets a failure indication, it can try something else, like
re-sending the command without the offending VSA, or giving up.

-Pete