Subject: Re: MGC-Initiated Control

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Jun 2000 10:47:45 -0400

It's a potential security problem, because any arbitrary MGC that
stumbles across an otherwise unmarried MG can take it over.  In the
present model the MGC has to be someone you are provisioned to trust,
or someone one of the MGCs you trust told you to trust.

Not a really big deal.  I think the circumstance is so rare as to be
not worth worrying about.  I did think about a circumstance where
the MG lost connectivity to all MGCs.  It went through its list in
vain.  The real correct response, when connectivity is restored, is
to restart the search, and not to have some MGC simply step up and
take it.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Friday, June 02, 2000 9:45 AM
> To: [email-masked]
> Subject: MGC-Initiated Control
>
>
> There are cases where an MG will not be able to initiate a
> control session
> (e.g. it has gone through its list of MGCs without success).
> Can we agree
> on principle that an MG that is not currently in a control
> session will
> respond to an MGC-sent ServiceChange command directing it to
> initiate a
> session at a given address?  If so, we could add this to the
> Implementor's
> Guide and our IETF equivalent.
>
> The exact text that would go into the Implementor's Guide would be as
> follows:
>
>         If an MG is not currently in a control association
> with an MGC and
> it receives a ServiceChange command from an authorized source with
> ServiceChangeMethod equal to Handoff, it will attempt to
> initiate a control
> association as directed by that command.  To make this
> possible, an MG not
> currently in a control session shall listen for incoming
> commands at the
> default transport address corresponding to its supported transport and
> encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: [email-masked]
>

---

From: Michael Thomas <[email-masked]>
Date: Fri, 2 Jun 2000 08:49:57 -0700

> or someone one of the MGCs you trust told you to trust.

   I wouldn't think that that should be a problem
   if you require an SA to be established first.
   Regardless of which side initiates the SA, you
   still need to authenticate the remote side to
   determine whether they are who they claim they
   are.

                Mike

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 2 Jun 2000 13:54:56 -0400

> or someone one of the MGCs you trust told you to trust.

Are you saying that the protocol does not allow an MG to talk to an MGC
that's not part of a pre-provisioned list of MGCs, or are you simply
referring to proper security credentials being presented ?

-- Flemming

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839

---

From: Michael Brown <[email-masked]>
Date: Fri, 2 Jun 2000 13:58:01 -0400

I agree with the overall response, because the protocol doesn't specifically
prohibit it but had one other thought about the proposal.

The question I have is how the new MGC would know that the MG is
"stranded".  What is  the mechanism that would be used to trigger an MGC to
initiate the connection in the first place?  The MGC has to know somehow
that it is supposed to initiate control. This to me implies that some
network management function identifies the MG as stranded and then messages
to the MGC telling it to initiate the control handoff. If that's the case,
why wouldn't the NM function just tell the gateway to add the new MGC to its
list and then the model for initiating the control association doesn't
change.

As mentioned though, I don't suppose it really matters too much since the
trigger mechanism is outside the scope of Megaco and the protocol doesn't
prohibit the suggested behavior.

Mike