Subject: [AAA-WG]: More comments on base draft 05

From: Jacques Caron <[email-masked]>
Date: Wed, 06 Jun 2001 02:09:53 +0200

Hi,

Me again... I have some more :-)

==========

What about having a bit in the header flags to indicate that this message 
should not be proxied, but only handled locally? This would enable a 
relay/proxy to recognize messages it doesn't know about that it's supposed 
to handle (and complain about it?).

[I'm really in favor of having relays be able to do as much as possible 
while knowing as little as possible about the specifics of any application, 
command, or AVP].

==========

For answers, since in most cases (other than the (in-)famous MRA) the 
command code is the same as the request, we have a bit to distinguish 
requests from answers, and the result-code is mandatory, why not simply put 
the result-code in the command code field?
The distinction between protocol and application errors could then be done 
either based on the result-code (protocol errors are in the 3xxx range) or 
using the proxy/local flag above...

==========

Regarding loop detection, I think the text should specify exactly how host 
matching is done: based on host descriptor (text), name+port, IP+port, any 
of the above...

==========

Back on the routing of answers: if one admits we forget about 
Destination-Host to make sure the answers travels the same path back, 
should a proxy use the route-record AVP, or send it back on the same 
connection it received the request on (and which it saved in the 
transaction state table, or in Proxy-State AVPs)?
If route-record, then it should be checked on receipt that it matches where 
the message was received from?
Alternatively, it could be decided that the route-record AVP is added upon 
_receipt_ of a message, not when forwarding it. Which elimites the need for 
a NAS to insert it.

=========

I have only glanced at the NASREQ & Mobile-IP applications, but I really 
wonder why there is any need for separate Auth Request commands? I think 
the protocol should be streamlined as much as possible by limiting the 
number of commands (in too classes: those that are used for local hop 
interactions: Capability Exchange, Device Watchdog...; and those that are 
used for end-to-end requests: Auth req, Acct start, Acct stop...; the 
difference being made with the flag mentionned earlier). The difference 
between different types of auth requests would then be indicated by an 
application Id in the command header (which is way more efficient than a 
Auth/Acct-Application-Id that is mandatory anyway).

Having standard auth and acct commands also permits relays to make the 
difference between auth and acct commands for routing purposes (when a 
downstream server advertises Auth capability and another Acct capability 
for a given Application Id), without having to check 
Auth/Acct-Application-Id presence which have complex rules that are not 
stated anywhere (only one of them should be present, obviously).

========

Some minor nit-picking:
- in 6.0, Device Reboot should be changed to whatever is the new name of 
those messages
- in 6.0 first paragraph, there is a "first", but no "next" or "then" or 
"second"...
- in 6.1, "Relay and redirect agents MUST advertise the *Relay* application..."
- in the same paragraph, Device Reboot again
- in the next paragraph, it should be upstream, not downstream.
- in 7.2, the RTT/RTO stuff isn't used anymore?
(didn't go through all the state machine, but there are plenty of DRIs and 
such in there)

========

In 9.0, what happens if there is no alternate to send the request to? 
Should the MRA be forwarded upstream? As-is? With stuff changed 
(Origin-Host, Hop-by-hop, End-to-End Ids...)?

========

In 9.0, in the result-code AVPs that require Failed-AVPs, need a 
clarification whether this is done only by the home server, or by any 
proxy/relay on the way

========

In 9.0 still, what about errors regarding invalid length (packet or AVP)? 
Especially for AVPs, since it will be difficult to include a correctly 
formatted AVP if length is wrong anyway?

========

Which raises another question: what about a Grouped AVP with M not set 
containing AVPs with M set? Yes I know I have silly questions.

========

In 5.3.2/9.1:

Unless I'm blind (which could be true), DIAMETER_REDIRECT_INDICATION is not 
defined.

========

In 9.1.3:
- as stated above, a separate class for protocol errors is redundant with 
the use of MRA.
- what's the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in 
which case is which sent?
- any specific messages for DNS errors (transient such as timeouts, or 
permanent such as NXDOMAIN)?

========

In 9.1.4/9.1.5:
- should AUTHENTICATION_REJECTED and USER_UNKNOWN really be different? I 
guess that's the usual tradeoff security (having only one prevents an 
attacker to find active accounts on which to focus) against 
user-friendliness...
- the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED 
is, er, unclear.
- NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in 
Protocol errors?
- missing errors for message or AVP length errors

=======

In 10.0 third paragraph, "If the server does not receive another 
authorization request before the timeout occurs", I guess some leeway for 
transmission and processing delays would be a good thing :-) The other 
option is to use Authorization-Lifetime only as a "Reauth timer", and 
Session-Timeout as the max length after which the user is to be 
disconnected and forgotten (and even then, keeping state a tad more to 
match the accounting stop info that is supposed to arrive would still be a 
good idea).

=======

In 10.3 second paragraph, an example of a reason to have multiple 
Session-IDs in the same message would be good.

=======

In 10.7, the STR should be sent along the same path as previous requests, 
not directly to the server (by using Origin-Host of the auth answer as 
Destination-Host), for proxies along the way to be able to update state.

More generally, again, I really find the Destination-Host AVP very annoying 
and probably not very useful, except for unsollicited requests from the 
server to the client, and even in those cases, something should be done to 
make sure proxies along the way are aware of what's going on. The other use 
would be to make sure the STR goes to the same server that authorized the 
connection, but it should apply to all intermediate proxies/relays too, so 
it should be based on some other mechanism.

Anyway, in many cases it simply won't be possible to use Destination-Host 
because of the lack of security associations between the two endpoints...

=======

In 12.3, still a -Ind command.

=======

Isn't there some redundancy between STR and an Accounting-Request with 
type=STOP?

=======

15.1.2 is not up to date (bit numbers)

15.4 does not include protocol errors

=======

I guess that's it for the second round... Again, my apologies if any of 
anything has already been discussed, is already a known issue, or is not 
relevant, just tell me which ones would be in that case, so I can fill in 
formal issue templates for the others.

Thanks,

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 6 Jun 2001 10:41:44 -0700

> while knowing as little as possible about the specifics of any application, 

Well, the protocol already states that it the Destination-Realm is NOT in
a message's ABNF, then it isn't proxiable, but perhaps something more explicit
for dumb relays?

Open an issue...

> using the proxy/local flag above...

This would break the API, and I really don't like it much. I think that 
the command really needs to be maintained across answers.

> matching is done: based on host descriptor (text), name+port, IP+port, any 

ok, open an issue

> _receipt_ of a message, not when forwarding it. Which elimites the need for 

ok, if that will make it clearer, please open an issue.

> stated anywhere (only one of them should be present, obviously).

The way the messages are handled in both NASREQ and Mobile IP are vastly
different. The command ABNFs are different, the behavior of the command is
different, etc. I think that streamlining would only cause additional
confusion, and complexity in implementation.

I would prefer we keep it the way it is now.

btw, if a new service is provided, and an existing Diameter application may
be used, then we do encourage that new AVPs be defined, and existing work
be used.

> (didn't go through all the state machine, but there are plenty of DRIs and 
Add this to your large nits issue

> (Origin-Host, Hop-by-hop, End-to-End Ids...)?

send back towards originator of the request.

> clarification whether this is done only by the home server, or by any 
hmmm... ok. open issue.

> formatted AVP if length is wrong anyway?
open issue

> containing AVPs with M set? Yes I know I have silly questions.

that's not a problem. If any AVP has the 'M' bit set, and it isn't recognized
then the behavior is well defined. It doesn't matter whether an AVP is
encapsulated in a group or not.

> Unless I'm blind (which could be true), DIAMETER_REDIRECT_INDICATION is not 

darn..... issue

> - as stated above, a separate class for protocol errors is redundant with 

yes, and I'd prefer to see MRA eliminated, rather than the class

> which case is which sent?

I know the domain, but cannot reach any servers. I don't know the domain.

> permanent such as NXDOMAIN)?

I'd prefer we not have any, buy if you feel it is necessary, please propose
some text.

> attacker to find active accounts on which to focus) against 
Right and it is up the server's policy to determine which error it wishes to
return.

> - the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED 

issue.

> - NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in 

except that protocol errors MUST only be used in MRA... see the problem :)

> - missing errors for message or AVP length errors

issue

> match the accounting stop info that is supposed to arrive would still be a 

Sorry I don't understand. Your other option is exactly the way the protocol
is defined. btw, I don't get the accounting stop thing. 

please try again...

> Session-IDs in the same message would be good.

The Accounting Poll command (which I believe we will eliminate), and the
Resource Management (which is not a WG work item), as well as batched
accounting. Since none of these are either supported by the protocol,
or a WG work item, we can eliminate this sentence.

> Destination-Host), for proxies along the way to be able to update state.

hmmmm... don't know how this can be achieved.

> because of the lack of security associations between the two endpoints...

I am not sure that I understand where this is leading....

> In 12.3, still a -Ind command.

and I had to keep it in the spec until the issue was closed. I didn't want to
create a new command set with the possibility of the command being eliminated.

> Isn't there some redundancy between STR and an Accounting-Request with 

no. Unlike RADIUS, Diameter doesn't rely on accounting messages to maintain state.
The STR message is used instead.

> 15.4 does not include protocol errors

Add these to your large nits issue

Thanks again,

PatC

---

From: Jacques Caron <[email-masked]>
Date: Wed, 06 Jun 2001 22:11:31 +0200

>a message's ABNF, then it isn't proxiable, but perhaps something more explicit

I thought in some cases the Destination-Realm could be added by a proxy? :-)

>the command really needs to be maintained across answers.

Haven't looked at the API yet (it's in the pile of drafts on my reading 
list though), but will come back as soon as I have read it ;->

>send back towards originator of the request.

With what processing? Since it's supposed to be handled locally, it 
probably shouldn't be forwarded as-is? Note that I think there is another 
discussion on the Error-Reporting-Host AVP that would be related.

>encapsulated in a group or not.

Not possible. Imagine a server receives an AVP it doesn't recognize, but is 
not marked M. It ignores it. Bad luck, it was actually a grouped AVP (which 
the server doesn't know since it doesn't recognize the AVP, and there is no 
AVP type) with an AVP with M set somewhere in it. I would say one should 
not be allowed to put an 'M' AVP within a non-'M' grouped AVP?

>yes, and I'd prefer to see MRA eliminated, rather than the class

I concur.

>I know the domain, but cannot reach any servers. I don't know the domain.

Mmmm. Needs clarification?

>I'd prefer we not have any, buy if you feel it is necessary, please propose

I understand that it's an indirect error and that we don't want to have all 
values of errno around, but I think those would be quite helpful for 
debugging purposes...

>except that protocol errors MUST only be used in MRA... see the problem :)

Get rid of MRA :-) Or define a "class" of inter-server requests with can 
have protocol errors in their answers, and end-to-end requests which 
cannot? Which amounts to my local/non-proxyable flag ;->

>is defined. btw, I don't get the accounting stop thing.

Well, Authorization-Lifetime is a timer for doing a Reauth. But Reauth is 
not instantaneous, so everybody maintaining state (stateful proxies and 
servers) should not forget about that session when Authorization-Lifetime 
expires (as stated in the draft), but only when Session-Timeout expires, 
which should be larger than Authorization-Lifetime.

And for the accounting stop, if for some reason the server wants to match 
that record with an existing connection (which just finished), it should 
keep information about that connection a little bit longer than 
Session-Timeout to make sure it's still there when the accounting stop 
message arrives.

Clearer?

>or a WG work item, we can eliminate this sentence.

Issue?

>hmmmm... don't know how this can be achieved.

Just don't send it to Destination-Host, but leave it to be routed exactly 
like the auth request for that session (based on Destination-Realm and the 
routing tables)?

>I am not sure that I understand where this is leading....

Well, get rid of Destination-Host :-) Always do hop-by-hop routing based on 
Destination-Realm. Still a problem with unsollicited requests, though, 
unless the server (as well as proxies that hide topology) remembers 
route-records for requests from that host, and we have source routing. Urg.

>The STR message is used instead.

Maybe a note about that somewhere would be useful so that people with a 
Radius background understand that? Unless it's already there and dear 
precious eyes failed to take notice of it of course :-)

>Thanks again,

Terrible what a "naïve" review of a document seemingly close to conclusion 
can do, eh? Sorry about that and coming so late in the discussion. :-(

And I'll send in all the mentionned issues.

Thanks,

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 6 Jun 2001 15:43:51 -0700

> I thought in some cases the Destination-Realm could be added by a proxy? :-)

or modified by a proxy

> discussion on the Error-Reporting-Host AVP that would be related.

Well, proxies are requested to take action, but if they cannot, the message is
sent downstream towards the access device, as in any other answer message.

> not be allowed to put an 'M' AVP within a non-'M' grouped AVP?

ok, fair enough. Then please open an issue on this one.

> Mmmm. Needs clarification?

open issue. Again, a single issue with all of these clarification requests
is sufficient. This is not intended to be too much of a burden, but we have
decided that we need to track all changes going into the document, and the 
chairs have decided that opening an issue is the best way.

and it works for me...

> Session-Timeout to make sure it's still there when the accounting stop 

right which is why we have the following in the base:

10.4  Authorization-Lifetime AVP

   [...]
   If both this AVP and the Session-Timeout AVP are present in a
   message, the value of the latter MUST NOT be smaller than the
   Authorization-Lifetime AVP.

> >or a WG work item, we can eliminate this sentence.

yup :(

> like the auth request for that session (based on Destination-Realm and the 

We were there about a year ago, and this was removed from the protocol.

> route-records for requests from that host, and we have source routing. Urg.

Again, this was in a version of the draft, and was removed from the protocol
at the request of the WG.

> precious eyes failed to take notice of it of course :-)

ok. I thought that the STR made this obvious, but you are correct :)

> can do, eh? Sorry about that and coming so late in the discussion. :-(

Actually, such a review was *exactly* was we needed. Many of us have been too
close to this for a while, and some fresh eyes helps alot.

> And I'll send in all the mentionned issues.

Most appreciated.

PatC