Subject: RE: Polls of MGC

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 24 May 2001 11:09:39 -0400

There is a pretty fundamental difference between
	"Will you help me?"
and
	"I'm your new master"

We believed that the common case would be many slave MGs with limited
resources and fewer, more powerful MGCs.  In that environment,
making the MG the client and the MGC the server, authentication is
done by the server against the client, and not vice versa.

The whole protocol is based on this approach, and it is pretty uniform
about it.  If you allow it to change, for example as Troy suggests, breaks a
couple of things.  The most significant is TCP.  The protocol always
defines the MG as starting the connection.  This means the MG is
a TCP client, and never a TCP server.  If you allow the MGC to start
the association, then the MG would have to be a TCP server.  This is
not a good idea for small MGs.  It also breaks a set of simplifying
assumptions MGs can make about ServiceChange, and also about creating
security associations in IPSEC.

Brian

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 10:53 AM
> To: 'Rosen, Brian'; 'Troy Cauble'; 'Terry L Anderson'
> Cc: [email-masked]
> Subject: RE: Polls of MGC
> 
> 
> Hi Brian/all,
> A Novice doubt. If the MG can say to MGC that "I'm your slave...please
> control me", why not the MGC can say "I'm your new master". I 
> think both MG
> and MGC will know each other by pre-provisioning. Else any MG 
> can register
> to any MGC and any MGC can control any MG.
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rosen, Brian
> Sent: Thursday, May 24, 2001 10:17 AM
> To: 'Troy Cauble'; Terry L Anderson
> Cc: [email-masked]
> Subject: RE: Polls of MGC
> 
> 
> Security implications.
> "Hello, I'm your new master. Don't worry, everything will be 
> all right"
> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 9:57 AM
> > To: Terry L Anderson
> > Cc: [email-masked]
> > Subject: Re: Polls of MGC
> >
> >
> > Terry L Anderson wrote:
> > >
> > > (resending since my original seems not to have made it to 
> the list)
> > >
> > > MGC/MG relationship is indeed master/slave but
> > registrations are only
> > > initiated
> > > from the MG end, so MGC being aware of loss of connectivity or an
> > > alternate MGC
> > > being aware that the primary is down does not allow
> > reconnection to the
> > > alternate - only the MG can take action to register with
> > the alternate
> > > (as in
> > > 11.5).
> >
> > Again, it seems much cleaner to fix this problem by changing
> > "registrations are only initiated from the MG end" statement.
> > Why are MGC initiated regstrations considered so evil?
> >
> > -troy
> >
> > > So it seems to me most important that MG detect failures (as it
> > > is the
> > > only one that can take action).  Its the MGC that can do
> > little when it
> > > detects
> > > a failure.
> > > MGC perhaps should make the decision as to whether failures
> > should be
> > > detected
> > > and frequency of polling but it seems to me that MG should do the
> > > polling.
> > >
> > > For failures of a TCP link or MGC failure and recovery
> > without loss of
> > > state,
> > > MGC may reestablish communications with a re-registration,
> > but I don't
> > > understand how an alternate MGC can take over after a
> > primary failure
> > > without MG
> > >
> > > detecting the failure.
> > >
> > > I did not think that an MG normally sent Add, Move,
> > Subtract.  I believe
> > > that
> > > the only MG initiated transactions commonly used are Notify and
> > > ServiceChange.
> > > Thus during a quiet period (edge GW with SS7/ISUP
> > signaling, no active
> > > calls),
> > > there would be no active events and so no reason to send
> > either Notify
> > > or
> > > ServiceChange and so GW would be unaware that:
> > > 1. MGC has gone down
> > > 2. network has lost connectivity to MGC
> > >
> > > In either case, without polling, MG would be unaware.  Yet
> > registering
> > > with
> > > alternateMGC might allow it to handle calls.
> > >
> > > I thought that the previously discussed methods for MGC and for MG
> > > polling were
> > > adequate but if we want to add a new mechanism, one could
> > allow complete
> > > control
> > >
> > > from MGC end by adding a "timer" event through a package. 
>  MGC could
> > > activate
> > > the timer event on say root termination and this would
> > cause a notify
> > > after the
> > > MGC specified period.  MGC would detect failure by lack of
> > this notify.
> > > MG
> > > would detect failure when the Notify received no reply.  MGC thus
> > > decides
> > > whether polling should occur, what period to use and there is only
> > > polling
> > > traffic in one direction but both ends detect failure.  
> It would be
> > > improved if
> > > the package specified that the timer was automatically 
> reset by any
> > > messages, so
> > >
> > > it would fire only when no messages had been exchanged for
> > the specified
> > > time
> > > (MGC would still detect failure by absense of any message
> > for greater
> > > than the
> > > timer period, MG detect by failed reply).
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day Troy et all,
> > > >
> > > > Sorry for the late support of No Polling. I still have 
> not seen a
> > > > definitive reason that the MG needs to poll the MGC. We
> > have defined a
> > >
> > > > master slave protocol with the MGC as the master. The MGC
> > should be in
> > >
> > > > control of error situations.
> > > >
> > > > I believe that it's enough that the MG can detect that 
> the MGC has
> > > gone
> > > > down when it try to signal using any appropriate H.248
> > Commands ie.
> > > > Add, Move, sub replies, Notify request, Service Change
> > etc. Lack of
> > > > timely response will indicate failure. The MG can then 
> re-register
> > > based
> > > > on this.
> > > >
> > > > If you look at the common MG use cases:
> > > > 1. The MG is a trunking gateway. In this scenario enough
> > traffic will
> > > be
> > > > generated to maintain a reasonable flow of signalling to
> > minimise the
> > > > time to detect errors. For a proper Telco solution you 
> should also
> > > have
> > > > enough management systems/redundency to know what MGC to
> > hand over to.
> > >
> > > >
> > > > 2. The MG is a residential gateway. Signalling traffic 
> is not that
> > > great
> > > > but interaction is only needed with the MGC when the 
> end-user does
> > > > something. Therefore the MG will find out about the
> > failure at this
> > > > time. Why generate unessary signalling across limited BW links?
> > > There's
> > > > the avalanche problems mentioned earlier but more
> > importantly someone
> > > > will have to pay for bandwidth this signalling takes
> > which basically
> > > > serves no purpose.
> > > > Again in this scenario the MGC will hopefully be owned by
> > someone who
> > > > wants to offer a decent service and has the necessary management
> > > > systems/reduncy. I do not envisage MG registration will
> > take very long
> > >
> > > > on a small residential gateway. Its a ServiceChange
> > request/response
> > > > round trip.
> > > >
> > > > What ever the proposed package, service change
> > reason/method, protocol
> > >
> > > > update polling is unecessary.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Troy Cauble wrote:
> > > > >
> > > > > Dave Sclarsky wrote:
> > > > > >
> > > > > > Troy,
> > > > > >
> > > > > > It doesn't matter what the new (or restarted) MGC
> > knows or doesn't
> > > know.
> > > > > > Megaco defines that the control association between
> > MG and MGC is
> > > ALWAYS
> > > > > > initiated by the MG.
> > > > >
> > > > > Then this definition is the problem and should be revisited.
> > > > >
> > > > > Polling is bad.
> > > > >
> > > > > -troy
> > > > >
> > > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > > reachable by a new (or a restarted) MGC until the his
> > MG notices
> > > the
> > > > > > failure.  We must define a way for it to know ASAP!
> > >
> > > --
> > > -------------------------------------------------------
> > > Terry L Anderson, DMTS                   [email-masked]
> > > Lucent Technologies /INS/ Voice over IP Access Networks
> > > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > > Voice:908 582-7013  FAX:908 582-6729
> > > http://its.lucent.com/~tla  (Lucent internal)
> > > http://www.gti.net/tla
> > > -------------------------------------------------------
> >
>

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 24 May 2001 14:49:23 -0400

HI Troy,
Even if you interpret the message from the new MGC as "I'm sorry to inform
you that your old master is ill.
	 Please verify this and find yourself another."

The new MGC itself is not secure how can we expect any triggers from this
unknown MGC (if not the handoff/any other registration commands). At least
if you try to find whether the old master is still active...this again will
give chance for "ping of death attack".

Regards
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Troy Cauble
Sent: Thursday, May 24, 2001 2:01 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: Polls of MGC

> There is a pretty fundamental difference between

Yes there is, but it's mostly your aggressive phrasing.
How about:
	"I'm sorry to inform you that your old master is ill.
	 Please verify that I am an acceptable new master."
or even
	"I'm sorry to inform you that your old master is ill.
	 Please verify this and find yourself another."

As implied by the latter one, the MG could register with
whoever it wants.  This message would just be a notification.

In fact there probably already is a ServiceChange message
that would work well for that.  The only change is that
when it gets that message from other than it's master, it
verifies that it's master is unreachable.

> security associations in IPSEC.

Yes, a TCP only MG would need to accept TCP connections.
I really don't think that's a burden.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Thu, 24 May 2001 14:01:26 -0400

-troy