[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Review of draft-ietf-radext-status-server

Thanks for the review. 

The Status-Server (12) and Status-Client (13) codes were allocated for
experimental use in RFC 2865 Section 3, which states:

"   Codes 12 and 13 are reserved for possible use, but are not further
mentioned here."

It had been my assumption that these codes had been implemented at the time
that RFC 2865 was published (June 2000), but perhaps that was not the case. 


-----Original Message-----
From: Ignacio Goyret [mailto:igoyret@alcatel-lucent.com] 
Sent: Thursday, January 21, 2010 3:30 PM
To: Bernard Aboba
Cc: igoyret@lucent.com; 'Alan DeKok'
Subject: Re: Review of draft-ietf-radext-status-server 

At 12:36 PM 1/11/2010 -0800, Bernard Aboba wrote:
>The document Use of Status-Server packets in the RADIUS protocol has now
completed RADEXT WG last call. 
> 
>Since the purpose of the document is to describe an existing deployed
protocol which was first implemented by Ascend Communications, we were
wondering if it would be possible for you to review the document for
accuracy. 
> 
>The document is available here:
>http://tools.ietf.org/html/draft-ietf-radext-status-server
> 

Hi guys,
Sorry for the delay, but I had to process some 6000 emails
after my vacation.

I don't know why you think that Ascend had implemented anything
like this. As far as I have been able to ascertain, neither our
RAS (MAX, TNT or APX) nor any of our RADIUS servers ever implemented
Server-Status. I even checked with the few folks still around
from the old Livingston (the creators of RADIUS) and got the
same story. Do you have any idea which product may have
implemented this? If you have any idea, let me know and
I'll try to find someone that can check the draft.


Anyway, I did a cursory review and have one technical comment
and a few trivial editorial fixes:

1) (tech comment) To be frank, both myself and our RADIUS engineers
were quite surprised that the response to a Server-Status is not
a code+1, or some other code like a fictitiuous "Server-Response".

The overloading of Access-Accept and Accounting-Response for
this purpose (response to a Server-Status command) is a bit
disconcerting and quite dangerous since it opens the door
for potentially bogus authentication.

I know that it is past WGLC so dramatic changes are out of
the question, but if nothing else, you should add some text
explaining the decision for this overloading.


2) page 6, section 2, 4th para:
                                                        vv
-   [RFC2865] Section 2.6.  "Keep-Alives" are sent when an downstream
+   [RFC2865] Section 2.6.  "Keep-Alives" are sent when a downstream
                                                        ^

3) page 6, section 2.1 title:

   Consider changing the title from:
       "Why Access-Request cannot be used"
   to something like:
       "Why Access-Request are not appropriate"

   This would make it more consistent with the 2.1.1 title
   which is a recommendation against, not a prohibition.

   Also, consider a similar change to the title section 2.2
   for the same reasons.

4) Page 10, first line:
                        vvvvvvv
-   same method as used for for calculating the Response Authenticator of
+   same method as used for calculating the Response Authenticator of
                        ^^^
5) page 20, section 6.2:

   The hex dump of the request is shown as:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   but it should be:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   (note change of "80" -> "50" in the 5th byte of the second line)

   Also, the response is wrong. It is shown as:

-----------------------(cut-here)-------------------------
      02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20 16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   but should be:

-----------------------(cut-here)-------------------------
      02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20
      16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   (two changes: "1a" -> "14" in the 4th byte of the first line,
    and a missing newline after "Length = 20").

HTH,
-Ignacio



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>