<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: RADIUS Filter Rules</title>
	<atom:link href="http://www.seanconvery.com/weblog/2006/06/21/radius-filter-rules/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.seanconvery.com/weblog/2006/06/21/radius-filter-rules/</link>
	<description>Ruminations on Identity Management for Networks</description>
	<pubDate>Thu, 07 Aug 2008 19:56:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Sean Convery &#187; Blog Archive &#187; A De Jure ACL Format</title>
		<link>http://www.seanconvery.com/weblog/2006/06/21/radius-filter-rules/#comment-1598</link>
		<dc:creator>Sean Convery &#187; Blog Archive &#187; A De Jure ACL Format</dc:creator>
		<pubDate>Wed, 20 Dec 2006 20:04:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.seanconvery.com/weblog/?p=28#comment-1598</guid>
		<description>[...] Back in June I wrote about a new draft in the IETF RADEXT working group concerning access control lists (ACLs). The draft specified a way to generically format and transmit IP ACLs using RADIUS. The draft is now in its sixth revision and left the working group headed towards a proposed standard in the IETF. If approved, we will finally have a common technique for passing ACLs to a network enforcement device from a AAA server. The approach taken in this draft is to reuse the filter format defined within Diameter (scroll down to page 44 to see the format). To date, enforcement vendors have either relied on proprietary techniques for formatting these ACLs or have simply not supported them. It is very common today to see no support for the specific ACL but a more general support for the RADIUS Filter-Id attribute (attribute 11, page 35). The Filter-Id attribute is nice but it only allows the AAA server to point to a pre-existing filter on the enforcement device, not to create one on the AAA server. [...]</description>
		<content:encoded><![CDATA[<p>[...] Back in June I wrote about a new draft in the IETF RADEXT working group concerning access control lists (ACLs). The draft specified a way to generically format and transmit IP ACLs using RADIUS. The draft is now in its sixth revision and left the working group headed towards a proposed standard in the IETF. If approved, we will finally have a common technique for passing ACLs to a network enforcement device from a AAA server. The approach taken in this draft is to reuse the filter format defined within Diameter (scroll down to page 44 to see the format). To date, enforcement vendors have either relied on proprietary techniques for formatting these ACLs or have simply not supported them. It is very common today to see no support for the specific ACL but a more general support for the RADIUS Filter-Id attribute (attribute 11, page 35). The Filter-Id attribute is nice but it only allows the AAA server to point to a pre-existing filter on the enforcement device, not to create one on the AAA server. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
