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

>Bernard is one of the main contributors to the RADIUS development, from
>his point of view this is not limited, it is applying a tool when RADIUS
>is proposed to be used in a new context, which I would think is highly
>appropriate.

Given what has already been done in RFC 2867-2868, use of RADIUS for VPN
configuration and setup isn't new. Such an application is well
established.  So I don't really see anything intrinsically wrong with
using RADIUS to authenticate and configure (PP)VPNs.

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.

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.

To that end, it would be helpful for people to take a look at some of the
latest RADIUS drafts, in particular:

http://www.ietf.org/internet-drafts/draft-chiba-radius-dynamic-authorization-20.txt
http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-29.txt
http://www.ietf.org/internet-drafts/draft-aboba-radius-iana-07.txt

In draft-chiba, dynamic authorization facilities are added that allow the
RADIUS server to reprovision a session. This is a bit tricky in that the
user may not necessarily know that their session has been reprovisioned --
if the VLAN or VPN were changed in mid-stream, for example.  So there
needs to be some user-NAS signalling in some cases and that may be media
dependent.

In draft-congdon, RADIUS is used to provision VLANs. This can be used to
provide layer 2 mobility, or perhaps just to allow centralized
MAC-address, user or port-based VLAN administration.

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.