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

I'm no radius expert, but I think  what Bernard Aboba is objecting to is the
proposed procedure by  which PEs seem to register  and unregister themselves
dynamically in RADIUS  as supporters of a particular  VPN instance.  This is
what he means by "service discovery", I think. 

Juha> my draft doesn't  use radius for service discovery.   the service type
Juha> in  the radius  request that  the pe  makes is  VPN-Login.  so  the pe
Juha> already knows what service to ask for. 

"Service discovery"  doesn't mean figuring out  what service to  ask for, it
means finding, from  a dynamically changing list of  servers, the servers to
connect to at some given time. 

I think that using RADIUS to get  a preconfigured list of PEs attaching to a
given  VPN is  probably  unproblematic, but  trying  to use  it to  maintain
dynamically learned PE/VPN associations  is probably overextending it, as it
is something that RADIUS is not typically used for. 

Richard> The  RADIUS  discovery draft  is  the  only  one that  includes  CE
Richard> authentication

I'm not sure that having the  CE authenticated by the SP is that interesting
in this  context, as such  authentication could be  done by the PE.   If the
authentication  could  be proxied  to  a  radius  server controlled  by  the
customer,  that might  be more  interesting,  as it  would be  immune to  SP
misconfigurations. 

Richard> and  meets all  the  discovery requirements  identified within  the
Richard> PPVPN WG so far including "Limits VPN information to only those PEs
Richard> involved  in  that  VPN",  "Extendible to  provide  information  in
Richard> additional to VPN endpoint IP address" and "Supports inter-provider
Richard> VPNs". 

The BGP-based discovery procedure meets these requirements.