Subject: [AAA-WG]: Thoughts on the MRI

From: Patrice Calhoun <[email-masked]>
Date: Thu, 1 Feb 2001 14:41:15 -0800 (PST)

All,

In the process of coding, and implementing certain error conditions (e.g. no
route to realm), I have found that the use of the MRI is somewhat vague.

I believe that the MRI should ONLY be used to return an error to the peer one
hop away, and should not be a routable message.

Let's say that a secret between two peers is broken, you wouldn't want the MRI
message to make it back to the NAS, since it wouldn't know what to do with it.

Similarly, if timestamps, or something else in the packet (e.g. version
number) is bad, the NAS wouldn't be able to do anything about it.

Therefore, I believe that I would like to add LOTS of clarifying text to the
MRI section to state that this is for PEER to PEER errors (and define those
errors separately).

For end-to-end, a request's corresponding response is to be used.

Does this make more sense?

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 1 Feb 2001 15:21:58 -0800 (PST)

Just to re-inforce the message, let me state another example.

NAS---->ProxyA----->HomeServerA
          |
          |-------->HomeServerB

NAS Send a request to ProxyA, which is forwarded to HomeServerA. HomeServerA
does not support the extension (but it would if it was active as a proxy --
see previous mail from Barney), and therefore returns a
DIAMETER_UNSUPPORTED_EXTENSION error back to ProxyA. If this was a result
code, in the appropriate response command code, it would be returned to NAS,
which wouldn't be able to do anything with it. However, if it is an MRI, it
would indicate to ProxyA that another server within the same domain should be
tried.

Here's another example. 

           +----> Redirect Server
           |
NAS----->ProxyA------>HomeServerA

In this case, ProxyA forwards the request to the Redirect Server, which
returns a redirect indication. Now, if this would be in the normal request's
response message, it would be forwarded to the NAS, which would deny access to
the user because of an error (or realize it is a redirect, and attempt to talk
to the home server). A good implementation would do the latter, but it is
possible that some NASes not be allowed to talk directly to home servers.

However, if the redirect is returned in an MRI, then ProxyA would know to take
action, notice the redirect, and do what's necessary.

Hopefully the above examples will provide enough justification for hop-by-hop
error handling.

PatC
> Let's say that a secret between two peers is broken, you wouldn't want the
> MRI message to make it back to the NAS, since it wouldn't know what to do
> with it.
>

---

From: Barney Wolff <[email-masked]>
Date: Thu, 1 Feb 2001 19:44:43 -0500

I'm not getting it.  How would error-handling ever be end-to-end,
other than by a proxy deciding that it's not profitable to retry
to another server?  Yes, a proxy is forbidden to turn a reject
into an accept, but we can't stop a proxy from retrying to
another server to which it can legally send the request.

I can recount a case at a "large national ISP" where the proxy
was instructed to do just that, because the primary server was
the secondary for the user database, and a reject might mean
that a new user's record had not propagated to it yet.  So
every reject was retried to the backup server.  I don't claim
that was sane and it was not my decision; management insisted.

That's why we introduced (at least I think we did :) the distinction
between transient and permanent reject codes, so the server can
give a clue whether retry is a good bet.  In the above case it
would not have helped, but that was definitely an aberration.

Barney

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 1 Feb 2001 16:54:29 -0800 (PST)

Let me try again.

Does it make sense to restrict the MRI message from being proxied? This means
that the MRI would be a "server alert" sort-of message. An indication that the
server receiving this has some work to do. A normal response, with a failure
Result-Code, wouldn't really require that the proxy perform any local action.
This is especially important for dumb proxies that just... route.

However, having read your response, I see that there are some servers that
actually take action when failures occur. I wasn't aware of this.

ok, so my argument is limited to a small number of errors (e.g. MD5 on message
failed, unsupported transform, timestamp bad, unsupported version, extension
unsupported). These errors shouldn't be forwarded to the NAS. My point was
that I wanted to make sure this is true, and it seemed that the MRI was the
way to go.

Do you have any other suggestions?

PatC

---

From: Barney Wolff <[email-masked]>
Date: Thu, 1 Feb 2001 20:24:22 -0500

Well a proxy getting an MRI owes *some* response back to the NAS,
unless it's retrying and that only delays the response.  I
certainly agree that relaying the MRI itself back is wrong.
Isn't there a "trouble downstream" failure code/response?

Barney

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 1 Feb 2001 17:47:57 -0800 (PST)

> Isn't there a "trouble downstream" failure code/response?
DIAMETER_UNABLE_TO_DELIVER is what you are looking for. However, I was sort-of
hoping that dumb routing proxies wouldn't have to inspect each message (at the
extension level) to figure out what to do.

I suspect that we may not have much of a choice.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 1 Feb 2001 19:07:18 -0800 (PST)

So given the text below, I believe that some new text must be added to "6.4.2 
Proxying Responses" that states that proxies MUST look at the Result-Code AVP
to figure out whether it should attempt to take some additional action.

However, there are only certain types of errors that proxies should care
about. Perhaps these errors should belong in their own (new) class?

I think this would be the simplest way to fix the problem.

Comments?

PatC
> DIAMETER_UNABLE_TO_DELIVER is what you are looking for. However, I was
> sort-of hoping that dumb routing proxies wouldn't have to inspect each
> message (at the extension level) to figure out what to do.
>

---

From: Barney Wolff <[email-masked]>
Date: Fri, 2 Feb 2001 10:52:19 -0500

I think if the server separates errors into "I don't like the user"
and "I'm in trouble myself" classes it would help.  Anything
fancier should be a proxy implementation decision that we don't
need to specify.
Barney