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

From: Yiwen Jiang <[email-masked]>
Date: Mon, 7 May 2001 10:50:24 -0400

> > > 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?
> 
> 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?)
Ahh.... yes. That makes sense..
 
> > 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?
> 
> 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.
Hmm... But wouldn't that restrict all Diameter servers to be upgraded at the
same time when a new extension is deployed? Otherwise, no new extension
messages can be exchanged at all since proxy will reject all of them...?

Can the following be a possible solution? 

I would assume that a proxy will have a record of realms it can forwards
requests to. Can it also maintain a list of extensions that the realm
supports? This way, when a home network deploys a new extension support, the
deployer will ensure that within that all the affiliated proxies are
informed of such change. The deployer will also ensure that within its own
network, the new extension is supported. So the intermediate proxies can use
realm as another policy when performing policy checking: If there are
mandatory AVPs that the destination realm does not support, proxy returns
error. If the destination realm supports extension, it should have been
registered with the proxy, even if the proxy does not support that
extension, the proxy will forward the message. This way, if the proxy
supports the extension, it can perform policy checking. Otherwise, it leaves
the policy checking to the end server.

> > 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?
> 
> that is the proposal. Quite radical this late in the game, I 
> understand, 
> but it would fix the problem.
Yeah, but this means no new extension messages can be sent until all proxies
supports that extension. That is really not very ideal, is it?

> 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.
Okay. So this implies that an -Ind is a -Req but with an optional -Answer
message associated with it?
 
> > 
> > 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?
> 
> 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 :)
I'm really not sure how much benefit this feature provides, because this
makes the integration with future extensions much more difficult. Another
question I have is, now that all Diameter server must support all
extensions, is the mandate of having pluggable extensions a valid one?

Thanks.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 7 May 2001 08:15:13 -0700

> messages can be exchanged at all since proxy will reject all of them...?

It would require that proxies that exhibit the above behavior be upgraded,
yes. However, the number of proxies that behave this way is small, but certain
business relationships require this feature.

> the policy checking to the end server.

This is the way Diameter normally works.

> supports that extension. That is really not very ideal, is it?

Not at all. The proposal is to allow new extensions that wouldn't be supported
by all proxies. Proxies in fact will most likely want to route messages, and
not care about the contents of the message, but if an error is found, it
should be able to reply back to the NAS, right? That's the goal here.

> message associated with it?

The key difference here is that a -Req always has a response. An -Ind only
has a response if an error occured.

> extensions, is the mandate of having pluggable extensions a valid one?

Again, some people want to run their networks like this (and are today), so
I don't think we can eliminate this feature since RADIUS supports it.

Do recall, though, that this is not the "default" way the protocol works. This
is a special configuration for special business relationships.

PatC