[Gerry.Flynn@VerizonWireless.com: RE: draft-carroll-dynmobileip-cdma-04.txt]

[David Kessens <david.kessens@nokia.com>]

----- Forwarded message from Gerry.Flynn@VerizonWireless.com -----

Resent-Message-Id: <200503022011.j22KBTkh015467@rotala.raleigh.ibm.com>
From: Gerry.Flynn@VerizonWireless.com
X-Host: atlas.odc.vzwcorp.com
X-MID: 127923355
To: fquick@qualcomm.com, narten@us.ibm.com
Cc: rfc-editor@rfc-editor.org, Ccarroll@ropesgray.com, housley@vigilsec.com,
        hartmans-ietf@mit.edu
Subject: RE: draft-carroll-dynmobileip-cdma-04.txt 
Date: Tue, 15 Feb 2005 14:34:36 -0500
Resent-To: aaa-doctors@ops.ietf.org
Resent-Date: Wed, 02 Mar 2005 15:11:29 -0500
Resent-From: Thomas Narten <narten@us.ibm.com>
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,FORGED_MUA_IMS,
	MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=3.0.1

Frank

We have had discussions and shared information on DMU with several Carriers
who are planning to launch Ev-DO networks but they are not commercial yet. 

_____________
Gerry Flynn
Verizon Wireless 
Adv. Technology & Strategy 
Phone: (908)-306-6895 
Fax: (908)-306-7240
E-Mail: gerry.flynn@VerizonWireless.com 



-----Original Message-----
From: Frank Quick [mailto:fquick@qualcomm.com]
Sent: Tuesday, February 15, 2005 2:26 PM
To: Thomas Narten
Cc: RFC Editor; Flynn, Gerry J; Carroll, Christopher P.; Russ Housley;
Sam Hartman
Subject: Re: draft-carroll-dynmobileip-cdma-04.txt 


Thanks for the update.  Sorry this has been such a struggle.

I am unaware that anyone other than Verizon Wireless is actually using 
DMU.  Within their network it is my understanding that every CDMA EV-DO 
device uses DMU.  (Gerry, anything to add?)

The discussion of this central issue terminated shortly after I pointed out 
that RFC 2869, Radius extensions contains three attributes that are added 
as allowed in access-reject (see 5.19).  Perhaps we can continue the 
discussion.

One could argue that 2865's prohibition, "No other Attributes (except 
Proxy-State) are permitted in an Access-Reject" applies only to the 
attributes defined in 2865, and not to extensions as defined in 
2869.  Further, I suppose the philosophical stance taken below would argue 
that these new attributes are not intended to be delivered to the user, 
hence do not violate the (unwritten) intent of 2865.  But I think the 
philosophy here is misguided, and overly restrictive on the use of 
vendor-specific attributes.

The comment is made that 2865 does not allow any service provisioning 
attributes in Access Reject.  However, 2865 does not contain the phrase 
"service provisioning", nor do any of the attributes defined in 2865 appear 
to have anything to do with service provisioning.  I doubt the authors of 
2865 anticipated the over-the-air provisioning that is performed in 
cellular systems, which would explain why there is no allowance for it.  To 
perform provisioning of the sort done in DMU, the AAA must have a means to 
indicate to the terminal and serving system that the terminal should be 
denied access to Internet service until it has performed a key 
update.  That is the function of the vendor-specific attribute in the 
Access Reject.

The only alternative I can see is to add a new message to RADIUS to signal 
that a key update is required.  That avoids all the rules in 2865, though 
perhaps the philosophical objection might resurface in a different 
form.  In any case, I hope we will all agree that extending the use of 
vendor-specific attributes is far simpler than adding a new message.

Given the state of affairs, the IESG can block the publication of this RFC, 
but it is too late to prevent the use of DMU.  The reality is that IETF has 
little control over what vendors do with vendor-specific 
attributes.  Perhaps that's as it should be, otherwise why allow such 
attributes to exist?

At 01:37 PM 2/15/2005 -0500, Thomas Narten wrote:
>Hi.
>
>The IESG is (once again) going to discuss this document during its
>teleconference on Thursday. My hope is we'll come to some closure.
>
>For RFC Editor submissions, the IESG is now using RFC 3932 as a guide
>for how to review such submissions. Using 3932 as a guide, the
>following point is at issue:
>
> >    5. The IESG thinks that this document extends an IETF protocol in a
> >       way that requires IETF review and should therefore not be
> >       published without IETF review and IESG approval.
>
>As has been discussed before, the central issue with this document is
>its apparent extension of radius, by including an attribute where it
>is specifically forbidden to do so via an explicit MUST NOT. Different
>people may disagree as to the significance of this change, but one
>expert indicates:
>
> > The particular case under discussion is somewhat unique, in that it not 
> only
> > violates a MUST NOT -- but it also represents a major change to the 
> security
> > model of the protocol in question.
> >
> > Authentication, Authorization and Accounting protocols are built on a
very
> > fundamental idea:  that AAA servers can unambigously allow or deny 
> access to
> > the network.  Denying access means that the user cannot access network
> > services, except possibly to re-attempt authentication.
> >
> > RFC 2865 Section 2 states:
> >
> > "If desired, the server MAY include a text message in the Access-Reject
> > which MAY be displayed by the client to the user.  No other
> > Attributes (except Proxy-State) are permitted in an Access-Reject."
> >
> > Table 5.44 of RFC 2865, indicates that inclusion of a vendor-specific
> > attribute (or indeed any service provisioning attribute) in an 
> Access-Reject
> > is a MUST NOT:
> >
> >    Request   Accept   Reject   Challenge   #    Attribute
> >    0+        0+       0        0+          26   Vendor-Specific
> >
> > There is a simple reason for this.
> >
> > Since an Access-Reject results in denied access, there is no service
that
> > can be provided to the user, other than perhaps routing the Reject
message
> > to the right NAS or explaining to the user why they have been denied 
> access.
> >   To provision a service to a denied user would imply that they have not
> > been denied access after all.
> >
> > Provisioning a service with an Access-Reject is like redefining a "Deny"
> > packet filter to allow packets to pass through, or defining a "null
> > authentication" mode for IKE.
> >
> > The RADIUS specifications generally take a lax attitude toward security,
> > doing only the minimal amount of work to avoid wholesale compromise.  So
> > when MUST NOT language is used, that's  a sign that the practice in 
> question
> > is not just another bad idea, but so bad that even RADIUS could not
abide
> > it.
>
>Anyway, reviewing some of the mail on this topic, I found:
>
>Frank Quick <fquick@qualcomm.com> writes:
>
> > Date: Wed, 29 Oct 2003 11:04:02 -0800
>
> > I know I received these questions, and I thought that I had even sent a
> > response, but similarly I can find no record of either.  Subject to
> > comment/change by Verizon, here is a tentative answer.
>
> >    - does this describe something that has already been deployed? If
> >      so, by whom and how widely?
>
> > Yes, it's deployed by the vendors supporting Verizon Wireless' 1xEV-DO
> > system, which is now commercial in Washington, DC and San Diego, CA.
>
> >    - Is this something that is Verizon-specific? Are other operators
> >      using it (or planning on using it)? If Verizon-specific, it would
> >      be customary to change the title to make this more clear.
>
> > At the moment it is only in use by Verizon Wireless, however the intent
of
> > publishing is to make it available for others who may wish to use it.
>
>Can you comment on the current state of use/deployment of this system?
>Has it expanded beyond what is described above?
>
>Thomsa


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
___________________________________________________________________
The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure.  If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof.  Thank you.

----- End forwarded message -----