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: > >> 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 >> >> >
- [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Dan Wing
- Re: [rtcweb] Transports: RFC 4941 support? Harald Alvestrand
- Re: [rtcweb] Transports: RFC 4941 support? Dan Wing
- Re: [rtcweb] Transports: RFC 4941 support? Harald Alvestrand
- Re: [rtcweb] Transports: RFC 4941 support? Simon Perreault
- Re: [rtcweb] Transports: RFC 4941 support? Simon Perreault
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Dan Wing
- Re: [rtcweb] Transports: RFC 4941 support? Dan Wing
- Re: [rtcweb] Transports: RFC 4941 support? Simon Perreault
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Simon Perreault
- Re: [rtcweb] Transports: RFC 4941 support? Dan Wing
- Re: [rtcweb] Transports: RFC 4941 support? Ted Hardie
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Roman Shpount
- Re: [rtcweb] Transports: RFC 4941 support? Dan Wing
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Roman Shpount
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Olle E. Johansson
- Re: [rtcweb] Transports: RFC 4941 support? Harald Alvestrand
- Re: [rtcweb] Transports: RFC 4941 support? Harald Alvestrand
- Re: [rtcweb] Transports: RFC 4941 support? Justin Uberti
- Re: [rtcweb] Transports: RFC 4941 support? Ted Hardie
- Re: [rtcweb] Transports: RFC 4941 support? Roman Shpount
- Re: [rtcweb] Transports: RFC 4941 support? Dmitry Anipko
- Re: [rtcweb] Transports: RFC 4941 support? Martin Thomson
- Re: [rtcweb] Transports: RFC 4941 support? Harald Alvestrand
- Re: [rtcweb] Transports: RFC 4941 support? Harald Alvestrand
- Re: [rtcweb] Transports: RFC 4941 support? Roman Shpount