[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    Re: [asterisk-dev] strictrtp seems to be not so strict
From:       "Olle E. Johansson" <oej () edvina ! net>
Date:       2016-08-26 12:33:43
Message-ID: 63BA9E30-CD3B-4E7A-9E6B-694937BD7FD3 () edvina ! net
[Download RAW message or body]


> On 26 Aug 2016, at 14:29, Joshua Colp <jcolp@digium.com> wrote:
> 
> Torrey Searle wrote:
> > I wouldn't dare change the default :-)
> > 
> > But the way I understand the code is that it would end up being a
> > switching, as getting a packet from the current source doesn't seem to
> > re-set the counter.
> > 
> > I'll do the following,
> > change the conf validation to allow probation = 0  (default will remain 4)
> > 
> > if learning_min_sequential is 0, the else in
> > 
> > if (rtp->strict_rtp_state == STRICT_RTP_CLOSED) {
> > if (!ast_sockaddr_cmp(&rtp->strict_rtp_address, &addr)) {
> > 
> > will be disabled
> 
> If an attacker were aggressive with the sending of the RTP and were able to get \
> enough packets in before a legit one, yes. As it is the reception of a legit packet \
> resets the counter each time (the call to rtp_learning_seq_init) so under normal \
> usage a rogue stream can't cause it to switch.

Also note that if there's ICE support this function needs to be disabled. We lock on \
the one sending us the right credentials in ICE

/O
-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


[prev in list] [next in list] [prev in thread] [next in thread]