Subject: [AAA-WG]: Host-Name and Destination-NAI AVPs

From: Patrice Calhoun <[email-masked]>
Date: Fri, 9 Feb 2001 10:22:58 -0800 (PST)

All,

I would like to see if anyone agrees with me that the Host-Name and
Destination-NAI AVPs should contain FQDN, instead of NAIs. Originally, I
believe that they contained NAIs for the purposes of routing, but the
User-Name is an NAI, and in its absence the Routing-Realm can be used. So, I
really do not see a reason for making the Destination-NAI and Host-Name AVP be
an NAI. FQDNs can be used to resolve the name to an IP address, which is much
more useful.

Comments?

PatC

---

From: David Frascone <[email-masked]>
Date: Fri, 9 Feb 2001 13:05:58 -0600

I agree.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 9 Feb 2001 22:57:18 -0800

David Frascone [mailto:[email-masked]] writes:

Ditto (with the obvious name change).

---

From: David Spence <[email-masked]>
Date: Sat, 10 Feb 2001 16:11:50 -0500

> an NAI. FQDNs can be used to resolve the name to an IP address, which is much

Whoa, slow down a minute.  This sounds to me like a major change, and since
you didn't explain how it would work, I don't see how I can either agree or
disagree with it.

O.k.  Let me excercise my brain a bit and see if I can imagine what you
might have in mind and what the implications might be.

My first set of assumptions concerns how the protocol is intended to work as
specified in Alpha2.  Not all of this is actually stated in Alpha2, but
probably should be.

I assume that if the Destination-NAI AVP contains an NAI then it has the
format server@realm where "server" identifies the last hop server and
"realm" identifies the last hop realm.  Such an AVP, if it appeared in a
message of type Request or Query could be used to route the message to its
final destination.

Note:  The terms route or routing as used in this memo refer to the process
of message forwarding through a chain of proxies at the application
(Diameter) layer -- not to the activity of routing packets at the network
(IP) layer.

Similarly, I assume that if the Host-Name AVP contains an NAI then it has
the format client@realm where "client" identifies the Diameter client (e.g.,
NAS) within the service provider's realm and "realm" identifies the last hop
realm to which a message of type Indication containing the AVP should be
routed.

I assume that messages of type Response or Answer are routed using
information in either the Route-Record AVPs or the Proxy-State AVP, but that
messages from server to client of type Indication will 1) not contain
Route-Record AVPs, 2) may be routed by the information contained in the
Proxy-State AVP (if present), but 3) must contain a Host-Name AVP that can
be used for routing.

Now let me state my assumptions concerning your proposal above.

The Destination-NAI and Host-Name AVPs will contain the fully qualified
domain name (host name) of the source or destination (depending on the
message type) client or server in the proxy chain.  It may contain dots but
no @ signs.  I assume you will probably rename the Destination-NAI AVP to
something like Destination AVP, so I will use the term Destination AVP in
what follows to avoid confusion.

In the case of the Destination AVP, the FQDN will be the host name of the
host on which the Diameter server is running.  Now of course this host name
may be totally different than and might not contain any part of the
destination realm name.  In fact, it might not contain the name of any realm
used by any network.  So if a Diameter proxy has a realm routing table which
it uses to route Request messages containing a User-Name AVP, for example,
such a routing table can not be used to route on Destination AVP.  In fact,
I assume that the Destination and Host AVPs will be relatively useless for
routing purposes except perhaps for the last hop routing decision.

So my question is, how is routing supposed to work if you implement your
above proposal?

One possibility is that you could create an AVP of type Grouped that would
contain two AVPs: one indicating the realm and the other the FQDN.  The
realm would be used for routing at all but the last hop, and the FQDN would
be used for the last hop routing decision.

I don't believe that some of the messages that currently contain Host-Name
or Destination-NAI AVPs currently contain any other AVP encoding the realm
to which the message should be routed.  For example the STI message contains
no other AVP except the Host-Name AVP that could be used for routing.

I think routing on the FQDNs themselves (except at the last hop) is a bad
idea for the following reasons:

1) Creating a route table for FQDNs I think would be very difficult.  What
part of the FQDN do I route on?  With an NAI, I route on the part after the
@ sign except at the last hop.

2) Creating a route table for FQDNs is unapealing because proxies would then
need two route tables: one for realms and one for FQDNs.

3) Many different realms may be served by the same Diameter server.  I am
not absolutely sure that the routing to the server should always be the same
for all of the realms served by the server.  I can imagine that different
proxies and brokers might be involved in the chain even though the endpoint
is the same.  Even if this does not need to be the case, it may be anyway
because it will be difficult to enforce consistency between the realm
routing table and the FQDN routing table.  If the proxies and brokers keep
state information, inconsistent routing for messages relating to the same
session would be problematic.  For example, the Access-Response and
Session-Termination-Indication messages for a given session should follow
the same route.  Therefore they should use the same routing table.

Another possibility is that you could use something like the Record-Route
system for routing on FQDNs.  Then there is no need for an FQDN routing
table, and all messages of a session take the same route.  But sessions may
be long-lived, so this idea creates backup-recovery problems.

In conclusion, if I've recreated your line of thinking properly, then I
really don't like the above proposal and would prefer to keep using NAIs. 
But, of course, I may have misunderstood entirely.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 07:47:02 -0800 (PST)

> you didn't explain how it would work, I don't see how I can either agree or

Sorry that I didn't provide the justification for this change.... let's see if
I can do this here..

> specified in Alpha2.  Not all of this is actually stated in Alpha2, but

Right, and I am working on the text that will make all of this much clearer.

> message of type Request or Query could be used to route the message to its

Correct, this is the way it is currently defined.

> realm to which a message of type Indication containing the AVP should be

Correct, this is the way it is currently defined.

> Proxy-State AVP (if present), but 3) must contain a Host-Name AVP that can

Indication messages are just like request and queries. They will be routed
based on the User-Name, or the Routing-Realm AVP. The Host-Name is present,
but only for information, and no routing is performed based on this AVP.

> what follows to avoid confusion.

of course.

> routing purposes except perhaps for the last hop routing decision.

I see the confusion. The new text would state that routing of request, queries
or indication messages is done through: - Routing-Realm AVP
- User-Name AVP

When the domain portion of the AVP is determined to be local, then the server
looks for the Destination AVP to see if the message needs to be routed to a
particular server within the domain. Think of this as the difference between
forwarding a packet based on its ARP address, as opposed to routing a packet.

Now, the justification:
- All Responses and Answers are forwarded using the Record-Route AVP. The
Record-Route AVP contains an FQDN. This format allows a Server to be
dynamically discovered using DNS (or some other mechanism), but does require
that the clients file now contain a host's FQDN instead (or an IP Address
which is resolved at runtime). - Since the clients file (or the structure
created) includes the FQDN, it seems to make sense to change the Destination
to now include the FQDN, and a quick lookup in the clients entries would
determine whether the server can be contacted directly or not. An NAI would
require more work on the part of the software where it would have to dissect
the NAI, construct an FQDN, then perform the clients file lookup.

> be used for the last hop routing decision.

Sure, but the Routing-Realm or User-Name is *already* present. Why another AVP?
> no other AVP except the Host-Name AVP that could be used for routing.

<Session-Termination-Ind>  ::= < Diameter Header: 274 >
                               < Session-Id >
                               { Host-Name }
                               { User-Name }
                               { Destination-NAI }
                             * [ AVP ]
                             * [ Proxy-State ]
                             * [ Route-Record ]
                             * [ Routing-Realm ]
                            0*1< Integrity-Check-Value >

> @ sign except at the last hop.

Again, messages are not routed based on the FQDN. Messages are only forwarded
to the host, if the host in the FQDN AVP is recognized as being one that the
local server can communicate with directly.

> need two route tables: one for realms and one for FQDNs.

Right, and I agree this would be bad.

> the same route.  Therefore they should use the same routing table.

correct.

> be long-lived, so this idea creates backup-recovery problems.

Again, the Destination AVP does introduce a backup-recovery problem, and MUST
only be used when the destination is fixed. Messages like the STI fall under
this category.

> But, of course, I may have misunderstood entirely.

Now that I've cleared it up, please let me know what you think.

Thanks for the feedback, and agfain I appologize for not justifying my
proposal.

PatC

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 12:19:43 -0500

Patrice Calhoun wrote:
>... 

How about server-to-client Indication messages?  The realm in the User-Name
points the wrong way (to the home organization or server, not the service
provider or client).  The only use for Routing-Realm specified in Alpha2 was
in place of User-Name for client-to-server messages.  So how are
server-to-client messages routed?  I thought they were routed using the
Host-Name AVP which prior to your proposal contained a realm.

>...

So AVPs containing FQDNs are only used for routing at the last hop.  O.K.

> - All Responses and Answers are forwarded using the Record-Route AVP. The

You mean Route-Record AVP.

> the NAI, construct an FQDN, then perform the clients file lookup.

Yes, I'm o.k. with using an FQDN at the last hop.

> Sure, but the Routing-Realm or User-Name is *already* present. Why another AVP?

I wasn't sure they were always present.  And anyway, how do server-to-client
Indication messages get routed?

>                             0*1< Integrity-Check-Value >

Ah, but this is a totally different STI definition than the one (Alpha2) I
was looking at.  This one has both Route-Record and Routing-Realm.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 09:25:57 -0800 (PST)

> Host-Name AVP which prior to your proposal contained a realm.

check. The text reads that the Routing-Realm takes precedence over the
User-name AVP. So, for server initiated messages, the routing-realm would
contain the domain portion of the Host-name AVP for the particular session.

> So AVPs containing FQDNs are only used for routing at the last hop.  O.K.

Right, and the text must makes this very clear.

> You mean Route-Record AVP.

aaaarrrgggg... I always get this wrong :(

> Indication messages get routed?

See above. Routing-Realm gets checked first, prior to User-Name.
Server-initiated messages MUST include the Routing-Realm AVP.

> was looking at.  This one has both Route-Record and Routing-Realm.

This one was taken from
ftp://ftp.isi.edu/internet-drafts/draft-ietf-aaa-diameter-00.txt. Alpha 2 has
come and gone :)

Would this proposal work for you (assuming, of course, that it is well
documented?)

PatC

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 12:44:58 -0500

Drat.  I hit send when I meant to hit save on that last message.  I wasn't
finished with it yet.  This one contains everything the last one did, but
some more as well.  Sorry.

>                             0*1< Integrity-Check-Value >

***** Here is where I left off in the previous message.  The stuff below is
new. *****

Ah, but this is a totally different STI definition than the one (Alpha2) I
was looking at.  This one has Destination-NAI, Route-Record, and
Routing-Realm!  So apparently the Routing-Realm can be used in
server-to-client messages.  This should be stated somewhere.  How will the
server know what to put in the Routing-Realm since the transaction that
established the session contained only Host-Name which now contains FQDN,
not realm?  And does the Destination-NAI AVP here contain the home server
(source of this message) end or the client (destination of this message)
end?

Also, Route-Record is a problem here in that the rules for Route-Record
require it to be used if present.  (Route-Record provides a sort of "source
route" routing capability.)  The problem is that by the time the STI is
sent, not all of the proxies in the chain may still be up and the ones that
are up and played games with the Route-Record as specified somewhere in
Alpha2 may no longer have the state required to complete the routing?
 
> local server can communicate with directly.

O.K.  I understand that now.

> > Another possibility is that you could use something like the Record-Route

I meant Route-Record.  :)

> Now that I've cleared it up, please let me know what you think.

I think there is still a problem in the server-to-client direction.

I think that there are way too many AVPs involved in routing, but more on
that in another message perhaps.

> Thanks for the feedback, and agfain I appologize for not justifying my

O.K., Now I'll send it.

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 13:04:19 -0500

See replies interspersed below.

> contain the domain portion of the Host-name AVP for the particular session.

O.K.

> Server-initiated messages MUST include the Routing-Realm AVP.

O.K.

> ftp://ftp.isi.edu/internet-drafts/draft-ietf-aaa-diameter-00.txt. Alpha 2 has

Yeah, I know.  But you're putting in some fairly major changes.

> Would this proposal work for you (assuming, of course, that it is well

Mostly, except for some questions toward the end of the followup message I
just sent which you hadn't received yet when you wrote this.