Subject: [MMUSIC] Trickle, privacy and bogus addresses

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Mar 2013 16:00:36 -0400

Someone proposed that we use 0.0.0.1:9 to signal "no candidates".

I don't believe this to be necessary and would rather we don't go there at all.

If privacy concerns do not prevent the sharing of addressing
information, trickle can proceed with host candidates.  This is not a
real concern.

If privacy protection is paramount, pay the price and allocate a turn
candidate prior to sending the offer or answer.  It's only the caller
that is required to pay this cost, which is a little silly because the
answerer is the most likely to want this sort of protection.

Furthermore, in WebRTC, we have a candidate pool that would ensure
that would allow us to prime the answerer in preparation for receiving
an offer such that overall session setup would not take any longer.
If anyone is unconvinced, I'm happy to walk through a proof of this.

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Mar 2013 16:10:07 -0400

If we can maintain privacy without having to specify an intentionally 
bogus address, then I am strongly in support of avoiding this silliness 
also.

/a

On 3/14/13 16:00, Martin Thomson wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Emil Ivov <[email-masked]>
Date: Thu, 14 Mar 2013 16:12:58 -0400

Hey Martin,

> I don't believe this to be necessary and would rather we don't go there at all.

When we talked about this on Tuesday, it appeared as if we had consensus
and the only issue was about making a choice between one of the many
possible options. (127..., 0.0.0.X, something else that IANA would
allocate for us).

How do you get from that to "I'd rather we didn't do it at all" ?

> information, trickle can proceed with host candidates.  This is not a

Right.

> that is required to pay this cost,
>
>
> which is a little silly because the

I am not sure I got the idea, so yes, please do :).

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 14 Mar 2013 16:16:41 -0400

> bogus address, then I am strongly in support of avoiding this silliness 

We do not need a bogus candidate because of privacy. We have one that is
defined by 3264 with exactly the necessary meaning: 0.0.0.0.

The reason we need a bogus candidate is because some people here have
expressed concerns that we need to take into account poorly
implemented/legacy SDP parsers who might somehow fail on 0.0.0.0 because
of what it used to mean in 2543.

Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Mar 2013 16:18:51 -0400

> How do you get from that to "I'd rather we didn't do it at all" ?

I applied some brain cycles to the problem, talked to a few people.

I'll find you and walk through the proof.  It's not especially complicated.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Mar 2013 13:01:02 -0700

You may want to enforce address privacy on the outgoing offer because you
_never_ want the other side to learn your IP.

In the case where both sides want to maintain address privacy, using a null
address shortens the setup time since TURN allocation can happen in
parallel.