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

[Justin Uberti <[e-mail]>]

On Mon, Jul 8, 2019 at 6:01 PM Roman Shpount <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>