2.4.8 Network Access Server Requirements (nasreq)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 09-Mar-00

Chair(s):

David Mitton <dmitton@baynetworks.com>
Mark Beadles <mark.beadles@columbus.rr.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

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:

Jun 99

  

Submit first draft of requirements as an Internet-Draft

Jun 99

  

Submit first draft of practices as an Internet-Draft

Aug 99

  

Interim Meeting to finalize practices & requirements

Sep 99

  

WG Last Call on I-Ds

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

Internet-Drafts:

No Request For Comments

Current Meeting Report

47th IETF
Monday, March 27, 2000
Network Access Server Requirements, nasreq (Next Generation) WG

Recorded by: Herbert Lin, hlin@nortelnetworks.com
Chaired by: David Mitton, dmitton@nortelnetworks.com

Agenda:
1. Agenda Bashing
2. Relationship of nasreq documents to AAA WG's
3. Document Status
- NAS Operational Model
- NAS Extended Radius Practice
- Criteria for Evaluating NAS Protocols
- Evaluation of Protocols against NAS Criteria
4. Final Comments on Above
5. Megaco; NAS Package Input?
6. Next Steps

----
1. There were no agenda issues.

2. AAA vs. Nasreq documents

The AAA Network Access Requirements draft now includes Nasreq documents by reference. The most recent changes to the Criteria draft was made to harmonize requirement terminology and description between the two documents, as discussed in the AAA WG Interim meeting. We need to make sure we stay in sync.

3. Document Status and Mailing List
3.a. Drafts Status:
- NAS Operational Model
draft-ietf-nasreq-nasmodel-01.txt
WG Last Call
- NAS Extended Radius Practice
draft-ietf-nasreq-ext-radiuspract-02.txt
WG Last Call
- Criteria for Evaluating NAS Protocols
draft-ietf-nasreq-criteria-04.txt
WG Last Call
- Evaluation of Protocols against NAS Criteria
incomplete

4. Comments:
4.a. Extended Radius Draft Comments
There were some comments that there were still mentions of vendors and products in this document, even after the recent edits. These have been reduced to a simple list at the end of the document. After some discussion, the group as a whole didn't seem to have a problem with this.

4.b. The three above documents will be put up for a formal final WG Last Call and with no substantive comments will be advanced to the IESG for any last review and RFC considerations.

4.c. Evaluation of Protocols draft or lack thereof
This working group is chartered to product a protocol evaluation draft based on our NAS Criteria. We have had several presentations at prior meetings, but no document has been published yet. Should we follow through on this, or revector our energy into the AAA WG?

Discussion:
What is the purpose of this document: "Evaluating NAS Protocols"?
- IESG: It is not just conflict with AAA; but we also to fill all the requirements as a whole.
- AAA WG took Nasreq requirement document as reference for evaluation
- Nasreq document has a lot of more details than AAA requirement documents
- We need someone familiar with the topic and just produce the documents for comments
- Do we need to just go ahead and produce this document and coordinate with AAA group?
- We could either choose to include this effort by reference
- (e.g. make the AAA document refer to us, or directly include our text in the AAA document by participation)
- It was observed that many of the same people would be involved in either effort, and this may be a redundant.
- There were no volunteers. However various people in the room did not want to give up.
- A Hum was called and consensus was that we should coordinate with AAA WG.

5. Megaco (Media Gateway Protocol)
A typical relationship of Media Gateway Controller and NAS is shown below.

. SS7--> +----------+
. -----------| MGC |
. +----------+
. ^ |
. | |
. | | Megaco/H.248
. v |
. +----------+ AAA +-------+
. TDM call-->| | ---> | AAA |
. -----------|D-channel | +-------+
. | NAS | IP Data
. | |<----------------->
. +----------+

From signaling point of view, NAS is responsible to setup TDM calls coming to the D-channel. Do we need to create a new protocol for AAA to communicate with NAS to set up the calls for VoIP applications and L2TP Tunneling applications?

NAS and AAA relationship:
- Concerns are: what are the interfaces between MGC and AAA?
- Concerns are: what are the timing issues?
- Concerns are: Are we going to allow thousands of real-time calls' authorizations flow thru AAA?
- Concerns with picking up the complexity and expericence of NAS services and AAA in another protocol!
- AAA group is meeting later in this IETF meeting to discuss these Megaco call set-up issues.
- Call-back profile in AAA:

ss7 call setup ---> MGC --->AAA
|
call-back authorization <----|

- Megaco WG is only looking at L2TP for NAS application today.
- Other issues are policy issues on MGC:
- How do you set up the relationship between MGC and AAA?

a proposal below:

. +-----+
. | | Call request +----------+
. | |----------------->| AAA |
. SS7 calls --->| MGC |<---Set up L2TP---| |
. | | +----------+
. +-----+ ^
. ^ |
. | Megaco w/AAA data |
. v |
. +-----+ |
. | | AAA |
. | |----------------------+
. PRI calls --->| NAS |
. | | IP Data
. | |<------------------>
. +-----+

- MGC does call control/setup/policy management
- Some NAS devices are very simple and may not support AAA function, in the future (given this kind of deployment).
- Megaco is meeting on Thursday morning to discuss these issues.

6. Next Steps?
Per discussion and hum consensus, we are NOT going to produce a Nasreq Protocol Evaluations draft; but the door is always open.

Given no more active documents, the chair does not expect to call for more meetings unless some particular need arises. The group will stay active on the mailing list while the AAA effort is ongoing.

<attached presentations from Nov 1999 meeting>

Slides

NAS Criteria and COPS
RADIUS Vs. Criteria