[asterisk-dev] SIP, NAT, security concerns, oh my!

[Ryan Wagoner]

On Sat, Oct 22, 2011 at 11:02 AM, Tilghman Lesher <tilghman at meg.abyt.es> wrote:
> While that's true, the Asterisk project has always had interoperability
> as one of its main design goals.  It's one of the reasons why a lot of
> SIP implementors choose Asterisk as a test platform when writing their
> own SIP stacks.  That's what makes going down this road a little more
> difficult (because it has the potential to break older clients), but as
> Kevin said, we're required to break the RFC in order to preserve (or
> enhance) security.
>
> My concern is that there will be people who will disable any security
> option if it interferes with interop.  I'm torn between Options 2 and 3
> for this reason.  If we go with Option 2, there will be people who will
> not upgrade, because it cannot be disabled.  If we go with Option 3,
> there will be people who will disable it the first time they have a client
> with trouble connecting, and forget about it.
>
> Here's another option:  send responses to _both_ ports while the
> client is still unauthenticated.  This would have the effect of an
> attacker being unable to distinguish between a peer existing and not,
> while still allowing peers to be configured either with rport enabled or
> rport-oblivious.
>
> That still leaves peers without authentication to be a problem, but
> those are typically authenticated by other means, such as
> possession of a particular IP address, or restricted to a context
> without outward dialing capabilities.
>
> -Tilghman

I would go with option 3. Just make it clear in the configuration
files the potential consequence of disabling the option. This allows
everyone to decide what is best for their use case. This is no
different than the alwaysauthreject option. If you go with option 2
there will those users who revert the patch and continue on their way.

Your option of sending responses to both ports sounds interesting.
However what happens if the client receives both responses? How much
extra network traffic does this cause for a server with thousands of
peers. Just like option 3 if you make this optional it could be a good
choice for some use cases.

Ryan