2.4.7 Network Access Server Requirements (nasreq)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 15-Jun-99


David Mitton <dmitton@baynetworks.com>
Mark Beadles <mbeadles@wcom.net>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>


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:

Jun 99


Submit first draft of requirements as an Internet-Draft

Jun 99


Submit first draft of practices as an Internet-Draft

Jul 99


Submit review and recommendations document as an Internet-Draft

Jul 99


Review WG Charter

Aug 99


Interim Meeting to finalize practices & requirements

Sep 99


WG Last Call on I-Ds

Oct 99


Submit requirements document to IESG requesting publication as an RFC

Oct 99


Submit practices document to IESG requesting publication as an RFC

Oct 99


Submit practices document to IESG requesting publication as an RFC

Oct 99


Submit requirements document to IESG requesting publication as an RFC

Nov 99


Meet at DC IETF (Decide on recommendations for final document)

Dec 99


Submit review and recommendations document as an Internet-Draft

Jan 00


Review/update WG charter


No Request For Comments

Current Meeting Report

Network Access Server Requirements Working Group Meeting
17-July-1999, 45th IETF, Oslo, Norway

Chaired by Dave Mitton, Mark Beadles.
Reported by Nicole Gallant. Edited by Dave Mitton.

Dave Mitton <dmitton@nortelnetworks.com>
(absent) Mark Beadles <mbeadles@wcom.net>


Agenda bashing
Charter and Document Status
Document discussions:
- "NAS Operational Model" (Draft-ietf-nasreq-nasmodel-00.txt)
- "Extended Radius Practices" (Draft-ietf-nasreq-ext-radiuspract-00.txt)
- "Criteria for Evaluating NAS Protocols" (Draft-ietf-nasreq-criteria-01.txt)

Activities in related working groups: AAA, Roamops, RSVP, PPPext (Mobile IP)

Next Steps
Interim meeting plans

Status: It was announced that our email archive is finally online and running.
Thanks Alex!


Discussion of The NAS Operational Model Document

This document is informational. It provides a basic overview of what a NAS is and what a NAS does. There have been few comments on this document from the mailing list. This document consists of two pieces. The first piece is a set of examples with respect to configuration, and types of authentication. After these examples, the second piece sets out terminology and some structure of what a NAS is composed. A NAS offers services which are authorized and controlled by authentication. This draft is a combination of two drafts presented at prior meetings.

Questions from the floor: NONE

Discussion of the Extended Radius Practices Document

This is another informational document; it contains examples of some types of functions outside of RADIUS but clearly within the scope of NAS functions. It was presented at the previous meeting. This is the first draft availible to the WG.

Questions from the floor: NONE

Discussion of the Criteria for Evaluating NAS Protocols Document

Purpose of this document is to start evaluating approaches for future work. This being a first pass, it was felt there could be more material added.

Dave Mitton presented slides based on Mark Beadle's Criteria for Evaluating NAS Protocols document.

Questions from the floor on the presentation:

Q> On the general service requirements - Are we talking about load balancing or thousands of calls for signaling?
A> This is aimed at the Service Profile of the NAS

Q> Not load balancing on the telephone network. This should be captured and addressed.
A> These slides are abstracted from Mark's document - his paragraphs should make more sense but lets review them to make sure.

Q> On Authorization requirements, isn't a location check the same as caller ID?
A> A location is the same as a POP (Point of presence) - this is one of the things that a server could support if reported by the NAS.

Q> What about reporting failures from the NAS to an AAA server?
A> It is assumed that any server type functionality is reported!

Q> Can we come to a group conclusion whether there are only three A's (from the AAA WG - Accounting, Authorization, and Authentication), or four A's (The fourth A is for Auditing)?

There was the supposition that Auditing is not sufficently different than Accounting to warrant seperate treatment. It was decided that this could not be settled in the meeting, we need to gather together information from people who insist these are different.

PRESENTATION - "IPv6 Tunnel Server Requirements", Marc Blanchet

Mark presented slides showing how they were developing a tunnel server that provided IPv6 connectivity through an IPv4 "backbone". The purpose of the presentation was to see if this application met or required changes in our NAS Models.

Q> Why would you use a tunnel server when you could just do a IPv6 to IPv4 translation?
A> That's under discussion

Comment> The best way is to use translation - we don't want to tell people to do tunnels. Being a tunnel server have a big impact on the NAS performance. A NAS is engineered with distributed processing networks in mind, not for ending tunnels.

Comment> This looks more to me like a firewall! A NAS, historically does not bridge two IP networks

Q> Do you have a (IETF) draft in for this?
A> Yes, We're gonna look also if RADIUS includes similar functions

Q> We don't have a model for ending tunnels - only starting tunnels!
A> RADIUS has attributes for this.. The Tunnel server becomes a virtual NAS

Q> Our tunnel servers are NASes?
A> We don't want to push this as a requirement.

Q> This is just another remodeling of WEBDAC

Q> How does the authentication work?

Q> How is the tunnel server different from a router?

Q> Are you considering RSIP?
A> No! You use RSIP OR IPv6toIPv4!

Q> Mobile IP works fine, too!

Q> Is the tunnel server a NAS?

CONCLUSION: We will continue to discuss this issue of IPv6 Tunnel Server Requirements for a NAS on the mailing list.

Activities in Related Working Groups

Comments from the chair (Dave Mitton) that NASREQ needs to follow developments in related working groups, such as RADIUS, AAA, and Roamops. General agreement from the floor.

The Interim Meeting

The chairs propose an interim meeting to progress the Criteria document and start on the Recommendiations document, probably to be held in mid or late August, most likely somewhere in the midwest of the U.S.A.

Our esteemed AD requested that we give ample prior notice for any that wished to attend be able to schedule travel and accomodations.

The purpose of holding an interim meeting would be make progress against our scheduled milestones. Mailing list contributions have not been sufficent to achieve this.

As an alternative suggestion, some people would prefer to hold teleconference(s) rather than have to travel to an actual meeting.

The chair asked for show of hands, on those willing to travel and didn't get much response.

CONCLUSION: A request for an interim meeting or teleconference be sent out on the mailing list.

Next Steps:

The groups Chartered Milestones were projected directly off the IETF web page. Some transcription problems were found.

The next work item(s) to complete are

1) to review and finalize the Criteria document
2) to start and put out for review our Recommendations document.

A request for volunteers to edit the Recommendations draft was put to the audience and Glen Zorn of Microsoft responded.


NASreq Criteria for AAA
IPv6 Tunnel server requirements for NAS