[sr-dev] source port for TCP & TLS connections

[Federico Cabiddu]

Hi,
I've been playing with SO_REUSEPORT (included in kernel since 3.9) and
Kamailio quite successfully.
I have a branch for this in my personal fork (
https://github.com/grumvalski/kamailio/tree/tcp_reuseport) that I've been
planning to submit as a PR since a while.
If you agree I can do it to start the discussion.

Regards,

Federico


On Wed, Dec 7, 2016 at 9:36 AM, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Hello,
>
> I will try to follow up with more on this discussion after I get the
> time to check the resources at the links you mentioned. I know that
> forcing a source port for a tcp connection was not reliable, but things
> may have changed with newer versions of kernels.
>
> Cheers,
> Daniel
>
>
> On 05/12/2016 14:01, Daniel Pocock wrote:
> >
> > RFC 3261 doesn't appear to require anything more than the default random
> > selection of source port for transports like TCP and TLS
> >
> > Section 18[1] even appears to anticipate that two proxies communicating
> > over reliable transports may have two different connections open at the
> > same time, one for requests initiated in each direction.
> >
> > However, I've seen a couple of situations where using the listening port
> > as the source port would be beneficial:
> >
> > - peer has buggy implementation that tries to connect back to source
> > port / rport (which should only happen for unreliable transports),
> > observed in reSIProcate[2]
> >
> > - firewall policy is particularly strict and prefers or even expects
> > specific source ports to be used
> >
> > - potentially halves the number of sockets / FDs required (better use of
> > system resources)
> >
> >
> > It is not hard to configure a TCP (or TLS) client socket to use a
> > specific[3] source port, although as that example[3] demonstrates, there
> > could be situations where a socket is not fully closed and a new one
> > can't be opened immediately for the same source/dest port combination.
> > That type of issue doesn't arise for randomly selected source ports.
> >
> >
> > Has anybody else tried setting a fixed source port for TCP/TLS
> > connections and can you share any observations about this for better or
> > worse?
> >
> > Has anybody seen similar behaviour to the bug[2] in other SIP
> > implementations?
> >
> > We are thinking about implementing this as an optional feature in
> > reSIProcate, partly to help people mitigate the impact of peers who have
> > the bug #137.
> >
> > Regards,
> >
> > Daniel
> >
> >
> > 1. https://tools.ietf.org/html/rfc3261#section-18
> >
> > 2. https://www.resiprocate.org/bugzilla/show_bug.cgi?id=137
> >
> > 3.
> > http://stackoverflow.com/questions/2605182/when-
> binding-a-client-tcp-socket-to-a-specific-local-port-with-winsock-so-reuse
> >
> >
> >
> > _______________________________________________
> > sr-dev mailing list
> > sr-dev at lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20161207/1c1c45f5/attachment.html>