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

From: Brian Rosen <[email-masked]>
Date: Thu, 19 Aug 1999 18:24:14 -0400

What I worry about is race conditions.

Suppose the "prep" took longer to arrive than the stream.
What do you do?

Suppose that the capability exchange was delayed, so the prep
never went out, but the other end got it's instructions and
started RTP?

These are not really "errors", but what does the poor MG do?
Wouldn't the MGC at least want to know about them?

Denial of service by flooding requests is a problem.  No manner
of mechanism can totally stop it.  The best defense is to
enable authentication.  No authentication, no flow.

The easiest way to take down an MGC is to send it ServiceChange requests
from non-recognized fake MGs (better yet, sniff a real one and impersonate
it).  The easiest way to take down an MG is to send it bogus RTP, no doubt,
but a bogus handoff ServiceChange would be pretty good also.

The event is clearly optional, so if you get worried, don't use it.

> -----Original Message-----
> From: Michael A. Ramalho, Ph.D. [mailto:[email-masked]]
> Sent: Thursday, August 19, 1999 8:48 PM
> To: Brian Rosen; [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
>

---

From: David Mazik <[email-masked]>
Date: Thu, 19 Aug 1999 18:22:57 -0400

> Wouldn't the MGC at least want to know about them?

There should be some sort of RTP packets/sec, absoulte packet, or
absoulte time threshold that is exceeded prior to notifiying the MGC.
This will be a normal occurrence during call setup and teardown.

No matter what you do,  one MG will always start/stop RTP
before the other MG.  These windows are wide relative to the
small RTP packet times.  And as you imply,  they will grow
in loaded environments.

> > Personal email: [email-masked]

=========================================================
Dave Mazik                            Lucent Technologies
Sr. Software Engineer             Access Engineering-VOIP
mailto:[email-masked]            http://www.lucent.com

---

From: Christian Huitema <[email-masked]>
Date: Thu, 19 Aug 1999 18:47:55 -0400

>Suppose the "prep" took longer to arrive than the stream.

Well, you can only receive legitimate RTP packets after you have publicized
the RTP port
on which you are ready to receive, so there is normally no race condition
there. There is however
a period during which the port is open for reception, but you have no idea
of the valid sending
address.  You have two options there, to ignore the packets and risk
clipping an announcement,
or to accept the packets and risk opening a window for hackers.

But everybody should realize that checking the source address of IP packets
is a lousy protection.
If you are serious, then you want to use some form of
authentication/encryption.  This suppresses
both the race condition and the security risk:

a) during the add, the MG learns, or generate, an encryption key for the
RTP termination.
b) from that point on, it only accept properly keyed packets, and drops all
other packets.

You won't risk clipping the announcements, because your peer will have
learned the key before sending any packet, and you also won't risk hacker
attacks, because they won't know the key (well, in theory at least...)

As Michael points out, you really don't want to create signalling traffic
as a consequence of rogue UDP packets.

Christian Huitema

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Aug 1999 18:49:49 -0700

> never went out, but the other end got it's instructions and

   Flip answer: fix the call flows.

 > of mechanism can totally stop it.

   Heavens no! It's a huge and trivial denial of
service attack waiting to happen. While DoS are
difficult to impossible to prevent, you don't have
to make it completely trivial. This entire thing
strikes me that if you wanted to do _anything_
that you might record it in some MIB variable.

 > The best defense is to

   But isn't that the mandate that some sort of
security (AH minimum) is required? Doesn't that
basically answer your question?

                Mike