NASreqNG BOF MINUTES
IETF-43 NASreqNG BOF
10 December 1998
Reported by Rick Cobb/WarpSpeed Communications (email@example.com).
Edited for format by Mark Beadles/MCI WorldCom Advanced Networks (firstname.lastname@example.org).
Mark Beadles (email@example.com)
David Mitton (firstname.lastname@example.org)
Agenda bashing (Mark Beadles)
There were no objections to the agenda.
Charter Presentation (David Mitton)
The proposed WG charter was presented, and the NASreqNG WG/BOF history was presented.
Document Status (Mark Beadles)
Introductory drafts are available:
The WG mailing list info is:
- email@example.com with "subscribe" in the body, or firstname.lastname@example.org with "subscribe nasreq" in the subject.
The list archive is at http://nasreq.rutgers.edu
Beyond RADIUS: Current NAS Practices (David Mitton)
There are lots of RADIUS implementations that do things well beyond the current RFC's. The messages are of RADIUS format, but involve coding and semantics well beyond the specification Not included are practices that could relate to other specifications These are things discovered by reading industry manuals or had to respond to in competitive bidding or RFQ situations.
The motivation for the document is to give some real examples of what people are really doing.
Disclaimers: Data & numbers are gleaned from public sources and vendor documents along the way. Assignments are subject to change by vendors with no revision control.
Following are a partial list of what current RADIUS practices have been discovered so far.
Attribute Usage: RADIUS defines ~60 attributes, and reserves area above 192.
Attributes 92-255 are in use by Ascend, some conflict with Shiva.
Vendor Attribute VSAs in use by: Microsoft (20 or so for MS-CHAP); ACC (16or so, did an informational RFC); Bay / Nortel (60 and growing); 3COM / US Robotics (130 or so). US Robotics VSAs are different than RFC suggested format. Nortel/Bay VSE approaches additions to enumerated standard attribute values by embedding vendor id.
Attribute Data Types include: the base has 4 types (integer, string, ipaddr, and date); Optional compound tag bytes for tunnel attributes; Ascend "abinary" - puts parsing burden on server; Ascend "phone string", similar; Accounting Message sub-types: Merit's been using call start/stop; Bay has a toggle for getting accounting status, subsessions, NAS status, etc.
The Base has 6Primary Message Codes, Vendors have added around 29.
Operations include: Password change; Pre-authentication screening; Access request on call arrival; Username = dialed number, password = "fixed string"; Service-Type=Framed-callback; Access-Reject means don't answer/busy; Access-Accept takes call off-hook; Additional authentication may be suppressed by attribute, particularly for remote outsourcing. There are issues with security: a user can enter an appropriate phone number and fixed string, and use that to get access.
Authentication Modes include: Next passcode; New PIN; Password Expired. Authorization Resources include: IP address allocate; IP address release (But it's not clear whether this should be done in the RADIUS server, DHCP, etc.); Resource Management Issues; Resource request; Resource response; Resource Free Request; Resource Free Response; Resource Reclaim Request; NAS Reboot Request/Response. Managed Resources include IP Addresses, Concurrent Logins, Tunnels, and Ports. This requires coordinating state across multiple NASs. Authorization Changes include Messages sent from Server to NAS, Change Filter Request (sometimes doesn't come from the Server; it can come from somewhere else); Change Filter Ack/NAK; Disconnect Request; and Disconnect Response.
RADIUS servers are getting very complex, Often brokering authentication and authorization to other authorities or repositories. RADIUS is often used as a glue protocol. Some of the "solutions" are kludges that would clean up if we cleaned up some of the underlying assumptions. RADIUS as the RFC's describe it is becoming less relevant. Many features require matching client and server processing; without standardization of these functions we don't have much interoperability in the field. Compatibility modes are becoming "features"
We would like input from vendors or users on practices and details known, particularly reference material. David will roll up this information into the I-D. The Idea is to open our Eyes to the problem. Input into the BCP document is strongly encouraged, so we don't miss something important that's known right now.
NAS Requirements (Mark Beadles)
Mark Beadles presented a framework on what we might focus on in a requirements document.
A NAS does not necessarily talk to a modem, or to the phone network. There is not a very clean line between a router and a NAS. We have modems, DSL, cable-modems, ISDN -- and in all these cases, ISPs need to supply the same policy services to all these situations.
The focus area of Security / Authentication includes requirements in: Advanced authentication services, EAP, Certificates / PKI, Device Security IPSec. The scope of this area has some overlap with the POLICY working group but dialup security is explicitly excluded from Policy WG charter. The focus of this group is also mainly on wireline access, as the MobileIP WG is working on wireless/mobile access.
The focus area of Authorization includes requirements in: User authorization, Policy implementation, Dynamic provisioning, Resource management - hard policy limits / restrictions, Granting specific types & levels of service based on system state, may include QoS and video/integrated services.
Accounting & Auditing both refer to looking at what has been done. Accounting is for tracking resource consumption. Auditing is done for tracking user activity. The focus area of Accounting & Auditing includes requirements in: Real-time and batch accounting, Demand accounting, User-based resource usage collection, Resource management - soft policy, Reporting and planning
Resource management is more a focus of authorization.
The focus area of NAS Resource Mgmt includes requirements in: Dynamic IP pool management, Dynamic naming services, Advanced Filtering, Tying together address management and other resource management, Telco resource management, Outsourcing / resource sharing.
VPN's are another focus area for requirements. NAS's that participate in VPN's include: Dial NASs building compulsory VPN's to other servers or networks; Dial NASs providing services to voluntary VPN users; Tunnel NASs providing tunnel termination services; or distributed NAS model (User dials in, gets policy, tunneled to a termination service that's into another NAS, potentially implemented on a general purpose OS).
The focus area of Quality of Service includes requirements in: Quality / Levels of service through NAS; Policy / Authorization / Accounting for QoS; Bandwidth management; Dynamic quality / levels of service. This may include such things as users having more than one QoS for multiple applications, and integrated services.
Roaming must also be considered for NAS requirements, although the Roamops WG owns the main requirements in this area. This focus area includes: Roaming Operations, Operation across administrative domains, global operations, accounting, Outsourcing applications
Comments from the group
It was suggested that such things as multicast, etc., have to be part of what NAS's do. Consensus was arrived at that we are not trying to specify what routers do. NAS's may include routing functionality; we don't need to write RFC 1812 again, but should reference it. We may work on things such as, how to use SNMP to manage NAS's. Harald Alvestrand noted "The SNMP group does not tell you how to manage something."
Charter review and discussion (Mark Beadles)
Work Item number 1 is to collect requirements. Functions that are addressed by other protocols or groups will be referenced as possible. Output will be an informational requirements document.
Work Item number 2 is a survey of the ways that existing NAS protocols are used. Output, after some discussion, was decided to be an informational document. ROAMOPS wrote a document like this, we should use it as a model. Include references to web sites where more current detail could be gotten. There was a suggestion to put a web page up where vendors can post their changes to that work.
The final work item is to review then-current drafts and RFC's for applicability to the above requirements. The output will be an informational RFC detailing the evaluation of the candidate protocols and our recommendations for their use, expansion, or stating where there are key weaknesses that need to be addressed by this or some other working group. We should funnel requirements to the AAA WG as well.
After the other items are complete, we will review the charter, determine if we've completed our work, and adjust to our charter to address the work that needs to be done.
The first step is to review the charter on the mailing list to get final nits out. Since IETF Scheduling discussions will take place around 22 Feb 1999, and we may need several rounds on the charter, the AD wants to have this WG-final charter to him by 11 Jan 1999. The final dates of work items, which will be incorporated into the charter, were the following, arrived at by consensus:
- January 1999: Charter approval, WG established
- Late February 1999 (cutoff date): First draft of requirements document, first draft of practices document.
- May 1999: Working group last call on both documents.
- June 1999: Pass documents to IESG for approval. Begin review & recommendations.
David Mitton will be the principal author of the practices document. Mark Beadles will be the primary author if the requirements document. Document editors will be Bernard Aboba and Mark Beadles, accepted by consensus. There was consensus that there should be a document that states exactly what a NAS is. The preliminary paper Mark wrote to help define this BOF was very useful, and may be incorporated into the requirements draft.
All charter comments should be in by 20 December. There is a 1 January deadline for final review before pass-off to the AD.
It was the consensus of those attended to form a NASREQ Working Group; WG chairs will be Mark Beadles and David Mitton, with no objections. Harald asked us to ensure that at least one chair is not the author for each document.
Many thanks to Rick Cobb for taking minutes at this very fast-paced meeting!
Beyond RADIUS: Current NAS Practices</A>