> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Viktor Dukhovni
> Sent: Friday, February 08, 2019 13:00
>
> > On Feb 8, 2019, at 12:55 PM, Michael Wojcik <michael.woj...@microfocus.com>
> wrote:
> >
> > For IPv4: Create your socket, bind it to the local interface you want to
> use (specifying a port of 0 if you want an ephemeral port assigned as in the
> usual case), then connect to the peer. You'll probably want to enable
> SO_REUSEADDR on the socket before calling bind.
>
> For the record, one should *not* use SO_REUSEADDR for client sockets used in
> outbound connections.

Not usually, but in the specific case of testing connections bound to specific 
local addresses - an artificial use case - it will either avoid having to wait 
for the 2MSL timer to expire (if you bind to a specific local port) or 
exhausing the ephemeral port space (if you use a stack-assigned ephemeral port) 
if you're making a lot of short-lived connections.

Obviously bypassing TIME_WAIT this way introduces precisely the problem that 
TIME_WAIT exists to prevent: picking up data from a previous connection. 
However, modern stacks with randomized ISNs make the failure mode for that 
situation more palatable (more likely to produce an error state rather than 
silently accepting the stale data), and applications that implement their own 
session and/or presentation layers on top of the TCP bytestream will typically 
do a good job of 1) ensuring there isn't any stale data, and 2) detecting it if 
there is. TLS provides such a layer.

I recognize that the use of SO_REUSEADDR on the active-open (client) side is 
controversial, but this particular use case shouldn't appear in a production 
environment anyway.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to