Subject: RE: [AAA-WG]: A proposal for the elimination of MRI and comments on -03.

From: Yiwen Jiang <[email-masked]>
Date: Fri, 4 May 2001 14:36:06 -0400

Hi Pat,

> 2. Unknown command code.
> 
> 	This error occurs when a proxy receives the message, but has no
> 	servers that supports the extension in the home domain. The
> 	initial reason why the MRI was used, instead of the natural 
> 	request's answer, was that the proxy may not recognize the
> 	request, and wouldn't know what to set the command code to.
> 
> 	However, in -03, it is now mandatory that servers support
> 	all extensions, so it is now possible for the proxy to
> 	simply return the natural answer with an error condition stating
> 	that the message couldn't be delivered. 
If the servers all support all extensions, why would proxy return an error
and couldn't deliver the message?
 
> 3. AVP marked mandatory is unsupported.
> 
> 	This error can occur in two directions; towards the home domain
> 	(request) and towards the NAS (response) [note, of course for
> 	server initiated messages, this would be inversed, but I am just
> 	using this terminology for clarity].
> 
> 	If a proxy had received a request, and it contained an 
> unrecognized
> 	AVP with the 'M' bit set, it would have to return an 
> error. Again,
> 	since servers must support all extensions, the proxy can now
> 	return the natural answer with the Result-Code AVP set to the
> 	correct value.
> 
> 	If a proxy had received an answer, and it contained the same
> 	error, the proxy would have to overwrite the Result-Code AVP
> 	with the local error. This means that the Result-Code AVP MAY
> 	appear more than once in a message. I would also prefer to
> 	see the Result-Code combined with the Error-Reporting-FQDN AVP.
> 	Perhaps this is needed as a Grouped AVP?
I agree that a group AVP is a better way to do this.

> 	So now a NAS would have to look at more than one 
> possible Result-
> 	Code AVP, and if one contained an error, it would have to
> 	reject the answer.
Maybe this already has been discussed before, but why MUST a proxy care
whether it supports some AVPs for messages that is not destined to itself? I
mean shouldn't a proxy first checks to see if a message's Destination-FQDN
is itself, and if no, just simply forwards the message, and not care for its
contents? The AVP supportability check would be only relavent and conducted
by the end servers, no?

> 	Now a new problem presents itself. How does the home server know
> 	that the answer was rejected? We can do one of two things:
> 
> 	1. Introduce a new -Ind message that is used to inform the
> 	   home server that an answer was bad, and therefore ignored.
> 	   This is hard, and has the same issues as the MRI one that
> 	   were discussed on the list.
> 
> 	2. Have the NAS issue an STR, with a Termination-Cause. This
> 	   seems to be the best approach.
But if this is the case, how is a peer to peer connection separated from a
user session connection? From what I understood so far on the base protocol,
peer connections and session connections are two separate entities. when a
server is proxying a request, it would/should use the peer to peer
connection, right? How would the receipt of STR from NAS tells the server
that one of the messages it sent via the peer connection is rejected?

On another note, maybe I am completely reading this wrong, but it is my
feeling that as the base protocol evolves, the peer connections and session
connections are evolving to be more related to each other, rather than in
the initial drafts, where they are two completely separate entities?

> 4. An AVP is received with an unknown or illegal value
> 
> 	I would argue that this error is VERY similar to case #3, and
> 	should be handled the same way.
Could this be another item handled by the DSI?
 
> So as you can see, now that the Diameter protocol has 
> evolved, the need for
> the MRI isn't there anymore. So I would propose that we make 
> the necessary
> changes described above, and eliminate the command code.
As the base draft evolve, it is my personal impression that it gets bulkier,
especially in the case of how extensions are associated with the Diameter
server, i.e. what does a diameter server support? Initially, it was just the
base, with one or more extensions, regardless of the type of the extension.
Then, accounting is added as part of the server. 

Now, in -03, Page 11, "Diameter servers MUST support the Base protocol,
which includes Accounting, and both the NASREQ and Mobile IP extensions."
This sentence is quite similar to a statement in -01, when it talked about
Diameter servers MUST support the Base protocol, and the accounting
extensions. Does this sentence mean that any server that do not support any
of the three extensions cannot be identified as a "Diameter server"? If this
is the case, the Diameter server is no longer a "pluggable" server with
extensions. Right?

In addition, should there be a new extension Foo proposed and accepted, and
a Diameter server that supports Foo is built and deployed to the network,
all existing Diameter proxies will not recognize the Foo specific commands
when they receive it, and will reject them. So how does new extensions
server actually integrate/communicate with the existing Diameter servers on
the network?

Thanks!

Yiwen

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 4 May 2001 13:36:00 -0700

> and couldn't deliver the message?

Just because a server supports all extensions, they aren't necessarily
enabled (turned on). So, it is possible for no servers in the home domain
to advertise a given extension.

> I agree that a group AVP is a better way to do this.

ok. I'd like to hear from others.

> contents? The AVP supportability check would be only relavent and conducted

Some proxies do more than just forward. Some maintain state information,
some do policy checks, etc. So it is feasible for a proxy to care what's
inside a message.

> user session connection? 

correct.

> From what I understood so far on the base protocol,

Let me try again. A NAS issues a request, and the home server sends back
a response. The NAS receives the response, but doesn't like its contents.
It has to signal to the home server that the session was never started, so
it issues an STR, with a Termination-Cause of "Didn't like your AVP set",
or some such error.

> the initial drafts, where they are two completely separate entities?

not at all... they aren't even closely related.

> Could this be another item handled by the DSI?

Only if an intermediate proxy determines this. In any case, this error has
to be signaled back to the NAS, so a per-hop behavior is the wrong approach.
A response with the Result-Code set to "no way joe" is the right thing to do.

> Then, accounting is added as part of the server. 

correct.

> is the case, the Diameter server is no longer a "pluggable" server with

This sentence was added based on comments generated by the IESG. Take it up
with the ADs and the chair if you do not like this requirement.

> server actually integrate/communicate with the existing Diameter servers on

Correct, they wouldn't be able to provide the correct response.

There is, however, a fix to this problem. I have spent a whole 21 seconds
thinking about this, so please exercise patience if I explain it wrong, or
even if it doesn't make a whole lot of sense.

Currently, the protocol defines command codes. Some are Requests and others
are Answers. A proxy must know the right command code to set should it
receive a request it has a problem with. Your suggestion above states that
if a new extension, foobar, comes out and gets deployed, and an error is
found in a packet, a proxy that doesn't support an extension wouldn't know
how to respond.

What if we all request/answer commands only require a single command code,
and the EIR bits in the header was used to determine if the command was
a request, or an answer? This way, new extensions could be deployed, and
if a proxy didn't support the particular extension, and found an error in
a request, it could still return the correct response.

Does this make sense?

(btw, thanks for the great scenarios you are discussing)

PatC