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

From: [email-masked] (Patrice Calhoun)
Date: Wed, 13 Oct 1999 08:21:09 -0700

I just took a look at the latest document, and I like it. Thanks to Mark for
the enormous effort it must have taken to get the document in shape for
the I-D deadline.

I do, however, have come up two more requirements. I am not sure that this
requirement really needs to be incorporated into a new revision before the
deadline, perhaps it can wait. In RFC 2477 [ROAMOPS], the following is stated:

    -  capabilities adjustment.  Each manufacturer's equipment has
       different capabilities.  Thus, the AAAL may have to modify the
       authorization information from the AAAH.

This is a very important requirement for two reasons:

1. In the RADIUS world, there is a proliferation of vendor specific attributes.
When a client talks to a server (or a server to another server), it has NO
idea what the manufacturer of the equipment is, and MAY attempt to send vendor
specific attributes. If both peers could know a priori what each other supports,
it would make operations that much simpler.

2. In the NASes that I am aware of, when one configures the RADIUS servers, 
one must specificy which ones is the accounting server, and which one isn't.
As new services become available, the NAS must then have additional 
configuration so it knows which server to ask for specific services. If the
NAS could get an idea of which servers should be used for what purpose, this
would reduce the overall configuration of the NAS, and again make the operations
simpler.

It would be nice if NASes could use a service discovery scheme to locate
AAA servers. Let's use SLP as an example. When a NAS comes up, it could use
SLP to locate the servers in the network. Imagine a network where one simply
installs a new server, and NO configuration is necessary on the NAS. It simply
locates the new server, and makes use of it. 

Comments?

PatC

---

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Wed, 13 Oct 1999 12:23:57 -0700

I agree with Pat.

One of the major reasons for insertion of RADIUS proxies
is capabilities adjustment. Given the different dialects
that are spoken nowadays, getting the editing right is
already quite tedious and might be likely to become
unbearable in the future if we don't do something about
it. 

There are several possible solutions:

a. Capabilities negotiation. This is the approach taken
in BGP. This approach seems to work well when there are
lots of extensions sets, thus making it likely that each side
might not be able to communicate well unless they reach
an agreement beforehand. 

b. Use a Mandatory bit as in L2TP. In this approach, typically 
only standardized attributes should be marked Mandatory, so as to
avoid potential "bullying." However, if there are sets of
standardized attributes that might not be implemented by a
client or server (as might be the case when there is a base
protocol and extension sets), then this might not work so well.

---

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Wed, 13 Oct 1999 13:09:39 -0700

If you knew that the other side could handle a capability (via
capabilities negotiation) why would you *also* need to mark
an attribute as Mandatory? Does this have something to do
with proxy editing?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 13, 1999 12:34 PM
To: Bernard Aboba (Exchange); [email-masked];
[email-masked]'
Subject: RE: comments on draft-ietf-nasreq-criteria-03.txt

Actually, I do not see the two solutions provided as being mutually
exclusive. I think that both can be used simultaneously. The former
allows for one to identify standards-track extensions, and the later
to identify vendor-specific attributes.

PatC

---

From: [email-masked] (Patrice Calhoun)
Date: Wed, 13 Oct 1999 13:21:45 -0700

>as we have learned that we can not make vendor-specific non-standard
>extensions truely mandatory, it devolves into a form of negotiation.
>
Correct. The question is whether this negotiation occurs prior to
any other AAA communication (read: bootstrap message), or on the fly 
(read: Sorry, I don't like attribute xyz). Proposal A (above) is the
former, while B is the latter.

PatC

---

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Fri, 15 Oct 1999 23:53:11 -0700

>hide a bunch of incompatible stuff so our front-end systems don't 
>have to know the kinks of the 42 different vendors equipment 
>we've acquired.  this makes sense.

Well, that is one reason proxies have been used, yes. But once
again, it is really a response to a protocol inadequacy. The
objective of capabilities negotiation should be to remove the
need to deploy a proxy for this purpose, making it possible 
for servers to talk to NASes (or local proxies) without the
need for intermediaries.