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

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

That's fine. A RADIUS "Call Check" assumes that the user is authenticated
by another means (e.g. OSPF MD5), so there are no authentication
attributes in the Access-Request. But it *does* require that the CE be
identified in some way. That typically is via an L2 address, but it
could be something else. I'm just asking what uniquely identifies the CE
in this case. Given that there is no authentication exchange occurring,
it is probably not appropriate for the PE to "forge" an
authentication as through the CE really did authenticate when
in fact it didn't.  Since RADIUS doesn't require authentication (that's
what "Call Check" and "Authorize Only" Service-Type values are for)
there's no need to forge an authentication just to be compliant with the
protocol.

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

I think that's ok. The Tunnel-Type could just be "PPVPN".

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

Tunnel-Assignment-ID is used to allow multiple connections to be carried
over the same tunnel. That is not quite the same thing as having multiple
tunnels between two endpoints.

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

I agree that RFC 2868 is a superset of what you're trying to do.  I don't
think that the document necessarily requires the use of all the
capabilities, though.