Subject: [AAA-WG]: [issue] Destination-FQDN in re-auth Messages

From: Mark Eklund <[email-masked]>
Date: Fri, 25 May 2001 14:10:39 -0400 (EDT)

This issue was one of the issues that it was decided should be
sent to the list for discussion.  So enjoy...

Submitter name: Mark Eklund
Submitter email address: [email-masked]
Date first submitted: 25-May-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

Note: The answer to this issue may be related to the answer for issue
26, "What to do if STR is sent to unavailable server" and issue 38,
"Home should state whether the Destination-FQDN is present in follow-on
messages"

* When a Diameter server re-authorizes, the Destination-FQDN
  is optional.

* There is no guidance as to how to use the Destination-FQDN.

* There are two types of authentication realms:
  Simple: A simple realm where the servers are ignorant of each other.
          Re-authorization MUST go to the same server.
  Linked: A linked realm where the servers are knowledgeable of each other.
          Re-authorization MAY go to any of the servers in that realm.

* There are two common causes of re-authorization
  Timeout: The Authorization-Lifetime may soon end and re-authorization
           is needed.
  Forced: A server sends a AA-Challenge-Ind
   
* So the Destination-FQDN will be set according to the following situations:
  Simple-Timeout: Re-authorization MUST go to the same server that 
                  the previous authorization happened.
  Simple-Forced:  If the previous authorization server and the sender of the
                  Re-authorization are the same, send it to that server.
	          If they are different, the re-authorization location
  		  has to be specified in the draft. 
  Linked-Timeout: Either always use the Realm, or have a retry mechanism
		  where it uses the previous authorization server and if
	          that is unreachable, send to the Realm (no Destination-FQDN).
  Linked-Forced:  Combine Simple-Forced and Linked-Forced

* If you are using Destination-FQDN with re-authorization, and the server
  is down, do you send to the realm, assume Re-authorization was successful, 
  or disconnect the user.

Requested Change:
 Option 1:
  * Only allow Re-authorization in Linked realms.
  * Destination-FQDN if used must be that of the server used for the most
    recent authentication.
  
  Something like this text should be added.
  
  If re-authorization is required by the server because of
  Authorization-Lifetime timeout or an AA-Challenge-Ind, all servers in
  the authorization realm (not just the one that did the authorization
  of that session) MUST be capable of re-authorization.  If the
  Destination-FQDN is included, it MUST contain the Origin-FQDN of the
  last server that authenticated the user.  If the request returns with
  the error DIAMETER_UNABLE_TO_DELIVER, the client MAY re-send the AAR
  without a Destination-FQDN.

 Option 2:
  * Assume realms are not linked.

  Something like this text should be added.

  Re-authorization MUST use as the Destination-FQDN the Origin-FQDN of
  the server that authenticated the session.  If the server is
  unreachable, the client MAY either assume authorization failure or
  success.  If success is assumed, a Diameter client SHOULD NOT expect
  payment for services rendered past the session expiration time.

 Option 3:
  * Expect ignorance, and allow for enlightenment.

  Something like this text should be added.

  Re-authorization MUST first use as the Destination-FQDN the
  Origin-FQDN of the server that previously authorized the session.  If
  the server is unreachable, the client MAY remove the Destination-FQDN
  and send the re-authorization request again.  The servers in the
  realm MAY handle a re-authorization request of a session that they
  did not authenticate in any way (for example database lookup, always
  fail, always succeed, or any other method).

 Option 4:
  * A combination of 2 and 3

  Something like this text should be added.

  Re-authorization MUST first use as the Destination-FQDN the
  Origin-FQDN of the server that previously authorized the session.  If
  the server is unreachable, the client MAY fail the authentication,
  pass the authentication, or remove the Destination-FQDN and send the
  re-authorization request again.  If success is assumed, a Diameter
  client SHOULD NOT expect payment for services rendered past the
  session expiration time.  If the request is sent again, servers in
  the realm MAY handle a re-authorization request of a session that
  they did not authenticate in any way (for example database lookup,
  always fail, always succeed, or any other method).

====================================================================