[asterisk-dev] ICE and STUN address calculations

[Joshua C. Colp]

On Fri, Apr 3, 2020 at 3:20 PM Jaco Kroon <jaco at uls.co.za> wrote:

> Hi All,
>
> Following up on some work I've been busy with (
> https://gerrit.asterisk.org/c/asterisk/+/13362) a few potential issues
> came to the fore on which I need some input on what the "correct" behaviour
> should be.
>
> Note that none of this affect me directly (currently).
>
> 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):
>
> eth0:  192.168.0.1/24 and dead::beaf/64
> eth1:  192.168.1.1/24 and foo::ba/64
>
> 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.
>
> 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.
>
> 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).
>
> 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 192.168.0.1:10000 - does it really make sense to
> advertise 192.168.1.1:10000 as ICE candidate?  Not to mention the v6
> addresses?
>
> 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.
>
> 3.  raddr should be one of the candidates presented.
>
> 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).
>
> So we will send STUN in the case that:
>
> 1.  STUN is configured;
> 2.  The RTP bound socket is NOT blacklisted for STUN purposes;
> 3.  We haven't got PJ_ICE_MAX_CAND candidates yet (default value is 32, so
> unlikely).
> 4.  The socket is bound to IPv4 or then ANY ([::] or 0.0).
>
> *First issue:  include non-bound addresses as candidates*:
>
> If socket is bound to 192.168.0.1:10000 then the kernel will drop all
> frames to 192.168.1.1:10000, 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.
>
> 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).
>
> If the RTP socket is bound to v4 ANY (0.0.0.0) we should only advertise v4
> addresses.  This is current behaviour.
>
> If the RTP socket is bound to v6 ANY ([::]) we should advertise all
> addresses.
>

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.


> *Second+Third issue:*
>
> 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.
>
> My opinion, based on a potentially wrong understanding of the reading I've
> done:
>
> 1.  If RTP is bound to ANY (v4 or v6), we should:
> 1.1 Force-include the v4 address from which ast_ouraddrfor as an ICE
> candidate (even if it's ICE blacklisted); and
> 1.2 Use same for base address (raddr).
>
> 2.  If RTP is bound to a specific v4 address, we should:
> 2.1 Force-include the address as an ICE candidate (even if it's ICE
> blacklisted); and
> 2.2 Use same for base address (raddr).
>
> 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.
>
> Current behaviour is to iterate the list of selected candidate addresses
> and use the first IPv4 address found for base address (raddr).
>
> 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?
>
> I would greatly appreciate any input on these thoughts as to what the
> correct thing to do is.
>
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.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200416/3ff38d9d/attachment-0001.html>