RADIUS Discovery Discussion Summary

Rick

Where do we stand with things regarding the RADIUS discovery draft
(draft-heinanen-radius-pe-discovery) becoming a WG document? A number of
issues have been raised by Bernard and have been resolved either through
further explanation from Juha, or through agreed amendments to the next
version of the draft. I believe a summary of the issues resolved to date is
as follows:

1. Section 2 attempts to update RFC 2486.
- This was fixed in version 4, the terms conflicting RFC2486 are gone.

2. Use of RADIUS for service discovery is a bad idea.
- Agreed that the draft does not use service discovery and that the use of
RADIUS for discovering VPN endpoints is OK.

3. Requires that RADIUS servers be stateful.
- Agreed to add a statement to this effect in the next version of the draft.

4. Include potential mitigating measures in the Security Considerations
section.
- Security considerations such as those in RFC2868 and
draft-aboba-radius-rfc2869bis-22.txt could be incorporated or referenced in
the next version of the draft.

5. Exponential backoff is required to support a large number of VPN sites.
- The draft currently states that PEs should use exponential backoff. Future
versions of the discovery draft could reference the new AAA draft described
by Bernard that will provide details of exponential backoff behaviour in
RADIUS.

6. Use of interim accounting.
- Agreed to replace interim accounting with re-authentication in the next
version of the draft. The use of re-authorisation (as described in
draft-chiba) for this purpose could also be investigated as work progresses.

There seems to be rough consensus from the few people that have offered an
opinion, that using RADIUS as a discovery protocol is a viable solution, as
Bernard says "Overall, I think that the draft has value and its purpose is
within the precedent established in RFC 2867-2868.  Given that RADIUS
already supports configuration of VPNs and VLANs, it is not much of a
stretch to see it being used for PPVPN configuration."

Thanks,

Richard