Re: Request for review of DNS related draft

[Dean Anderson <dean@av8.com>]

None of these need to know the first hop router on _another_ network.

Tapping a network for law enforcement is a simple as placing a sniffer at
some convenient point where that customers packets can be grabbed. The
packets are then turned over to law enforcement. It has nothing to do with
"trust" of the sniffer.  Law enforcement is responsible for decoding VOIP
traffic, or paying someone to do it, given packets.  A tap on a customer
network also does not need to involve the first hop router. And a law
enforcement tap should probably NOT involve the first hop router, since it
might be detectable by the customer being tapped!

Your second example, (and I have worked on large VOIP networks using cisco
and other equipment), is just plain wrong.  Voice quality functions for
VOIP are built into the Voice gateway.  You don't have to "listen in".
Telco people can't listen in either, unless they want to lose their job.
In wireline switches, there may be capabilities to listen in, and to
provide audio monitoring ports for law enforcement. (Law enforcement is
usually not allowed in the CO, but get a special line for recording
wiretaps).

And last, the analogous actions in a VOIP network (as I said previously)
do NOT involve the first hop gateway, which typically isn't VOIP _AWARE_

I think you need to learn more about Voice networks before proposing
RFC's to solve problems. The problems you are quoting don't exist.

If you work for Cisco, please consult your VOIP group.

		--Dean

On Sat, 1 Mar 2003, Edward Warnicke wrote:

> I'll provide two examples.
>
> 1)	In most nations there is a regulatory requirement to
> 	that a service providers provide a wiretap of a
> 	customer when presented with a warrant.  When performing
> 	such a tap customer premise equipment is not considered
> 	trusted, even if it is controlled by the SP.  Therefore
> 	the device in the network responsible for carrying
> 	out the wiretap must get cooperation from the
> 	first hop router in the SP's network.  See
> 	http://www.packetcable.com/downloads/specs/pkt-sp-esp-I01-991229.pdf
> 	for example.
>
> 2)	In the traditional PSTN networks ( according to my telco
> 	guys, I'm *not* a telco guy myself ) there are a group
> 	of maintenance functions which involve monitoring the
> 	actual voice streams of a call for small periods of
> 	time to check voice quality ( I'm told in the US this
> 	is legally permissible for between 20-30 seconds of
> 	a call ).  Analogous maintenance actions for a VoIP
> 	( say MGCP driven Cable VoIP ) SP would require
> 	cooperation of the first hop gateway in the service
> 	providers network.
>
> Ed
>
> On Fri, 28 Feb 2003, Dean Anderson wrote:
>
> > This seems the wrong way to go about MGCP management activity. What makes
> > you think the first hop router will have anything to do with VOIP or MGCP?
> >
> > In the VOIP networks that I've worked with (a number of large voip
> > installations since 1998), the first hop routers were never VOIP-aware at
> > all.
> >
> > 		--Dean
> >
> > On Fri, 28 Feb 2003, Edward Warnicke wrote:
> >
> > > Not everyone is privy to the routing tables.
> > >
> > > For example.  Imagine an MGCP call agent which wishes to
> > > perform a maintenance activity that requires the cooperation
> > > of the first hop gateway for an MGCP gateway.  I'm aware
> > > of no MGCP call agent which participates in the IGP for
> > > the networks containing those endpoints.  Additionally
> > > almost all IGPs will allow for some route summarization
> > > which would prevent me from actually knowing who the
> > > first hop gateway is in some circumstances.
> > >
> > > So in this example I would either have to provision the MGCP
> > > call agent with information about where the first hop gateway
> > > for each endpoint was, or allow it to use the method of the
> > > draft to resolve it.
> > >
> > > Since many of the environments where MGCP is seeing deployment
> > > have a very large number of endpoints, and an unusually large
> > > churn of first hop gateway changes ( think splitting a cable
> > > node ), as well as a tendency toward hierarchical distibution
> > > of control of the network, DNS resolution of this information
> > > seemed to make sense.
> > >
> > > The reason RFC 1101 doesn't get used for these sorts of
> > > purposes is that it doesn't support features in common use
> > > in these networks ( variable length subnet masks ).
> > >
> > > Ed
> > >
> > > On Fri, 28 Feb 2003, Robert Elz wrote:
> > >
> > > >     Date:        Thu, 27 Feb 2003 16:01:03 -0500
> > > >     From:        Ed Warnicke <eaw@cisco.com>
> > > >     Message-ID:  <3E5E7C8F.2000404@cisco.com>
> > > >
> > > >   | But DHCP will not allow a device which
> > > >   | is not the endpoint ( or the DHCP server ) to discover the network which
> > > >   | contains
> > > >   | an IP address and the first hop gateway(s) which service that network.
> > > >
> > > > Rather than how, perhaps the question should be why would anyone care?
> > > >
> > > > That's largely why 1101 never got used - the nodes for which it might
> > > > have provided information that could didn't already know it via other
> > > > means, never had much of a reason to care.
> > > >
> > > > Why would my nodes care what the network that contains some random IP
> > > > address might happen to be (or why would I ever care more than the
> > > > routing tables will tell me) ?
> > > >
> > > > kre
> > > >
> > > >
> > >
> > >
> > >
> > > #----------------------------------------------------------------------
> > > # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> > >
> >
> > #----------------------------------------------------------------------
> > # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> >
>
>

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.