Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt

From: Chip Sharp <[email-masked]>
Date: Tue, 11 Jan 2000 15:57:27 -0500

At 09:43 PM 1/10/00 -0500, Tom-PT Taylor wrote:

>This is a timely intervention.  Before sending the requirements off to the
>IESG I wanted to do one last check of the archives.  I found a great deal
>of responsiveness to Matt's concerns, but not complete capitulation.  I
>think the proof of the wisdom of these requirements will be found in the
>packages which emerge to meet them.  In any event we aren't going to be
>held up in the way Matt feared.  I am therefore going to send the
>requirements document in to the IESG as it stands.
>
>What follows is totally optional reading, but might make sense out of past
>debates.
>
>Fundamentally, I think we are all agreed (including Matt) that Megaco must
>work within the following logical control architectures:

I agree that we should support item 1.  This would allow current NASes to
operate most similarly with today's operation.

I see item 2 as a subset of  item 1 and as such has no further affect on
megaco.  It does require the MGC to act as a AAA proxy and support the
capabilities required thereof, but that is independent of megaco.

See comments below:

>(1) NAS connects directly to AAA
>
> >              +-------+        +-------+
> >   Signaling  |       |        |       |
> >   -----------+  MGC  +        |  AAA  |
> >              |       |        | server|
> >              +---+---+        +--+----+
> >                  | Megaco       /
> >                  |             /
> >              +---+---+        /
> >              |       |   AAA /
> >              |  NAS  +------/
> >              |       |
> >              +-------+
> >
>
>(2) MGC proxies AAA
>
> >              +-------+        +-------+
> >   Signaling  |       |  AAA   |       |
> >   -----------+  MGC  +--------|  AAA  |
> >              |       |        | server|
> >              +-+-+---+        +--+----+
> >          Megaco| |AAA
> >                | |
> >              +-+-+---+
> >              |       |
> >              |  NAS  |
> >              |       |
> >              +-------+
> >
>
>The first case places the requirement on Megaco to be able to transport
>anything which could be received in or derived from call signalling which
>is needed for NAS operation, in addition to local policy.  The second case
>is the same as the first case if the NAS initiates the AAA transaction.

Agreed.

>The second case introduces novel elements if the MGC is the one to
>initiate the query to the AAA server.  There are two possibilities, both
>of which have their challenges:
>
>(1) The response leg of the AAA transaction is passed through to the NAS
>using an existing AAA protocol.  In this case Megaco has to have the means
>to tell the NAS that this information is coming, and to allow the NAS to
>correlate it with the related Megaco transactions.  The correlating
>information clearly depends on the particular AAA protocol being used, so
>we can look forward to separate packages corresponding to the respective
>protocols.  Goutam has suggested, I believe, the alternative that
>correlation is achieved by proximity, by tunneling the AAA protocol within
>the confines of a Megaco command.
>
>
>(2) The response leg of the AAA transaction is translated to a Megaco
>equivalent.  This leads to the bottomless swamp of protocol duplication
>Matt warns about, except that it may not be necessary to pass everything
>in the AAA response down to the NAS.  Some information may go no further
>than the MGC.  This approach seems to be implicit in some of the
>requirements Nancy has defended.

I believe one of the main points has been missed in the summarization.

Existing AAA protocols (e.g., RADIUS, TACACS+), provide services for
Authentication (are you who you say you are), Authorization (what services
are you allowed access to) and Accounting (what happened
:-).  Traditionally this was done based on the login information from the
dialin user (PAP, CHAP, async login).  However, with the advent of ISDN
more information was available at call setup time to make decisions (e.g.,
Calling party number, Called Party Number).

There were two concurrent trends.  Vendors found it convenient to download
configuration information at the time of Authentication and/or
Authorization.  Vendors also found it convenient to use the call setup info
to key on certain information.

Several of the people who originally developed RADIUS repeatedly stressed
that RADIUS was not intended to be a configuration protocol.  However, the
convenience of using it as such was too great.  Therefore, more and more
configuration was added to RADIUS.  Thus, configuration has erroneously
(IMO) been lumped into the term AAA.

Current NASes  (not all) in dialup networks today can be configured to do
two RADIUS accesses.

The first is done during Call Setup and is based on Calling or Called Party
Number to return some relevant information (e.g., L2TP tunnel info, AAA
server info, etc.)

The second is based on the username/password acquired during LCP
negotiation to do AAA (plus further configuration such as returning an IP
address to use for the connection).

In an MGC/NAS architecture, the MGC can handle the Call Setup configuration
information based on the Calling Party Number, Calling Party Number, CIC or
some other info.  This is not much different from what it does for
Voice.  The MGC can store the configuration locally or use LDAP, RADIUS or
TACACS+ to access an external server.  Whatever way it chooses, the MGC
must then be able to send the configuration information to the NAS so the
NAS can connect the call and treat it appropriately.

After the NAS connects the call and performs LCP negotiation, it will
perform AAA normally using RADIUS or whatever protocol the AAA group comes
up with.

Chip

>-----Original Message-----  From:   Goutam Shaw
>[SMTP:[email-masked]]  Sent:   Monday, January 10, 2000
>6:11 PM  To:     [email-masked]  Subject:        Re:
>I-D ACTION:draft-ietf-megaco-reqs-09.txt
>
>Nancy, I'm sorry for the delayed reply. I thought we had put this matter
>to rest once and for all after we had the conf. call that was attended by
>Nancy, Myself, Matt and I think Gunner. According to my opinion what we
>have in the requirements is not AAA. These are configuration parameters
>that are call specific and have to be conveyed to the MG before the call
>is terminated and SHOULD NOT AND CANNOT BE dealt by a AAA server. The
>parameter should help determine how the call is supposed to be treated and
>has nothing to with "AAA". I would like to keep section d (of
>draft-ietf-megaco-reqs-10.txt)  as it is, that relates to the ability to
>configure the call adaptation rate. For example, for a given call a
>service provider might want to restrict the call to 28.8 kbps based on the
>call specific policy information.  As Tom has mentioned we don't need a
>unanimous decision all we need is a consensus and I believe we have it
>(unless I hear any major objection from the mailing list which I haven't
>heard in the past on this topic). Regards, ..Goutam. Nancy-M Greene wrote:
>    Matt, Megaco/H.248 is a device control protocol. It is true that for
> NAS, we allow the MG itself to contact the AAA server. Yet, there will be
> implementations that would have the MGC contact the AAA server. The
> requirements in this section allow for the development of a NAS package
> IN THE FUTURE, that would allow the information returned from the AAA
> server to be passed down to the MG. How this package would be written is
> NOT specified in this requirements document.  As for your comment that
> ALL your comments regarding the NAS section have been ignored, this is
> simply not true! Your comments have been discussed several times on the
> mailing list. As editor, I have tried to come up with compromise text
> again and again, and every time, you come back saying I haven't yet
> succeeded in satisfying your wishes.  Perhaps it is time for the chair to
> step in and see if we have rough consensus on the requirements document
> or not.  Your comment on 11.2.1 D is correct. 11.2.1 D will be removed
> from the requirements document.  Also, I don't understand your comment
> that the requirements document should change, based on recent discussions
> of the protocol. We did update the requirements document based on
> discussion at the Washington meeting. Tom is planning to put out a
> companion I-D that maps the Megaco/H.248 protocol against the
> requirements document.  Nancy
> --------------------------------------------------------------------------
 >  Nancy M. Greene Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077)
> E:[email-masked]         ---------- From:  Matt
> Holdrege[SMTP:[email-masked]] Sent:  Thursday, December 23, 1999 12:00
> PM To:    [email-masked] Subject:       Re: I-D
> ACTION:draft-ietf-megaco-reqs-09.txt         It's sad to see that all my
> comments regarding the NAS section have been ignored again. So let's go
> through them one more time and I'll try to put more detail into my
> comments.          At a high level, NAS requirements should be set by the
> NAS requirements working group. That's where the experts are. Also, it's
> easy to see that there are NO specific NAS requirements for MEGACO. For
> the basic purposes of MEGACO, a NAS is no different than a VoIP gateway.
> I can see how you may want to do some special things with special
> packages, but nothing in the base protocol needs to be NAS
> specific.          So let's go through the NAS requirements step by
> step...          A. Callback. This is all that's listed. There are many
> aspects to callback which are covered by RADIUS and are a part of the new
> AAA requirements. If all you can list is callback, you should remove this
> requirement and leave it up to AAA where it belongs.          B. Modem
> types. This is also handled by RADIUS and AAA. The MG contacts the AAA
> server to instruct it on which modem to use. Remember that the MGC and MG
> are not necessarily in the same management domain. But the MG DOES trust
> it's AAA server. So that is where the information must come from and it
> works best if it is transmitted directly. If you introduce a proxy, you
> introduce a lot of difficulties. The AAA WG is trying to deal with the
> difficulties of proxy and we shouldn't jump ahead of them.          C. D.
> E. F. These requirements can and should be covered by a single sentence.
> The Protocol must be able to support Q.931 IE's. F already kind of says
> this. Please be succint and less tutorial. Q.931 IE's are a basic
> requirement of all MG's. Not just NAS's.           >g.   Ability for the
> MGC to direct the NAS to connect to a specific tun-  >     nel, for
> example to an LNS, or to an AAA server.          There are a multitude of
> tunnel types on the Internet. L2TP, IPsec, IPinIP, IPSRA, RSIP, GRE,
> PPTP, ATMP, etc. These tunnel types are not all the same. They are
> handled in different IETF working groups that have defined their
> operation and their setup. The MEGACO WG should not be dictating how
> tunnels get set up. Working groups such as L2TPEXT have defined RADIUS to
> setup their tunnels.          H. This is already covered in the VoIP
> section. Reproducing requirements is just adding confusion.          You
> mention that wiretapping has been removed, yet it is still in 11.2.1 D.
> Whether the MEGACO protocol allows wiretap or not, I don't think we want
> this specific requirement in an RFC. This was discussed at the Washington
> plenary.          Lastly, I think this document should go through a more
> lengthy last call since we are in the holiday time. We've gone into
> detail at the last two meetings on the protocol itself and this
> requirements document doesn't accurately reflect that.          At 09:41
> AM 12/10/99 -0500, Tom-PT Taylor wrote:          >I propose WG Last Call
> based on this document, with the expiry two weeks >hence (24
> December). > >Changes from the previous version are as follows: > >-
> removed reqt 5.6 c) Support general test capabilities, for
> example >loopbacks through the MG to test DSP operation. >It was agreed
> that inward loopbacks are outside the scope of the protocol >- they are
> not part of call control, so would be handled by some other >maintenance
> protocol. Thus the above requirement is deleted. > >- reqt 5.7 a) -
> changed word call to connection > >- table in section 11 -
> removed  wiretap > >- reqt 11.1.3.1 a) rewording of 2nd bullet  on
> addressing - didn't mean >wildcarding, meant instead allowing the gateway
> to choose (part of) the >identifier > >The references need to be
> completed still, and there may be an editor's >note or two that should
> still come out. >-----Original
> Message-----  From:
> [email-masked] >[SMTP:[email-masked]]  Sent:
> Friday, December 10, 1999
> 8:08 >AM  To:     [email-masked]  Subject:
> I-D >ACTION:draft-ietf-megaco-reqs-09.txt > >A New Internet-Draft is
> available from the on-line Internet-Drafts >directories.  This draft is a
> work item of the Media Gateway Control >Working Group of the
> IETF. > >         Title           : Media Gateway control protocol
> architecture >
> and                            requirements          Author(s)       :
> N. > Greene,  M. Ramalho,  B. Rosen          Filename        : >
> draft-ietf-megaco-reqs-09.txt          Pages           : >
> 45          Date            : 09-Dec-99 > >TThis document describes
> protocol requirements for the Media Gateway >control protocol between a
> Media Gateway Controller and a Media Gateway. A >URL for this
> Internet-Draft >is: ><
> <<http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>http:/
> /www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>>
> <http://w> >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > >I
> nternet-Drafts are also available by anonymous FTP. Login with
> the >username  "anonymous" and a password of your e-mail address. After
> logging >in,  type "cd internet-drafts" and
> then          "get >draft-ietf-megaco-reqs-09.txt". > >A list of
> Internet-Drafts directories can be found >in  <
> <<http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html>>
> <http://www.ietf.org/shadow.html>  or ><
> <<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shado
> w-sites.txt>>
> <ftp://ftp.ietf.org/ietf/1shadow-> >sites.txt > >Internet-Drafts can also
> be obtained by e-mail. > >Send a message
> to:          [email-masked].  In the body >type:          "FILE
> /internet-drafts/draft-ietf-megaco-reqs-09.txt". > >NOTE:   The mail
> server at ietf.org can return the document >in          MIME-encoded form
> by using the "mpack" utility.  To use >this          feature, insert the
> command "ENCODING mime" before the >"FILE"          command.  To decode
> the response(s), you will need >"munpack" or          a MIME-compliant
> mail reader.  Different >MIME-compliant mail readers          exhibit
> different behavior, >especially when dealing with          "multipart"
> MIME messages (i.e. >documents which have been split          up into
> multiple messages), so >check your local documentation on          how to
> manipulate these messages. > >Below is the data which will enable a MIME
> compliant mail >reader  implementation to automatically retrieve the
> ASCII version of >the  Internet-Draft. << Message:  >>
>  << File: Card for Goutam Shaw >>

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 11 Jan 2000 22:06:21 -0800

>to key on certain information.

It had nothing to do with vendor convenience. It has to do with ISP demand.
That's the way that the vast majority of ISP's choose to run their operation.

>perform AAA normally using RADIUS or whatever protocol the AAA group comes

That's where problems can occur. Some of those tricky config paramters must
be performed DURING the LCP phase. So you have to have them all lined up in
advance.

The big problem with this MEGACO proposal is that the real world of
Internet Access is much, much more complex that anything written in an RFC.
RADIUS has evolved quite a bit to support that complexity. Nothing written
in any MEGACO draft comes close to meeting true ISP requirements.