[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Review of draft-ietf-radext-status-server
-----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/>