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

[Tilghman Lesher]

On Sat, Oct 22, 2011 at 9:31 AM, Yaroslav Panych <panych.y at gmail.com> wrote:
> For me as for potential implementer of SIP UAC, option #3 is more
> preferred. But in variant when force_rport is disabled by default.
> Personally I dislike very much rport option. As said, it was
> introduced because of no NAT-aware clients will be unreachable for
> responses. And I asked myself "who's its fault? server or client?" My
> answer was "client". Why program/developer which uses connection less
> transport protocol(UDP) does not care about reverse route? Because
> developer was so lazy that he decide not to implement NAT traverse
> technologies.
> Then, when appeared rport option, this lazy developers have real
> reason to be lazy in future(reason to do something if it already works
> somehow?)
> If force_rport will be defaulted or hardcoded, this means admirations
> of UACs developers laziness. Its UAC's problem to be reachable from
> server, UAC should care to redirect answers to right port on all
> potential NATs. I personally will never use SIP-client which is unable
> to do that.

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