draft-heinanen-radius-pe-discovery: Summary

As a result of issues that have been raised, Juha has agreed to make a
number of changes to the RADIUS discovery draft. It has also been agreed
that the draft will be refined and additions made as work progresses.

The changes to be made as work progresses are minor issues rather than
objections to the draft becoming a WG document. Some of which are concerned
with CE authentication rather than actual VPN endpoint discovery.

As its getting towards the end of the 2 week discussion period, are there
any objections to the draft becoming a WG document? Or indeed, following the
issues that have been raised and resolved, are there any individuals that
would like to express their support that haven't done so yet?

A summary of the changes Juha has agreed to make to the draft and changes
that will be investigated as work progresses are summarised below:


AGREED CHANGES TO THE DRAFT:
============================

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

2. "Incorrect use of interim accounting"
- Agreed to replace interim accounting with re-authentication in the next
version of the draft. 

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

4. In the following paragraph: "If a PE wants for some reason to get from
Radius an up-to-date list of PEs in a particular VPN, it can at any time
issue a new Access-Request for any one of its CEs that belongs to the VPN."
- Make it clear that the intent is for the CE to re-authenticate as part of
the Access-Request.

5. "Use of RADIUS for CE-based VPNs"
- Agreed to remove this reference as it is confusing and not within the
scope of the draft.


REFINEMENTS/ADDITIONS AS WORK PROGRESSES:
=========================================

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

2. "Use of re-authentication (instead of interim accounting)"
- Investigate the use of re-authorisation (as described in draft-chiba)
instead of re-authentication for this purpose.

3. "Re-use of existing attributes in RFC2868"
- Agreed to consider using "Tunnel-Client-Endpoint" and "Tunnel-Server
Endpoint" attributes for carrying PE IP addresses.
- Agreed to consider using "Tunnel-Assignment-ID" and/or
"Tunnel-Private-Group-ID" attributes for carrying VPN ID.

4. "Multiple tunnels for the same VPN using RFC2868"
- Need to investigate how by using RFC2868 attributes multiple tunnels can
be supported, taking into consideration the way the 'Tunnel-Preference'
attribute is currently used to select a single tunnel.

5. "CE Identifier"
- As this has not been discussed within the PPVPN, the CE Identifier (e.g.
port, MAC address, name, IP address, etc) needs to be determined, or to be
agreed that it is up to the service provider to choose a suitable CE ID.

6. "Use of 'Call Check' and 'Authorise Only'
- Decide whether Call Check/Authorise Only should be used in an
Access-Request instead of authentication using CE name and password. This
also involves the issue of storing passwords on PEs instead of in a single
place.

7. "Re-authentication initiation"
- Existing mechanisms such as Session-Time and CoA-Request will be
investigated and incorporated to control re-authentication.

Thanks,

Richard