RE: draft-heinanen-radius-pe-discovery: Summary

Rick

Considering the 2 week discussion period finished a couple of days ago for
the RADIUS discovery draft, is there any news on the decision to make it a
WG document?

Thanks,

Richard

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