NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 09-Feb-99
Chair(s):
David Mitton <dmitton@baynetworks.com>
Mark Beadles <mbeadles@wcom.net>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Editor(s):
Bernard Aboba <aboba@internaut.com>
Mailing Lists:
General Discussion:nasreq@tdmx.rutgers.edu
To Subscribe: majordomo@tdmx.rutgers.edu
Archive: http://nasreq.rutgers.edu/nasreq/
Description of Working Group:
The purpose of this group is to gather and process the requirements of modern Network Access Servers (NAS) with respect to user-based service Authentication, Authorization, and usage Accounting. Services being considered go beyond simple dial-in access, and include Virtual Private Network support, smart authentication methods, and roaming concerns. The common thread is demand-based dynamic services requested within a user authentication model, viewing the NAS as a tool for implementing network policy and security.
The RADIUS protocol was developed in response to the previous incar- nation of the Network Access Servers Requirements (NASREQ) BOFs. The protocol was a simple but flexible solution to many of the require- ments in terminal and network access servers at the time. The RADIUS Working Group is about to conclude its work on the basic protocol, but NAS development continues at a rapid pace, and implementations are trying to use more standards now than when RADIUS began. As we add more services to NAS boxes, the RADIUS protocol is often stretched and bent well beyond the original design goals, and often fails to deliver the desired reliability, functionality, or security.
As NAS installations become larger and more complex, and as NAS services are virtualized in other servers, the services being authorized require more sophisticated mechanisms for coordinating policy and resource state across multiple systems and servers.
The group will work closely with other Working Groups (including roamops, pppext, policy, et al.), to serve as input for the group's requirements and to identify candidate protocols which may meet those requirements.
This group will document all of the current requirements for services which fully meet the needs of modern and next generation NAS systems.
Goals and Work items:
The first goal of the group will be to collect and organize functional requirements. The focus of the requirements will center on NAS user authorization. Functions provided adequately by other standardized protocols will be documented as such. Requirements will be generated by the members of the BOF/WG, with input from the RADIUS WG, the RoamOps WG, the AAA BOF/WG, and other groups as required. The output of this effort will be an informational requirements document.
In parallel, another document will be a survey of the current practices that NAS vendors and deployers are engaging in to provide similar services, using extensions to RADIUS or pro- prietary protocols. The output will become an informational survey document.
The group will review current draft work on RADIUS extension or successor protocols and determine their suitability to meeting the WG's requirements. The output of this effort will be an informational document detailing the evaluation and recommendations.
The charter of the group will be reviewed at that time, and adjusted according to any new work items and directions.
Goals and Milestones:
Feb 99 |
|
Submit first draft of requirements as an Internet-Draft |
Feb 99 |
|
Submit first draft of practices as an Internet-Draft |
May 99 |
|
WG Last Call on I-Ds |
Jun 99 |
|
Submit requirements document to IESG requesting publication as an RFC |
Jun 99 |
|
Submit practives document to IESG requesting publication as an RFC |
Jul 99 |
|
Submit review and recommendations document as an Internet-Draft |
Jul 99 |
|
Review WG Charter |
Internet-Drafts:
No Request For Comments
Minutes of the Nasreq Working Group Meeting
44th IETF, Minneapolis Minn.
Monday, March 15, 1999, 7:30 pm
Chairs: Mark Beadles, Dave Mitton
1. Criteria Draft (draft-ietf-nasreq-criteria-00.txt)
Mark Beadles led this discussion, working from the slides attached to these minutes. He reminded the group that the criteria document differs from a normal requirements document as described in RFC 1812. The criteria document does not say what functions are required in a NAS, but instead says how these functions must be performed if they are present. The Working Group's basic intent is to provide definitions and a reference model, and then to indicate where existing protocols apply within that model.
The discussion proceeded from this point on the basis of the interfaces shown in the draft reference model.
a. Client Interface: PPP support is considered a typical minimum, however the group is not ruling out coverage of mobile IP and use of IPSEC at the Client Interface.
b. Network Interface: no remarks.
c. AAA Interface: Mark's diagram showed this as "AAA Interface (Policy)". Concern was expressed that AAA is not the same as policy. Mark pointed out that there was a close relationship, since authorization is the means by which policy is enforced. The rejoinder to this was that the NAS could contain fixed policies, with the point being that policy could come from multiple sources. The conclusion of the meeting was that a policy interface should be added to the reference model.
The suggestion was also made that a fourth "A" should be added to the AAA interface: Auditing. This may be viewed as Accounting information used in real time.
d. Management Interface: no specific remarks.
The general conclusion was that more discussion of the AAA, Policy, and Management interfaces was needed on the list before the Working Group could feel sure that it had defined the right reference model. A key point of the discussion should be the question: where does the NAS get policy from?
The discussion moved on to consider the basic model as presented in the draft. "Telco or encapsulated" was renamed "User Sessions". "Modems or Virtual" was initially defined to be a source of PPP. Then Async and HDLC were added as possible inputs, with more possibilities in the offing. This caused further discussion, with the final conclusion that the function needs to be renamed.
The group agreed to include Layer 2 switching as well as routing within the fabric of the NAS. This fits the US regulatory environment, which prevents RBOCs from doing routing within the Central Office. At that point the AD intervened to warn that the group should concentrate as narrowly as possible on functions unique to the NAS. It was noted in response that the group must take account of the needs of service providers. This led to a general discussion of the size of the job facing the Working Group. The AD suggested that the group choose PPP and/or Mobile IP and/or one or two access technologies, proceed to create the document, then accept additions provided that the authors can indicate the precise changes which must be made to the baseline document to accommodate the additions.
Discussion then turned to the question of how telco signalling related to NAS requirements. Is signalling relevant? The answer is tied to the definition of the NAS as seen by Megaco and whether that defintion is consistent with the one being used by NASReq.
In conclusion, the group must refine the definition of a NAS to the point where its boundaries become clear.
Mark called for co-authors to help flesh out the document. Pat Calhoun will take on AAA, Matt Holdrege will contribute on signalling, and Alexander Catzko will work on management.
2. RADIUS Current Extended Practices Draft
David Mitton gave a status update for the RADIUS draft. He apologized for narrowly missing the submission deadline and reminded attendees that it had been sent out to the list. The suggested file name is draft-ietf-nasreq-ext-radpract-00.txt. It was created from the Powerpoint presentation given at the last meeting, including the remarks received at that meeting. David will resubmit after cleaning up the formatting and boilerplate text.
Discussion moved into the side issue of copyright. The material in the draft is summarized from, but does not quote directly, vendor-copyrighted material. Hence it can legally be issued as an Internet Draft without concern for copyright. A suggestion that it be sent out as an E-mail to the list to be totally safe was turned down because it would cause problems of its own, since copyright for E-mails accrues to their author.
Matt Holdrege expressed the concern that RADIUS practices change regularly, so that the document would quickly be out of date. The response was that the group needs a current snapshot to work from, so the work has to be done and will be useful.
David welcomes contributions of further descriptions of practice provided that no IPR is attached to these descriptions.
The group noted that the RADIUS WG has concluded meeting, but still has some drafts being revised and awaiting final approval.
3. Presentation Of The Megaco Model
Tom Taylor, Chair of the Media Gateway Control group (Megaco) presented a chart showing a possible interpretation of the Megaco architecture in terms of NASReq reference model. This chart showed the NAS as architectecturally equivalent to the combination of the Megaco Signalling Gateway (SG), Media Gateway Controller (MGC), and Media Gateway (MG) functions. The SG function takes message-based signalling (e.g. SS7, PRI) from the telephone network, terminates the lower layers, then passes the signalling PDUs to the MGC function. The latter could be called the NAS Controller function in the NASReq context. It responds to or originates telephony signalling on the one hand, and directs the MG function to perform the services required for each call on the other.
For the NAS application, the MG function is responsible for the following:
- detecting and reporting line or per-trunk (MF, R2) signalling to the MGC function
- applying line and per-trunk signals in the outgoing direction as directed by the MGC
- processing and routing of the user data flows.
When the MGC and MG functions are in separate boxes, the control interface thus exposed carries the Megaco protocol.
Tom pointed out that the AAA interface could terminate on either the MG or the MGC function, and that the alternative chosen would have a major effect on the content of information passing across the MGC-MG control interface. The general feeling of the group was that the AAA interface would terminate on the MG function.
Tom indicated that the current Megaco requirements draft (draft-ietf-megaco-reqs-01.txt) contained an inadequate description of NAS-related requirements. draft-mitton-nasreqng-model-00.txt and the criteria draft, even in its current incomplete state, will be helpful in fleshing out the Megaco requirements.
The suggested mapping of the Megaco architecture to the NASReq reference model was done hastily, and clearly took the meeting by surprise. A more careful mapping is required to allow the group to verify the validity of the Megaco requirements. Tom is prepared to work with NASReq to create that mapping.
4. Other Items
A brief discussion ensued regarding items earlier excluded from the Working Group's consideration. The discussion was triggered by Mark's reference to tunneling servers. The key point noted was that the group should not restrict itself so much as to exclude the "next generation" aspect from its work.
5. Policy Framework Working Group
John Strassner, Co-Chair of the Policy Framework Working Group, provided an update on his Working Group's activities. Essentially the aim of the group is to provide tools through which the SLA can be transformed through a series of steps ending up with the device which enforces it.
The work derives originally from DEN, and the WG is cooperating with the DMTF so that they use the same policy models. The WG is adding conflict detection to the basic model. The core schema is close to last call. The architecture description has passed through multiple drafts with continuing contention between message passing versus signalling models. A cost schema will be created in a future effort. The intent is that the NAS will be the point where policy is implemented on the network.
If the criteria draft needs a policy section, John Strassner volunteered to write it.
6. NASes and Roaming
The NAS is being viewed as a gateway for roaming operations. ROAMOPS has accordingly been putting a lot of requirements onto the NAS (e.g. RFC 2477) which NASReq should take into account.
7. Review of Current Milestones
The Chairs are considering an interim meeting to progress the criteria draft before Oslo. Details will be discussed on the mailing list.