Re: [rtcweb] Transports: RFC 4941 support?

On 03/20/2014 03:52 PM, Dan Wing wrote:
>
> On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <harald@alvestrand.no
> <mailto: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
>>> <mailto: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]."

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
>>>> <mailto:dwing@cisco.com>> wrote:
>>>>
>>>>
>>>>     On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com
>>>>     <mailto: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 list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 
Surveillance is pervasive. Go Dark.