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

Bernard Aboba writes:

 > 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".

by keeping dynamically track i mean that radius server keeps state based
on access requests and stop accounting requests about which pes
currently have members in which vpns.  radius server does not and should
not know anything about the resuiting tunnels.  the procedure on how
this keeping track takes place has been defined in the draft.

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

in the protocol described in the draft the ces have nothing to do with
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."

that is a referral to a possible other schenario which is not covered
nor is within the scope of the draft.  i agree that it is confusing and
will remove the sentence from the next version.

 > 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?

no, it is not equivalent to call check.  the pe simply performs the
authentication of the ce on behalf of the ce if the ce itself doesn't
support an authentication protocol like 802.1x, i.e., the username and
password are in that case configured in the pe instead of the ce.

 > 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?

yes.

 > 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.

the pe needs from radius a list of ip addresses of other pes.  if there
is an existing attribute that can return that, it is fine with me to use
it.

i have been oin vacation a few days and will issue a new version of the
draft during the coming weekend.  i do not claim that the new draft
would be ready to be published as an rfc but it should be ready enough
to be published as working groupo document.  then detailed work on it
can beging.

-- juha