Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt

Bernard Aboba writes:

 > I'm just trying to understand what changes to the RADIUS protocol are
 > required to meet *all* the requirements for this application, not just
 > configuration and authentication of (PP)VPNs. If configuration and
 > authentication of (PP)VPNs were all we are talking about then this might
 > be supported by just allocating some new values of the attributes defined
 > in RFC 2868 (e.g. new Tunnel-Type, etc.), without adding any new protocol
 > messages or even attributes. That's all we had to do in order to support
 > RADIUS-configured VLANs.

as i said in my previous message, the pe discovery application does not
require any changes to radius protocols nor do i propose any changes.
of course radius protocols could be improved in various ways, but those
improvements are not mandatory in order to make pe discovery work.

 > So by nature this discussion is going to focus on the "fringe" areas of
 > the proposal -- since the core of it is well within established uses of
 > RADIUS. The goal is to see if *all* the requirements can easily be
 > accomodated within existing facilities or not -- and if not, how far we
 > have to go in order to accomodate the needs.

i have tried to meet all requirements using existing facilities.  since
radius protocol does not include any keepalive mechanism between the nas
and the server, the pe discovery application uses interim accounting
requests for that purpose.  that is, however, just a particular
application of the radius accounting protocol that doesn't change the
protocol itself.  if you have a better means to achieve the same goal,
i'm more than happy to change the draft accordingly.

 > In draft-chiba, dynamic authorization facilities are added that allow the
 > RADIUS server to reprovision a session. 

there is no such need in the pe discovery application that i have
described.

 > The RADIUS IANA considerations draft outlines the procedures necessary for
 > allocation of RADIUS packet types, attributes and values.  This has been
 > tightened up somewhat compared to what was in RFC 2865.

the latest version of my draft
ftp://lohi.eng.song.fi/tmp/draft-heinanen-radius-pe-discovery-04.txt
which details the protocol, defines one new service type (VPN-Login) and
one new attribute (PE-List) that of course need to get assigned code
points according to the iana procedures.

-- juha