[fquick@qualcomm.com: Re: draft-carroll-dynmobileip-cdma-04.txt]

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

----- Forwarded message from Frank Quick <fquick@qualcomm.com> -----

Resent-Message-Id: <200503022012.j22KCL7D015481@rotala.raleigh.ibm.com>
Date: Wed, 16 Feb 2005 12:45:15 -0800
To: Thomas Narten <narten@us.ibm.com>
From: Frank Quick <fquick@qualcomm.com>
Subject: Re: draft-carroll-dynmobileip-cdma-04.txt 
Cc: RFC Editor <rfc-editor@rfc-editor.org>, gerry.flynn@verizonwireless.com,
        "Carroll, Christopher P." <Ccarroll@ropesgray.com>,
        Russ Housley <housley@vigilsec.com>,
        Sam Hartman <hartmans-ietf@mit.edu>,
        David Kessens <david.kessens@nokia.com>
X-PMX-Version: 4.7.0.111621
Resent-To: aaa-doctors@ops.ietf.org
Resent-Date: Wed, 02 Mar 2005 15:12:21 -0500
Resent-From: Thomas Narten <narten@us.ibm.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1

At 07:35 AM 2/16/2005 -0500, Thomas Narten wrote:
>Frank Quick <fquick@qualcomm.com> writes:
>
>> 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.
>
>I'm all in favor of getting as much understanding on this issue as
>possible.
>
>A followup to your remarks:
>
>> The RFC 2865 prohibition is strictly adhered to in all RADIUS RFCs - the
>> only attributes allowed in an Access-Reject are those which can inform the
>> user as to why they have been denied access (Reply-Message,
>> EAP-Message/Failure, etc.) or those that route the message to the right
>> NAS/Port/User (Proxy-State, etc.).
>
>> In particular, VSAs MUST NOT be included within an Access-Reject, since
>> that would open the door to providing service to users to whom access has
>> been denied.



>Given the MUST NOT, existing NAS devices may silently
>> discard these attributes if sent.

But then DMU wouldn't work; or, then the existing NAS device that discards 
the VSA would not be acceptable for use in the Verizon system.  The fact is 
that DMU works when the network devices support it, and may not work 
otherwise.  That is a practical consideration but not a reason to prohibit 
similar use of VSAs in a vendor-specific environment.  Anyway, one can 
clearly see that your current MUST NOT has about as much effect as the 
Maginot line.

>> Frank does make an argument that this particular VSA is used for the
>> purpose of informing the user that they have been denied access and need 
>to
>> change keys.  However, the document also requires that the NAS not tear
>> down service to the user after receipt of an Access-Reject:
>
>>    Upon receipt of an Access Reject containing the
>>    MIP_Key_Update_Request VSA, PDSN MUST send an RRP to the MN with the
>>    MIP_Key_Request VSE.  The PDSN MUST use the RRP error code = 89
>>    (Vendor Specific) and MUST not tear down the PPP session after
>>    transmission.

I see the point of confusion.  In my mind, at least, service is not 
provided unless the terminal is allowed general Internet access.  That is 
not synonymous with retaining a PPP session, which of itself only provides 
a link through which DMU can be performed.  The PPP requirement is quite 
specific to the CDMA air interface and should probably be clarified as 
such.  I would, in fact, argue that the DMU draft should not specify CDMA 
air interface requirements, but instead should have a more general 
requirement about retaining a connection to the terminal through which DMU 
can be performed.  Perhaps a note about PPP as an example for CDMA would be 
useful.  I would even suggest that the network should (must?) not allow 
access to the Internet in general until after successful authentication.

Chris, Gerry, would that be an acceptable direction for a revision?  Would 
that help the problems noted by the IETF folks?

>> So overall, I'm not clear about whether in fact Access has been denied, or
>> not.  The test would be whether the user could gain the ability to send a
>> network layer packet (e.g. complete IPCP) without having to
>> reauthenticate.
>
>> Had such an attribute been sent within an Access-Challenge rather than an
>> Access-Reject, there would be no issue at all.  I'd also argue that if a
>> standard attribute had been used, rather than a VSA (such as if the
>> message were sent within a Reply-Message attribute), there would be no
>> issue.

I would agree with that, but unfortunately we are stuck with the current 
DMU since it is already in use.

>Thomas


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

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