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

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Thu, 14 Oct 1999 06:18:59 -0700

>What happens if one has a proxy situation (e.g. over two aaa proxies,
>the middle RADIUS server belonging to a broker), where some specific
>attribute needs to be send end to end, but the next hop doesn't know it.

Interesting case. There are a couple of mechanisms being talked about
in the requirements. One is end-to-end security. This allows you
to indicate that the attribute in question cannot be edited and must be
passed
along. However the question is how the endpoint can know that this
attribute can be understood by its end destination. Capabilities
negotiation won't give you this because it's only a hop-by-hop
mechanism. Since you need this attribute to be passed along, if
it is a standard one then I'd presume it would be marked
Mandatory. However, that doesn't influence proxy behavior; it 
just tells the end destination how to behave in case it doesn't
understand the attribute. So it isn't entirely clear to me that
this case is covered by what we've been talking about.

---

From: "Yves T'Joens" <[email-masked]>
Date: Thu, 14 Oct 1999 15:35:21 +0200

> this case is covered by what we've been talking about.

use of the mandatory bit indeed doesn't help here.
Note that if a 'generic' AAA protocol is in use, it would occur a lot I
presume that extensions are written to it, that may be understood by
both end points, while the 'proxy in the middle' still runs an older
version... so somehow, I think we should certainly have a look at this
requirement. As I said before, one can learn something from the way this
has been handled in ATM signalling (correct in the ITU, messed up in the
ATM forum...)

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Oct 1999 07:10:48 -0700 (PDT)

> has been handled in ATM signalling (correct in the ITU, messed up in the

One of the things that we seem to be forgetting is the fact that AAA
communication can occur over several intermediate hosts, or proxies. The way
that I view capabilities exchange is not end to end. It is VERY difficult to
do end to end capabilities exchange, especially since it would need to be done
prior to the actual auth request.

I view capabilities exchange as a hop-by-hop thing that allows two peers to
know what each other support. Let's take an example of a NAS installed in a
network with 4 AAA servers. Using capabilities exchange it could find out that
server B is to be used for Mobile IP Auth, while server A does PPP and server
C + D support accounting. Today this would have to be manually configured on a
NAS, which is administratively tedious.

Moving away from the NAS, when the AAA server talks to a broker, there may be
different servers within the broker network for each service. Similarly, when
the broker's server talks to the home network's AAA server specific servers
may perform specific functions. This is what I view capabilities exchange for,
reduction of manual configuration.

When the user dials into a NAS, the request reaches the local Server, then the
broker and finally the home server. Having the NAS perform some capabilities
exchange with the home network, in which each intermediate node needs to adjust
the capabilities to reflect their own supported extensions, makes this a VERY
difficult problem and dramatically increases the latency involved in the call
setup. This would not fly for the wireless space.

For this reason, I would prefer to have both capabilities exchange, and the
mandatory bit. The AAA protocol MUST allow a server to return an error if it
receives an unknown attribute, and it SHOULD even specify which attribute
caused the error(s). This would allow a clever implementation to try again
without using the offending attribute, if it wants to.

PatC

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Oct 1999 07:21:51 -0700

<ad hat off>

i am slow.

given that security and trust are usually end-to-end due to a long history
of middle weaknesses, why are smart (i.e. able to look at content) relay nas
devices needed?  it seems to me that they will be an ever-expanding source
of complications.

as the answer is probably obvious to all here except for me, private
education may be more appropriate than major distraction on the list.

randy

---

From: "Yves T'Joens" <[email-masked]>
Date: Thu, 14 Oct 1999 16:34:41 +0200

> prior to the actual auth request.

I did not even mention the difference between end to end and hop by hop
capabilities exchange. I know it is VERY difficult, the question is, is
it necessary.

> NAS, which is administratively tedious.

The NAS still needs to be configured on how to reach the other server
(either manually or by other means), so why not add an indication of the
server capabilities at the same time.

> setup. This would not fly for the wireless space.

Indeed in such a configuration, a sort of trial and error scheme would
be better than reaching agreement prior to attribute exchange, given
that 99% of the trials will work, while the other 1% fail.

> without using the offending attribute, if it wants to.

This imposes a bit of an configuration burden. If one imagines a
consortium of ISPs that allow roaming of any kind, then one is surely
limited by the capabilities of the broker proxy.
Let me try to give an example.
Assume within the present roaming consortium, some local ISP starts
offering QoS like services to its customers. Roaming users that have
also these capabilities at home, may request them while roaming. A
supporting local ISP may thus add to the authorization request some new
AVP (totally unknown AVP to the broker), just to indicate this (assume
these capabilities to be already 'standard' but not implemented by all
ISPs and not by the broker). 
My question is then, will they be able to pass the broker proxy ? 
The local ISP may mark the attribute as mandatory, since it is
'standard', but of no concern to the broker. It would be nice if the
local ISP could indicate in the AVP that the information has only end to
end value, and that the broker should pass it unharmed, even if not
understood.

I don't see this requirement in the present nasreq document.

Note that this is orthogonal to the issue of capability negotiation
between the two endpoints (although related).

> PatC

Yves

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Oct 1999 07:44:45 -0700 (PDT)

> server capabilities at the same time.

I thought this was my point....

> that 99% of the trials will work, while the other 1% fail.

I think that the reality of it all is that protocol extensibility via vendor
specific attributes works well intra-domain. For inter-domain cases, any
vendor specific attributes should NOT be sent. Perhaps this is the rule that
needs to be applied, and no protocol requirements would be required.

> end value, and that the broker should pass it unharmed, even if not
hmmm... well if the broker is in it for the long run, and plans to keep its
customers, it very well better start deploying new protocol extensions.
Otherwise ISPs will be forced to look for better service from another broker
(and even today we do not have a shortage of brokers).

Even having had this discussion, I am still convinced that capabilities
exchange (hop by hop) provides enough functionality to make most of the
network work well. I think that my statement above that vendor specific stuff
should be stripped when requests are sent inter-domain would ensure that we do
not run into the end-to-end problem.

PatC

---

From: "Yves T'Joens" <[email-masked]>
Date: Thu, 14 Oct 1999 17:07:03 +0200

> > "[email-masked]" wrote:
[...]
> I thought this was my point....

By that means, SNMP would be used to configure a NAS with the list of
all its peer AAA servers, while the capability exchange would be used to
see what the nature of the servers is, and the range of attributes they
support. My intention was to say, that the nature of the server could be
configured alongside its IP address. For the support of attributes, I
agree...

> needs to be applied, and no protocol requirements would be required.

I was not exactly refering to vendor specific attributes, but to all
attributes, in a world, where capabilities change and the main concern
is to have differentiation in services, and where one wants to avoid the
need to upgrade the whole network just to get some information end to
end...

> (and even today we do not have a shortage of brokers).

well....

Yves

---

From: Chip Sharp <[email-masked]>
Date: Thu, 14 Oct 1999 10:57:27 -0400

> > has been handled in ATM signalling (correct in the ITU, messed up in the
...snip...
>without using the offending attribute, if it wants to.

If the AAA protocol allows a server (or client) to return an error if 
receives an unknown attribute, why is a Mandatory bit needed?  If the 
originator of a request receives an error response for an attribute that it 
thinks is mandatory, it should be able to take appropriate action (e.g., 
clear the call, cancel the request, send an SNMP Trap, etc.).  If the two 
endpoints are so out of synch that one is using mandatory attributes the 
other doesn't recognize, it is more than just a transitory failure.

As discovered in the L2TP saga, the message from IESG seems to be "Just Say 
No" to Mandatory bits.

Chip

>PatC

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

---

From: "Yves T'Joens" <[email-masked]>
Date: Thu, 14 Oct 1999 17:15:12 +0200

> other doesn't recognize, it is more than just a transitory failure.

there is good reason for the mandatory bit. It can be used to indicate :
if you don't understand this, too bad, just throw it away and proceed.
no error messages.

> As discovered in the L2TP saga, the message from IESG seems to be "Just Say

... in vendor specific attributes...
> Chip

yves

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Oct 1999 08:16:17 -0700

> I think that the reality of it all is that protocol extensibility via
> vendor specific attributes works well intra-domain.

does this imply an assumption of intra-domain vendor homogeniety?  if so,
and if by 'domain' your mean e.g. one isp.  this is certainly not the case
in many very significant domains of which i am aware.

randy

---

From: Chip Sharp <[email-masked]>
Date: Thu, 14 Oct 1999 11:47:07 -0400

>if you don't understand this, too bad, just throw it away and proceed.

Hmm.  Perhaps someone should define "mandatory" in this discussion since I 
had a different definition of the word.  My undestanding of a mandatory 
attribute one that is required to be supported or the exchange (or call) fails.

>... in vendor specific attributes...

In the case of standard attributes, there will be attributes that MUST be 
supported (mandatory) and attributes that MAY be supported (optional). In 
the former case, a mandatory bit isn't required.  In the latter case, what 
does a mandatory bit mean?

---

From: Robert Pluim <[email-masked]>
Date: Thu, 14 Oct 1999 21:18:31 +0200 (CEST)

Bernard Aboba writes:
 > passed along.

What if one of the two servers disagrees about whether a non-editable
attribute should be editable or not? Do you drop the packet? Or do you
remove the offending attribute? (I can think of at least one real-life
example here, involving multilink).

Robert
--

---

From: Glen Zorn <[email-masked]>
Date: Fri, 15 Oct 1999 19:45:22 -0700 (PDT)

On Thu, 14 Oct 1999, Randy Bush wrote:

> does this imply an assumption of intra-domain vendor homogeniety?  

Not necessarily; however, it does, I think, imply intra-domain knowledge
of vendors (which may be essentially the same thing).

>if so,

---

From: Paul Krumviede <[email-masked]>
Date: Fri, 15 Oct 1999 20:39:37 -0700

>> does this imply an assumption of intra-domain vendor homogeniety?  

it better not. acquisitions, particularly international ones, break any such
assumption.

> of vendors (which may be essentially the same thing).

even if i have such knowledge now, it can be overtaken by events.
of course, suitable choice of the scope of a domain can make this
true by definition, but that seems to be an unproductive exercise.

-paul

---

From: Glen Zorn <[email-masked]>
Date: Fri, 15 Oct 1999 20:41:21 -0700 (PDT)

> even if i have such knowledge now, it can be overtaken by events.

True, but (in theory, at least) the effects of such events are suspected,
(if not known) in advance. 

> true by definition, but that seems to be an unproductive exercise.

Precisely why we have standards, right?

---

From: Randy Bush <[email-masked]>
Date: Fri, 15 Oct 1999 21:46:33 -0700

> true by definition, but that seems to be an unproductive exercise.

it may have been bernard who explained to me that intradomain proxy use is
really needed for facades to provide homogenity, i.e. 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.

but, in this case, we can have the differences under administrative
configuration control.  we can just say no to configuring an intermediate
proxy that will obscure what needs to be made visible.  i.e. this may not
be a problem that must be solved by protocol.

whatcha think?

randy

---

From: Paul Krumviede <[email-masked]>
Date: Fri, 15 Oct 1999 22:27:01 -0700

> of the 42 different vendors equipment we've acquired.  this makes sense.

oh, i agree that some mechanism, such as intradomain proxies, is
needed here. but it isn't always easy to hide equipment differences
for more complex services that require vendor-specific attributes be
delivered to the end box(es), such as a NAS.  Now where this vendor
specific stuff gets inserted into the response(s) going back to the
requestor is the interesting, and hard, part.  It is currently hard to
say "this caller needs a secure tunnel to gateway X" in a vendor
neutral fashion (as least as far as I know it is; I wouldn't mind being
proven wrong).

> be a problem that must be solved by protocol.

This is what I recommend where possible. As long as the
protocol(s) allow me to transport the right level of abstraction
to specify the services I want to offer (now and in the future)
I can probably make this work and push the gory detail
into the places that need to know it.

One reason for commenting on this thread is that I'm not so
sure that vendor specific attributes work all that well in more
complex intradomain situations. Administrative scoping
within a domain, with something that can do the right
intrepretation at boundaries, seems like a very reasonable
approach, but I need a reasonable way to communicate
the necessary service configuration info, and this seems to
impose requirements on the data represenation.

One reason this whole discussion can be messy is
that the scope of a domain could be considered to
align with a business (e.g. MCI WorldCom) or with
some finer granularity (e.g. UUnet and vBNS) within
the business.

-paul

---

From: Glen Zorn <[email-masked]>
Date: Mon, 18 Oct 1999 14:06:24 -0700 (PDT)

On Fri, 15 Oct 1999, Paul Krumviede wrote:

> requestor is the interesting, and hard, part.  

I have long been of the opinion that this stuff should be inserted at the
proxy closest to the NAS.

> It is currently hard to

I don't think it's _that_ hard; see draft-ietf-radius-tunnel-auth-09.txt
(delayed for many months, apparently for political reasons).