RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Frank Quick <mailto:fquick@qualcomm.com> supposedly scribbled:

> You're not the first to raise these issues.  

Actually I think that I might have been the first, several years
ago, I certainly must not be the only one since I would expect
anyone with a cursory knowledge of RFC 2865 and more than 3 firing
neurons (I think I still have 4 or 5 ;-) to make the same
observations. 

> Had the protocol not
> already been deployed in millions of EV-DO devices, we might be
able
> to make such changes.  

Does Verizon really have millions of PDSNs deployed?  

> But since it is deployed, and working, changes
> aren't feasible.   
> 
> I suppose that if IETF had an interest in creating a new,
> standards-track version of DMU, that version could include changes
to
> address the issues that have been identified.  
> 
> Regarding the "violation" of 2865, this is not the only use of
> vendor-specific attributes in access reject messages; other RFCs
also
> do this.  

I am apparently ignorant of these RFCs; would you mind providing
references to them?

> IMHO, the restriction on VSA in 2865 is unnecessary; and
> since we seem to be able to do it without negative consequences,
the
> restriction is also impractical to enforce.  

Indeed; in fact, standards have little use in a closed system.  I
actually see the inclusion of VSAs as a relatively minor offense; in
my mind the modification of the Access-Reject semantics is much more
serious.

> As I pointed out to
> others, IETF may be able to block the publication of this draft as
an
> RFC, but they are powerless to prevent DMU from being used as is.
I
> don't see the harm in making the protocol publicly available as an
> RFC for those who may want to make interoperable devices.  

If the RADIUS portion of the protocol had been designed correctly,
it would have automatically been interoperable and we wouldn't be
having this conversation.  As for harm & benefit, the harm lies in
the IETF laying its imprimatur (even as informational) upon a
document which rather brazenly violates an IETF standard; it's
difficult to see the benefit in publishing what amounts to an
advertisement for Verizon/Qualcomm IPR.  It's a shame, because
portions of the draft are really quite clever.
  
> 
> The security of the protocol in general is somewhat minimal, but
> conforms to the customer requirements.  A saving grace is that the
> terminal cannot initiate DMU unless it is enabled by the network. 
> That limits the window for any type of attack to the brief period
> when DMU is enabled.    
> 
> At 10:44 PM 3/2/2005 -0800, Glen Zorn \(gwz\) wrote:
>> 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
> 
> 
> Frank Quick
> office   +1-858-658-3608 fax +1-858-651-1940
> portable +1-619-890-5749
> paging   fquick@pager.qualcomm.com
> RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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