[VOIPSEC] RTP packet signature

Dan Wing dwing at cisco.com
Thu Oct 6 11:02:36 CDT 2005 

Except for VAD (voice activity detection), RFC2833 messages (such as DTMF),
T.38-over-RTP, and text over RTP.  All of which are valid, legitimate uses
of RTP.  It all depends on behavior for false positives and false negatives
-- do you get worse QoS, drop the packet entirely, corrupt it, raise an
intrustion detection alarm, etc.

-d

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Pankaj Shroff
> Sent: Wednesday, October 05, 2005 12:30 PM
> To: mailinglist
> Cc: Voipsec at voipsa.org; Haluska, John J
> Subject: Re: [VOIPSEC] RTP packet signature
> 
> I beleive one way to manually "sniff" for RTP VOICE packets 
> would be to
> watch UDP packets on the interface (using tcpdump or ngrep or 
> something
> similar), and typically for a given codec, given interval, 
> the packet sizes
> will be constant. So if you see several hundreds of packets 
> between the same
> source/destination ip:port pairs that have the exact same 
> size (172 bytes
> for G.711 20ms). Once you have identified ip:port pairs with 
> this consistent
> stream of packets, you should be able to use any of the 
> methods described
> before to "confirm" that these are indeed RTP voice packets. 
> You can then
> capture them and play the voice or audio out using any number 
> of open source
> utilities available (including Ethereal). Note: I am sure 
> this is applicable
> to voice RTP but I am not sure it is true for other forms of media
> transported using RTP.
>  Pankaj
> 
>  On 10/5/05, mailinglist <mailinglist at pbxnsip.com> wrote:
> >
> > Oopps, true. Anyway, the hash would be an additional method.-)
> >
> > Take a look at Ethereal. I checks the signalling and then uses the
> > signalling as hint that a packet is a RTP packet. Seems like without
> > looking
> > at the signalling it is not possible to detect that a 
> packet is a RTP
> > packet.
> >
> > > -----Original Message-----
> > > From: Haluska, John J [mailto:jhaluska at telcordia.com]
> > > Sent: Wednesday, October 05, 2005 7:52 PM
> > > To: mailinglist at pbxnsip.com
> > > Cc: Voipsec at voipsa.org
> > > Subject: RE: [VOIPSEC] RTP packet signature
> > >
> > > I had the impression that the original question was regarding
> > > a third party, not the intended recipient (who would have had
> > > access to the signaling protocol). Third party would also not
> > > be able to decode the packet if it's SRTP.
> > >
> > >
> > > -----Original Message-----
> > > From: mailinglist at pbxnsip.com [mailto:mailinglist at pbxnsip.com]
> > > Sent: Wednesday, October 05, 2005 12:11 PM
> > > To: Haluska, John J
> > > Cc: Voipsec at voipsa.org
> > > Subject: RE: [VOIPSEC] RTP packet signature
> > >
> > > The SRTP packets may have a hash at the end of the packet (4
> > > or 10 bytes).
> > > If the receiver is able to decoce the packet it will also be
> > > able to check the hash. If it does not match you can discard
> > > the packet.
> > >
> > > > -----Original Message-----
> > > > From: Voipsec-bounces at voipsa.org
> > > > [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Haluska, John J
> > > > Sent: Wednesday, October 05, 2005 3:46 PM
> > > > To: Voipsec at voipsa.org
> > > > Subject: Re: [VOIPSEC] RTP packet signature
> > > >
> > > > Of course almost anything is possible. In general, it
> > > would be very
> > > > difficult to determine without any context whether a 
> single packet
> > > > contains RTP.
> > > >
> > > >
> > > >
> > > > The only field you can really count on is the RTP version field,
> > > > pretty much anything else can change. And this is a very small
> > > > field, the chances of any random packet matching that 
> value at that
> > > > offset in the UDP header is pretty good anyway,
> > > >
> > > >
> > > >
> > > > The ports used for RTP are negotiated dynamically, so it's not
> > > > possible (without context) to know even which port number
> > > to look for.
> > > >
> > > >
> > > >
> > > > With context, it is possible, but not simple. So a single
> > > packet would
> > > > tell nothing. But if you look for a stream, with packets sent at
> > > > periodic intervals (usually 10 or 20 msec for pcm type 
> codecs), and
> > > > see appropriately incrementing values in the offsets 
> where the RTP
> > > > timestamps and sequence numbers belong, and a constant
> > > value where
> > > > the SSRC belongs, and yu have some reason to think there
> > > could be an
> > > > RTP stream here, then you've got a start.
> > > >
> > > >
> > > >
> > > > There are other clues too, like the presence of sparse
> > > traffic at udp
> > > > port number + 1, which would be RTCP, you could analyze
> > > these packets
> > > > (if they exist) and correlate the information here with
> > > that in the
> > > > suspected RTP stream.
> > > >
> > > >
> > > >
> > > > In my experience I have seen that certain endpoint always
> > > use the same
> > > > UDP port numbers for RTP streams, if you have the context
> > > of knowing
> > > > the endpoints then you might also be able to use this 
> information.
> > > > Also, if the particular endpoints always use the same 
> SSRC (it is
> > > > supposed to be randomly chosen but this may not always be
> > > done) then
> > > > you can look at this too. But again this requires that 
> you know in
> > > > advance what you are looking at, so in general this 
> cannot be used.
> > > >
> > > >
> > > >
> > > > But this is only to determine that you do in fact have RTP,
> > > not sure
> > > > what you intend to do with it. If they are using dynamic
> > > payload types
> > > > as recommended by the RFCs, then you cannot in general know
> > > the codec
> > > > from the payload type, you need to guess or play trial and
> > > error with
> > > > different codecs.
> > > >
> > > >
> > > >
> > > > So, for a single packet, there is really no signature you
> > > can reliably
> > > > count on. With enough context and processing, you can do
> > > it. All this
> > > > of course applies just to RFC 3550 RTP sent in the clear.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > John Haluska
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Message: 3
> > > >
> > > > Date: Tue, 4 Oct 2005 16:53:32 +0200
> > > >
> > > > From: Marc.JACOBS at etca.alcatel.be
> > > >
> > > > Subject: [VOIPSEC] RTP packet signature
> > > >
> > > > To: Voipsec at voipsa.org
> > > >
> > > > Message-ID:
> > > >
> > > >
> > > > <OF377A4B83.D2232863-ONC1257090.0050CD02-C1257090.0051CE77 at etc
> > > > a.alcatel.
> > > > be>
> > > >
> > > >
> > > >
> > > > Content-Type: text/plain; charset="us-ascii"
> > > >
> > > >
> > > >
> > > > Dear all,
> > > >
> > > > Is there a means to know either an UDP/TCP packet
> > > > encapsulates a RTP/RTCP
> > > >
> > > > packet or not without using the signaling protocols (SIP,
> > > H323, ...) ?
> > > > In
> > > >
> > > > other words, how can I identify a RTP packet on-the-fly
> > > > without having
> > > >
> > > > access to the signaling protocol ?
> > > >
> > > > Thanks,
> > > >
> > > > Marc
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Voipsec mailing list
> > > > Voipsec at voipsa.org
> > > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> 
> 
> 
> --
> Pankaj Shroff
> shroffG at Gmail.com
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

More information about the Voipsec mailing list