Subject: Re: (radius) Retransmission hints

From: Carl Rigney <[email-masked]>
Date: Thu, 25 Feb 1999 09:59:10 -0800 (PST)

>> If you wanted to use a new Request Authenticator when sending to the
>> backup server, you could (and would then have to use a new ID).
>
>Since its sending to a different server, it wouldn't necessarily need a
>new ID.

IDs are really (server, source port, ID) 3-tuples, so if you're sending to
a new server, its a new ID, even if the content of the ID field in the packet
hasn't changed.  But that may be confusing to explain.

Note that if you use different ID tracks for different servers, then the
server MUST use the address you sent to when replying to you.  Do we want
to make that explicit?

Do we want to require that IDs be tracked globally on a NAS, and not per
server?  At the moment we don't say one way or the other, but this is a subtle
enough point that I'd like to provide guidance in the updated draft.

People who need to have more than 256 requests outstanding can always
open additional source ports so there's no capacity issue either way.
I note in passing that hammering a server with 256+ requests
back-to-back before it even responds to the first one is hardly very
network or server friendly.

Thoughts on language concerning global ID vs. per-server ID?

--
Carl Rigney
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Steven P. Crain" <[email-masked]>
Date: Thu, 25 Feb 1999 13:17:23 -0500 (EST)

> Thoughts on language concerning global ID vs. per-server ID?

The issue of how a client interacts with many servers seems marginal.  
The purpose of the ID field is to allow a single client/server pair to
keep track of which reply is to which request.  What IDs the client uses
with other servers should not matter as far as the RADIUS protocol is
concerned.  So, I would press for per-server IDs being acceptible.

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net, An ISP with Excellence in the Greater Boston Area.

-

---

From: "Heath Partington" <[email-masked]>
Date: Thu, 25 Feb 1999 13:25:51 -0500

>     -----Original Message-----
>     From: [email-masked]
>     [mailto:[email-masked]]On Behalf Of Carl Rigney
>     Sent: Thursday, February 25, 1999 12:59 PM
>     To: [email-masked]
>     Cc: [email-masked]
>     Subject: Re: (radius) Retransmission hints
>
>

My implementation currently tracks ids on a per server basis.  Is there a
reason why a server would respond using a different address then the one the
client sent to?

I personally would not like to see the restriction that ids cannot be kept
per server as I have already implemented it that way.  One benefit of
keeping the ids per server is to prohibit the last case you talk about where
you bomb a single server with more than 255 requests.  Of course I guess you
could keep track of this separately...

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Thu, 25 Feb 1999 13:38:12 -0500 (EST)

> reason why a server would respond using a different address then the one the

Yes, on a multi-homed machine the response could come from any of the
interfaces.  The radius server needs special code to be able to make sure
its response comes from the same interface that received the request.

Many server implemenations simply bind to any incoming IP address, which
would not interoperate correctly with your client if the server was run on
a machine with more than one interface.

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net: Local Ties... World Class Connections

-

---

From: Alan DeKok <[email-masked]>
Date: Thu, 25 Feb 1999 14:23:17 -0500

Carl Rigney <[email-masked]> wrote:
>
> IDs are really (server, source port, ID) 3-tuples,

  Let me start another firestorm by saying I almost disagree.

  Say you've got a server which uniquely identifies requests based on
the client, source port, ID, and request code.  The clients use the
same source port for all messages (as do most clients I've seen).

  The server keeps track of the requests for a period of time, X, in
order to detect duplicate requests from the NAS.  After that time, the
server deletes the remembered requests/replies from it's cache.

  When the server is under heavy load from a client: 200+ requests per
second, where X is ~5s.  This server will then:

- send 256 replies to 256 client requests.

- ignore "duplicate" requests with the same client, source port, ID,
  and request code.  (Or send "duplicate" replies, the effect is the same)

- after the timeout period X has passed, it will start replying to
  requests again. 

  The net effect is that authentication becomes "bursty".  Lots of
people get authenticated, then more people wait a long time, then more
people get authenticated again.

  The only solution I could think of was to use the Request
Authenticator as part of the unique request identifier.  My reasoning
goes like this:

  IF the client is sending another request with the same code, ID, and
source port, it MUST either be a duplicate request, or a new request.

  IF it's a duplicate request, then the Request Authenticator MUST be
the same.

  IF it's a new request, then the Request Authenticator MUST be
different.

  IF it's a new request, then the client must have received the old
reply, and the server can throw away its saved copy of the old request.

  With these modifications, a server can do 256 requests per second,
with *all* requests having ID=0.  This gets rids of the "bursty"
problem, and flattens the response time.

> server MUST use the address you sent to when replying to you.  Do we want

  Yes.

> Do we want to require that IDs be tracked globally on a NAS, and not
> per server?  At the moment we don't say one way or the other, but
> this is a subtle enough point that I'd like to provide guidance in
> the updated draft.

  ID's SHOULD be tracked per server.

  If ID's are tracked globally, we run into the "pseudo duplicate"
problem above even more quickly.

  Alan DeKok.
-

---

From: "Heath Partington" <[email-masked]>
Date: Thu, 25 Feb 1999 15:20:00 -0500

>     [mailto:[email-masked]]On Behalf Of Steven P. Crain
>     Sent: Thursday, February 25, 1999 1:38 PM
>     To: Heath Partington
>     Cc: Carl Rigney; [email-masked]
>     Subject: RE: (radius) Retransmission hints
>
>

So the assumption here is that the server is listening on the same port for
all of these interfaces?  Shouldn't a multi-homed server have to put this
extra code in to insure that the return address is the same as the one it
received the request on?

-