[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
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
> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:firstname.lastname@example.org]
> Sent: Thursday, March 03, 2005 2:08 PM
> To: 'Frank Quick'; email@example.com
> Cc: firstname.lastname@example.org; 'W. Mark Townsley'; Thomas Narten
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> Frank Quick <mailto:email@example.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
> > 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
> > 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
> > 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,
> > 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
> > RFC, but they are powerless to prevent DMU from being used as is.
> > 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
> >> appears to unnecessarily violate RFC 2865. For example: "The
> >> AAA Server MUST support a subscriber specific MIP Update
> State Field.
> >> When the MIP Update State Field set to UPDATE KEYS (1),
> >> RADIUS AAA Server MUST initiate the DMU procedure by including
> >> MIP_Key_Request attribute in an Access Reject message sent to the
> >> PDSN...Note that the inclusion of a vendor-specific attribute in
> >> Access Reject message is not consistent with section 5.44 of .
> >> 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,
> >> 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
> >> violations could easily be avoided through the use of
> >> Access-Challenge instead of Access-Reject. Is there some reason
> >> you feel that Access-Challenge is inappropriate in this
> >> 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 firstname.lastname@example.org
> > RSA: 29EA D619 31F2 B4D3 8815 3D59 4340 FA43
> > D-H: 2A24 131C D38F 12E6 4D6A 46EE 8BBF B50A 754E F63D
> Hope this helps,
> 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
> email@example.com 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.