Subject: Re: (usr-tc) Radius question

From: Steve Valiunas <[email-masked]>
Date: Wed, 13 Oct 1999 05:24:38 +0000

Aaron & Corneliu,

>RFC states as clear as posibile: "For retransmissions where the contents
>are identical, the Identifier MUST remain unchanged.".

And the RFC warns just as clearly in the next sentence: " Note that if
Acct-Delay-Time is included
in the attributes of an Accounting-Request then the Acct-Delay-Time value will
be updated when
the packet is retransmitted, changing the content of the Attributes field and
requiring a new
Identifier and Request Authenticator."

 If you look closer at the retransmitted accounting packet you will notice that
it is NOT identical, due to
this fact. Therefore the packet MUST have a new identifier.

>My question: how is suposed a Radius server to identify the duplicates?

  This is a tough one-
  The radius server needs to be able to overcome the shortcomings of the
radius protocol.  It Can't rely simply on a single field that allows
only values of 1 to 254 to decide if it's seen a packet before. Imagine
a busy server- taking 1000 or more requests a second...
  One solution might be for the server to build it's own key- based on
NAS_IP,  SESSION_ID, and USER_NAME for example.  That would make the
packets pretty unique in most situations. This is the method used by the
latest version of 3Com's security server.

>>But later, when it comes time to send another request, it has
>>"forgotten" that it previously incremented the identifier and merrily
>>uses the last one again!

 Can you send along an example of this happening (using the same packet-ID
twice in a row for the same destination port and with current HiperArc code)?
If it is an issue it will be fixed.  Keep in mind though that it only
takes a couple hundred packets to wrap back around and reuse the same ID
again.

>The Radius server is supposed to contact the System Administrator
>and get him to purchase products from a vendor that knows how to
>read a RFC, or, failing that, at least fixes problems when they
>are pointed out to them.

What exactly was it that 3com missed in the RFC?

You can send the trace directly to me if you don't want to post to the list.

    Thanks,
     [email-masked]

Aaron Nabil <[email-masked]> on 10/12/99 08:14:07 PM

Please respond to [email-masked]

Sent by:  Aaron Nabil <[email-masked]>

To:   [email-masked]
cc:    (Steve Valiunas/MW/US/3Com)
Subject:  Re: (usr-tc) Radius question

Corneliu Rudeanu writes...
>I was really surprised to see how HARC deals with the radius packet
>identifier.
>
>RFC states as clear as posibile: "For retransmissions where the contents
>are identical, the Identifier MUST remain unchanged.".
>
>Yet watching (monitor radius) the id-s of the packets being retransmited I
>found that hiperArc (4.2.29) assigns diferrent id for the packets being
>re-sent to radius server for the same accounting request.

Hah!  It's much better than that!  (Note the date, too!)

>From: Aaron Nabil <[email-masked]>
>Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit
>Date: 14 Jun 1998 16:58:15 -0700 (PDT)
>
>
>The HiperArc has a nasty Radius bug.
>
>If a packet get lost in transit or for some other reason is never
>acknoweldged, the HiperArc increments the identifier and tries
>sending it again after the timeout period.
>
>But later, when it comes time to send another request, it has
>"forgotten" that it previously incremented the identifier and merrily
>uses the last one again!

Not only does it incorrectly increment the identifier, it then
goes on to re-use the same identifier again later!  Yes, this is
so incredibly broken it's not even imaginable that it hasn't
been fixed.  But it hasn't.

>My question: how is suposed a Radius server to identify the duplicates?

The Radius server is supposed to contact the System Administrator
and get him to purchase products from a vendor that knows how to
read a RFC, or, failing that, at least fixes problems when they
are pointed out to them.

--
Aaron Nabil

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: [email-masked]
Date: Wed, 13 Oct 1999 14:19:02 +0000

U>Aaron & Corneliu,

U>>RFC states as clear as posibile: "For retransmissions where the
U>contents >are identical, the Identifier MUST remain unchanged.".

U>And the RFC warns just as clearly in the next sentence: " Note that if
U>Acct-Delay-Time is included
U>in the attributes of an Accounting-Request then the Acct-Delay-Time
U>value will be updated when
U>the packet is retransmitted, changing the content of the Attributes
U>field and requiring a new
U>Identifier and Request Authenticator."

U> If you look closer at the retransmitted accounting packet you will
U>notice that
U>it is NOT identical, due to
U>this fact. Therefore the packet MUST have a new identifier.

U>>My question: how is suposed a Radius server to identify the
U>duplicates?

U>  This is a tough one-
U>  The radius server needs to be able to overcome the shortcomings of
U>the radius protocol.  It Can't rely simply on a single field that
U>allows only values of 1 to 254 to decide if it's seen a packet before.
U>Imagine a busy server- taking 1000 or more requests a second...
U>  One solution might be for the server to build it's own key- based on
U>NAS_IP,  SESSION_ID, and USER_NAME for example.  That would make the
U>packets pretty unique in most situations. This is the method used by
U>the latest version of 3Com's security server.

Do you mean 6.09 ?  If so, what about 6.08 ?

Jeff Binkley
ASA Network Computing

U>    Thanks,
U>     [email-masked]

CMPQwk 1.42 9999

-

---

From: Aaron Nabil <[email-masked]>
Date: Wed, 13 Oct 1999 16:41:26 +0000

Steve Valiunas writes...
> . . . 

Sure.  As it happens, I still had the patch in my Radius to test
this, just a matter of changing the values.

First thing I tested was the auth, it now works fine, it doesn't
change the id on retransmit, and after a retransmit it correctly
increments the id.  If this was fixed intentionally, thanks.

Here's the acct test.  I patched our radius server to ignore request
ID 205.  I logged in, logged out (but ignored the stop), logged back
in, and the NAS has re-used ID 206 from the "retransmit" of the stop
for the start.

Code:       Accounting-Request
Identifier: 204
Attributes:
        Class = "902"
        User-Name = "nabil"
        Acct-Status-Type = Start
        Acct-Session-Id = "16777229"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Service-Type = Framed-User
        NAS-Port-Type = Async
        NAS-Port = 25
        USR-Modem-Training-Time = 18
        USR-Interface-Index = 1513
        USR-Chassis-Call-Slot = 2
        USR-Chassis-Call-Span = 1
        USR-Chassis-Call-Channel = 1
        USR-Unauthenticated-Time = 4
        Calling-Station-Id = ""
        USR-Modulation-Type = v90Digital
        USR-Simplified-MNP-Levels = ccittV42
        USR-Simplified-V42bis-Usage = ccittV42bis
        USR-Connect-Speed = 46666_BPS
        Framed-Protocol = PPP

Code:       Accounting-Response
Identifier: 204
Attributes:

Code:       Accounting-Request
Identifier: 205
Attributes:
        Class = "902"
        User-Name = "nabil"
        Acct-Status-Type = Stop
        Acct-Session-Id = "16777229"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Service-Type = Framed-User
        NAS-Port-Type = Async
        NAS-Port = 25
        USR-Modem-Training-Time = 18
        USR-Interface-Index = 1513
        USR-Chassis-Call-Slot = 2
        USR-Chassis-Call-Span = 1
        USR-Chassis-Call-Channel = 1
        USR-Unauthenticated-Time = 4
        Calling-Station-Id = ""
        USR-Modulation-Type = v90Digital
        USR-Simplified-MNP-Levels = ccittV42
        USR-Simplified-V42bis-Usage = ccittV42bis
        USR-Connect-Speed = 46666_BPS
        Framed-Protocol = PPP
        Acct-Session-Time = 9
        Acct-Terminate-Cause = User-Request
        Acct-Input-Octets = 440
        Acct-Output-Octets = 289
        Acct-Input-Packets = 15
        Acct-Output-Packets = 13

Code:       Accounting-Request
Identifier: 206
Attributes:
        Class = "902"
        User-Name = "nabil"
        Acct-Status-Type = Stop
        Acct-Session-Id = "16777229"
        Acct-Delay-Time = 60
        Acct-Authentic = RADIUS
        Service-Type = Framed-User
        NAS-Port-Type = Async
        NAS-Port = 25
        USR-Modem-Training-Time = 18
        USR-Interface-Index = 1513
        USR-Chassis-Call-Slot = 2
        USR-Chassis-Call-Span = 1
        USR-Chassis-Call-Channel = 1
        USR-Unauthenticated-Time = 4
        Calling-Station-Id = ""
        USR-Modulation-Type = v90Digital
        USR-Simplified-MNP-Levels = ccittV42
        USR-Simplified-V42bis-Usage = ccittV42bis
        USR-Connect-Speed = 46666_BPS
        Framed-Protocol = PPP
        Acct-Session-Time = 9
        Acct-Terminate-Cause = User-Request
        Acct-Input-Octets = 440
        Acct-Output-Octets = 289
        Acct-Input-Packets = 15
        Acct-Output-Packets = 13

Code:       Accounting-Response
Identifier: 206
Attributes:

Code:       Accounting-Request
Identifier: 206
Attributes:
        Class = "902"
        User-Name = "nabil"
        Acct-Status-Type = Start
        Acct-Session-Id = "16777230"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Service-Type = Framed-User
        NAS-Port-Type = Async
        NAS-Port = 25
        USR-Modem-Training-Time = 18
        USR-Interface-Index = 1513
        USR-Chassis-Call-Slot = 2
        USR-Chassis-Call-Span = 1
        USR-Chassis-Call-Channel = 1
        USR-Unauthenticated-Time = 5
        Calling-Station-Id = ""
        USR-Modulation-Type = v90Digital
        USR-Simplified-MNP-Levels = ccittV42
        USR-Simplified-V42bis-Usage = ccittV42bis
        USR-Connect-Speed = 46666_BPS
        Framed-Protocol = PPP

** Sending to 208.130.244.232 port 1646 ....
Code:       Accounting-Response
Identifier: 206
Attributes:

Code:       Accounting-Request
Identifier: 207
Attributes:
        Class = "902"
        User-Name = "nabil"
        NAS-IP-Address = 208.130.244.232
        Acct-Status-Type = Stop
        Acct-Session-Id = "16777230"
        Acct-Delay-Time = 0
        . . .

> . . .

The part about unique identifiers.  Ie, using the same identifier for
two packets in a row isn't good.  Above, you re-used 206.

In addition to fixing this obviously broken behavior, how about providing
a configurable on the hiperarc to suppress the "acct-delay" so that 
retransmitted packets would be identical (and have the same ID), and thus 
easily filtered out by less sophisticated radius servers?

-- 
Aaron Nabil

-