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

From: [email-masked]
Date: Fri, 20 Aug 1999 08:01:39 -0600

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

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 20 Aug 1999 10:25:29 -0400

It looks like the two of you are in basic agreement, and have a sensible
solution.

> From: [email-masked] [SMTP:[email-masked]]
> Sent: Friday, August 20, 1999 10:02 AM
> To:   [email-masked]
> anticipa te

---

From: [email-masked]
Date: Fri, 20 Aug 1999 20:55:30 +0300

> 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?

Yes - it's certainly possible to think of firewalls as
policy-based routers that route certain types of traffic
off to the sweet hereafter.  The stuff under discussion is
certainly among the reasons that some sort of firewall
control interface with a notch more functionality than SOCKS
is needed.

It's probably worth pointing out, as well, that it's not
RTP traffic per se that's the issue - it's all unwanted incoming
traffic.

Melinda
--
Melinda Shore
Member of the Scientific Staff
Nokia IP Telephony
127 West State Street
Ithaca, NY  14850
+1 607 273 0724 (office)
+1 607 275 3610 (fax)
+1 607 227 4096 (mobile)
[email-masked]

---

From: Roy Spitzer <[email-masked]>
Date: Fri, 20 Aug 1999 15:00:24 -0400

It looks like there is confusion between operation & maintenance and
signaling.

From a signaling/voice traffic standpoint, RPT packets using unallocated
ports or SSRC should be thrown away without any indication given to any
other signaling entity.  Any indication might compromise network security
and lead to unauthorized calls.

From an operation & maintenance standpoint, there is a problem.  At a
minimum such instances need to be counted.  It might be desirable if an SNMP
trap was sent to the OSS so the problem could be investigate as it is
occurring.  The OSS in any event must determine whether the unassigned RTP
packets are due to race conditions or security problems.  If it is due to
race conditions, the network topology needs to be researched to provide
reasons why the MEGACO protocol may not be properly taking traffic
conditions into account.  Otherwise, potential security attacks need to be
prevented in the future.

Regards,
Roy

Roy Spitzer                             Telogy Networks, Inc.
Phone:  (301) 515-6531                  20250 Century Blvd.
Fax:    (301) 515-7954                  Germantown, MD 20874
Email:  [email-masked]

                -----Original Message-----
                From:   [email-masked]
[mailto:[email-masked]]
                Sent:   Friday, August 20, 1999 1:56 PM
                To:     [email-masked]
                Subject:        Re: How do you deal with incoming RTP
sessions you don't anticipa te

                It's probably worth pointing out, as well, that it's not
                RTP traffic per se that's the issue - it's all unwanted
incoming
                traffic.

                Melinda

---

From: [email-masked]
Date: Fri, 20 Aug 1999 22:44:27 +0300

> From: EXT Roy Spitzer [mailto:[email-masked]]
> Sent: Friday, August 20, 1999 3:00 PM

> and lead to unauthorized calls.

I guess I'm not sure I understand why this is an issue.
The gateway *application* is only going to pick up incoming
packets on ports to which it's listening.  Traffic destined
to ports on which nobody is listening get chucked once the IP
stack realizes that nobody wants it.  At the IP layer, however,
there's the potential to commit a denial-of-service attack by
blasting gobs of packets at the gateway, forcing it to do
unnecessary processing.  To the extent that this is a megaco
issue at all, the lesson should be something like "don't listen
at random ports."

Melinda