Subject: Re: Topology

From: Brian Rosen <[email-masked]>
Date: Wed, 25 Aug 1999 06:49:05 -0400

FWIW, the way you audit a feature is either:
1. Declare a property of root that is a boolean which indicates the
capability.  AuditValue of root gives it to you.
2. Declare the feature in some package, which can be audited per my
prior suggestion (either just auditCapabilities a termination and look at
the package names or adopt a new descriptor that returns the package
names implemented on the termination).

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, August 24, 1999 9:32 PM
> To: [email-masked]
> Subject: Re: Topology
>
>
> Rex Coldren writes:
>  > If you are correct, are you then suggesting "mandatory" should be
> "optional"?
>
>    At the very least. You'd probably need YAAV
> (yet another audit value) to determine whether the
> MG supports the feature.
>
>    BTW, at some point we need to round up all of
> the "optional" features and make certain that the
> MGC, probably through auditing, can find out which
> features are supported.
>
>                 Mike
>
>
>  > Michael Thomas wrote:
>  >
>  > > Christian Groves writes:
>  > >  > > 1) The "residential gateway" variety of MG is often
> installed within the
>  > >  > > customer premises. This means that the wiretap
> targets have ample
>  > >  > > opportunities to tamper the box and defeat any
> wiretap command. Even if
>  > >  > > they don't actually tamper the box, they can easily
> monitor the box's
>  > >  > > behavior and detect that a wiretap has been
> installed, wich defeats the
>  > >  > > purpose of wiretapping.
>  > >  >
>  > >  > [CHG]
>  > >  > Can you give details of how Wiretaps would be
> achieved in this case if
>  > >  > two residential gateways communicate? I can see any
> other way of doing
>  > >  > this because the media stream goes directly (via an
> IP router network)
>  > >  > between 2 residential gateways?
>  > >
>  > >    Assuming that there exists a sniffer-like
>  > > device with sufficient information to detect the
>  > > flow (something to bear in mind here is that it's
>  > > not just the bearer that needs to be snooped, but
>  > > the signaling too) as well as the proper
>  > > decryption keys, the sniffer could then record the
>  > > traffic as well as potentially play it out, real
>  > > time. This could be integrated into the
>  > > functionality of edge routers, aggregating
>  > > routers, or duplicated and forwared to a
>  > > standalone device, etc. This could be either under
>  > > the administrative control of the MGC, or some
>  > > other interface to the sniffer.
>  > >    This solution solves the problems with lawful
>  > > intercept without involving the actual MG's.
>  > > Network architectures which have *any* untrusted
>  > > MG's will need to use this, or some functional
>  > > equivalent of this scheme.
>  > >    The solution you're proposing with the topology
>  > > descriptor only works in a limited set of
>  > > situations, so the larger question is whether the
>  > > the added complexity to the protocol is worth
>  > > adding if that's the main benefit. A large class
>  > > of devices would, most assuredly, never use the
>  > > nominal reason the feature was added, and as
>  > > Christian points out, if it is manditory to
>  > > implement, adds a significant amount of complexity
>  > > to the MG.
>  > >
>  > >                 Mike
>  >
>  >
>