Subject: [AAA-WG]: Handling of Duplicate Requests

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 15 Oct 2001 16:51:33 -0400

Hi Pat,

The Diameter base draft mentions a few things about how the AAA home
server handles duplicate request messages, but leaves much to the
implementer's imagination.  Maybe this is by design, but maybe the
AAAH's actions should be specified a little more.

Here's the kinds of things I've been thinking about:

Suppose a home server receives a duplicate request, i.e. a request
whose Origin-Host and End-to-End-Identifier match a recent
previously-received request.

There's a couple cases here:

1. The previously-received request has already been replied to.

or 

2. The previously-received request hasn't yet been replied to.  The
server is waiting for something, e.g. the original request is an AMR,
the server has sent an HAR to the Home Agent, but hasn't gotten the
HAA back yet.

And for each of these two cases, there are a couple of cases:

a. The duplicate request is really a duplicate.

b. The duplicate request is not really a duplicate:
-- Even though the Origin-Host and End-to-End-Identifiers match, the
"duplicate" differs in some essential way, e.g. the Session-Id or
User-Name differs from the previously-received request.  
-- Or maybe the duplicate differs in some minor but legitimate way.
(Maybe the following aren't real-world examples, but here goes...)
Example#1: An FA is connected to two AAAFs.  The FA sends his AMR to
AAAF1, then fails over and resends his request to AAAF2.  AAAF1 and
AAAF2 twiddle the MIP-Feature-Vector bits differently, and forward the
AMR to the AAAH.
Example#2: A NAS is connected to two local proxies.  The NAS sends his
request to AAAP1, then fails over and resends this request to AAAP2.
AAAP1 and AAAP2 modify the request message differently because of
slightly different policy.

Does the following make sense for the AAA Home Server?:

Case 1a: is easy, just send back pretty much the same answer.

Case 1b: Send negative reply for duplicate, Result-Code=[TBD].  Send
an Abort-Session-Request for the original (iff original answer was a
SUCCESS).

Case 2a: Is the expectation here that when the server can finally
respond to the original request, that it responds to the duplicate at
the same time?

Case 2b: Send a negative reply for both the original request and the
duplicate, Result-Code=[TBD].

Bob K.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 17 Oct 2001 04:58:36 -0700

well, unlike RADIUS, identifiers aren't changed just because a bit is
twiddled in the packet. That's a fundamental difference since it makes it
much easier to interpret duplicates.

The down side (as you state above) is that a future request could have a 
different set of AVPs. However, I would claim that once you've asked for a
set of features, I don't understand why you'd want to change your mind
mid-course.

Given the above, is your concern answered?

PatC

---

From: "Bob Kopacz" <[email-masked]>
Date: Sun, 21 Oct 2001 13:43:09 -0400

Hi Pat,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Pat Calhoun
> Sent: Wednesday, October 17, 2001 7:59 AM
> To: Bob Kopacz
> Cc: Pat Calhoun; aaa-wg
> Subject: [AAA-WG]: Re: Handling of Duplicate Requests
> 

I think, yes.

I was blathering on a bit, sorry.  What I was trying to ask, and what
I am no longer asking, was:

1. When a home server receives a duplicate request, i.e. a request
whose Origin-Host and End-to-End-Identifier match a recent
previously-received request, should it examine the AVPs from the duplicate
request to confirm it is really a duplicate? [Answer:no].

2. If the AAAH detected a duplicate is not really a duplicate, how
should it handle this error? [Answer: not a question anymore, since
the AAAH doesn't make this check].

3. A theoretical question: Is it possible for a duplicate to not really
be a duplicate for legitimate reasons, such as one proxy modifying the
original request in one way, and a second proxy modifying the retransmission
in a different way?  [Answer: even if yes, any changes are inconsequential].

4. Should duplicate checking be done only by home servers, or should 
proxies also check their pending transaction queue for duplicates?
[Answer: only home servers].

5. If a home server recieves a duplicate, while the original is still pending,
then should it send an answer for both the original and the duplicate?
[Answer: yes]

Thanks,
Bob K.