Subject: [AAA-WG]: [issue] What to do if STR is sent to unavailable server. (2nd try)

From: Mark Eklund <[email-masked]>
Date: Mon, 4 Jun 2001 10:23:45 -0400 (EDT)

All,

I had sent this issue out earlier and got no response.  My vote
is for option #3.  If someone wants to send an STR a second time
with no Destination-FQDN, let them.

-mark

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

* The Session-Terminate-Request requires a Destination-FQDN

* There was going to be text added to state that the Destination-FQDN
  should be that of the last place you authenticated.

* What happens if that Destination-FQDN is down?  If this is a cluster
  of servers, there may still be a need for the STR to be sent to the
  realm.

Requested change:

One or more of the following changes:

1. Do nothing.  If the authenticating server goes down, either all the
   state data is lost, or session timeouts will cleanup any STRs missed.
   A statement as such should be added to the RFC reflecting this.

2. Make the Destination-FQDN optional.  If the client receives a 
   DIAMETER_UNABLE_TO_DELIVER, the client may send the request without
   a Destination-FQDN.

3. #2 above, but allow a proxy to also do this.

4. Make the Destination-FQDN optional.  Add an STR-Destination AVP 
   that is of type integer that is sent as a part of the authentication 
   process.  This would contain the Destination-Realm and optionally
   the Destination-FQDN to which this should be sent.

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

---

From: David Spence <[email-masked]>
Date: Mon, 04 Jun 2001 17:14:24 -0400

#3 sounds good to me.  That includes #2, resend the STR without the
Destination-FQDN, plus let certain types (to be specified later) of proxy
resend the STR without the Destination-FQDN to relieve the client from
having to do so.

I must admit, I don't quite understand #4.  If anyone favors it, perhaps
they could elaborate.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Mark Eklund <[email-masked]>
Date: Mon, 4 Jun 2001 17:27:54 -0400 (EDT)

David,

> I must admit, I don't quite understand #4.  If anyone favors it, perhaps

I don't favor #4, but I'll elaborate. The basic idea was to give
the server control over what is sent.  It could tell the client
to not use a Destination-FQDN.  It would do this with an
STR-Destination AVP which would be included in the AAA.

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 14:21:10 -0700

> I must admit, I don't quite understand #4.  If anyone favors it, perhaps

I think that #2 is really the only sensible way of doing this. Otherwise, this
requires special handling of the STR by relays, and how would a client know
that it has been handled by a relay?

Further, I really think that the only way to fix this is to fix #38. The home
should state whether it *requires* that follow-on messages are to be sent to
the same server (for the session) or not. Otherwise, sending an STR to the
wrong server in the same realm MAY only cause confusion.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 14:27:36 -0700

> STR-Destination AVP which would be included in the AAA.

That's my preference. Don't send it unless the home server tells you it is ok.

PatC

---

From: Mark Eklund <[email-masked]>
Date: Mon, 4 Jun 2001 18:00:06 -0400 (EDT)

Pat, 

Would you have a similar AVP for accounting?  
Would re-auth be the same AVP as STR?
Can we combine option 2 and 4?

AA-Destination-Config
 The AA-Destination-Config is of type Enumerated.  It specifies
 how subsequent AAR and STR MUST be sent.  This may be sent in
 either the initial authentication, or any re-auth.  If not
 present, BOTH is used.

 BOTH(0)  - Always use Destination-FQDN and Destination-Realm
 REALM(1) - Only send Destination-Realm
 TWICE(2) - Do BOTH.  If DIAMETER_UNABLE_TO_DELIVER retransmit
            using REALM

Acct-Destination-Config
 Same as above except this may be sent in accounting packets.

Mobile-Destination-Config
 Do we need this too, or does AA-Destination-Config handle this?

Also, could it be simply Destination-Config and what it
configures is dependent upon what type of packet this is?

Also, this would break using the presence of Destination-FQDN as
an indicator of continued conversation.

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 5 Jun 2001 07:14:33 -0700

> Would you have a similar AVP for accounting?  

hmmmm... it would be interesting to include an AVP that contains the
identity of the server that handles accountinng for a particular session.

others?

>  TWICE(2) - Do BOTH.  If DIAMETER_UNABLE_TO_DELIVER retransmit

That works for me. Anyone object?

>  Do we need this too, or does AA-Destination-Config handle this?

Actually, by pulling this particular AVP into the base protocol,
it would be used by *any* application
> configures is dependent upon what type of packet this is?

Right, that's my thought. It would handle all re-auths and STRs.
> an indicator of continued conversation.

Not at all. If a server states that it does not care where the message
is sent, then this implies that the servers have shared state, and therefore
it really doesn't matter where the message is sent to. So, load balancing
would allow this message to be sent to *any* server.

PatC

---

From: Robert Sargent <[email-masked]>
Date: Tue, 5 Jun 2001 10:45:06 -0400

> identity of the server that handles accountinng for a particular session.

accounting host ip, key, port ???

Rob

-- 
Rob Sargent
Tel: (865) 671-8823
Software Development Manager -*-  Remote Site Manager - Knoxville
10850 Murdock Dr
Knoxville TN 37932                       http://darien.cisco.com/

---

From: Mark Eklund <[email-masked]>
Date: Tue, 5 Jun 2001 11:06:46 -0400 (EDT)

Pat,

> identity of the server that handles accountinng for a particular session.

Just to verify.  The above question and comments have to do
with having the present AAA contain something telling where to
send the ACR.  If there is interest, this would be a different
issue.  Correct?

> it would be used by *any* application

How about we call it Application-Destination-Config (or
something abbreviated).  When received, all subsequent requests
for that session with that application type will be controlled
by that config.  Before sending, you would have to lookup where
to send it.

Session_ID Application AA/Acct Destination-Config
XYZ...     NASREQ      AA      BOTH
XYZ...     NASREQ      Acct    REALM
MNO...     MOBILEIP    AA      TWO
MNO...     MOBILEIP    Acct    TWO
MNO...     NEWWAY      Acct    ONE

This is getting a little complex.  What if we made it really
simple with a new option.

4. If the client receives a DIAMETER_UNABLE_TO_DELIVER, the
   client MUST re-send the request with a Destination-FQDN of
   "*".  "*" denotes that this is a rebroadcast because the
   initial Destination-FQDN was unreachable.

If a server cannot handle re-auths or accounting records for a
fellow server, it can drop it.

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 5 Jun 2001 08:03:25 -0700

> send the ACR.  If there is interest, this would be a different

Right. So would it make more sense to send the identity of the
accounting server, or just something similar to the AA-Destination-Config
AVP below, where all accounting records will be guaranteed to be sent
to the authorizing server.

Yes, this would be a separate issue, IMHO. Oh, and this sure smells
like a new feature, so we should be careful here in adopting new
features.

PatC