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

Bernard

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

RS> Although I think it is useful feature, I think it should be left up to
the service provider to decide whether CE authentication should be carried
out by RADIUS or not. For example, the RADIUS discovery protocol might be
used across an RFC2547 VPN network, and a particular CE-PE link might be
running OSPF with MD5, in which case the service provider may not feel it
necessary to carry out any further authentication. The PPVPN WG has not
defined a requirement that the actual discovery protocol itself MUST
authenticate CEs, although it is obviously an attractive option.
 
 > 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.

RS> There is a difference between attributes that should be signalled using
a signalling mechanism, and attributes that should be discovered using a
discovery mechanism. The PPVPN group is yet to agree on exactly which
attributes should be signalled and which should be discovered. However, the
PPVPN WG has not identified the need to use the discovery mechanism to
identify the tunnel type or the PSN type, and therefore none of the
discovery mechanisms defined to date include these attributes in the
discovery process. In my opinion the discovery mechanism should discover the
minimum amount of information required to allow signalling to take place,
i.e. a list of PE IP addresses belonging to the same VPN. 

Re-using some of the attributes from RFC2868 such as Tunnel-Client-Endpoint
and Tunnel-Assignment-ID (which looks more appropriate than the
Tunnel-Private-Group-Id you suggested as multiple tunnels may exists between
endpoints) is probably a good idea. However, I don't think one should expect
to be able to make some changes to RFC2868 and use that instead of Juha's
draft. RFC2868 describes attributes for setting up different types of
tunnels across different PSNs, Juha's draft is intended to be a simple
mechanism for discovering VPN endpoints only.

Richard