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

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 3 Jul 2019 22:26:40 -0700

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

---

From: Roman Shpount <[email-masked]>
Date: Thu, 4 Jul 2019 15:26:55 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 8 Jul 2019 16:55:37 -0700

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 <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 <[email-masked]> wrote:
> 
> Nils,
> 
> When writing ice-sip-sdp we have considered two possible options when using FQDN in ICE candidate lines:
> 
> 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. 
> 
> On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
> Hello,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2019 17:08:43 -0700

The FQDN seemed like the most straightforward option, since nothing new
needed to be invented.

It's now apparent that that might have been overly optimistic, and we're
open to workarounds that are tolerated better and don't create issues of
their own.

On Mon, Jul 8, 2019 at 5:02 PM Nils Ohlmeier <[email-masked]> wrote:

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Jul 2019 21:00:58 -0400

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:

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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2019 19:09:58 -0700

On Mon, Jul 8, 2019 at 6:01 PM Roman Shpount <[email-masked]> wrote:

> 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.
>
> safer for the WebRTC compatible end points..
>
> 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:
>
> 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:
>

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.

>> 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?
>> To deal with both, ice-sip-sdp specifies, that when verifying ICE
>> support, both options should be accepted.
>>