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

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

Having the PE fabricate a User-Name and Password exchange where in fact
no such exchange is occurring is not a good idea.

Clearly the PE must be identifying the CE in some manner so that it is
confident it is the correct CE, no?  Since there is no username and
password exchange, is there is some means for identifying the CE (a
MAC address? a port number?) Otherwise you really have no idea who the CE
is, or even who should be billed for the service.  The Call-Check Service is
designed for these kind of situations, where the CE is identified in some
way (e.g. by MAC address) but no authentication is done.


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

OK. You might go ahead and say that explicitly.

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

Yes, there is. There is Tunnel-Client-Endpoint and Tunnel-Server Endpoint.
If used with a Tunnel-Medium-Type of 1 (IPv4) or 2 (IPv6) these Attributes
can contain IP addresses. Have a look at RFC 2868.

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

You might also want to chat with the authors of RFC 2868bis to see if they
can accomodate your need for multiple tunnels. That seems like the major
extension that is required to enable what you want to do.