Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03

Justin Uberti <juberti@google.com> Tue, 09 July 2019 02:10 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1055F120305 for <rtcweb@ietfa.amsl.com>; Mon, 8 Jul 2019 19:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.204
X-Spam-Level:
X-Spam-Status: No, score=-16.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Jzk555ugDCXR for <rtcweb@ietfa.amsl.com>; Mon, 8 Jul 2019 19:10:11 -0700 (PDT)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553AA120395 for <rtcweb@ietf.org>; Mon, 8 Jul 2019 19:10:11 -0700 (PDT)
Received: by mail-vk1-xa36.google.com with SMTP id u64so2888684vku.8 for <rtcweb@ietf.org>; Mon, 08 Jul 2019 19:10:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fneUdbjYTpzrusgWILz0TGZAHoYYx3x4FR8N9VlnMv0=; b=VqgYjBg9oawZ7Cnawu+GfIyooZ5+SgWAO4WOSXCQpQ5S+GRghnREVRJ7rHLDinoi6x nK4NupaeXk3cC1Lg8SZeD8yacl1SggVlcF9/vQz7fpQIXgPNLN9FnTwYnjgssd3C7En6 BWCCgtUhavB0xekAM0PBSOkcTsVJNcNnD2ODCZAn7sXDif/FvQ8XqNvOHErP54m40ygQ 0hQ1nUKzhO+eqUfidM0s6Mmh3a4wYOHuLBArufNBCFNDoy2dETULB1Jwxz9lA226w3Gp aZRgx2/wO8z+WgE1B/p3KufXVdUlvRh4a3IVCApy5LvdpHmE9voboyikE11gVlQzqeTi 4iKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fneUdbjYTpzrusgWILz0TGZAHoYYx3x4FR8N9VlnMv0=; b=no8yu04wkUz00RR/NE2DsOFmDqGMRVq9ip9/sx8tNtWVh0B4oz1iAu6DaQNxCKlZgG mCRpabdbUPsJ9p8DmN8+k5H1Hv0ayzp5rGRYREWhznkgzoX1abXMu39YcNJA3mBUiy2w PKYJm4kPlE7fcTaTC8+SwicwMV+ttcfAHQjHBfEOh5O/ULkQYOSrHtW8xkDQuNiwCfeV 69MYTd2i4AJuRkN4uqbDDN5EAMN04V4LnNG7HPHaxjoeAAq5kwuQj0a3EYBW8BkUfXyD 5mVg/r+BK5fr81liEy4BVjzrw5qv9iah/nCPbxw6R4GYEAB4w9UaAvJOjwWgfDSmJ9xg Wt8g==
X-Gm-Message-State: APjAAAVBYPuI/mnroqh4rN05VjVCQbxyf8tITvWRg1pQQMJ9pqKzvAha hTddWU802mua02PUcipENbGsq9y6StezZ5M+HYLJAA==
X-Google-Smtp-Source: APXvYqzk7ny51k16r+WJUmJzSWaeqUAsfRf+j8L307DZPeU/iiyjhbi1WI6Ly6pyL21FyPMinpL/zeUAPsceO8uXdns=
X-Received: by 2002:a1f:9b83:: with SMTP id d125mr7115489vke.76.1562638209846; Mon, 08 Jul 2019 19:10:09 -0700 (PDT)
MIME-Version: 1.0
References: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> <CAD5OKxuCj8cbU5X+9xb5_xDC4VR6qYSuvwwNoKvSYxJHxeeN0g@mail.gmail.com> <C4EF9E8D-6A7A-40DF-82ED-0E4CB1D028EC@mozilla.com> <CAD5OKxvYiz15QSibbBj7sLnvnnt7G3Nx4cFtwZjd1GwBuzC9Eg@mail.gmail.com>
In-Reply-To: <CAD5OKxvYiz15QSibbBj7sLnvnnt7G3Nx4cFtwZjd1GwBuzC9Eg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Mon, 8 Jul 2019 19:09:58 -0700
Message-ID: <CAOJ7v-0Mt9ZB+YKu9fK3g=3Hr-qK-QRZCkM12uOoG8s2pe5XRQ@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000698a4d058d360fa5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/ii0gKx_9aKH8qRnDc24YeaBMWuA>
Subject: Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 09 Jul 2019 02:10:15 -0000

On Mon, Jul 8, 2019 at 6:01 PM Roman Shpount <roman@telurix.com> wrote:

> Hi Nils,
>
> Using FQDN was not my decision and it is certainly not uncontroversial. As
> I have mentioned, I see two possible options for address in c= line:
>
> 1. Same FQDN as in default ICE candidate
> 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9"
>
> The main argument for option 1, is that it should be compatible with
> legacy implementations based on RFC 4566/RFC 5245. There is a question of
> Verifying ICE Support (https://tools.ietf.org/html/rfc5245#section-5.1).
> It is unclear what matching default candidate to a=candidate supposed to
> mean when FQDN is used, but using the same literal value seemed like a
> safer option.
>
> The main argument against option 1 is that no one implemented or tested
> FQDN in a=candidate before chrome implemented mDNS candidates, so default
> candidate selection and verifying ICE support was not tested either. I did
> see multiple implementations using FQDN in c= line. There are multiple use
> cases for this which existed outside of ICE and mDNS.
>
> The main argument for option 2 is that end points that implemented trickle
> ICE support, would likely support  "0.0.0.0"/"::" and port value of "9" in
> "c="/"m=" lines. This option is documented in JSEP as well, so it seems
> safer for the WebRTC compatible end points..
>
> The main argument against option 2 is that legacy endpoints which are not
> WebRTC compatible will have no reason to support   "0.0.0.0"/"::" and port
> value of "9"   in "c="/"m=" lines.
>
> This being said, FQDN in a=candidate is a breaking change either way,
> since nobody tested for this before mDNS. If legacy implementations do work
> with it, it is mostly by accident.
>
> I do not see how FQDN in a=candidate can be rolled out without causing
> some breakage.
>
> Finally, using FQDN in a=candidate was always broken/under-specified in
> RFC 5245. The following things in RFC 5245 are missing or broken:
>
> 1. ICE Support Verification procedures -- was fixed in ice-sip-sdp by
> stating that FQDN on c= line must never cause the ICE verification failure
>
> 2. Default candidate selection procedures -- no guidance was provided what
> address value, address family and type should be specified in the "c="
> line. mDNS draft specifies using FQDN literal value and always using IN IP4
> regardless of the actual address used for FQDN. As we know this is causing
> breakage with Firefox and can potentially cause breakage with legacy
> implementations which implemented FQDN candidate support based on RFC 5245
> (unclear if such implementations exist).
>
> 3. Candidate FQDN assignment procedures, i.e. do not assign FQDN which
> resolves to more then one address
>
> 4. Candidate FQDN resolution procedures in RFC 5245 are broken. Two end
> points can end up with different addresses if FQDN resolves to multiple
> addresses or if DNS64, 464XLAT or some other DNS based NAT firewall is
> present for one of the end points.
>
> I think, resolution problem is not fixable unless additional information
> about address family and type is added to a=candidate line which uses
> FQDN.. This will make a=candidate line orivude the same information as c=
> line, ending up with something like:
>
> a=candidate:2 1 udp 2129033471 alice.comany.biz 60460 typ host addrype
> inipv4
> a=candidate:1 1 udp 2129289471 alice.comany.biz 60454 typ host
> addrype inipv6
>
>
> If anybody interested I can describe the problem and solution in more
> details.
>

I would like to understand this issue better as it relates to mDNS. It's
not clear to me that mDNS suffers from this problem. But let's discuss that
in a separate email thread or in the mdns-candidates issue tracker, and
keep this thread focused on the c= line issues.

>
> Best Regards,
> _____________
> Roman Shpount
>
>
> On Mon, Jul 8, 2019 at 7:55 PM Nils Ohlmeier <nohlmeier@mozilla.com>
> wrote:
>
>> Hi Roman,
>>
>> I know that not being able to handle FQDN in c-lines is a bug on the
>> Firefox side.
>> And we are working on it to fix it:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1544770
>>
>> But my main question is: why does the draft right now recommend to use
>> the mDNS FQDN in the c-line, rather then a fake IPv4/IPv6 address?
>> I fail to see the advantage of using the FQDN and it appears to cause
>> more interop issues.
>>
>> Best
>>   Nils Ohlmeier
>>
>> On 4Jul, 2019, at 12:26, Roman Shpount <roman@telurix.com> wrote:
>>
>> Nils,
>>
>> When writing ice-sip-sdp we have considered two possible options when
>> using FQDN in ICE candidate lines:
>>
>> 1. Same FQDN as in default ICE candidate
>> 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9"
>>
>> To deal with both, ice-sip-sdp specifies, that when verifying ICE
>> support, both options should be accepted.
>>
>> Since RFC 5245 provided no guidance regarding handling FQDN in default
>> candidate, both options would likely cause ICE support verification
>> failures. Using FQDN in default candidate also raised the question of
>> address family and address type in c= line since neither is specified in
>> the ICE candidate.
>>
>> This being said, FQDN in c= line is allowed by RFC 4566:
>>
>> connection-field =    [%x63 "=" nettype SP addrtype SP
>>                          connection-address CRLF]
>>                          ;a connection field must be present
>>                          ;in every media description or at the
>>                          ;session-level
>>
>> ; sub-rules of 'c='
>> connection-address =  multicast-address / unicast-address
>> unicast-address =     IP4-address / IP6-address / FQDN / extn-addr
>>
>> Not being able to handle FQDN in the c= line is technically a bug.
>>
>> Best Regards,
>> _____________
>> Roman Shpount
>>
>>
>> On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier <nohlmeier@mozilla.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I have concerns regarding the current recommendations in
>>> draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP
>>> addresses in the “c=“ lines.
>>>
>>> Section 3.1.2.3 recommends to use mDNS for the connection-address. I
>>> think we should reconsider this advice as some SPD parsers handle parsing
>>> failures differently depending on line type.
>>> In case of Firefox a parsing failure for the connection line is treated
>>> as terminal failure. Where parsing failures for a= lines are expected, as
>>> these might contain unknown new features.
>>>
>>> Section 4.3 mentions that hostnames in ICE candidates can result in ICE
>>> failures, but it does not cover backward compatibility in regards to the c=
>>> line.
>>>
>>> My recommendation is to change the draft so that it recommends to always
>>> use a fixed value, for example IP6 ::1 in all c= lines, if mDNS is in use.
>>> Obviously it could also be recommended to use an IP4 address instead. The
>>> important point is only to use the same IP consistently in all c= lines and
>>> across all instances.
>>> I think the advantage of this is better backwards compatibility, and it
>>> will not reveal any more details about the user agent compared to using
>>> mDNS names in c= lines.
>>>
>>> Best regards
>>>   Nils Ohlmeier
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>