Subject: Re: How do you deal with incoming RTP sessions you don't anticipate

From: "Michael A. Ramalho, Ph.D." <[email-masked]>
Date: Fri, 20 Aug 1999 13:16:19 -0700

Ike,

(Good to hear from you)

I think that from other comments on the thread ... that much
of what you propose below is agreed to (i.e., the security issue
and dropping packets from flows that have yet to be set-up).

The idea of sending a message when a gateway is becoming
"bogged down" by too many rouge packets (as Christian
calls them) is an interesting one. But again ... who do you
send this message to? A policy/provisioning system that
requests a router upstream from the MG to filter out the
rogue packets? And if you were this router, how would
you tell the rogue packets from the non-rogue ones
(assuming that the router doesn't know the security
association)?

Like I said before ... this issue (and most other malicious user
issues) requires a little more thought .... but I think the issue of
a MG should do with flows that have yet to be fully set-up is
becoming clearer.

Michael

At 08:01 AM 8/20/99 -0600, [email-masked] wrote:
>Mike,
>This may be an implementation detail, rather than a protocol
>issue, but how about requiring the MG to drop RTP packets for
>flows that haven't been prepped?  And then requiring the MG
>to alarm only if it is processing so much unsolicited RTP traffic
>that it is approaching a state where it can't perform its function?
>
>There is also a related issue of a hacker spoofing the source IP
>address of a prepped flow, and sending RTP packets to an MG.
>In this case, I think the MG should drop out of sequence packets,
>which should guard against audio insertion pretty well.
>
>If you want better protection, then we will need to go to a security
>key approach, where the key is in every RTP packet.
>
>Ike
>
>> -----Original Message-----
>> From:        Michael A. Ramalho, Ph.D. [SMTP:[email-masked]]
>> Sent:        Thursday, August 19, 1999 6:48 PM
>> To:  [email-masked]
>> Subject:     Re: How do you deal with incoming RTP sessions you don't
>> anticipate
>>
>> Re: "What happens when a flow arrives without the prep?
>> .... At the very least, you want an event. "
>>
>> For the case of native IP ... why?
>>
>> Shouldn't you naturally just ignore it?
>>
>> I think quite a bit about the impact of malicious users
>> of a network. It appears to me that the whole issue
>> of directing streams to points in a IP network where they
>> were not requested is an open invitation to network abuse
>> by malicious users.
>>
>> Think of a process that would send RTP packets to all known
>> ports/addresses of a given gateway (or set of gateways). These
>> malicious streams would kick off events to be processed in
>> an attempt to determine the source (and presumably request it
>> to shut up). This could potentially kick off a signaling (or processing)
>> overload in the network (causing it to fail or fail to meet
>> other network obligations).
>>
>> I think this issue may require a bit more thought.
>>
>> I might agree to sending an event in the case of a
>> persistent stream to a given port (one that exists
>> for much longer than any reasonable call set-up
>> delay). But ... what exactly to do after that? For
>> an IP over ATM network .. the ATM VC might
>> give a clue to the (potentially errant) source.
>>
>> Any other comments?
>>
>> Michael
>>
>> At 03:06 PM 8/19/99 -0400, Brian Rosen wrote:
>> >In general, the side of a call that is expecting it's
>> >counterpart to establish an RTP flow is prepped for that flow
>> >by performing an Add of an RTP Termination with appropriate
>> >parameter settings.  There could be an event when the flow
>> >arrives.  Matching is done on the basis of port assignments.
>> >
>> >What happens when a flow arrives without the prep?
>> >
>> >At the very least, you want an event.  How would you establish
>> >such an event, and against what termination would it be
>> >reported?
>> >
>> >I used to know the answer to this; there was a termination
>> >"base" and you could have events on it.  For example, there
>> >was RTP/.  When you did the Add, you did it to RTP/?, meaning,
>> >I want an RTP connection, choose a the last part of a
>> >terminationID.  In theory, RTP could have properties that were
>> >different from RTP/???.  All of that is gone now.
>> >
>> >At the moment, the best I can come up with is that it is an
>> >event on the root termination.  We might even go so far as to
>> >define an RTP package for root that had the event, and any
>> >parameters we needed.
>> >
>> >Brian
>>
>> Michael A. Ramalho, Ph.D.
>> Cisco Systems
>> Wall Township, NJ
>> Office email: [email-masked]
>> Personal email: [email-masked]
>> Office: +1.732.449.5762
>> Cell: +1.732.245.3957

Michael A. Ramalho, Ph.D.
Cisco Systems
Wall Township, NJ
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.245.3957