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

Artem Makhutov artem at makhutov.org
Sun Oct 23 05:06:27 CDT 2011


Hi,

Tilghman Lesher schrieb:
> On Sat, Oct 22, 2011 at 10:50 AM, Ryan Wagoner<rswagoner at gmail.com>  wrote:
>> On Sat, Oct 22, 2011 at 11:02 AM, Tilghman Lesher<tilghman at meg.abyt.es>  wrote:
>>> 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.
>>
>> 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.
>
> It shouldn't actually be a problem; the second packet would be ignored,
> because in UDP-based SIP, there's always a possibility that a packet is
> lost (never received), so re-transmits are built into the protocol.  Thus, a
> SIP UA should always be prepared to receive an identical (in terms of
> payload) packet.

I don't like this idea. What if a phone is behind a nat router which is running a sip server?
So in this case the sip server of the nat router will get one packet and also the phone behind the nat router will also receive one.

Option 3 sounds fine for me.

Regards, Artem

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4364 bytes
Desc: Kryptographische S/MIME-Signatur
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111023/96b54d19/attachment.bin>


More information about the asterisk-dev mailing list