Re: [rtcweb] Transports: RFC 4941 support?

Justin Uberti <juberti@google.com> Wed, 19 March 2014 16:09 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 176461A07BF for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 09:09:24 -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 b10hgO57T3TP for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 09:09:20 -0700 (PDT)
Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B69771A07AA for <rtcweb@ietf.org>; Wed, 19 Mar 2014 09:09:20 -0700 (PDT)
Received: by mail-oa0-f46.google.com with SMTP id i7so8538308oag.33 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 09:09: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=vBPrnFYqp11MpNwNuI0Ij95NcpzyAXA1qzvGMZgKGhU=; b=XErhqWRxOxg/XcRtq1m2NmBuIbv+zdq2CpO9zSOE3srs+Y1uLm8psu+7D3LHz6YsYG d3BS8zyjqyrWcLlc8gja6dSP+gtn7CpP5ECaLewNcoYVL6+r4A9vYCXVT+hNSOuNaxpD wEZdWmYtaeDcDLxEKUWplebBAdk9Af/Lh6JSGsWGi/XbUjiWOMEFiqt5LuqHa0bJzzfd ncVSJLXcSCh1r/3e+PK2ut8CCzkfpOHHHMikfQt/Adu+XEatv1ijlu5mNKnTRwfq72I8 WpInvN9yplt3GeXz9nmoVn597wRks0zh9k8ElP5uDywlpKPZZD02L6IM8/xUA9kl1Bww 18Yg==
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=vBPrnFYqp11MpNwNuI0Ij95NcpzyAXA1qzvGMZgKGhU=; b=Gp5PwQba24PUpH1yjQuQRO8IYScM+VGybx2JD3TtjPt96y4mNiNgnCTu7FtmAl2GzQ 3aWWFz7DGQKJYJAt6XX1IDInnOoHVykuxi1BVpodhcLdAjNRaiIyv3THmgaum6KaLzXp p1paNAvCtxa2yyaImvfjyyWYQezvqik2XqndUY+bcnov6tZqENeIY720ykII8c/+mGkZ 8EWqMXy2vP76Btt4j9snrLsglp7+obsOfSsUkTEAEY5h7kB/muiF5phNL7qLMqtAnyeV elF29wmBxwDn7GmVsGzw0Wuh4JR3zTR+8uz0t+kuoWHWZZdi1bW6anMkq+gmYdveGcj9 t9aA==
X-Gm-Message-State: ALoCoQlpu/TWHPAVRXfDzgesmLpRvwDcLqqQwr01lHdEe4lqQPqxE4ocUDMDqodtDTPaf/+ZPiM+mXhs9tTHGmb+RN3q1HaJISxFfiBnzWCtEdY9e67qLIkYdQsOaYBWI2Kr3o4U3DHMS3927FPU9qAM4EhQBP2/Gnx00hUDauLToy74aftPJ+uzPzL9kdCCnHfLnC6Oxx4u
X-Received: by 10.182.156.19 with SMTP id wa19mr1049793obb.80.1395245351118; Wed, 19 Mar 2014 09:09:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.96.230 with HTTP; Wed, 19 Mar 2014 09:08:49 -0700 (PDT)
In-Reply-To: <5329B617.2070001@alvestrand.no>
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>
From: Justin Uberti <juberti@google.com>
Date: Wed, 19 Mar 2014 09:08:49 -0700
Message-ID: <CAOJ7v-24WfmXeKPH8VcnZ5Uz4cKOWJBadraVKY7SO+Li=51Omw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=f46d0444ee91932c7704f4f7df79
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lVIqpSVYgMRwxLUjC4i24FCssZ0
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: Wed, 19 Mar 2014 16:09:24 -0000

ICE by default is going to gather host candidates from all interfaces,
which means that the non-temporary addresses are going to be used,
regardless of priority, for connectivity checks at least.

As a result, if we don't do anything, it means 2x the v6 interfaces, and 4x
the v6-v6 ICE checks, in addition to any linkability concerns.

We could say that if a system has chosen to prefer non-temporary-addresses,
or privacy is not a concern, then non-temporary-addresses can be used.


On Wed, Mar 19, 2014 at 8:21 AM, Harald Alvestrand <harald@alvestrand.no>wrote;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.
>
>
>  -d
>
>
>
>
>
> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:
>
>>
>>  On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:
>>
>>  https://tools.ietf.org/html/rfc4941 defines the concept of temporary
>> IPv6 addresses. For, example, as enumerated on my local system:
>>
>>  inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
>> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf
>> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf
>> *temporary *
>>
>>  As indicated in the RFC, the temporary addresses expire after hours or
>> days, and therefore could be used to prevent long-term linkability of
>> sessions. Expiration shouldn't be an issue for WebRTC, since we can simply
>> do ICE restart if this occurs during a session.
>>
>>  Is this something we want to recommend in the transports doc?
>>
>>
>>   Yes.
>>
>>  And it should be as frequent as every new 'call', if IPv6 privacy
>> addresses are to provide the same privacy as a NAPT44, as a NAPT44 should
>> be assigning random ports per reasons described in RFC6056.
>>
>>  The transport document should also recommend doing port randomization
>> (RFC6056), as that was found pretty useful for DNS, but randomizing ports
>> is still not popular with many OS's TCP stacks for whatever reason.
>>
>>  -d
>>
>>
>>
>
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>