Subject: [AAA-WG]: Indications and three-legged transactions

From: Paul Funk <[email-masked]>
Date: Tue, 01 May 2001 20:09:17 -0400

Indications are different from other types of messages in 
that they can be issued in any of three legs of a 
transaction: by the originator, by the responder, or by 
the originator after receiving a response it doesn't 
understand.

This poses a problem for interpreting the Identifier. In 
some cases, the Identifier in an Indication was 
manufactured by the sender, in some cases by the receiver. 

In the case of two-legged transactions, the ownership 
of the Identifier can at least be distinguished, since 
different Indication messages are issued by originators 
and responders.

But in the case of a three-legged transaction, it can be 
ambiguous.

An MRI can be issued by the responder if it doesn't 
understand an request AVP, or by the originator if it 
doesn't understand an answer AVP. But in both cases the 
Identifier is the one created by the originator.

Thus, when you receive an MRI, you can't tell if it's 
your Identifier or the other guy's.

For example, suppose A sends B a request with A's 
Identifier = 10 and gets an MRI in response, Meanwhile, 
B sends A a separate request with B's Identifier = 10, 
gets an answer containing an unknown AVP, and sends an 
MRI back to A. Now A has received two MRIs, each with 
Identifier = 10 and can't tell them apart.

Another problem with three-legged transactions is 
that you have to make real sure you won't respond to 
an MRI with another MRI, otherwise you'll get two 
servers with a lot to say to each other.

I'm not sure why we need three-legged transactions at 
all. When a server finds out its answer was rejected, 
what is it expected to do? Is it supposed to learn 
which AVPs the client doesn't like and make them 
non-mandatory? Is it supposed to locate the session 
that it thought had started and release it?

Better would be to have the client just issue an STR 
indicating that the session is terminated (or was 
not started). At some point a human being will have 
to notice and perform some reconfiguration.

If it is felt that debugging information at the server 
side is necessary, we should define a separate 
Indication (e.g., Reply-Reject-Indication) that the 
client issues with a completely new Identifier (that 
is, unrelated to the original request) that simply 
allows the server to log the fact that this client 
doesn't understand a particular AVP and is not 
starting sessions because of it.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 2 May 2001 14:22:43 -0700

Paul,

You bring up an interesting problem, and one does certainly does
need to be resolved. You are correct in your problem statement
below that an MRI sent in response to a bad reply will contain
an identifier that may not be recognized by the receiver.

Your proposal is to do away with the MRI, and just allow a 
response to include the proper Result-Code when an error occurs.
An if an error occurs in a Reply, that an STR should be sent to
inform the server that the session is being cleared (presumably
with some indication of why the STR was sent). 

I believe that this is a reasonable approach.

However, the original intent behind the MRI was to allow a
proxy in the chain to return an error. The proxy could, of
course, return an error using the a request's natural response,
but my thinking was that proxies may not support all extensions,
and therefore would not know what the correct command code should
be set to.

However, in my conversations with IESG and the chairs in the past
few days, we came to the conclusion that the following text
was necessary in the base protocol:

"Diameter servers MUST support the Base protocol, which includes Accounting,
and both the NASREQ and Mobile IP extensions. Diameter Clients MUST support
the Base protocol, including Accounting, and MAY support any other
extension that would be required to provide service."

So, if all servers (including proxies) MUST support all extensions, then
the problem I had originally created the MRI for (proxies not supporting
an extension) is no longer a problem. Well, this is true until another
extension is standardized.

So, I believe that your proposal is workable, and requests the rest of the
WG's comments.

Thanks,

PatC