RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

[Avi Lior <avi@bridgewatersystems.com>]

Hi Frank,

Comments inline.

> -----Original Message-----
> From: Frank Quick [mailto:fquick@qualcomm.com] 
> Sent: Tuesday, March 08, 2005 12:31 PM
> To: Avi Lior; Nelson, David; Avi Lior; gwz@cisco.com; W. Mark Townsley
> Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, 
> Christopher P.; gerry.flynn@verizonwireless.com; 
> radiusext@ops.ietf.org
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> My thinking as of this point is:
> 
> 2865 clearly states (multiple times) that VSAs cannot be in 
> Access-Reject.  Personally I think this is an unnecessary 
> requirement, but 
> I do not mind including a disclaimer indicating that this is a 
> noncompliance in the draft, and recommending that future work 
> not repeat 
> that noncompliance.

I agree that disallowing VSAs does seem today to be a tad harsh.  We need to
fix that...


> 2865 does _not_ state that an Access-Reject must result in 
> tearing down the 
> connection.  I think there is an old saying that "the 
> faintest writing is 
> better than the clearest memory."  In this case, no matter 
> what people 
> remember, there is no part of 2865 that can be cited as a 
> basis for the 
> draft's noncompliance with this non-requirement.  The 
> disclaimer could 
> state that the opinion of the IETF is that a client should 
> disconnect when 
> receiving an Access-Reject, and recommend that this be 
> required in future work.

I don't agree with the last sentence. To premature.  Its not the opinion of
the IETF that Access-Reject means tear down the PPP session.  I will fight
that tooth and nail. So I don't  think we need to set a precendant here.

Access-Reject means don't provide access to the user.  It doesn't
necessarily mean tear down the call.  What happens between the NAS and the
user device is not in scope of AAA.

  
> I no longer think it adds anything to change the paragraph in 
> which it is 
> required that the PPP connection be maintained, and I will 
> not include that 
> change in a revised draft.

You are free to do that.  But its should not be the mandatory behaviour of
RADIUS.
 
> In the current disclaimer, the sentence "Subsequent RFCs 
> allow for other 
> attributes to be included in an Access-Reject packet but 
> these are included 
> to indicate the reason the authentication/authorization has 
> failed" is 
> clearly false, given the usage in 2869, and should be 
> removed/replaced.

I agree. And thankyou for pointing this out to us. At least someone is
reading the documents ;-)
 
> I don't know whether Verizon will be ok with the sentence "As 
> a result, the 
> use of this specification in other circumstances than those 
> described in 
> the document is not recommended", but I have left it in for 
> the moment.
> 
> Possible wording is:
> 
>      This protocol defines how RADIUS (RFC 2865) is used in a
>      specific situation with vendor-specific protocol extensions.
>      It has been reviewed by the Radius community and the
>      following issues have been noted: (1) The document suggests
>      returning a vendor-specific attribute in an 
> Access-Reject message. 
> According to
>      RFC 2865 an Access-Reject packet MAY only include Reply-Message
>      and Proxy-State attributes, and the inclusion of vendor-specific 
> attributes
>      is expressly prohibited.  In future work, the use of an 
> Access-Challenge packet
>      to carry the vendor-specific attributes may be more 
> appropriate. (2) 
> It is also IETF's
>      recommendation that receipt of an Access-Reject at the 
> NAS terminate the
>      session of the attached network host.

No again take that out.  There is no consensus on this point.  And it may
break existing implmementations and requires further study.


>      As a result, the use of this specification in other 
> circumstances than
>      those described in the document is not recommended.  Any 
> future work 
> based on
>      this specification should take these issues into consideration.
> 
> At 11:44 AM 3/8/2005 -0500, Avi Lior wrote:
> >David,
> >
> >I agree that not all RFCs are equal.   I wasn't disputing that.
> >
> >But in practical terms, are you then saying that because 2869 is 
> >introducing an attribute into Access-Reject it is violating 
> 2865 which 
> >states:
> >
> >"No other Attributes (except Proxy-State) are permitted in an 
> >Access-Reject."
> >
> >So no EAP-Message, no Message Authenticator introduced in 2869
> >
> >Which then invalidates RFC 3579....
> >
> >Which puts RADIUS EAP in the toilet.
> >
> >If this is all true....why were we thinking when we wrote these 
> >documents. Why would we work on documents that are clearly violating 
> >RADIUS?  Why would the IESG approve such documents?
> >
> >I would hope clearly that the above logic is flawed.  And if 
> it is then 
> >lets apply it equally and move on.
> >
> >If the above logic is not flawed then....wow!!!
> >
> >Avi
> >
> > > -----Original Message-----
> > > From: Nelson, David [mailto:dnelson@enterasys.com]
> > > Sent: Tuesday, March 08, 2005 11:29 AM
> > > To: Avi Lior; gwz@cisco.com; Frank Quick; W. Mark Townsley
> > > Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, Christopher 
> > > P.; gerry.flynn@verizonwireless.com; radiusext@ops.ietf.org
> > > Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> > >
> > >
> > > Avi Lior writes...
> > >
> > > > Regarding: not all RFCs are created equal...
> > > > We have to be careful here.  This line of thinking is going
> > > to create
> > > > havoc.
> > >
> > > Havoc?  That sounds like an overstatement, IMHO.
> > >
> > > RFCs are issued as Informational for several reasons.  
> Some of those 
> > > reasons are (a) the protocol is not considered 
> sufficiently mature 
> > > to be considered as a Proposed Standard,
> > > (b) the protocol is vendor proprietary or has a limited scope of 
> > > applicability, and (c) the internet-draft was not the 
> product of any 
> > > IETF working group, a therefore has had more limited review.
> > >
> > > I suspect that some of the RADIUS RFCs issued after the RADIUS WG 
> > > closed fall into the (c) category.  Some of them may also have 
> > > fallen into the
> > > (a) category, at least at the time of publication.
> > >
> > > Glen is correct, however, in his statement.
> > >
> 
> 
> 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
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>