[Christopher.Carroll@ropesgray.com: RE: draft-carroll-dynmobileip-cdma-04.txt]

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

----- Forwarded message from "Carroll, Christopher P." <Christopher.Carroll@ropesgray.com> -----

Resent-Message-Id: <200503022012.j22KCk2w015488@rotala.raleigh.ibm.com>
Subject: RE: draft-carroll-dynmobileip-cdma-04.txt 
Date: Thu, 17 Feb 2005 09:12:21 -0500
From: "Carroll, Christopher P." <Christopher.Carroll@ropesgray.com>
To: "Frank Quick" <fquick@qualcomm.com>
Cc: "Thomas Narten" <narten@us.ibm.com>,
        "RFC Editor" <rfc-editor@rfc-editor.org>,
        "Russ Housley" <housley@vigilsec.com>,
        "Sam Hartman" <hartmans-ietf@mit.edu>,
        "David Kessens" <david.kessens@nokia.com>,
        gerry.flynn@verizonwireless.com
X-OriginalArrivalTime: 17 Feb 2005 14:12:22.0119 (UTC) FILETIME=[B2A0CF70:01C514FA]
Resent-To: aaa-doctors@ops.ietf.org
Resent-Date: Wed, 02 Mar 2005 15:12:46 -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

Hi Frank,

See my comment below.

> -----Original Message-----
> From: Frank Quick [mailto:fquick@qualcomm.com]
> Sent: Wednesday, February 16, 2005 3:45 PM
> To: Thomas Narten
> Cc: RFC Editor; gerry.flynn@verizonwireless.com; Carroll, Christopher
P.;
> Russ Housley; Sam Hartman; David Kessens
> Subject: Re: draft-carroll-dynmobileip-cdma-04.txt
> 
> 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?
> 

I agree that there appears to be confusion about the difference between
maintaining a PPP session and allowing access to the Internet (or some
other network).  Thus, it likely makes sense to clarify this distinction
in a revision.


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