<div dir="ltr"><div dir="ltr">On Fri, Apr 3, 2020 at 3:20 PM Jaco Kroon <<a href="mailto:jaco@uls.co.za">jaco@uls.co.za</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi All,</p>
<p>Following up on some work I've been busy with
(<a href="https://gerrit.asterisk.org/c/asterisk/+/13362" target="_blank">https://gerrit.asterisk.org/c/asterisk/+/13362</a>) a few potential
issues came to the fore on which I need some input on what the
"correct" behaviour should be.</p>
<p>Note that none of this affect me directly (currently).</p>
<p>For the purposes of this discussion, let's assume a host with two
IPv4 addresses, and two IPv6 addresses (globals, ignore link-local
and scope-restricted for now):<br>
<br>
eth0: <a href="http://192.168.0.1/24" target="_blank">192.168.0.1/24</a> and dead::beaf/64<br>
eth1: <a href="http://192.168.1.1/24" target="_blank">192.168.1.1/24</a> and foo::ba/64<br>
<br>
v4 routing has default pointing out on eth0 via 192.168.0.2, and a
rule-based from 192.168.1.1 via 192.168.1.2.</p>
<p>v6 has "high pref" route out via eth0 on LL%eth0, and "medium
pref" out via eth1 on LL%eth1. This may well require things like
rp_filter to be switched off, so I'm going to assume you're
networking is fine.<br>
</p>
<p>When calculating ICE candidates, it's generally for a specific
socket, which can be bound to a specific address (IPv4, or IPv6,
or ANY - as far as I understand).</p>
<p>1. In the case where the socket is NOT bound to any, does it
make sense to include ANY OTHER addresses as ICE candidates?
Specifically, let's say socket is bound to <a href="http://192.168.0.1:10000" target="_blank">192.168.0.1:10000</a> -
does it really make sense to advertise <a href="http://192.168.1.1:10000" target="_blank">192.168.1.1:10000</a> as ICE
candidate? Not to mention the v6 addresses?</p>
<p>2. In the case of STUN (srflx) requests being included, as I
understand the raddr should be the address FROM where the STUN
request was sent.</p>
<p>3. raddr should be one of the candidates presented.</p>
<p>So currently the code has two ACLs, one for ICE addressess
candidates. I actually require this. And one for the STUN
*source* address, which is the address to which the rtp socket is
bound (ANY in the case of PJSIP).</p>
<p>So we will send STUN in the case that:</p>
<p>1. STUN is configured;<br>
2. The RTP bound socket is NOT blacklisted for STUN purposes;<br>
3. We haven't got PJ_ICE_MAX_CAND candidates yet (default value
is 32, so unlikely).<br>
4. The socket is bound to IPv4 or then ANY ([::] or 0.0).</p>
<p><b>First issue: include non-bound addresses as candidates</b>:</p>
<p>If socket is bound to <a href="http://192.168.0.1:10000" target="_blank">192.168.0.1:10000</a> then the kernel will drop
all frames to <a href="http://192.168.1.1:10000" target="_blank">192.168.1.1:10000</a>, unless there is a DNAT rule in
place to forward these packets, or a SNAT rule created a matching
CONNTRACK entry on egress of our first RTP frame. If you're using
these kind of stunts on an asterisk host I officially declare you
braver than me.</p>
<p>I'm arguing in a case where the RTP socket is NOT bound to ANY we
should only advertise the bound address on ICE (v4 or v6).</p>
<p>If the RTP socket is bound to v4 ANY (0.0.0.0) we should only
advertise v4 addresses. This is current behaviour.</p>
<p>If the RTP socket is bound to v6 ANY ([::]) we should advertise
all addresses.</p></div></blockquote><div><br></div><div>Only candidates which have a possibility of succeeding should be included, so if it's bound to something explicitly then only candidates relevant to that should be included.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p><b>Second+Third issue:</b></p>
<p>This gets really tricky. Assuming the above four conditions (it
should be noted we won't sent STUN for a v6 socket bound anywhere
other than ANY ([::]), so we've already decided we need to send
STUN.<br>
</p>
<p>My opinion, based on a potentially wrong understanding of the
reading I've done:<br>
<br>
1. If RTP is bound to ANY (v4 or v6), we should:<br>
1.1 Force-include the v4 address from which ast_ouraddrfor as an
ICE candidate (even if it's ICE blacklisted); and<br>
1.2 Use same for base address (raddr).</p>
<p>2. If RTP is bound to a specific v4 address, we should:<br>
2.1 Force-include the address as an ICE candidate (even if it's
ICE blacklisted); and<br>
2.2 Use same for base address (raddr).</p>
<p>I need to check if it's possible to include the srflx (STUN)
address before the "forced" address or not, but I can investigate
that if need be.<br>
</p>
<p>Current behaviour is to iterate the list of selected candidate
addresses and use the first IPv4 address found for base address
(raddr).</p>
<p>This unfortunately is a behavioural change. One option would be
to bind this to a configuration option. Or two, one for the
change in base address (raddr) selection, and one for forcing
selected raddr as a candidate. But then, what should the defaults
be?<br>
</p>
<p>I would greatly appreciate any input on these thoughts as to what
the correct thing to do is.<br></p>
</blockquote></div>I think behind options, with defaults matching existing behavior today. I say this because it has existed this way for.... many many years... so unless people have experienced issues and never investigated/reported, I think opting for that is fine.<br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>