[MMUSIC] Trickle, privacy and bogus addresses

Martin Thomson <martin.thomson@gmail.com> Thu, 14 March 2013 20:00 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AF711E80F2 for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 13:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn6ejeV9FzmU for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 13:00:37 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 762F411E80D7 for <mmusic@ietf.org>; Thu, 14 Mar 2013 13:00:37 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id ds1so2075562wgb.0 for <mmusic@ietf.org>; Thu, 14 Mar 2013 13:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fFfDI1zKSnZocGhol71LN5AUsb9kqEavVjfe9/VvSrc=; b=OdzN/tGza9EvfqTXYoVwkKCreN64RycBZ0bo1IB3CgtMqFFQHEDujEE+aDKCHKeZDm gA4bv1blsBFn9l7a3Vc3PmpqWRNMj/QiDhSs8yC/6NNqcJDsjTyt1lJNcqLBEZzDkQAy Y1eg74gtTUubx1XzSvuBf6jSyXVXDpYkPEw6oNXQuwwo7ebwiE2AjlC1VOEWALfl8RwW YL4HKpZSUK7P0by62KSTRJiaBD6XGttPcmtXSN4htwu4m9RvyKiRRpeWwIwXzHbPgb6v P7g1LaZJLDjlsmWbQBAQ4tCDvJ654UMOYru49GhfnyJBxEscPFcIZY3UoSQ5DjJINk3I mShA==
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr6809978wjw.21.1363291236660; Thu, 14 Mar 2013 13:00:36 -0700 (PDT)
Received: by 10.194.5.135 with HTTP; Thu, 14 Mar 2013 13:00:36 -0700 (PDT)
Date: Thu, 14 Mar 2013 16:00:36 -0400
Message-ID: <CABkgnnW_epOmud_=uVoLvcipeC=5ukG+daJ3axa-tc72CPzCgw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Subject: [MMUSIC] Trickle, privacy and bogus addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 20:00:38 -0000

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.