Re: [rtcweb] Transports: RFC 4941 support?

Justin Uberti <juberti@google.com> Wed, 19 March 2014 20:44 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 1895D1A0783 for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 13:44:19 -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 DvgvpuD4HDZr for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 13:44:16 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 49CA61A06D3 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 13:44:16 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id ik5so10170336vcb.28 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 13:44:07 -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=QQhYTlL5ak/QUNjQnakl3sdaAfmBMN33Bm3dcKZjT/E=; b=YcvD9QTZjCe32x/a+SJeiDz1onDKHxUbIyaf2EhQ/q9gN+5pSFXyU3kM6jYofzlycl TSJ/ZZCU9Z54Lmt4bHCD9H3CFjxrHVc8KJB4stg54RCbssPwHOsZHTcxuLNcSM87oxPy +0GD/6h+wg2isXfzK02OzU2ewhkvMWE2NUKIfIb3rUkJoRHPaHK2N8erbSpKxSt4fgER 5tt+nKuHFf+8fUEeekiZHSJYFwd+eOAwG5WipNcjCnKKRmG2GxeWW315fGAtPq3rkm0T YF4KIJHIkmbT1XKuujGDdmy+OkI0ye4guP6T2u+KOcxiHkXHi3czOPOyuBoB8sFevM92 s1Sw==
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=QQhYTlL5ak/QUNjQnakl3sdaAfmBMN33Bm3dcKZjT/E=; b=GqLtxa1Q/saM1HnNA5f/HHH9BfQw3y7cDG73lMngh2u/cTHYL1yTweqNQS2orekJUj VH+EX2zHz79IHswwd0uv1DgYjhNVZ25xT9PkXVp+PY3ODEGJJI3VTy7mu6KnX3N3S5gq s9pzfc41uTpOkwJr8oA1Gzegs03gIZDleKCnTgz3Re3qUFVJj2plvF9YNKy7EXJGEUdz V51F9a6x9owlSlSjJpHPQ92wkAhKVburlpSyZgYQE6AajIQMMq8l/mKBtiVqu1+nJSxz sJ4DQITRdBiswbdgLP3ZrH0BzwyRgwnTwPtOLVMiseO0IWa+qatbkRS2mkkjkzNxg/JM HZnw==
X-Gm-Message-State: ALoCoQlSoOEAU4S3tE3zNVVltOtNgGaIFvmaWKmc4qrbKhf60Kw4XF3BVNsd1qOtFIF3qhsfhCezJhHNdOHP+HHVpEH8YJ+xHE8vhzmw+Kt1FltUHEKkIP4F9yI4R3LEntjTvl43lZgpAFv2TM2EtrhqrzT1L56Yq9gb8fT1/+84uN/N1fGcZA7Fp6u5mYL6hjnYgakBBml1
X-Received: by 10.52.136.35 with SMTP id px3mr233255vdb.66.1395261847180; Wed, 19 Mar 2014 13:44:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 13:43:47 -0700 (PDT)
In-Reply-To: <CAOJ7v-24WfmXeKPH8VcnZ5Uz4cKOWJBadraVKY7SO+Li=51Omw@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> <CAOJ7v-24WfmXeKPH8VcnZ5Uz4cKOWJBadraVKY7SO+Li=51Omw@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 19 Mar 2014 13:43:47 -0700
Message-ID: <CAOJ7v-2K5Psgd7R41bjGN2tBfnM9Oq20ZdqXMkzOBBs7TR1AQg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=bcaec52d4acfc5375904f4fbb622
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e-_3ODsIzYDwcK9bxzheIg33z0Y
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 20:44:19 -0000

(and, to be clear, that by default, non-temporary addresses SHOULD NOT be
used by clients)


On Wed, Mar 19, 2014 at 9:08 AM, Justin Uberti <juberti@google.com> wrote:

> 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
>>
>>
>