1 Apr 2005 18:41
Re: : RE: AAA Transport Profile and Application Failure
Rakesh Mehta <mehtark_2002 <at> yahoo.com>
2005-04-01 16:41:52 GMT
2005-04-01 16:41:52 GMT
As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER message with E bit set and send to proxy if local application is not available to process the message.
I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please???
Thanks,
Rakesh
STURA Marco Consultant <Marco.STURA <at> consultant.vodafoneomnitel.it> wrote:
Mike,
some comment in line.
Regards
Marco
-----Original Message-----
From: m.hillier <at> telenet-ag.de [mailto:m.hillier <at> telenet-ag.de]
Sent: Wednesday, March 23, 2005 2:43 PM
To: aaa-wg <at> merit.edu
Subject: AAA Transport Profile and Application Failure
A question has come up concerning the detection of a failed Diameter
application and the consequences for the AAA client.
RFC 3588 suggests very strongly that Diameter stacks should be
implemented
in layers. Accordingly the possibility exists that in a Proxy agent or
a
server, the Diameter Base protocol handling process is functioning
properly
but the application process has fallen over. I.e. The Diameter
Transport
connection is up and the watchdog commands (DWR/DWA) a re being sent and
received.
[MSt] Yes, Diameter stack should be layered and inte rnal communication
between layers is left to the implementation. There was an attempt to
standardize a basic API, but this was shut down a while ago. I have seen
some discussion lately but probably nothing concrete yet.
In such a situation and on receipt of a Request from a AAA client, the
Base
process in the Proxy (or Server) will either not send any response back
to
the client at all or reply with an error and Result-Code set to
DIAMETER_UNABLE_TO_DELIVER, depending on implementation and
interpretation
of RFC 3588 and RFC 3599.
[MSt] A Diameter agent MUST always send an answer back to the client,
either success or failed. If the agent is acting as a relay for a
request, then the base protocol layer is mainly the one responsible for
the full handling of the request. However, if the agent is acting as
proxy for a request, the request ha ndling responsibility is typically
shared between layers (i.e. base protocol and possib ly proxy
application).
Section 6.1 of RFC 3588 reads:
[start fragment]
When a message is received, the message is processed in the following
order:
1. If the message is destined for the local host, the procedures
listed in Section 6.1.4 are followed.
2. If the message is intended for a Diameter peer with whom the local
host is able to directly communicate, the procedures listed in
Section 6.1.5 are followed. This is known as Request Forwarding.
3. The procedures listed in Section 6.1.6 are followed, which is
known as Request Routing.
4. If none of the above is successful, an answer is returned with the
Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set.
[end fragment]
I think a proper implementation would work as follow:
- The base protocol layer receives the request. It decides as whe ther it
is acting as proxy or relay for the request (i.e. based on Local Action
in t he realm routing table).
- If the request is to be proxy (i.e. the agent is acting as proxy for
the request), the proxy application should process the request by
modifying the message according to its policy (e.g. add a
Destination-Host to force the request to be routed to a pre-defined
destination or other policy specific actions). Hence the base should
pass the request to the application layer and, if this one fails, it
should answer according to step 4 above. Basically, there should be
internal communication between layers in order to detect the failure
(i.e. if the proxy application process is down, and this is required for
the processing of the request, this should be internally detected and an
appropriate answer sent back to the originator of the request).
The AAA client is now faced with the situation that every single Request
to
a peer is failing. Depending on the application and mode of use, an
individual Request (e.g. at the start of a Session) can failover to a
secondary peer. However there seems to be no mechanism for the client
to
detect the general failure and thereby suspend the peer and send all
future
Requests directly to the alternative peer. It seems that this
situation
can occur both in a Proxy Agent and in a Server.
[MSt] See my previous comment. In my example the agent is up and running
in relay mode, but perhaps not in proxy mode because the proxy
application process is down. Therefore every request for which the agent
has to act in proxy mode will possibly be answered with Result-Code
DIAMETER_UNABLE_TO_DELIVER. The AAA client receiving such an error, will
possibly re-send the request to an alternate peer (and the request may
eventually get a successful answer). That's all what the standard says.
Then, depending on the degree of complexity of yo ur implementation (but
this is up to your implementation I think), the client may decid e to
stop sending such requests (perhaps for a while) to a peer after a
number of failed request with this kind of result-code.
Have I miss-understood the mechanisms or even the architecture of a
Diameter node? Or is this "out-of-scope" of the RFCs, possibly being
"implementation dependent"?
[MSt] My feeling is that internal communication between software
components that build up your Diameter stack is definitely
implementation dependent.
Best Regards
Mike Hillier
Michael Hillier
Mobile +49 170 5454 121
M.Hillier <at> telenet-ag.de
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
>
>
Ok.
> PKI solutions only cover authentication, not authorization (EAP could
> change this, but its use with SIP is not standardized). TLS / Basic
> authentication works only with the limited number of SIP devices that
> implement TLS. Basic authentication has been deprecated for SIP in
> [RFC3261].
>
>
>
>
> Current RADIUS-based AAA infrastructures have been built and debugged
> over years. Deficiencies of RADIUS have been mitigated with
> proprietary (ie costly) extensions. Operators are therefore
> reluctant to replace their RADIUS infrastructure in order to enable a
> single new authentication mechanism.
>
>
>Same as above. And I'm not sure all deficiences have been
>mitigated.
>
>
Ok.
> DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
> DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
> DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
> will be assigned by IANA, if this specification becomes a working
> group or IESG document.
>
>
>Here's an idea: I'd prefer the attributes in this and the Diameter
>draft to be constructed with the following rules:
>
>
>(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
> and Dig-Authp could all use the same attribute? They all have
> the same syntax in HTTP (param=value).
>
>
>(2) If both RADIUS and Diameter are going to define the attributes,
> IMHO it would make sense to allocate them from the RADIUS space
> so a conversion box would not have to map attributes.
>
>
> Alternative idea: use some of the extended RADIUS attribute
> format ideas and allocate the numbers from the Diameter space.
>
>
>(3) Use exactly the set of attributes for the pure digest function
> (I did not check if this is already the case).
>
>
Ok, this is mostly as I wanted it to be in the Radius document.
However, I wonder if the current Diameter document should
use individual AVPs instead of Grouped AVP:
SIP-Authenticate ::= < AVP Header: xx12 >
{ Digest-Realm }
{ Digest-Nonce }
[ Digest-Domain ]
[ Digest-Opaque ]
[ Digest-Stale ]
[ Digest-Algorithm ]
[ Digest-QoP ]
[ Digest-HA1]
* [ Digest-Auth-Param ]
* [ AVP ]
Because translating this grouped AVP appears to require
additional work from a gateway, no? Bernard/Miguel, can
you file on issue to the Diameter document on this.
> +-----+ (1) +-----+ +-----+
> | |==========>| | (2) | |
> | | | |---------->| |
> | | | | (3) | |
> | | (4) | |<----------| |
> | |<==========| | | |
> | | (5) | | | |
> | |==========>| | | |
> | A | | B | (6) | C |
> | | | |---------->| |
> | | | | (7) | |
> | | | |<----------| |
> | | (8) | | | |
> | |<==========| | | |
> +-----+ +-----+ +-----+
>
>
>The choice between the server and client generated
>nonces: is there some guidance on how the client knows
>which one to do? if it believes it may have a user that
>does Digest AKA then it should do use the server generated
>scheme? But how would it know this in a roaming case?
>
>
>Other ideas?
>
This has been raised by Bernard too, apparently we
didn't do good enough job to fix it.
Conclusion: close issue 11. Bernard's roaming issue
still needs to be kept alive, and I'm suggesting one
new issue on the Diameter SIP document.
--Jari
--
to unsubscribe send a message to radiusext-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <
RSS Feed