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

[Avi Lior <avi@bridgewatersystems.com>]

I know its not your decision nor mine. We just put out 2 cents worth in.

So at least lets recommend text that makes us sleep well at night lol.

> -----Original Message-----
> From: Frank Quick [mailto:fquick@qualcomm.com] 
> Sent: Tuesday, March 08, 2005 1:32 PM
> To: Avi Lior; 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
> 
> 
> I am ok with including or not including issue (2) - I agree with your 
> argument completely but it is not my decision to make.
> 
> At 01:15 PM 3/8/2005 -0500, Avi Lior wrote:
> >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
> > >
> 
> 
> 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/>