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, 08 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 >
- [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-… Nils Ohlmeier
- Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-… Roman Shpount
- Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-… Nils Ohlmeier
- Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-… Justin Uberti
- Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-… Roman Shpount
- Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-… Justin Uberti