Subject: AW: Basic Package and NAS (was Re: AW: Packages Conference Call M inutes)

From: Bilalis Zacharias <[email-masked]>
Date: Thu, 7 Oct 1999 08:58:22 +0200

In the introduction of the NAS package, It is mentioned that dial-in
access to the NAS is supported, not the
 contact to a AAA server. The latter is part of other protocols. That is why
issues e.g. how password is sent to AAA server and accepted/rejected are not
part of the package. But if we want to support dial-in access, we have to
know if the AAA server has permitted the access or no.

Best Regards 

Zacharias Bilalis

SIEMENS ICN WN CS EC D12
> Schertlinstr. 8
> D-81359 Muenchen
> Germany
Tel: + 49 89 722 28391
Fax: + 49 89 722 61243
Mail to: [email-masked] 

> -----Ursprüngliche Nachricht-----
> Von:  Matt Holdrege [SMTP:[email-masked]]
> Gesendet am:  Donnerstag, 7. Oktober 1999 00:56
> An:   [email-masked]
> Betreff:      Re: Basic Package and NAS (was Re: AW: Packages Conference
> Call Minutes)
> 
> At 01:32 PM 10/6/99 -0400, Chip Sharp wrote:
> >It is hard to reconcile the NAS part of this package with the
> requirements
> >in draft-ietf-megaco-reqs-06.txt.
> 
> As I've said on many an occasion, the requirements as written go outside
> the scope of MEGACO. We even had a conference call on this issue which I
> though solved the problems. Bottom line, we do not do AAA with MEGACO!!
> 
> >I'm especially referring to the following text:
> >"This encompasses the support of dial-in access to the NAS, but not the
> >contact to a AAA server for authentication, authorisation etc and the
> >possible subsequent set-up of a layer 2 tunnel to a remote NAS. Those are
> >autonomous functions of a NAS and therefore out of scope for the Megaco
> >protocol (see e.g. IETF RFC 2661 (L2TP) and RFC 1661 (PPP)). "
> >
> >It is certainly desirable to allow legacy NAS equipment to continue
> >operating as currently deployed and implemented.  However, to restrict
> >future development to legacy capabilities is over-restrictive.  It is a
> >definite probability that megaco may be used for a host of things related
> >to AAA and tunneling (among other things) at least based on information
> >received from the SCN (e.g., Called Party Number, Calling Party Number,
> >Bearer Capability, etc.).
> 
> If you think the current scheme is "legacy" and should be improved, you
> should be contributing to the discussions going on in the AAA WG. I don't
> think characterizing the method currently used by 50,000,000-odd Internet
> users is overly restrictive. The Internet would not have scaled as
> massively and quickly had that been true.
> 
> >It is clear that the NAS package is pretty rudimentary and will have to
> be
> >extended substantially for proper operation of a Dial POP.  This may not
> >happen until after the white paper is released or after H.248 is
> approved.
> >
> >If you don't want the currently defined NAS package to provide these
> >features, then don't include them.  But don't say they are outside the
> >scope of megaco.
> 
> I think that protocols that are handled by other WG's are outside the
> scope
> of MEGACO. The L2TP WG handles L2TP. The AAA WG handles AAA.
> 
> >Actually, the more I think of the current megaco architecture since the
> >March Compromis (reminds me of the Missouri Compromise) the more I think
> >the best way to support NAS behavior is via a NAS termination.  In this
> >case, the DS0 termination would control behaviour of the DS0 and the NAS
> >termination would control the behaviour of the NAS (modem type, HDLC
> >controller, which AAA server to use, which L2TP destination to use,
> >etc.).  This would have to be rolled up into a package defining the media
> >descriptor, eventdescriptor and signaldescriptor parameters.
> >
> >Other items:
> >
> >In Section 3.14.2.1.4 (CallBack Request), you take into account only AAA
> >initiated callback.  There are various other types of callback allowed
> >(e.g., PPP callback) that may not involve AAA.
>
> PPP callback is a part of PPP and has nothing to do with MEGACO except
> that
> the PPP engine on the NAS will request a call setup to the MEGACO engine.
> The same works for any method of setting up a call on a NAS.
> 
> 
> >Authorisation Succeed/Fail:
> >RADIUS doesn't separate Authentication and Authorisation.  However, they
> >are separate events.  Therefore, a user could conceivably pass
> >Authentication and fail Authorization for a service.  If these types of
> >indications are to be sent to the MGC, then they should be separated into
> >separate events.  I see that the package has the Authorisation event
> >defined but there is no Authentication event defined.
> 
> If the MGC needs to know about Auth failure, it can learn that from the
> AAA
> server out of band of MEGACO.

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 7 Oct 1999 08:30:09 -0700

>know if the AAA server has permitted the access or no.

It may be desired, but it's not at all mandatory. Internet access today
using ISDN doesn't provide this at all. The out of band management knows
the result of the AAA, and optionally the end-user can be informed, but the
call control has no knowledge of AAA nor has it ever been required to have
this knowledge. All we send back to call control is a disconnect.