[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/>