[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-carroll-dynmobileip-cdma-04.txt (fwd)
Here is Glen Zorn's review.
---------- Forwarded message ----------
Date: Wed, 2 Mar 2005 22:44:40 -0800
From: "Glen Zorn (gwz)" <gwz@cisco.com>
To: christopher.carroll@hbsr.com, fquick@qualcomm.com
Cc: radiusext@ops.ietf.org, gwz@cisco.com
Subject: Comments on draft-carroll-dynmobileip-cdma-04.txt
Hi. I was recently asked to review this document and during the
review I noticed a couple of problems. In particular, the document
appears to unnecessarily violate RFC 2865. For example: "The RADIUS
AAA Server MUST support a subscriber specific MIP Update State
Field. When the MIP Update State Field set to UPDATE KEYS (1), the
RADIUS AAA Server MUST initiate the DMU procedure by including the
MIP_Key_Request attribute in an Access Reject message sent to the
PDSN...Note that the inclusion of a vendor-specific attribute in the
Access Reject message is not consistent with section 5.44 of [4]. A
RADIUS AAA server that supports DMU SHOULD NOT include a
vendor-specific attribute if the corresponding Access Request
message was not received from a DMU-compliant PDSN." However, the
PPP connection is not closed, even though an Access-Reject was
received (thus modifying the semantics of the Access-Reject
message). Looking at section 4.11, however, it appears that these
violations could easily be avoided through the use of
Access-Challenge instead of Access-Reject. Is there some reason why
you feel that Access-Challenge is inappropriate in this situation?
In addition, I couldn't find any reference to message integrity
protection. Did I just miss it?
~gwz
--
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/>