Subject: AW: Basic Package and NAS

From: Bilalis Zacharias <[email-masked]>
Date: Mon, 11 Oct 1999 13:59:19 +0200

If e.g. AAA fails, the cleanest solution is that MGC is informed and ends
the connection

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:  Freitag, 8. Oktober 1999 20:31
> An:   Bilalis Zacharias
> Cc:   [email-masked]
> Betreff:      Re: AW: AW: Basic Package and NAS (was Re: AW: Packages
> Conference Ca ll M inutes)
> 
> 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.
> 
> 
> At 08:51 AM 10/8/99 +0200, Bilalis Zacharias wrote:
> >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: Mon, 11 Oct 1999 08:27:30 -0700

That is exactly what happens. The MG may disconnect internally and send a 
MEGACO disconnect message to the MGC. But any auth information in that 
message would be optional.