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

[Avi Lior <avi@bridgewatersystems.com>]

Well Glen is right we all noticed it.

But originally DMU was for Verizon only and instead of making waves we just
let it slide - since it was already being deployed.

So maybe that was the wrong thing to do.


Perhaps the way forward is to make a note of the "error(s)" in the
Informational RFC?



> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
> Sent: Thursday, March 03, 2005 2:08 PM
> To: 'Frank Quick'; christopher.carroll@hbsr.com
> Cc: radiusext@ops.ietf.org; 'W. Mark Townsley'; Thomas Narten
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> 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/>
> 

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