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

From: Bilalis Zacharias <[email-masked]>
Date: Fri, 8 Oct 1999 08:51:25 +0200

What happens if NAS access fails due to AAA deny? Must MGC not be informed ?

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 22:54
> An:   [email-masked]
> Betreff:      Re: AW: Basic Package and NAS (was Re: AW: Packages
> Conference Call M inutes)
> 
> Where is this "need" that you mention? As I said, the model actually works
> 
> today. It is not deficient. Millions are using it with ISDN and in fact a 
> great deal of NAS ports are using the current AAA model with the new 
> signalling architecture, and with a MEGACO pre-cursor protocol (e.g.
> Q.931+ 
> and IPDC).
> 
> As for the MGC being in charge of end-to-end, that isn't even true for an 
> ordinary voice call, much less a data call. With voice, in a trunking 
> scenario, there is a source and destination MGC and each control's their 
> own MG. With data for Internet access, the MGC *only* passes the call off 
> to the NAS. The rest of the end-to-end data session has other IETF
> standard 
> entitites controlling it. AAA servers, LNS's, route servers, etc., control
> 
> this. Not the MGC.
> 
> 
> At 03:03 PM 10/7/99 -0400, Faad Ghoraishi wrote:
> 
> 
> 
> >Matt writes:
> > >The NAS supports all the actions you list below today through the IETF
> > >standard methods. Perhaps you should discover how NAS's work today to
> see
> > >how they can work best with MEGACO.
> >
> >I know that the NAS today support all the actions I listed. What is your 
> >point?
> >
> >These are old methods, we need to have new methods in MEGACO.
> >As Chip said, it is good and most likely required to be backward 
> >compatible with
> >old NAS functions, but we need to MOVE ON.
> >If the MGC is truly in charge of the end to end call, then it MUST know
> of all
> >AAA and Tunneling
> >procedures. Futher it should be able to activate these functions within 
> >the NAS
> >termiantions.
> >
> >Why do you want to dublicate data provisioning in both the NAS (as is 
> >today) and
> >the MGC (in the future)?
> >
> >
> >Faad
> >
> >
> >
> >
> >
> >Matt Holdrege <[email-masked]> on 10/07/99 02:27:34 PM
> >
> >Please respond to Matt Holdrege <[email-masked]>
> >
> >To:   [email-masked]
> >cc:    (bcc: Faad Ghoraishi/Bellcore)
> >Subject:  Re: AW: Basic Package and NAS (was Re: AW: Packages Conference
> >       Call M inutes)
> >
> >
> >
> >
> >The NAS supports all the actions you list below today through the IETF
> >standard methods. Perhaps you should discover how NAS's work today to see
> >how they can work best with MEGACO.
> >
> >
> >At 09:32 AM 10/7/99 -0400, Faad Ghoraishi wrote:
> >
> >
> >
> > >I have the same concern as Bilalis about not supproting AAA function in
> > >MEGACO.
> > >How does the NAS notify the MGC of the success of AAA?
> > >If it is through the O,A&M interface (as Matt suggested), it is unwise 
> > to mix
> > >call related
> > >messages with operation system messages. During congestion, this is
> > >potentially going to be a nightmare.
> > >
> > >Also, if MEGACO does not support AAA and/or Tunneling requests, is the
> NAS
> > >suppose to
> > >now maintain Call State for each incoming modem call. How is the NAS to
> know
> > >what AAA protocol
> > >to use per call (i.e., RADIUS, TACACS, Login, etc.)? Is it going to 
> > maintain a
> > >list of Called Number (ISP number) and
> > >the associated AAA protocol to use
> > >Also, how does NAS  know  which framing to use (PPP asynch, PPP hdlc,
> SLIP,
> > >etc)?
> > >
> > >May be the MEGACO protocol should not support PPP and L2TP protocol
> > >itself, but
> > >it should
> > >certainly support the capability to request such protocol  from MGC to
> MG.
> > >
> > >
> > >Faad Ghoraishi
> > >Telcordia Technologies, Inc
> > >********************************************
> > >
> > >
> > >
> > >
> > >Bilalis Zacharias <[email-masked]> on 10/07/99
> 02:58:22 AM
> > >
> > >Please respond to Bilalis Zacharias <[email-masked]>
> > >
> > >To:   [email-masked]
> > >cc:    (bcc: Faad Ghoraishi/Bellcore)
> > >Subject:  AW: Basic Package and NAS (was Re: AW: Packages Conference
> Call M
> > >       inutes)
> > >
> > >
> > >
> > >
> > >         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: Fri, 8 Oct 1999 11:30:41 -0700

MUST? No. Just as a Class 5 switch is not informed of nor has any knowledge 
of an AAA server. COULD? Perhaps if you wish to build that type of feature 
into your system. It would be a trivial task to have your MGC notified of 
AAA activities (heck, they could even be in the same box!), but MEGACO 
should not be encumbered with such overhead and complexity.