[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: <200503022010.j22KAZ8J015452@rotala.raleigh.ibm.com>
From: Gerry.Flynn@VerizonWireless.com
X-Host: redstone.odc.vzwcorp.com
X-MID: 127870629
To: narten@us.ibm.com, fquick@qualcomm.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:02:25 -0500
Resent-To: aaa-doctors@ops.ietf.org
Resent-Date: Wed, 02 Mar 2005 15:10:35 -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

Thomas

Thank you for the e-mail and heads up with respect to additional discussion
of our submission.  As a matter of update to Frank Quick's 29 October 2003
note, Verizon Wireless has expanded its commercial deployment of 1xEV-DO to
cover over 75 million population across thirty large metropolitan areas.  We
have also shared DMU with other Operators both domestically and
internationally and intent is to point Operators to IETF for use of this
submission. 

Please advise if we can provide any additional information to you in support
of the submission.


Thank you

Gerry

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



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


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