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

> neither is this application requiring any dynamic changes to user
> sessions as covered by draft-chiba-radius-dynamic-authorization-20.txt.
> in particular, the pe discovery application described in my draft does
> not require or need the radius server to send any unsolicited messages
> for any purpose to the pes.

My question is how dynamic changes to user sessions are being handled.

The draft states that:

   In addition to the above manually configured information, Radius
   keeps dynamically track of the PEs of the VPN as described below
   (Protocol Operation)."

Typically, once the attributes described in RFC 2868 are sent, the RADIUS
server does not monitor the resulting tunnels. So I'm not clear
exactly what the RADIUS server is expected to do to "dynamically track".

I'm also still unclear about whether the CEs also use RADIUS.

For example, the draft states "It is envisioned that a similar Radius
based mechanism can be used by CEs of a CE-based VPN to discover the other
CEs of the VPN."

The problem is that RADIUS is not a protocol in which users (CEs)
participate directly to discover other users.

With respect to the following paragraph:

"  When a CE is to be connected to a VPN at a PE, the PE issues a Radius
   Access-Request using the user name and password of the CE.  The PE
   has either learned this information from the CE via an authentication
   protocol, for example, 802.1x/EAP, or it has been configured in the
   PE."

RADIUS either assumes that the user (CE) performs authentication, or
that a Service-Type="Call Check" is being performed where the user (CE) is
authorized based on attributes such as Called-Station-Id and
Calling-Station-Id (e.g. telephone number or MAC address identification).
Is the "configured in the PE" case equivalent to a Call Check, and if so,
how is the CE identified?

In the following paragraph:

   If a PE wants for some reason to get from Radius an up-to-date list
   of PEs in a particular VPN, it can at any time issue a new Access-
   Request for any one of its CEs that belongs to the VPN.

This seems like it is describing a re-authorization request. Is the intent
for the CE to re-authenticate as part of this Access-Request?

In terms of the attributes necessary to implement this draft, I'd suggest
reuse of the RFC 2868 Tunnel Attributes, if possible.  Of the top of my
head, I'd recommend the following:

a. Definition of new Tunnel-Type values as appropriate.
b. Reuse of existing Tunnel-Medium-Type values.
c. Transmission of the VPNID in the Tunnel-Private-Group-Id Attribute.

The question with RFC 2868 attributes is if they can be extended to
allow for multiple tunnels to be set up.