Re: [rtcweb] Transports: RFC 4941 support?

Justin Uberti <juberti@google.com> Thu, 20 March 2014 23:04 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF31A077C for <rtcweb@ietfa.amsl.com>; Thu, 20 Mar 2014 16:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33rcXAu5RpSQ for <rtcweb@ietfa.amsl.com>; Thu, 20 Mar 2014 16:04:22 -0700 (PDT)
Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8F41A0930 for <rtcweb@ietf.org>; Thu, 20 Mar 2014 16:04:22 -0700 (PDT)
Received: by mail-ve0-f176.google.com with SMTP id cz12so1719397veb.21 for <rtcweb@ietf.org>; Thu, 20 Mar 2014 16:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a3Dr33Ah4N9EeTgHbQnc6qJ/XsjwXkLV6SIHQAXkvE0=; b=hNKh7tn+sqMf6P7VTvoDRNpB/5gYPaLXIQOsMBVli6wEG/IaSkirxpjMMHPTr7EhEm lY0wCuy4DfnxDf6jIescXSON/HMarmk5BFEA97+Fil2Y+8QVY3rr9ZxctvCSRJFhW9SI f1zHDLwy1A3gxsPZ/Yx5T/tuq0LO3eDCQwFu9GDPCMpHbIbeZbCMEZORFth9KQd06sG2 NpkwVY/+5JqcWFZ+BxDeZS3DwBurikQpVQva0tNz4tU3nI8Hyw9ZEyt2o/mTNJiqz7oO qFPcawucapJb8iHoRvvaWOoKbTFOvOBq1fiElvxnT1vV0gYYvLzndKAayGGEfd/6a2Xs EVow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=a3Dr33Ah4N9EeTgHbQnc6qJ/XsjwXkLV6SIHQAXkvE0=; b=mwnieSxR8bQP+/NcUfqRLTqiCrhjgj/aQYtT5XbCMqMQt0w9+CQDTXH2L1F3Yv9SAW nxgD8zKaS9Ext244FcVL+Wiwg0Y5q9ydOXiyPkUiLujDH0QFFK1GETkIcZfnazmH5l4i eiCQM9Nm2a5GyAgZK+53sioKnlLF3J4/PsfIa+U/merEvwKqfMs58NFSWJwAdSJph0NO Uhe70oIk+ntpmCUQraRH46Z7BdSa7xcMpyEMzrfa1nQsVnSy+L1T3QeSM6xG+WXb+/xW xUPhMYg4sIkdpF9kGvp96lxYkJUESjPqpFQ9MZuVvNnlu9IzujtwFHjZgYDu915/oime Z5DQ==
X-Gm-Message-State: ALoCoQnk4Zw56HWUx7PZD2+foaSkF/w77g2IuVdE1ir3oj1yrYQUduXnLLOKCFA8O/0z4kfb/wa0G1021xqLBLsI6GLWY9LvC4mCw9bUc5pOIgpvDssG7lnitPEei08PUoM83winf+/ZGngpGQSabZFuMlA76LHJ578dR2wL0Ezfn26eCPERmkgIlaMfE4n66/Mcuu1XQc6b
X-Received: by 10.52.134.202 with SMTP id pm10mr1704888vdb.55.1395356652834; Thu, 20 Mar 2014 16:04:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 16:03:52 -0700 (PDT)
In-Reply-To: <CA+9kkMD5jG-w7ahHLsUX9QMSkSMArS4Wz7ZYOucAZWkrmz5YsQ@mail.gmail.com>
References: <CAOJ7v-0Hw0NFs_avsB2Z8do21BCws2LRZSeSh6HP0t455SPXyw@mail.gmail.com> <B6836FFA-867A-4CBF-9855-D265425EC5E1@cisco.com> <CAOqqYVE=i2L7FxGgKuV0DVaaxYOPnxzSEbDoq0_4Tqapna575g@mail.gmail.com> <CD747481-EBDA-4FFC-A31D-618E6E217420@cisco.com> <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <CAOJ7v-0Dx4Owam7NzXqs6ALPi+ps9gKbmFK9=Zu5eBr9yHYgKg@mail.gmail.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> <CA+9kkMD5jG-w7ahHLsUX9QMSkSMArS4Wz7ZYOucAZWkrmz5YsQ@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 20 Mar 2014 16:03:52 -0700
Message-ID: <CAOJ7v-1JZG547KkiWeG=3zfCFk6WVzm+r9kF0MTg3SQynHMJdg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec5299f9ba0c75404f511c90c
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oBfvnQi4ZKLdzZkEUaCnOKdxfQg
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Transports: RFC 4941 support?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Mar 2014 23:04:25 -0000

Your take is what I had in mind. Basically a ruleset like this:

 gather_ipv4_addresses();
 if (has_ipv6) {
  if (has_temporary_addresses && temporaries_not_forbidden_by_policy) {
    gather_temporary_ipv6_addresses();
  } else {
    gather_non_temporary_ipv6_addresses();
 }
}


On Thu, Mar 20, 2014 at 1:56 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Thu, Mar 20, 2014 at 10:07 AM, Dan Wing <dwing@cisco.com> wrote:
>
>>
>> On Mar 20, 2014, at 9:34 AM, Justin Uberti <juberti@google.com> wrote:
>>
>>
>>
>>
>>
>> So perhaps:
>>>    "An RTCWEB implementation SHOULD prefer to use temporary addresses
>>> [RFC4941] where host and network policy permit [RFC6724]."
>>> ?
>>>
>>
>> I think it needs to be stronger than that - something like
>> "where
>> host and network policy permit, RTCWEB implementations SHOULD gather IPv6
>> temporary addresses and SHOULD NOT gather non-temporary addresses".
>>
>> Preferring to use temporary addresses is probably not sufficient to
>> prevent linkage, since you will have connectivity checks from the
>> non-temporary addresses. (i.e. an eavesdropper listening over an extended
>> period of time could determine calls are from the same endpoint)
>>
>>
>> Agreed.  I like your suggested wording.
>>
>> -d
>>
>>
>>
> So, I note that in this case where a non-temporary IPv6 address is present
> and  no temporary IPv6 address is present, this appears to push IPv6 out of
> the gathered list completely.  If I have that right, then my view as an
> individual is that this is the wrong result.  It will either force the use
> of IPv4 addresses which are just as linkable as IPv6 non-temporary
> addresses or rely on NATs to get the non-linkability (and provide us all
> the other subtle joys of NAT).
>
> As a friendly amendment, may I suggest "Where both non-temporary and
> temporary addresses are present and host and network policy permit, RTCWEB
> implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT
> gather non-temporary addresses"?
>
> I also confess to a suspicion that Harald's view is the most
> sensible--having a separate policy for this application either won't happen
> or doesn't make much sense.  But if we have one, I'd prefer one that
> doesn't shove IPv6 out the door completely if the host doesn't use
> temporary addresses.
>
> regards,
>
> Ted
>