<div dir="ltr">Hi Michael,<div>The connections are from different peers and we are unable to use same SSL. </div><div>Also getpeername on the UDP does not work as we have enabled SSL for the sender peer socket.</div><div>Any suggestions to resolve this?</div><div><br></div><div>When we have 2 SSL associated to a fd through BIO, on which BIO does the openssl do the read?</div><div>Can we restrict it to read from an SSL of user choice? </div><div><br></div><div>We are just looking for an option to distinguish DTLS on UDP connections. We were'nt successful in doing it with DTLSv1_listen as it hangs on the SSL.</div><div><br></div><div>Thanks,</div><div>Grace</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 14, 2018 at 3:12 AM, Michael Richardson <span dir="ltr"><<a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
Grace Priscilla Jero <<a href="mailto:grace.priscilla@gmail.com">grace.priscilla@gmail.com</a>> wrote:<br>
</span><span class="gmail-">    > Below is our scenario on DTLS.<br>
<br>
    > We have multiple connections to the same server. We have mapped one fd<br>
    > to the ssl in the server to receive all connections.<br>
<br>
</span>Are these connections from the same client (same 5-tuple), or are you just<br>
talking about multiple clients?<br>
<span class="gmail-"><br>
    > Whenever a connect is initiated from any client we need to know if it<br>
    > is already connected client or a new client. We are doing this by<br>
<br>
</span>    > * creating bio/ssl each time on the same fd<br>
<br>
    > * fetching the peer using BIO_dgram_get_peer after ssl_accept<br>
<br>
    > * Comparing it to the internally maintained list of peer<br>
<br>
    > * If it is a new peer we continue with handshake but if it is old peer<br>
    > we do the ssl_read.<br>
<br>
I don't think this is going to work.<br>
<br>
A UDP/DTLS server has two choices:<br>
<br>
1) read all the packets on a unconnected socket and demultiplex them into<br>
   appropriate BIOs/SSL structures.  I did not find an obvious way to do<br>
   this, I think that a new BIO type would make this easiest.<br>
<br>
   It also has the downside that it's hard to spread the load across<br>
   multiple processes, although with the right locking multiple threads would<br>
   likely work.<br>
<br>
2) after each call to DTLSv1_listen(), set up a new fd that is bind()/connect()ed to<br>
   the peer (by 5-tuple) so that all traffic from that peer arrives on the<br>
   correct FD.<br>
   AFAIK, there isn't anything to forbid two DTLS sessions between identical<br>
   UDP sockets, as they could have differing session cookies, etc.<br>
<span class="gmail-"><br>
<br>
    > The problem is that there are 2 bio/ssl that gets created for the same<br>
    > fd and the peer end up writing to one of them and we don't get the<br>
    > message on the intended ssl.  Hence we are checking for a way to detach<br>
    > and remove the ssl/bio that gets created in already connected case.<br>
<br>
</span>I don't think that is going to work.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
--<br>
]               Never tell me the odds!                 | ipv6 mesh networks [<br>
]   Michael Richardson, Sandelman Software Works        | network architect  [<br>
]     <a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a>  <a href="http://www.sandelman.ca/" rel="noreferrer" target="_blank">http://www.sandelman.ca/</a>        |   ruby on rails    [<br>
<br>
</div></div><br>--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
<br></blockquote></div><br></div></div>