Subject: [AAA-WG]: Extensions that Diameter servers MUST support

From: "Carolina Canales Valenzuela (ECE)" <[email-masked]>
Date: Wed, 16 May 2001 17:38:45 +0200

Hello,

I have a question regarding the necessity of all Diameter servers to support certain compulsory extensions (Mobile-IP, NASREQ etc).

I've read the IETF mailing list, and as far as I understand, this decision was made in order to eliminate the MRI command (discussion held mainly between Pat Calhoun and Yiwen Jiang in mails with subject "A proposal for the elimination of MRI and comments on -03").

In further company-internal discussions, it was clarified that End Servers don't need to have all those compulsory extensions activated (is this equivalent to not to implement them?) and that proxy servers must implement them *only if they want to perform certain policies* (in this case they must understand all the message, and not only pay attention to F A I R bits).

Is this assumption correct?
In this case, shouldn't the draft say (Section 2.0, 2nd paragraph):

"Diameter proxies MUST support the Base protocol, which includes Accounting, and MUST support the NASREQ and Mobile IP extensions, ONLY in case they want to perform any kind of policies" (after clarifying the servers behavior)

instead of:
 
"Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions".

Is it really necessary that every proxy server implements those extensions, even if they are not interested in them at all?. IMHO if the answer is no, it would make the protocol more pluggable.
If the answer is yes, this might drive certain vendors/organizations to implement proprietary Diameter extensions and support in their proxies only those extensions, not being IETF compatible in that case. 

For further clarification on the problem, please see the messages attached (internal discussion).

Thank you very much!
BR,
Carolina Canales

From:	Carolina Canales Valenzuela (ECE) [[email-masked]]
Sent:	Friday, May 11, 2001 10:14 AM
To:	'Tony Johansson'; Martin Julien (ECE)
Cc:	[email-masked]'
Subject:	RE: [ERI-AAA] RE: Extensions that Diameter servers MUST support

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Thursday, May 10, 2001 8:40 PM
> To: Martin Julien (ECE)
> Cc: Carolina Canales Valenzuela (ECE); [email-masked]'
> Subject: Re: [ERI-AAA] RE: Extensions that Diameter servers 
> MUST support
> 
> 
> 
> 
> "Martin Julien (ECE)" wrote:
> 
> > See my comments enclosed.
> >
> > > > I have a question regarding the necessity of all Diameter
> > > servers to support certain conpulsory extensions (Mobile-IP,
> > > NASREQ etc).
> >
> > I don't think supporting it means anything more than understanding
> > the set of command-codes and AVPs. It does not mean
> > that every Diameter node must be able to handle NASREQ
> > authentication, for example. At least, that is my understanding.
> 
> That is my understanding too. The NASREQ authentication, for example,
> could only occur if the server has negotiated support for 
> NASREQ in the
> DRI (i.e. turned it on and also that the server has users for which it
> will act as AAAH).
> 
> >
> >
> > > > > I've read the IETF mailing list, and as far as I
> > > > understand, this decision was made in order to eliminate the
> > > > MRI command (discussion held mainly between Pat Calhoun and
> > > > Yiwen Jiang in mails with subject "A proposal for the
> > > > elimination of MRI and comments on -03").
> >
> > That is not decided yet.
> 
> Correct.
> 
> >
> >
> > > > > In one of his mails , Yiwen Jiang suggests, FOR NEW
> > > > EXTENSIONS, that proxies should be aware of what extensions
> > > > are supported in what realm, and simply forward messages to
> > > > those realms if they support the extension, even if the
> > > > proxies don't understand the message because they don't
> > > > support that extension).
> > > > > In case the extension is not supported in the destination
> > > > realm, the proxy should be able to send an appropriate error
> > > > response, being able to understand the initial message by the
> > > > EIR bits in the header (and a special response should be
> > > > created for Ind messages).
> > > > > This is what I understood, but please correct me if I'm wrong.
> >
> > That's my understanding of the suggestion as well.
> 
> >
> >
> > > > > So, why not use this procedure for EVERY extension
> > > > (included Mobile-IP and NASREQ), so the protocol is really
> > > > pluggable and servers MUST only support the Base protocol
> > > > (plus accounting), but not Mobile-IP and NASREQ?
> >
> > I think it is the intention.
> >
> > > > The realm part that Yiwen is mentioning is mainly how the
> > > > protocol works today, but the new thing (or maybe I should
> > > > say clarification about this) seems to be that a proxy have
> > > > to check that all the AVPs in a received message are all
> > > > correct and reply an error message if any errors are found in
> > > > the message.
> >
> > In fact, a proxy would be required to validate the AVPs of the
> > messages it is proxying only if it needs to perform policies.
> > If it does not need to deal with policies, it can simply
> > forward the messages as they are, without validating anything
> > else than the minimum set of AVPs used for routing. It does
> > not make sense for all proxies to validate the messages all the
> > time, especially if you have 3 proxies between the client and the
> > home server.
> 
> Thanks for clarifying this Martin. You are absolutely correct. If a
> proxy does not perform any policies it would only have to check the
> minimum set of AVPs used for routing. So the proxy in this case would
> not really have to understand MIP or NASREQ, but still be 
> interoperable.

I thank you very much for your clarifications.

But, in this case, shouldn't the draft then say  (Section 2.0 Protocol Overview, 2nd paragraph ):
"Diameter proxies MUST support the Base protocol, which includes Accounting, and SHOULD support the NASREQ and Mobile IP extensions, in case they want to perform any kind of policies" (after clarifying the servers behavior)

instead of:
 
"Diameter servers MUST support the Base protocol, which includes Accounting, and both the NASREQ and Mobile IP extensions".

> > I think the specification would need to be clearer on this. I'm
> not sure if the wording should be SHOULD or MUST, but at least
> make clear that it is expected that only proxy servers that
> are required to execute policies are expected to validate
> Diameter messages. I guess you could bring it to the list
> after a comment from Tony.
>

I agree. I also think that this is good to get this clarified. So please,
bring it up. I'm not really sure about the wording either, but I think a
MUST is the right thing to state in the case that the proxy want to perform
policies (adding / changing the content of the message) because in such a
case it will need to understand extension anyway. Right?

BR, Carolina 
> 
> >
> >
> > > > This implies that a proxy server must at least know all the
> > > > extension commands and AVPs from all the involved extension.
> > > > So the AAAP in the figure below must check the messages (and
> > > > to some degree understand the content of the messages) even
> > > > though the messages are just forwarded through the AAAP to
> > > the AAAHs.
> > > >
> > > >   Please view in a fixed-width font such as Courier.
> > > >
> > > >
> > > >      nas.bar.com                           aaa2.foo.com
> > > >      +----+                                +-----+
> > > >      |NAS |                               /|AAAH |
> > > >      |    |\                        ext1 / |(NAS)|
> > > >      +----+ \ext1                       /  +-----+
> > > >              \                         /
> > > >               \ +-----+ ext1,4+-----+ /
> > > >                X| AAAF+-------+AAAP |X
> > > >               / |     |       |     | \
> > > >              /  +-----+       +-----+  \
> > > >      +----+ /  aaa.bar.com aaa1.foo.com \  +-----+
> > > >      |    |/ ext4                   ext4 \ |AAAH |
> > > >      |FA  |                               \|(MIP)|
> > > >      +----+                                +-----+
> > > >
> > > >      fa.bar.com                            aaa3.foo.com
> > > >
> > > >
> > > > However, the e.g. aaa2.foo.com in the figure would never have
> > > > to expect to get anything else than NASREQ related things. So
> > > > to my understanding I think we still can see the protocol as
> > > > partly pluggable even though the base draft says that servers
> > > > must support both MIP and NASREQ, because you can always "turn
> > > > off" the part that you don't want to support by not
> > > > advertising this in the DRI. The exception is of course the
> > > > proxy case (AAAP in the figure).
> >
> > Yes, that's correct.
> >
> > > Yes, I understand that the issue affects mainly to proxies
> > > (not to end servers).
> > > But what happens with the delay added, if every proxy has to
> > > process the content of every message that goes through it?
> > > Isn't this a problem?
> > >
> > > In order to provide an example, let's talk about the SLF
> > > case.These are the assumptions (please correct me if I'm wrong):
> > >
> > > As far as I understand, this node will work as a
> > > proxy/redirect server to the HSS , and I think that it is
> > > only interested in the Multimedia domain (right?).
> > > If we force it to implement any other extensions, it might
> > > happen that in 3GPP they will decide not to support the IETF
> > > protocol, but rather a proprietary protocol. Is that not a
> > > problem for us?
> >
> > Refer to my previous comments.
> >
> > > > According to Pat, has the IESG and ADs  requested that it is
> > > > a MUST with support for both MIP and NASREQ, so it may be
> > > > hard to make it more pluggable than this.
> > >
> > > Perhaps, if this is a decision that has been taken on another
> > > level, there is nothing more to talk about...Is this the case?
> >
> > I would say that the IESG should at least provide some kind of
> > motivations behind their decisions, no?
> 

> BR,
> /Tony
> > BR,
> > Martin

From:	Tony Johansson [[email-masked]]
Sent:	Saturday, May 12, 2001 2:22 AM
To:	Martin Julien (ECE); Carolina Canales Valenzuela (ECE)
Cc:	[email-masked]'
Subject:	Re: [ERI-AAA] RE: Extensions that Diameter servers MUST support

"Martin Julien (ECE)" wrote:

> > > > > > > So, why not use this procedure for EVERY extension
> > > > > > (included Mobile-IP and NASREQ), so the protocol is really
> > > > > > pluggable and servers MUST only support the Base protocol
> > > > > > (plus accounting), but not Mobile-IP and NASREQ?
> > > >
> > > > I think it is the intention.
> > > >
> > > > > > The realm part that Yiwen is mentioning is mainly how the
> > > > > > protocol works today, but the new thing (or maybe I should
> > > > > > say clarification about this) seems to be that a proxy have
> > > > > > to check that all the AVPs in a received message are all
> > > > > > correct and reply an error message if any errors are found in
> > > > > > the message.
> > > >
> > > > In fact, a proxy would be required to validate the AVPs of the
> > > > messages it is proxying only if it needs to perform policies.
> > > > If it does not need to deal with policies, it can simply
> > > > forward the messages as they are, without validating anything
> > > > else than the minimum set of AVPs used for routing. It does
> > > > not make sense for all proxies to validate the messages all the
> > > > time, especially if you have 3 proxies between the client and the
> > > > home server.
> > >
> > > Thanks for clarifying this Martin. You are absolutely correct. If a
> > > proxy does not perform any policies it would only have to check the
> > > minimum set of AVPs used for routing. So the proxy in this
> > case would
> > > not really have to understand MIP or NASREQ, but still be
> > > interoparable.
> >
> > I thank you very much for your clarifications.
> >
> > But, in this case, shouldn't the draft then say  (Section 2.0
> > Protocol Overview, 2nd paragraph ):
> > "Diameter proxies MUST support the Base protocol, which
> > includes Accounting, and SHOULD support the NASREQ and Mobile
> > IP extensions, in case they want to perform any kind of
> > policies" (after clarifying the servers behavior)
> >
> > instead of:
> >
> > "Diameter servers MUST support the Base protocol, which
> > includes Accounting, and both the NASREQ and Mobile IP extensions".
>
> I think the specification would need to be clearer on this. I'm
> not sure if the wording should be SHOULD or MUST, but at least
> make clear that it is expected that only proxy servers that
> are required to execute policies are expected to validate
> Diameter messages. I guess you could bring it to the list
> after a comment from Tony.
>

I agree. I also think that this is good to get this clarified. So please,
bring it up. I'm not really sure about the wording either, but I think a
MUST is the right thing to state in the case that the proxy want to perform
policies (adding / changing the content of the message) because in such a
case it will need to understand extension anyway. Right?

/Tony

> BR,
> Martin

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 May 2001 11:12:14 -0700 (PDT)

> Is it really necessary that every proxy server implements those extensions, even if 
> they are not interested in them at all?. 

I'm not even sure what it means for "routing proxies" to "implement" any
extension. This like talking about IP routers "implementing" TCP or an
application layer protocol. It's a contradiction in terms.

The purpose of a routing proxy is to forward packets. It doesn't need to
"implement" any functionality except that required for forwarding. Such
a proxy does *not* act as a AAA client or server. If
the AVPs required for forwarding were available in the same location
for all messages then the routing proxy would have no need to even
understand the semantics of the messages. This is why protocols like SIP
put the routing info right up at the top of the header -- so the proxy can
manipulate it easily. These are the kind of benefits that you get from
proper protocol layering.

To fix this issue, I think we need to clearly distinguish the behavior of
various types of proxies and define their behavior in the spec.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 16 May 2001 11:57:40 -0700

> application layer protocol. It's a contradiction in terms.

bingo!

> various types of proxies and define their behavior in the spec. 

Actually, proxies do not need to support *any* extensions in order for
them to be useful as proxies. The mandated support paragraph came from
the IESG. 

Having said that, the -02 release did in fact have problems with proxies
not supporting extensions, since they would have to know how to respond to
a bad request. This has since been fixed, and I am hoping that the IESG
will agree to allow us to remove this paragraph.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 May 2001 17:48:46 -0700 (PDT)

> them to be useful as proxies. The mandated support paragraph came from

The problem is in the terminology. Redirects, Forwarders (e.g. routing
proxies), and true application layer gateways (e.g. DIAMETER to RADIUS,
etc.) behave differently. The last category definitely *do* need to
support extensions, the others don't. I think we need to make this clear.