Re: Traffic Monitoring

[Deke Kassabian <>]

I think Tyler makes good points about the prospects of encryption 
reducing visibility.

It seems to me that a key question is what, exactly, will be 
encrypted.  If app and session signaling and transport layer info are 
available even as the media data itself is made opaque to prying eyes, 
then today's best practices (as described by Candace) still work.  If 
it's all encrypted, then yes, we will need new approaches.

If I were trying to tackle the simple monitoring/reporting problem you 
describe, Barry, I think my preference would be to proceed as Candace 
describes -- look at readily available information such as application 
port information in the transport layer headers.  Netflow data can 
help here in a reasonably scalable way.  There are commercial packages 
that do this nicely, and I'm sure a range of freely available tools 
that do so, too.

I'm with Tyler, of course, that it's worthwhile to look at the bigger 
picture and longer range.  We want to be able to identify realtime 
traffic (and for that matter, other kinds of traffic that might have 
special needs) and to apply policies as appropriate. Lots of good work 
has already been done in this area, and lots more is needed.

Good luck!
^Deke

--On Thursday, June 23, 2005 8:58 PM -0400 Tyler Johnson 
<> wrote:

> Barry,
>
> We are looking at the general issue of identifying voice/video
> traffic on the network, not only for measurement, but for policy,
> QoS and other issues. There seem to be a growing number of network
> systems out there that examine the packet payload or header
> information to make policy decisions. I personally think that
> encrypted media and signaling will be the norm. Therefore, policy
> systems that rely on packet inspection will fail. So, I think
> anything that performs stateful inspection should be viewed as a
> short term solution.
>
> What's a better solution? Good question, and one we don't have an
> answer to, though I think it has a lot to do with authentication and
> authorization at the application and network layers.
>
> Candace Holman wrote:
>
> > You should be able to use protocol (tcp vs udp) and port numbers to
> > differentiate traffic.
> >
> > If you're using SIP over UDP it should be easy.  For voice, use
> > port  5060 and all your RTP ports on UDP.
> >
> > Candace
> >
> > At 05:40 PM 6/23/2005, Barry Wray wrote:
> >
> > > I have a question that must be prefaced with the fact that I am
> > > not a programmer.   However, I am looking for some guidance on
> > > what it would take to monitor IP voice/video traffic on interface
> > > (T-1, DS3, etc.).
> > >
> > > Today we have "built" our own monitoring system that monitors
> > > traffic on edge routers, using SNMP and MRTG, but it is shown only
> > > as "data."  The result of this snapshot is a graph showing the
> > > latest data with peaks over the past say 24 hours or whatever time
> > > frame the user would choose.
> > >
> > > I would like to see the same type of graph with data traffic in one
> > > color, voice in a different color and so on.  What it comes down
> > > to is, what should I use to differentiate traffic?
> > >
> > > Thank you.
> > >
> > > Barry A. Wray
> > > State Networks Voice Engineer
> > > Indiana Higher Education Telecommunications Systems
> > > Indianapolis, Indiana
> > > 317.263.8934
> > >
> > > http://www.ihets.org

-------
Deke Kassabian,  Senior Technology Director
Information Systems and Computing, University of Pennsylvania

Attachment: pgpqlG0_wpKt1.pgp
Description: PGP signature