RE: Issue 226: RFC 3576bis and Renumbering

"Glen Zorn \(gwz\)" <gwz@cisco.com> Mon, 21 May 2007 23:24 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 21 May 2007 23:25:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79BFF.37D7DE9A"
Subject: RE: Issue 226: RFC 3576bis and Renumbering
Date: Mon, 21 May 2007 16:24:44 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504009F5E@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Issue 226: RFC 3576bis and Renumbering
Thread-Index: Acebuwg9QmpyMwKsQ0aRQdGR6sEYuQAQknTQ
From: "Glen Zorn (gwz)" <gwz@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, aland@freeradius.org
Cc: radiusext@ops.ietf.org
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4458; t=1179789886; x=1180653886; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:=20RE=3A=20Issue=20226=3A=20=20RFC=203576bis=20and=20Renumbering |Sender:=20; bh=ECZQHnhhpoyFLcJcmvbJ5vtozJYUFekfE+/0fEm3/zA=; b=SuXa/PgD09VIIfsmfVspC9+gttbqOW5M8ii1jkPmFIZdaT0EJIr1yG3pZxkvSugYsuEXAmgT o0T2Yewd7gvIC2847fCb4ACGQqpB+YDeWdeu2upoaImYxQ7qzvbQdItC;
Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; );

> I think we'd be better off just making Acct-Session-Id a MUST, and
> ignoring the other attributes.

Making Acct-Session-Id a MUST would ensure Diameter compatibility. 
User-Name probably needs to be at least a MAY for the same reason.  
 
There are just a few problems with this idea (in the absence of RADIUS
accounting).  The first & most obvious is that "sessions" do not exist
in RADIUS.  This is because the RADIUS server has no idea when (or if)
the session ends or, more subtly, if it actually begins.  All the RADIUS
server  knows is that it authorized a session in an Access-Accept; by
the time that message arrived at the NAS, the user might already have
left.  So, basically, what you are saying seems to be that 

1.	
	deploying RADIUS accounting is mandatory AND
2.	
	an undefined but incestuous relationship between separate RADIUS
and RADIUS Accounting servers is also mandatory OR
3.	
	the RADIUS and RADIUS Accounting servers must be one and the
same

None of those seem like very good ideas to me.  Not to belabor the
point, but all these problems have been thought through and solutions
designed in
http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.txt.  
 
 ...