[asterisk-dev] ICE and STUN address calculations

[Jaco Kroon]

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.

*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.

Kind Regards,
Jaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200403/1bd1d30a/attachment.html>