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-...
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
http://stackoverflow.com/questions/2605182/when-binding-a-client-tcp-socket-...
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@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
binding-a-client-tcp-socket-to-a-specific-local-port-with-winsock-so-reuse
sr-dev mailing list sr-dev@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel Pocock -
Daniel-Constantin Mierla -
Federico Cabiddu