Re: [rtcweb] Transports: RFC 4941 support?

Justin Uberti <juberti@google.com> Thu, 20 March 2014 16:35 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 0E8341A07C1 for <rtcweb@ietfa.amsl.com>; Thu, 20 Mar 2014 09:35:07 -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 f_KjyI1XE0g5 for <rtcweb@ietfa.amsl.com>; Thu, 20 Mar 2014 09:35:05 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E78921A0770 for <rtcweb@ietf.org>; Thu, 20 Mar 2014 09:35:04 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id id10so1234403vcb.26 for <rtcweb@ietf.org>; Thu, 20 Mar 2014 09:34:55 -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=PfaFudb1lJAzVQDlGJ4mBN+kOhnLly6nqdBG98XxVYg=; b=D6IeIWBtWy28xlbxzXZtmqyPwsxcLPxyZORqjqgwMhK5PQrxt/zFgC3wq9tnw63ugh R6Sfion7Bu2Doys9WFgKMp1MdDfltq7VT+XpKa8+eR1ipF7UmDRZ/Eqbs3zepvmHv3MP E08wCKYEVOFI9nUvskRdXbMOuczBayOqY/sXPdarnS3y3RtQeNEx8AsFGEXBh1+ZfnET ag4j6b19tUHkoUdq2TNo6UB4JG6WC1xuJr1V6ON2DjbqpDfTH5rsskWwvxoTm0Cpdjfy JGNdcEHLhpwW1FTT4Jv9rvBRkLzq/7iH66V/AZ5OP0bUapowlFHATF8ZgeStBpQ6AXy/ TYYg==
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=PfaFudb1lJAzVQDlGJ4mBN+kOhnLly6nqdBG98XxVYg=; b=Spmm0nu00Gea2kx1H7CjKmsFIQIBmDk+Dx7RzW1Rs9LIPufn6fQiSGO4MAB/s6n7jJ aGu+L74vqH+kcKyPiNzEHT4TR5tl8Ihyi71ySV3EIRZ4K/Ko/U5C7KX7hgutRlFzidPS 8a1kAC1RyDxb+N6SP7yem3lI4eYS4LFf6e8EpUxjIqP/o7x/VlpgtZpB7nEwePGpUB6p 9HzITjodPkBSkk+cGO1CkSGqn9O6MctnZNpDjoGyYmeDFZmopIAMgvNMranOBEd/QQ7P 6t30SkjcSdSBDyEID2QLXMqcx4R79ZDClwTBSw0beaD5ImY/dIkN8vO98o57bnNMO++8 6srA==
X-Gm-Message-State: ALoCoQl1rn/6e4BulIbrrWGuKFzLjrLWoOi6GMeR/WH8qPymJ4k83FyiQGb0A160u1oQci6d246wtdli3HB1XmQfwSffyh/9kBGZ57nJTGaAQezpmOotcSYsBDruylJeP/AHUz/AQzn5OmbWL2TERz+cHm6zTTetH9UDgU5qyuAuxUO+j2GfL56OeH6mhdwbNthpv3Vkg0Uv
X-Received: by 10.52.69.146 with SMTP id e18mr29097831vdu.15.1395333295732; Thu, 20 Mar 2014 09:34:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 09:34:35 -0700 (PDT)
In-Reply-To: <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.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>
From: Justin Uberti <juberti@google.com>
Date: Thu, 20 Mar 2014 09:34:35 -0700
Message-ID: <CAOJ7v-0Dx4Owam7NzXqs6ALPi+ps9gKbmFK9=Zu5eBr9yHYgKg@mail.gmail.com>
To: Dan Wing <dwing@cisco.com>
Content-Type: multipart/alternative; boundary=20cf3071cd0e6f99fb04f50c59f7
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eFsDcREVpS8Try4lXXMNqOXS9Hg
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 16:35:07 -0000

On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing <dwing@cisco.com> wrote:

>
> On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
> On 03/19/2014 04:08 PM, Dan Wing wrote:
>
>
> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> wrote:
>
> I'd like to be silent on the issue, since which IPv6 addresses to prefer
> is likely to be a matter of system policy. Trying to override system policy
> in an application specific profile usually leads to sadness.
>
>
> The application needs to indicate if it wants a temporary address. If the
> host's policy (or configuration or network) does not support temporary
> addresses, the application won't get a temporary address.  I don't see why
> being silent helps?
>
>
> What API is it using?
>
> With a little Googling, the system policy I was thinking of was the policy
> in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5
> rule 7: "Prefer  temporary addresses".
>
> I'm happy to say "it is a good idea for systems to implement the
> recommendations of RFC 6724" (or some more 2119-like language). I wouldn't
> want to claim that if a system has chosen to prefer non-temporary
> addresses, it would have to change its non-conformance to RFC 6724 in order
> to be conformant with RTCWEB specifications.
>
>
> 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)