Re: [rtcweb] Transports: RFC 4941 support?

Justin Uberti <juberti@google.com> Fri, 21 March 2014 15:27 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 0B49D1A0989 for <rtcweb@ietfa.amsl.com>; Fri, 21 Mar 2014 08:27:45 -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 C3yvZA91oQ2O for <rtcweb@ietfa.amsl.com>; Fri, 21 Mar 2014 08:27:42 -0700 (PDT)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 12BF11A0731 for <rtcweb@ietf.org>; Fri, 21 Mar 2014 08:27:41 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id jw12so2671690veb.23 for <rtcweb@ietf.org>; Fri, 21 Mar 2014 08:27:32 -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=4k4djDBRU8Yc7Jehbi4j65UZ/pYBBve7b5tM7ORgAT4=; b=DFmPPb+jvVXpCHCivkiANuVCpRSZzHdALfnHsxCpXhFNOG0slNrGnbONJz72LW6odv ZXRtpe3nJjhoFWJgVfI08fyqNcoP13B+/q9vL+N6JhYmpcqAi1ihhYktVg7r11I6c6GM W7agBwUMF65vSUOgUFTml5YV9SsOKVvPsutSHkzfEZzNfWQR7hmnve25KOEJSorHj8dz 1M1r6zoUEBSEbGNuUyuKXokLRNlCJe8l1R5+YmSeMag40G3/ApYn1fnhtlkBSGOwtjKQ Fjmq4OKUrB9bdYZ/TJM3yhIUc7oYwzj4Y7JHuWI9BcNDWdo6Knz0xcq+VaRSgQTvedQ0 /zNg==
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=4k4djDBRU8Yc7Jehbi4j65UZ/pYBBve7b5tM7ORgAT4=; b=gL/y+K4j6EEgTlfxnz3y2qMmAw3e3zU9VEBje4nRdNbq9DOyZA1eLMMzmdYd6CGxQ9 QQRaDRZBFLmG7JYylso+efQRCCpcht5Ovkt9Obs36X8zCNHo6pRFgVvCPhRj8rQ/EiBV ddVLhZBj93WPioTEAaC5RJDoa3XxapwjhwG2p6STGKfJy+EJrTjuuqUAmGhFg1Oqe6v4 awa3FxXDb4doO4RLOq/8LZEG+A2woWPjj+IjNq4xesPFqteY8l+g2qG7qQWWIBW8O+N6 wMoQoa+VdbEMcfN/LPymkE5d8bbow99FRoiYYoMWqCIuCAXx0UybFIUQed+QL4uAzdLi sanw==
X-Gm-Message-State: ALoCoQnR0LLbXDgScwP+N4ikLjj11R1JKJbJHKLnNG/7A4LShRpD3T4/HA4SSAFbP8/BE+II4+gsVY8rbCyNYkqHKX6XgkJcXkRsduWPdl+6pGY3foWPozgDlHjvR/GW2nRP8NciJMsdcoz9uLBKkwdGuPEeTD6O2cZnQ92kV5S8LS9Sg4/KkHNdXCSKt/aDQpbnoLO1497s
X-Received: by 10.221.74.65 with SMTP id yv1mr7880844vcb.31.1395415652512; Fri, 21 Mar 2014 08:27:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Fri, 21 Mar 2014 08:27:12 -0700 (PDT)
In-Reply-To: <532BF536.2060505@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> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <532BF536.2060505@alvestrand.no>
From: Justin Uberti <juberti@google.com>
Date: Fri, 21 Mar 2014 08:27:12 -0700
Message-ID: <CAOJ7v-0fRyQ5aXp86P3b9K-PP+39Yc-TnD-GGVx25uoWJxOFhQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=001a113656384861ad04f51f862c
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kQgWLADowNKNBOFfS2-ms3_uz0A
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: Fri, 21 Mar 2014 15:27:45 -0000

On Fri, Mar 21, 2014 at 1:15 AM, Harald Alvestrand <harald@alvestrand.no>wrote;wrote:

>  On 03/20/2014 03:52 PM, Dan Wing 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]."
> ?
>
> Or even be more explicit on what's being proposed:
>
> "When a client gathers all IPv6 addresses on a host, and both temporary
> addresses [RFC4941] and permanent addresses of the same scope are present,
> the client SHOULD discard the permanent addresses before forming pairs.
> This is consistent with the default policy described in [RFC6724]."
>

The permanent addresses need to be discarded before sending them to the
remote side (which happens before pairing). I would simply say that the
permanent addresses should be ignored.

>
>
> Pulling back a little, I am starting to wonder if this is an ICE concern
> rather than an RTCWEB concern. The explosion in candidate pairs as more
> transport / network options come on line is a real operational problem, and
> needs to be solved for all ICE usages.
>
> I'll stick something in -transport, but RTCWEB is not the only thing that
> will have this problem.
>
>
>
>
>  -d
>
>
>
>
>  -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
>
>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>