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

[Roman Shpount <[e-mail]>]

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.

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
>>
>
>