IETF Logo Mail Archive

Re: [rtcweb] Transports: RFC 4941 support?

Dan Wing <dwing@cisco.com> Wed, 19 March 2014 05:14 UTC

Return-Path: <dwing@cisco.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 B7A921A0381 for <rtcweb@ietfa.amsl.com>; Tue, 18 Mar 2014 22:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Level:
X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 u7cfafpt1KqT for <rtcweb@ietfa.amsl.com>; Tue, 18 Mar 2014 22:14:09 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 829B31A04AA for <rtcweb@ietf.org>; Tue, 18 Mar 2014 22:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3995; q=dns/txt; s=iport; t=1395206041; x=1396415641; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=cGNk5HZ6xjyxy1Jdsbr3Y0VdxNItRPe1g/Ks3O05bkI=; b=SSqYNK4SevPeC3ljrCgvEe93bFCGKN5dzuIa6Ic5xrd+UwDvemclAp++ hw049MxRN5pIMIAPK6GpBQgU1tIYEz/BjvVCV/PVNio7kqfFGcv4yfyJI TdFhBFaO/Dmn95uOzylWFlUutDKjip1xWFL9p1Htj6W93GDi0EO+miIhp k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAGcnKVOrRDoH/2dsb2JhbABagkJEO8MmgSAWdIIlAQEBAwF5BQsLBAo4VwYTh3EHDtA3EwSOXgQHgySBFASJUo51kjCDTR2BLCQ
X-IronPort-AV: E=Sophos; i="4.97,683,1389744000"; d="scan'208,217"; a="108471851"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 19 Mar 2014 05:14:00 +0000
Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2J5DxnH022887; Wed, 19 Mar 2014 05:13:59 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_B31ED087-23B5-4C3D-BF23-16861A720391"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CAOJ7v-0Hw0NFs_avsB2Z8do21BCws2LRZSeSh6HP0t455SPXyw@mail.gmail.com>
Date: Tue, 18 Mar 2014 22:14:00 -0700
Message-Id: <B6836FFA-867A-4CBF-9855-D265425EC5E1@cisco.com>
References: <CAOJ7v-0Hw0NFs_avsB2Z8do21BCws2LRZSeSh6HP0t455SPXyw@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O8HPuDMmOlPj_UHvONRP9VJ5hjA
Cc: Harald Alvestrand <hta@google.com>, "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 05:14:12 -0000

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

v2.23.0 | Report a Bug | By Email