Subject: [AAA-WG]: Comments on base draft 05

From: Jacques Caron <[email-masked]>
Date: Tue, 05 Jun 2001 22:18:11 +0200

Hi,

I've been reading though the Diameter drafts, and had a few comments. 
Please forgive me if any of those have already been discussed to death, I 
tried to check as much as possible in the issues list on the Web site, but 
since I haven't been following the list for very long, I might have missed 
some.

I understand that formal issues have to be submitted using the appropriate 
template, but given the number of comments I have, I guess a first quick 
run through on which others can give a quick word on whether the issue is 
not new would be better, to then formally submit only those that are 
actually valid? Let me know if you'd rather have me submit everything in 
the correct format directly...

===========

In 2.5.3, can a server that received a redirect cache the result (e.g. 
based on realm+application)?

===========

In 2.6/3, when using DNS, what if there are indirect relationships? Imagine 
the following:
- ISP A is a customer of roaming clearinghouse B.
- Company E is a customer of ISP D, which is a customer of roaming 
clearinghouse C.
- B & C have a "peering" relationship.

B---C
|   |
A   D
     |
     E

(the idea is to duplicate the peering/transit mechanisms of routing within 
the Internet, to reduce direct peering relationships, but still with the 
ability to have multiple competing roaming clearinghouse that talk to each 
other).

Since there are only direct relationships between A&B, B&C, C&D and D&E, 
the request must be proxied along all that path, but there is no mechanism 
to find it.

Let's say that A->B is done using a simple "default route".

I then see multiple options for B to send the request to E:
1. DNS+"backward" redirects
- The home diameter server (E) is found via SRV RRs by B, but since E 
doesn't "know" B, it redirects it to D (using some "default" mechanism)
- D points to C (ditto)
- request gets to C, which starts again, and so on until we get to E.
Has many drawbacks, amongst which there must be a way for diameter servers 
that don't know each other to talk at least a bit (not a good idea), and 
many round-trips accross the net.
Might be shortened a bit by A sending directly to B (default).

2. DNS+"backward" RRs
- B looks up SRV RRs for E
- since it doesn't know that server (in its peers list), it looks for 
another type of RR (TBD) that points to D (might be a TXT RR giving the 
realm for D)
- starts again to find C, which B knows and can forward the request to.

Probably the most elegant. May have issue with different applications, 
though (unless the server pointed to by SRV RRs is always a proxy that then 
sends to the right server for the specific application).

3. BGP-routing-like realm distribution in CER
Use the Capabilities-Exchange-Request to advertise the realm/application 
pairs that a server supports, not just applications. This would include 
realms that upstream servers support, so it could become quite large. 
Probably not very scalable.

4. BGP-routing-like realm distribution using something else
Might use other commands, a different protocol, or even use extensions to BGP?

My favorite is 2.

Note that all of this might be outside the scope of the (base) document, 
but I think it would be very useful for roaming, especially in the wireless 
(WLAN) context.

==============

In 3.1/4.1/4.5, what about reserving ranges for experimental command & AVP 
codes?

==============

In 3.2, Command ABNF:
- "fixed" isn't defined. It seems to mean that it is required, but at a 
specific position or in a specific order, but that's really unclear.
- the defaults for min & max in qual are not defined if only one of them is 
present (i.e. no qual = 1*1, but what about *n or n*? I guess the latter 
means n*infinity, but does *n mean 1*n or 0*n)?
- it says that it describes AVPs which MUST NOT be present, but that's not 
part of the ABNF (it's implicit).

===============

In 4.1, AVP Flags:
- still mentions both 'r' and reserved bits
- says that unrecognized bits should be considered an error, but also that 
r/reserved bits should be ignored.

==============

In 4.1, what about having a AVP type (OctetString, Address, etc.) in the 
header? This would be useful for logging/debugging purposes in relays that 
wouldn't need to have (up-to-date) dictionnary files.

==============

In 4.5, AVP Flag rules:
- what about a flag that isn't in any of the MUST/MAY/SHOULD NOT/MUST NOT 
categories for a given command?
- isn't there some redundancy between the "MAY encr" column and the 
position of P?

==============

In 4.3/4.4, do the AVP codes in a Grouped AVP share the same scope as those 
at "first level"?

==============

In 4.3, max length of an OctetString is still 65504.

==============

In 5.1, "the local host's identity is encoded in the Origin-Host and 
Origin-Host AVPs" (getting picky, sorry).

==============

In 5.0/5.3, it is unclear whether the Destination-Realm derivation from the 
User-Name should be done only in the NAS, or can be done by any agent on 
the way.

==============

In 5.3, Diameter agents *MAY* have a list of locally supported realms...

==============

In 5.0/5.3.4/5.6
- the use of Destination-Host for answers quite puzzles me. There's 
contradiction between 5.6 and 5.3.4 on how routing should be done (based on 
Destination-Host or Route-Record AVPs?). Using Destination-Host in any case 
would bypass relays/proxies, which would then lose the ability to track 
state, to perform accounting (especially in a roaming environment), etc. 
Not really sure it should ever be used?

- even better, the Destination-Realm should probably never be used to 
routes answers?

- Should original client add a Route-Record AVP (or Proxy-Info)? Or should 
a proxy check the Origin-Host for a loop too? How does routing back to the 
client work?

==============

In 5.3.2
- the use of MRA for redirects doesn't look "clean" to me. I'd rather 
always have an answer with the same command code as the request, with a 
specific result-code.
- loops should be checked

==============

In 5.3.3/5.0, loop checking should be done upon receipt of a message?

==============

In 6.0/5.3.1, how does a relay (which adverstised the relay application ID) 
know which commands are part of which application, if it has multiple 
upstream peers with different applications? Shouldn't the application ID be 
included in the packet header?

==============

In 5.3.4, the agent sending an STR "on behalf of the access device" is a 
violation of 5.4?

==============

In 5.3.1:
- clarify possibility of default realm (which would probably most often be 
the only realm on access devices).
- indicate multiple possible hosts for a realm, or is that handled at 
DNS/transport level?

==============

In 5.5, what's the purpose of the origin-realm? How is it defined/derived?

==============

In 5.8, isn't there some redundancy between Route-Record and Proxy-Host?

==============

Somewhere in 5, it might be interesting to include a way for diameter 
proxy/relay/server clusters to exchange state information to facilitate 
failover. This might be done by sending a copy of all received packets to 
the other node of the cluster, with either a specific flag set (so the 
other node updates its state tables, but does not act on the packet or 
forward it), or some other mechanism. Might be outside the scope of the 
spec, though.

==============

I guess that's it for today. I have a number of other issues, but they were 
against release 4 of the draft, so I have to check them against rev 5 first 
before bothering you any more :-) And thanks to all for all the good work 
that's already been done!

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:21:38 -0700

> the correct format directly...

Your proposal makes sense. Let's make sure there are issues in order to
minimize opening unnecessary issues.

See my response below.

yes, and this should probably be discussed in the base draft. Please open an issue
on this one.

Support for DNS was added in order for peers that do want to communicate directly,
and have a need to. So, in my implementation, I can state that in order to get to E
(or perhaps any domain that I don't recognize), I need to talk to a server in B. 
However, I don't have any servers setup for B, so I do a DNS query. I think 
that this is the best (and easiest) approach.

Options 2 requires that B know that C talks to D, which talks to E. It isn't clear
to me how this would be known. Certainly not in DNS, since one doesn't encode 
business relationships within DNS records. Business relationships != low latency/round trips :(

Options 3 and 4 have been discusses as research issues many times in the past few years,
but there are plenty of additional problems that arise (e.g. looping). So, if someone
believes this is necessary in the future, the protocol could be extended to support
this, but as it stands, this is a fairly large new feature to add at such a late
date.

> In 3.1/4.1/4.5, what about reserving ranges for experimental command & AVP 

Isn't the private AVP and command similar to experimental? I know that RADIUS
has such a thing, but it's never been managed properly. Look at the Status-Client
for example, there isn't a spec out there, and it is only used by a single vendor.
I believe that experimental commands made sense in RADIUS because its lack of
vendor specific commands.

> part of the ABNF (it's implicit).

Please open an issue for the above.

> r/reserved bits should be ignored.

Please open an issue for the above.

> wouldn't need to have (up-to-date) dictionnary files.

This has been discussed at length in the past, and we decided against it.
I agree that for logging and debugging, this is useful, but the format of
the AVP is required in order to process it anyways. If you don't know the
format of the AVP, simply print it as a hex value.

I you feel this is a MUST, open an issue, and we can see where this goes.

> - isn't there some redundancy between the "MAY encr" column and the 

There aren't any flags that aren't in the flag rules (or rather there shouldn't
be). P is not used for encrypting, but rather for signing.

> In 4.3/4.4, do the AVP codes in a Grouped AVP share the same scope as those 

Sorry this seems to break my parser. Could you try again? :)

> In 4.3, max length of an OctetString is still 65504.
Please open an issue.

> Origin-Host AVPs" (getting picky, sorry).

A nit that needs to be fixed. Please open an issue (btw, given that most of
these issues that I agree to do in fact need to be fixed, perhaps you want to
open a single issue, and just include all these comments). They are protocol
bugs, and need to be fixed, and not necessarily controversial enough that they
need to be tracked separately.

> User-Name should be done only in the NAS, or can be done by any agent on 

It is intentionally unclear. There are certain cases (e.g. dial-up outsourcing)
where the user-name is not know because the Diameter request is sent prior to
the call being answered. In such an example, the Destination-Realm would be 
identified via the called (or calling number).

> In 5.3, Diameter agents *MAY* have a list of locally supported realms...

Add that one to your issue.

> - even better, the Destination-Realm should probably never be used to 
MUST NOT
> a proxy check the Origin-Host for a loop too? How does routing back to the 

As long as there is a Route-Record AVP in the answer message, the agents use
the information in the Route-Record to find the next hop. When no Route-Record
is present, the Destination-Host AVP is used to forward the message to the
intended target Diameter node.

I see that 5.3.4 needs a last sentence, such as:

" Once the local Route-Record AVP has been removed, if no Route-Records 
  AVPs are present in the message, the Destination-Host AVP is used to forward 
  the message to the intended target Diameter node, as described in 5.2"

Please open an issue specifically for this one.

> always have an answer with the same command code as the request, with a 

Well I sympathize with your desire, but consensus at the interim meeting
shows that people want this approach. (I personally believe that a Result-
Code class is a MUCH better approach, and works MUCH better with the Diameter
API).

Open an issue on this if you feel this is important to you.

> - loops should be checked

Now sure why....

> In 5.3.3/5.0, loop checking should be done upon receipt of a message?

Not sure that I understand the question...

> included in the packet header?

This has been discussed, and including it in the header makes vendor specific
applications more difficult to handle. So, since the message must be parsed to
determine the Realm or Host to forward/route the message to, the application
id can be extracted at that time as well.

> In 5.3.4, the agent sending an STR "on behalf of the access device" is a 

On behalf doesn't mean that the Origin-Host is to be set to the access device's
identity. Of course, this would be broken. When sending a message, the Origin-Host
AVP is always to the local identity.

Am I missing something?

> the only realm on access devices).

open issue on this

> - indicate multiple possible hosts for a realm, or is that handled at 
The routing table definition already states that one or more server can be
configured for a particular realm. Is this not sufficient?

> In 5.5, what's the purpose of the origin-realm? How is it defined/derived?
Not sure why we decided that it was necessary, and perhaps it isn't required at
all. All operations are done on Origin-Host, Destination-Host and Destination-Realm.

Open separate issue on this requesting that the Origin-Realm be abolished.

> In 5.8, isn't there some redundancy between Route-Record and Proxy-Host?

Yes, and I had been thinking about how to add the proxy info to the Route-Record,
but doing so would require that the Route-Record be a Grouped AVP, which has 
additional processing requirements, and I prefer to keep the Route-Record
AVP as simple as possible. For proxies that insist on distributing their state
across the network, let them deal with the added cost of adding an AVP.

> forward it), or some other mechanism. Might be outside the scope of the 

Interesting, but clearly outside the scope of the base protocol :)

> that's already been done!

And likewise, thanks for the great comments,

PatC

---

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

> > another type of RR (TBD) that points to D (might be a TXT RR giving the

comes in. E would have some DNS RR that says "hey, if you don't know how to 
talk to me directly, please see with D", either directly (some slightly 
modified SRV RR) or indirectly (with a TXT RR giving the realm of D). D is 
a bit like a transit provider to E in routing analogies. Same thing would 
apply for finding C from D.

And many people encode many things about business relationships in DNS 
records. Most "hosting" cases (for NSes, MXes, As...) are quite evident in 
DNS records. Many other business relationships are visible through BGP or 
other means.

This would allow for "universal" roaming. Anyone could roam using a NAI 
very close to one's e-mail address, provided the domain has "routing" 
information to get to its Radius server via the appropriate roaming 
providers (that would do all the compensation stuff), without the need for 
a unique (badly scalable) roaming provider (or disjoint roaming "universes").

>this, but as it stands, this is a fairly large new feature to add at such 

Indeed, and they are not necessarily my favorites. Just for the sake of it, 
another issue is that of selection of the peer to use when two announce the 
same realm. We could have local weights, MEDs, communities... ;->

>vendor specific commands.

It was purely a rethoric question. Many protocols that have IANA-assigned 
ranges include experimental ranges, so I wondered if there was any 
reason/need to have those here. Probably not, then :-)

>I you feel this is a MUST, open an issue, and we can see where this goes.

Well, it certainly would not be a MUST. Would just have been nice :-)

>be).

Well, P often isn't in any column, and M isn't in any in Error-Message and 
Error-Reporting-Host.

>  P is not used for encrypting, but rather for signing.

Ooops. Have only glanced at the strong security draft yet :-(

>Sorry this seems to break my parser. Could you try again? :)

Errrr, are the numbers assigned to AVPs within a given Grouped AVP specific 
to that Grouped AVP, or should all AVP codes be unique, whether they are in 
a Grouped AVP or not?

Or, to take an example, if I have a grouped AVP (The-Famous-Host) which 
contains an AVP with code 500 (The-Famous-Port), can I reuse 500 for a 
"regular" AVP (which is not within my "The-Famous-Host" grouped AVP), or 
within another grouped AVP (The-Not-So-Famous-Host), with a different meaning?

You can see that like the enums: their name/values are specific to a given 
AVP, not to all AVPs.

>identified via the called (or calling number).

Mmmm. Maybe the unclarity should be made clear then? At some point it says 
it's done by the NAS, and then it's not so sure any more...

> > - even better, the Destination-Realm should probably never be used to

Issue? Or is that already written somewhere, other than implicitly from the 
way answers are supposed to be routed? If it is, it's unclear (the Message 
processing section should be called "Request Processing" then, and another 
section for  "Answer processing" would be needed).

>Please open an issue specifically for this one.

I will. I'm not convinced by this method :-/

>Open an issue on this if you feel this is important to you.

Not that it's so important, but it would really make the whole thing 
neater. I will combine that with my remarks on related subjects in the 
other mail.

> > - loops should be checked

A sends request to B. B says "redirect to C". What if:
- C is A
- C is B
- C is a host in the route-records?

>Not sure that I understand the question...

Instead of doing loop checking when sending a forwarded message, it might 
be simpler to always do it when the message is received (in any context: 
server, proxy, relay, redirect... as a given agent might assume different 
roles anyway). This depends a bit on exactly how Route-Record is handled, 
though (i.e. whether even a client should include it).

>AVP is always to the local identity.

Then what does the "on behalf of" mean? What exactly is set as if it was 
the access device sending it?

>configured for a particular realm. Is this not sufficient?

I should open those things called eyes sometimes :-)

>across the network, let them deal with the added cost of adding an AVP.

Mmmm. Should that be an issue?

>Interesting, but clearly outside the scope of the base protocol :)

I'll keep it for desert :-)

Jacques.

---

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

> a unique (badly scalable) roaming provider (or disjoint roaming "universes").

hmmm... ok. This very topic was brought up several times in roamops (a WG that
has since closed that I co-chaired with Glen Zorn), and was shot down. The reason
is that a DNS request is static. DNS doesn't know who is asking and this is a very
important piece of information. For example, in order for B to talk to E, it needs
to go through D, but when Z wants to talk to E, it needs to go through X.

So clearly, DNS cannot provide this information.

> same realm. We could have local weights, MEDs, communities... ;->

ok, well this is more of a research topic, and could be investigated within the
AAA WG, but once the base protocol is released. We have some pretty strict deadlines
to deal with, and cannot afford to start looking at new features (in fact, the
chairs have ruled out major new features at the Minn meeting).

> Well, P often isn't in any column, and M isn't in any in Error-Message and 

Then these should be brought up as issues. P shouldn't be set in all AVPs, btw.
Only those that are static across agents (meaning agents do not modify them in
transit).

> to that Grouped AVP, or should all AVP codes be unique, whether they are in 

They are. There is one AVP Code namespace, and it is used regardless of whether
an AVP is grouped or not.

> within another grouped AVP (The-Not-So-Famous-Host), with a different meaning?

no

> it's done by the NAS, and then it's not so sure any more...

Open an issue, then.

> section for  "Answer processing" would be needed).

5.7  Destination-Realm AVP

   The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and
   contains the realm the message is to be routed to. The Destination-
   Realm AVP MUST NOT be present in Answer messages. 
   [...]

> A sends request to B. B says "redirect to C". What if:

Then A would presumably notice that it is being told to redirect to itself.

> - C is B

Then B is clearly broken...

> - C is a host in the route-records?
Then when routing, this will be discovered.

Additional text could be added, as you state, but these are strange problems that would
be detected regardless.

> though (i.e. whether even a client should include it).

ok, but that would cause one to add a Route-Record even when the message is
locally processed. That would be most odd.

> the access device sending it?

The agent sends it, not the access device. I will change the words, if you
could create an issue (or amend the one you've already sent)

> Mmmm. Should that be an issue?

I'd prefer not, but if you insist, we can let the WG decide.