Subject: RE: comments on draft-ietf-nasreq-criteria-03.txt

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Sun, 17 Oct 1999 06:52:38 -0700

>> Suppose someone is dialing in to an ISP that is not his home one. The
>> AAA request for him goes to his home ISP via a broker. There is a
>> contract in place between the two ISPs, but it does not cover
>> multink. The home server returns an accept with a Port-Limit of 2,
>> say, and marks it as non-editable (otherwise someone intermediary could
>> increase it). The intermediate broker wants to change this Port-Limit
>> to 1, since it has no contract covering multink in place, but it
>> can't, since the attribute is non-editable.

>why does the broker care?  the two end systems make the decisions and
>the broker merely has to help the client find the authentication and
>authorization server.

Yes, I think that the issue is not really the broker here, it is that
the server and client have a way of coming to agreement on the values
of parameters. Today in RADIUS there are no error messages, and thus
no way for the NAS to say "sorry, can't do Port-Limit=2." Note that
this is a distinct problem from the ability to understand the
attribute, since it is the *value* that is unacceptable, not the
attribute itself.

---

From: Randy Bush <[email-masked]>
Date: Sun, 17 Oct 1999 08:02:03 -0700

> attribute, since it is the *value* that is unacceptable, not the

if broker != proxy, this kind of stuff becomes irrelevant, yes?

randy

---

From: John Vollbrecht <[email-masked]>
Date: Sun, 17 Oct 1999 23:27:33 -0400

> attribute, since it is the *value* that is unacceptable, not the

Seems to me that there are several issues here.

There is the negotiation issue -- does the protocol need to be able to allow
the nas or an intermediate broker say - "you can have one port, not two - will
you take a connection with one port?"

Another issue is the semantics question - what if a NAS vendor comes up with a
new feature and wants to let the user specify how it is to be configured,  how
does the vendor let the user do that without an inordinate amount of
beaurocratic hassle?  The Vendor specific attributes are a way to do that.
Other ways have been suggested.

Then there is the issue that the broker might want to offer a generic service
with attributes different than what is provided by the NAS.  For example it
might want to include a "huntgroup" attribute or a "charge class" attribute.
Such a broker might also want to have a single set of attributes which it
translates into appropriate NAS specific attributes.  The common example for
this is the filter setting - which is implemented differently by NAS Vendors.
A broker might have its own way of allowing users to specify a filter and then
translate that into what is needed by each NAS that it supports.

Then there is the issue that has been discussed a lot on this list already --
how do you handle the situation where one server does not understand an
attribute sent by another.  This could be handled in a number of ways. 1) one
way is to outlaw this by requiring all servers to negotiate with each other
about which attributes it understands, and sending anything it doesn't
understand is cause for dropping its association with the other server.  2)
another approach is to have a "mandatory" bit which is set by a sender if it
expects the receiver to understand the attribute.  The request is refused if
the receiver does not understand.  3) Another approach is to have the receiver
return a "conditional" acceptance with the caveat that it didn't understand
what the attribute meant, so if it was important the sender should not allow
the acceptance to go through.   This is a complicated situation, made even
more complicated by having the possibility of intermediate brokers between NAS
and user server.  I think this is a very important issue for the ng aaa
protocol, and any proposed solution needs to be well thought out and have well
documented the way it will work for a varitey of inter-organization AAA
environments.

John.