[sr-dev] why new tcp connection?

Andrei Pelinescu-Onciul andrei at iptel.org
Fri Nov 6 17:09:59 CET 2009

On Nov 06, 2009 at 14:39, I?aki Baz Castillo <ibc at aliax.net> wrote:
> El Viernes, 6 de Noviembre de 2009, Klaus Darilion escribi?:
> > Hi Juha!
> > 
> > Personally I do not like the alias approach. IIRC correctly there were
> > some security issues with aliases (at least some time ago) and ser does
> > hand aliases a little bit different then described by IETF to avoid this
> > issues.
> Could I know about those security issues? (just a brief description).

IIRC the original alias draft required to alias also the IP, so for
example a message from ip: with src_port 1234 and having in via would set an alias on the proxy:> which is evidently a security problem (I can
 use it to redirect someone else's  traffic to me).
In ser/sr/kamailio the alias will work only for the port, so in the
above example the alias will be:> and IIRC a message might be logged.

Even using only the port for the alias there can still be problems if
there are several UACs behind the same NAT that listen on the same port
(e.g. 5060). All of them would add 5060 in the via and on the proxy
there would be attempts to set multiple aliases for nat_ip:5060.
In this case one UAC will also get the requests intended for the others.
This can also be used on purpose, to intercept the messages of the
other users behind the same NAT or on the same machine.
> > To solve the situation there are 2 other solutions:
> >   1. in client
> >   2. in server
> > 
> > 1. client:
> > The client learns the public socket during REGISTER (Via received+rport
> > in response) and changes its contact in REGISTER

Even better would for the client to use STUN over tcp first to find the
port and NAT address and then send the REGISTER with the proper ports
(on the same connections). Then it could use STUN for keepalives
(in this case sr must be configured with STUN support, e.g.
 make config STUN=1)



More information about the sr-dev mailing list