Subject: Re: Topology

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Aug 1999 07:59:31 -0400

To implement LI, you need all the components of the network to do the
right thing.  What is the right thing for Megaco, which is in the middle?
Doesn't it depend on what the MGC does?  Does it have anything to do with
how the MGC-MGC protocol works?  What about the edge router - if it is
a REQUIREMENT that data taps be made, then it may make much more sense
to do all the intercept there.

You can't decide what the requirements in the MEGACO protocol are without
understanding what the system requirements are, and allocate them
appropriately.  You can't meet the deadline by making MEGACO do all the
work.  You can't meet the deadline if MEGACO makes one assumption, and
edge routers make another that conflict.  I wouldn't even start working
on implementations of this kind of capability unless I got the LEAs to
look at the whole SYSTEM and tell me if it meets the requirements because it
is harder to fix it AFTER I commit a design.  This effort smacks of
"Do something, do anything, the sky is falling".

There is NO way you can claim that the topology solution offered is
necessary or sufficient to achieve the goal.  You can only claim that
you think it might be looking at the problem through blinders.
That is not good enough.

Doing a proper system design is not only practical, it is necessary.
We can only argue about who does it.  It can be done if all the components
and the interfaces are standardized, or it can be done proprietarily.
There is sufficient time to do it right.  There has to be sufficient
motivation, we should participate (we HAVE to participate), but we can't
do it alone.

As to operator monitoring - wouldn't a listen-only termination do?  We
have that.

With respect to context parameters, when we need them, we add them.
We have been discussing what makes the most sense in this case.
I happen to agree that making it a command parameter is easier in this
case, regardless of whether it is done with pairwise specification
or list per termination.

I will take issue with parameters being optional.  Packages are optional
commands, and their parameters are not.  We aren't protocol police,
but if we defined topology, ANY Megaco/H.248 implementation would have
to implement them if it was claimed to be conformant to the spec.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, August 25, 1999 9:32 PM
> To: [email-masked]
> Subject: Re: Topology
>
>
> I see several issues here:
>
> 1. Legal Intercept in the Internet/IP networks
> 2. Topology in Megaco/H248
> 3. Context Parameters
>
> Issue 1:
> I agree with Brian that its a wide issue. Several bodies are
> already are
> looking at the issue. A BOF may be started (it may be
> duplicating work)
> but I think this goes across IETF Areas - Transport,
> Security, O&M? and
> getting an output by January I think would prove to be an impossible
> task. Legal Intercept is a requirement that we have from day
> 1 version 1
> and we will not be able to roll out networks without it. We
> can however
> take this requirement and implement what is necessary for
> Megaco/H.248.
> It may not be applicable to residential gateways but when we design a
> general purpose protocol we need to cover other MG type requirements.
>
> Issue 2:
> Topology is not just Legal Intercept, Tom also mentioned the case of
> Operator breakin and then there's general monitoring of
> terminations. We
> shouldn't get hung up on the LI case. Therefore there's several
> requirements to have it.
>
> Issue 3:
> Topology is just one of many possible Context parameters. We need to
> make an update to the H.248/Megaco syntax to allow placing
> parameters on
> a context. Like many other parameters they are optional, you
> don't have
> to support this in your gateway if you don't want to.
>
> Cheers, Christian
>
>
> Tom-PT Taylor wrote:
> >
> > This seems to make a lot of sense.  Scott: should we line up a legal
> > interception BOF for the next meeting?
> >
> > > -----Original Message-----
> > > From: Brian Rosen [SMTP:[email-masked]]
> > > Sent: Wednesday, August 25, 1999 6:06 PM
> > > To:   Taylor, Tom-PT [CAR:B901-I:EXCH];
> > > [email-masked]
> > > Subject:      RE: Topology
> > >
> > > I think supporting CALEA, and similar national
> > > wiretap laws in VoXXX networks requires a careful
> > > system design.  It affects MGs, MGCs, edge routers,
> > > and possibly other elements.
> > >
> > > If every group tried to meet the requirements independently,
> > > the resulting "system" is guaranteed to not meet all
> > > the requirements, and have wasteful duplication.
> > >
> > > I suggest:
> > >       Wiretap be deferred to Version 2
> > >       The IESG and the ITU get together a group
> > >               to do the system design.  This needs to
> > >               include:
> > >                       From IETF:
> > >                               MEGACO
> > >                               MMUSIC
> > >                               IPTEL
> > >                               ?Security?
> > >                               ???? Others
> > >                       From ITU
> > >                               SG16
> > >                               SG11
> > >                               ???? Others
> > >       When the system design is complete, the various groups
> > >               need to hammer out implementations
> > >
> > > Doing it piecemeal will fail.  We are wasting effort.
> > > Doing it right is practical.  It will succeed.
> > > The vendors (and operators) HAVE to implement it.
> > > It's in everyone's best interest to coordinate a
> > > sensible systematic design and implementation effort.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > > Sent: Wednesday, August 25, 1999 1:40 PM
> > > > To: [email-masked]
> > > > Subject: Re: Topology
> > > >
> > > >
> > > > I have sympathy with the argument that there should be a
> > > > general solution
> > > > for wiretapping, since its scope extends beyond telephony.
> > > > On the other
> > > > hand, we still have to handle operator break-in, which
> has a similar
> > > > selective requirement.
> > > >
> > > > We're in an odd position -- support for wiretapping is
> > > > certainly listed as
> > > > one of our requirements, while operator break-in is not.  In
> > > > the end the
> > > > IESG won't OK our work if we don't meet all of our requirements.
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Thomas [SMTP:[email-masked]]
> > > > > Sent: Wednesday, August 25, 1999 1:12 PM
> > > > > To:   [email-masked]
> > > > > Subject:      Re: Topology
> > > > >
> > > > > Alessandro Mordacci (ERA) writes:
> > > > >  >       No, you have different agencies in the very same
> > > > country. To be
> > > > > clear, I do not care of Sweden more than any other country :-)
> > > > >  >
> > > > >  >         I agree that we could do that in a lot of
> ways, the point
> > > > > is to agree on one. It seems to me that the topology
> is a very clear
> > > > > model of what is going on.
> > > > >
> > > > >   The general problem with this model is that if
> > > > > there are *any* untrustable MG's in your network
> > > > > which can talk to either another trusted or
> > > > > untrusted MG, you cannot use MG based snooping in
> > > > > the general case. Since I think that is the norm
> > > > > going forward in a whole lot of networks, it makes
> > > > > me wonder why one would want to go to great
> > > > > lengths to build a wiretap infrastructure which
> > > > > won't scale to present or future packet based
> > > > > voice networks. This is especially true when what
> > > > > is required to suppport it adds a fair bit of
> > > > > complexity to the MG and MGC.
> > > > >   Even for pure transit networks where everything
> > > > > is trusted the edge snooping technique works. It
> > > > > most likely could be a permutation of the same
> > > > > device as is going to be necessary for the
> > > > > untrusted MG situation.
> > > > >
> > > > >                 Mike
> > > >
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 26 Aug 1999 15:40:19 +1000

> to do all the intercept there.

[CHG] Today we do LI from a switch (MGC/MG) combination. This is a very
common solution amongst many vendors. As you need to intercept user
plane data (media) then it must be done in a MG. When you split an MGC
and MG you need to able to do intercept across this interface.

> "Do something, do anything, the sky is falling".

[CHG] I think having one group looking at a whole system is a bit
strange. What is a system anyway? Each vendor/operator will have
different solutions for implementing a system. Some companies involved
with MGC/MG have had legal intercept requirements for many years and
know what is involved. By its very nature LEAs don't like how they do LI
broadcast to everyone. Its not "the sky is falling" its "hey we have a
problem, we know how to fix it for many applications, let us do it".

> you think it might be looking at the problem through blinders.

[CHG] It comes down to having Topology descriptors in H.248 is an
enabler. Its a component of the whole LI issue. You have to make
considerations on your MC or MG and arrangements with the LEAs but as I
said previously LEAs don't like this publicised because they see that
its a security threat. LEAs requirements go down to the point where they
specify when you are developing this you have to keep documents locked
in a safe and you have to store code/documention a floppy disks and
store them in a safe.

> motivation, we should participate (we HAVE to participate), but we can't

[CHG] For particular applications certain systems and solutions apply.
If a MG LI doesn't suit those needs then people certainly need to
address it for their application. I doubt if one solution will work.

> case, regardless of whether it is done with pairwise specification

[CHG] I'm not sure I understand here. Do you then agree that we can make
a termID optional in a command?

> to implement them if it was claimed to be conformant to the spec.

[CHG] OK I made a mistake with terminology here. I meant to say that
this is a 'property' of a context. Properties are definately optional.
ie. not all MGs will be able to support GSM. To me a package was saying
that you support a set of properties.

Christian