Re: [openssl/openssl] Dtls listen refactor (#5024)

--===============4236720041035683051==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain


Matt Caswell <[email protected]> wrote:
    >> Matt Caswell <[email protected]> wrote: >> a) when the existing FD is
    >> connect(2) any future traffic to the bound >> port will get rejected
    >> with no port.  So the application really has to >> open a new socket
    >> first.  The application can do this two ways: it can >> open a new
    >> socket on which to receive new connections, or it can open >> a new
    >> socket on which to communicate with the new client.  The second >>
    >> method is better for reason (b) below.  Either way, it socket to >>
    >> communicate with the client needs to be bind(2) to the address that >>
    >> the client used to communicate with the server, and DTLSv1_listen() >>
    >> didn't collect or return that information.
    >>
    >> > The second way is what is intended.
    >>
    >> Unfortunately, there remains a race condition because we have to call
    >> bind() before connect() on the new socket.  Under load, if a packet is
    >> received between the bind() and the connect(), it might go onto the
    >> wrong socket queue. So some packets that could have been processed
    >> will get dropped and have to be retransmitted by the client.

    > This seems like a non-issue to me. At this point in the handshake the
    > client will have sent its ClientHello and won't progress until it gets
    > the server's flight back (ServerHello etc), i.e. in the vast majority
    > of cases it won't be sending anything.

*That* client will be waiting, but other clients may be sending new ClientHello
messages (with or without cookies).

    >> The address of the remote client is returned ("getpeername()") by
    >> DTLSv1_listen().  That's all that recvfrom() gives you.
    >>
    >> recvfrom() was a reasonable API for SunOS 3.x machines with a single
    >> 10Mb/s interface with a single IPv4 address.  I loved all that at the
    >> time...  But it doesn't work that well when we might have a dozen
    >> different kind of IPv6 addresses on each virtual interface.
    >>
    >> The address that I'm talking about needing is the one the remote
    >> client used to reach us.  That's the destination IP of the incoming
    >> packet ("getsockname()" in TCP speak).

    > Ahhh....its the *server's* address you are after. This requirement
    > seems more reasonable. I think the API is designed to expect you to
    > only bind to a single IP. I'd be interested in Richard Levitte's
    > opinion on this.

okay.
binding to a single IP is not scalable in many applications.

    > It seems like a fairly simple solution could solve this. Currently we
    > have BIO_dgram_get_peer() which returns the peer's address for the last
    > message read from a BIO. You could imagine a new call being introduced
    > to get our own address. You could then call that immediately after a
    > successful DTLSv1_listen() call. Obviously we'd have to change the
    > dgram BIO to use recvmsg for this to work.

That's here:
       https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
       https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
and:   https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpfeyQACgkQgItw+93Q
3WULgQf/Uh0CyHFNwrgYb+xoHaThlxaKtzFvaL87zUgv5skTEh1zcXBGwPwpBvLV
Rg3chyUDe4g7Y6ov23++OgwAdW0j3VmG1GYj4HrBJv5d00vl2qRVTLaUhbm3y8/m
zL6vjpe3NFbxJg1DXW68FfsfcsoSd3fJ5qlx2rWROCi7XHZn0dmwNlWPokBAhlNP
kFw2/hXZIuVAKDNfUsZpJvQwm4UnS7X2kykzfNWrWdLNlV7HsqQtQCP3EFcOpmxy
8ncLzCfoeLNoeVhfzX/xjCevslzH85wFb+exfvNHDytvCk9iCJsjCy6jibpNXPt1
lNollStkyoiBGDPz87nShLs18crWHw==
=nrBo
-----END PGP SIGNATURE-----
--=-=-=--

--===============4236720041035683051==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============4236720041035683051==--