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 18:26:51 -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?
> 
> 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.
Hmm... When would this scenario happen? It won't be in peer to peer case,
because to establish that connection, both peer must support the same
extension. Would this be to deal with unsolicited messages? or is this
specific to Mobile-IP extension for roaming?

> > 
> > > 	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?
> 
> 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.
But if a proxy doesn't recognize an AVP, why can it not just ignore it and
care about the ones it does understand, but still forward the request to the
next hop?

> 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.
Okay, that made sense. Thanks!

But relate back to the discussion earlier how NAS would examine the packet
received, and parse through the various error Result-Code put in by the
intermediate proxies that didn't understand some of the AVPs, right? My idea
is, that if those unknown AVP related result code weren't there, the only
Result-Code is there, should be the result from the end server, and this
makes the logic in NAS much simpler.. Or does NAS really have to know that
the intermediate proxies do not support some AVPs it uses?

> > > 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?
> 
> 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.
Agreed.
 
> > 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?
> 
> 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.
Okay, thanks for the info.

> > 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?
> 
> 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.
You've been so patient with me, and I know you must be swamped, so don't
worry. :)
 
> 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?
So you are saying, that if a proxy found an obvious error in the request
that it doesn't support,  it should just change the appropriate EIR bits,
and reply it back to the server that sent the request using the same command
code?

Hmm... I think that would work... But what about errors with -Ind messages?
Or does the proxy check for the validity of AVPs only with Request/Answer
messages?

Or another way, is to allow the proxy to skip AVPs that it does not
understand, and just do the validity check with AVPs that it understands, if
error, return correct response, else pass onto the next hop. Or is this
really not desired behaviour?

> (btw, thanks for the great scenarios you are discussing)
My pleasure... It's been a great learning experience, and I'm really
enjoying the discussions that are happening on the mailing list... And
thanks again for your prompt responses and patient help... It's been great.
:)

Cheers,

Yiwen

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 4 May 2001 15:32:48 -0700

> specific to Mobile-IP extension for roaming?

Correct, but consider the following scenario:

   +-----+      +-------+      +-------------+
   | NAS |----->| Proxy |----->| Home Server |
   +-----+      +-------+      +-------------+

         ------>         ------>
        DRI, ext=1       DRI, ext=2

        <-------         <------
        DRI, ext=1,2     DRI, ext=1,2

        --------->
        Cmd, ext=1
                     ------> Looks, but no ext=1 supported
        <--------
        Error

This could occur for one of two reasons. Either the home network
is misconfigured, and clients from that domain are asking for services
that are not available from its home net, or the home server that
provides ext=1 services is not available (crashed?)

> care about the ones it does understand, but still forward the request to the

Because it may want to make some intermediate authorization decisions. Let's
say that a broker is established, and provides roaming services for two
networks, a and b. The broker's arrangment is that at any given time it
will permit n users of service foo, and x users of service bar to be roaming.

Now if the broker receives a request, and it contains some AVP marked as
mandatory that it doesn't recognize, should it simply assume that the
request falls within the negotiated business contract and allow service?
I would expect not, so it would respond stating that something is weird
in the packet, and it isn't willing to provide roaming services.

> the intermediate proxies do not support some AVPs it uses?

See the above scenario. It does care if something was bad with the packet,
regardless of who complains.

> and reply it back to the server that sent the request using the same command

that is the proposal. Quite radical this late in the game, I understand, 
but it would fix the problem.

> Or does the proxy check for the validity of AVPs only with Request/Answer

A bad -Ind message is another problem, and I suspect that perhaps the MRI
could be salvaged for this purpose, or just create another bit to indicate
a bad response to an -Ind. This would ONLY be sent when an -Ind was rejected,
so a successful -Ind has no response.

> really not desired behaviour?

In the ideal world yes, but from the discussions that I've gathered on the
list over the past years, this is a desired feature. If people agree this
is not necessary, then we can simplify the protocol :)

> thanks again for your prompt responses and patient help... It's been great.

All for the good of the Internet Community....

PatC