Currently the QNT API probes all addresses supplied by the remote. Including any that point to e.g. documentation domains, test domains, private networks etc.
Not having any control over which addresses are used for probes means that the remote can directly control where NAT probes are sent, potentially directing probes at intentionally wrong places. Having an API which explicitly allows controlling which remote addresses NAT probes are sent to might help.
When designing this API bear in mind that the application will not always have the full up-to-date view of all advertised addresses. The address candidates can change as soon as the Connection::get_remote_nat_traversal_addresses call has returned and before another API has been called.
Currently the QNT API probes all addresses supplied by the remote. Including any that point to e.g. documentation domains, test domains, private networks etc.
Not having any control over which addresses are used for probes means that the remote can directly control where NAT probes are sent, potentially directing probes at intentionally wrong places. Having an API which explicitly allows controlling which remote addresses NAT probes are sent to might help.
When designing this API bear in mind that the application will not always have the full up-to-date view of all advertised addresses. The address candidates can change as soon as the
Connection::get_remote_nat_traversal_addressescall has returned and before another API has been called.