Subject: Re: [MMUSIC] [rtcweb] What goes into c= line address when FQDN is used for the default candidate?

From: Roman Shpount <[email-masked]>
Date: Fri, 1 Feb 2019 12:09:05 -0500

Hi Justin,

I agree regarding #1 in theory, even though in practice a lot of (most)
devices will not accept FQDN in either c= or ICE candidate.

Regarding #2, mmusic-ice-sip-sdp was updated (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1):

   <connection-address>:  is taken from RFC 4566
<https://tools.ietf.org/html/rfc4566> [RFC4566
<https://tools.ietf.org/html/rfc4566>].  It is the
      IP address of the candidate.  When parsing this field, an agent
      can differentiate an IPv4 address and an IPv6 address by presence
      of a colon in its value -- the presence of a colon indicates IPv6.
      An agent MUST ignore candidate lines that include candidates with
      IP address versions that are not supported or recognized.

Specifically, support for FQDN names there was removed due to RFC 8445
implementation issues. I believe Simon Perreault suggested this change.

Regards,
_____________
Roman Shpount

On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti <[email-masked]> wrote:

> My recommendation here would be that we do c=IN IP6
> 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6
> depending on which type of address is being wrapped.
>
> Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN
> in the c= line.
>
>      unicast-address =     IP4-address / IP6-address / FQDN / extn-addr
>
>
> Re #2: Quoth 5245 <https://tools.ietf.org/html/rfc5245#section-15.1>:
>
>    <connection-address>:  is taken from RFC 4566 <https://tools.ietf.org/html/rfc4566> [RFC4566 <https://tools.ietf.org/html/rfc4566>].  It is the
>       IP address of the candidate, allowing for IPv4 addresses, IPv6
>       addresses, and *fully qualified domain names (FQDNs).*  When parsing
>       this field, an agent can differentiate an IPv4 address and an IPv6
>
>       address by presence of a colon in its value - the presence of a
>       colon indicates IPv6.  An agent MUST ignore candidate lines that
>       include candidates with IP address versions that are not supported
>       or recognized.  An IP address SHOULD be used, but an FQDN MAY be
>       used in place of an IP address.  In that case, when receiving an
>       offer or answer containing an FQDN in an a=candidate attribute,
>       the FQDN is looked up in the DNS first using an AAAA record
>       (assuming the agent supports IPv6), and if no result is found or
>       the agent only supports IPv4, using an A.  If the DNS query
>       returns more than one IP address, one is chosen, and then used for
>       the remainder of ICE processing.
>
>
>
>
>
>
>
>
>
> On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount <[email-masked]> wrote:
>
>> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti <[email-masked]>
>> wrote:
>>
>>> We can however all agree that "c=IN IP6" is busted:
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=927309
>>>
>>>>
>>>>>
>> I guess one way to interpret this that each address should have a MDNS
>> alias. So, if you are dealing with dual stack host, it should provide two
>> MDNS candidates, one of which is IPv4 and another IPv6. The c= line should
>> specify FQDN for one of those candidates and specify the type (IP4 or IP6).
>>
>> There are two problems:
>>
>> 1. There is no way to know which address type is in the candidate-address
>> when FQDN is used there. Guidance in ice-sip-sdp is talking about the
>> presence of column in IP6 address, but this definitely does not apply to
>> FQDN. It would've been better to specify something like local4 and local6
>> as FQDN suffix in MDNS alias to specify the candidate-address type so that
>> correct DNS request can be issued.
>>
>> 2. A lot (if not most) SDP/ICE implementations do no support parsing FQDN
>> in candidate-address or c= line. This might create interop problems since
>> RFC 5245 specified that candidate-address is an IP Address.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>>
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 1 Feb 2019 09:39:12 -0800

I understand there were questions about the general case (e.g. regular DNS
names), but how do we plan to reconcile this removal with the need for mDNS
hostnames?

On Fri, Feb 1, 2019 at 9:09 AM Roman Shpount <[email-masked]> wrote:

>>> 1. There is no way to know which address type is in the
>>> candidate-address when FQDN is used there. Guidance in ice-sip-sdp is
>>> talking about the presence of column in IP6 address, but this definitely
>>> does not apply to FQDN. It would've been better to specify something like
>>> local4 and local6 as FQDN suffix in MDNS alias to specify the
>>> candidate-address type so that correct DNS request can be issued.
>>>
>>> 2. A lot (if not most) SDP/ICE implementations do no support parsing
>>> FQDN in candidate-address or c= line. This might create interop problems
>>> since RFC 5245 specified that candidate-address is an IP Address.
>>>
>>> Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>
>>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 1 Feb 2019 14:18:01 -0500

Most likely mDNS draft will need to update RFC 8445 to specify how ICE
nomination procedures are modified, when mDNS is used as candidate-address.

As far as mmusic-ice-sip-sdp is concerned, one option would be to allow
FQDN as candidate-address. The guidance for handling FQDN in
candidate-address should be updated from RFC 5245 and should specify that
FQDN names should be ignored. mDNS ICE draft then will update ice-sip-sdp
and specify that mDNS FQDN should be handled according the procedures of
this draft.

Another option, which I think word work better with existing specifications
is to add a new candidate type -- mdns. This way, instead of magic DNS
suffix, candidate type will be used to determine that this candidate should
be handled differently. I do not think MDNS candidates can be used for
anything except host candidates, so making then a special candidate type
might be the least painful option. It might even make sense to make
separate types for IPv4 and IPv6 MDNS candidates which would save a DNS
query for each candidate.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 1 Feb 2019 11:39:00 -0800

This has all been discussed at length in rtcweb and I don't think any
significant changes are needed, although I tend to think that we should
restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only
thing not in alignment at this point in time.

On Fri, Feb 1, 2019 at 11:18 AM Roman Shpount <[email-masked]> wrote:

> Another option, which I think word work better with existing
> specifications is to add a new candidate type -- mdns. This way, instead of
> magic DNS suffix, candidate type will be used to determine that this
> candidate should be handled differently. I do not think MDNS candidates can
> be used for anything except host candidates, so making then a special
> candidate type might be the least painful option. It might even make sense
> to make separate types for IPv4 and IPv6 MDNS candidates which would save a
> DNS query for each candidate.
>
> Regards,
> _____________
> Roman Shpount
>
>
>> I understand there were questions about the general case (e.g. regular
>> DNS names), but how do we plan to reconcile this removal with the need for
>> mDNS hostnames?
>>
>>>> Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for
>>>> FQDN in the c= line.
>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Feb 2019 19:58:35 +0000

Hi,

> Most likely mDNS draft will need to update RFC
> 8445 to specify how ICE nomination procedures are
> modified, when mDNS is used as candidate-
> address.

What part of 8445 would need to be updated?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 1 Feb 2019 15:09:05 -0500

> What part of 8445 would need to be updated?
Currently RFC 8445 specifies that candidates are only IP addresses and not an
FQDN:

   2.1.  Gathering Candidates

   In order to execute ICE, an ICE agent identifies and gathers one or
   more address candidates.  A candidate has a transport address -- a
   combination of IP address and port for a particular transport
   protocol (with only UDP specified here).  There are different types
   of candidates; some are derived from physical or logical network
   interfaces, and others are discoverable via STUN and TURN.

In case of mDNS, candidate is a FQDN name. So when gathering candidates,
DNS query will need to be performed and its result added to the candidate
list. Also, I am not 100% sure, but I think mDNS can resolve to either
IPv4/IPv6 or both addresses. So, single mDNS candidate can result in two
actual ICE candidates. All of this looks like RFC 8445 update.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 1 Feb 2019 15:22:15 -0500

> thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definition,
but  the portion which talks about handling it is completely broken.

Quoting 5245 <https://tools.ietf.org/html/rfc5245#section-15.1>:

I think it was discussed in quite a detail why using a random DNS
resolution result is not going to work here.

The only options we have here are:

a. Fix FQDN connection address handling. Probably the most logical way of
dealing with this would be to specify that candidate with FQDN should be
converted as a result of DNS resolution into multiple candidates, with each
candidate corresponding to A or AAAA record in DNS query result. We will
also need to specify how FQDN candidate gets applied to c= line address.
Something that says IN IP4 FQDN, if any A records exist for this DNS name
and IN IP6 FQDN if only AAAA records exist. Once candidate is nominated,
address family in c= line should match address family used for
communications. This will definitely require a lot more work and discussion.

b. Specify that FQDN connection addresses should be ignored until their
handling is defined in a future specification. This seems easy and only
requires a sentence or two to fix.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Feb 2019 20:27:28 +0000

Hi,

>>> 8445 to specify how ICE nomination procedures >>> are modified, when mDNS is used as candidate-
>>> address.
>>
> Currently RFC 8445 specifies that candidates are
> only IP addresses and not an FQDN:
>
>   In order to execute ICE, an ICE agent identifies and
>   gathers one or more address candidates.  A
>   candidate has a transport address -- a combination
>   of IP address and port for a particular transport
>   protocol (with only UDP specified here).  There are
>   different types of candidates; some are derived
>   from physical or logical network interfaces, and
>   others are discoverable via STUN and TURN.
>
> In case of mDNS, candidate is a FQDN name. So
> when gathering candidates, DNS query will need to
> be performed and its result added to the candidate
> list.

The 8445 text does not talk about encoding of candidates on the wire. A candidate always has an IP address and port - and that is true no matter what you signal in the SDP on the wire.

> Also, I am not 100% sure, but I think mDNS can
> resolve to either IPv4/IPv6 or both addresses. So,
> single mDNS candidate can result in two actual ICE
> candidates. All of this looks like RFC 8445 update.

I raised this issue before, and I think the agreement was that, with ICE, mDNS would only result in ONE address (either IPv4 OR IPv6).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Feb 2019 21:02:14 +0000

Hi,

I have no problem with allowing FQDNs - as long as they result in a SINGLE address:port.

If we want to define ICE usage of FDNSs resulting in MULTIPLE addresses:ports, I really think that should be a separate document - it should NOT be added as a last minute thing to draft-ice-sip-sdp.

...and, yes, perhaps such work would also affect 8445.

Regards,

Christer

________________________________
From: rtcweb <[email-masked]> on behalf of Roman Shpount <[email-masked]>
Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?

On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
This has all been discussed at length in rtcweb and I don't think any significant changes are needed, although I tend to think that we should restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definition, but  the portion which talks about handling it is completely broken.

Quoting 5245<https://tools.ietf.org/html/rfc5245#section-15.1>:

   <connection-address>:  is taken from RFC 4566<https://tools.ietf.org/html/rfc4566> [RFC4566<https://tools.ietf.org/html/rfc4566>].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When parsing
      this field, an agent can differentiate an IPv4 address and an IPv6

I think it was discussed in quite a detail why using a random DNS resolution result is not going to work here..

a. Fix FQDN connection address handling. Probably the most logical way of dealing with this would be to specify that candidate with FQDN should be converted as a result of DNS resolution into multiple candidates, with each candidate corresponding to A or AAAA record in DNS query result. We will also need to specify how FQDN candidate gets applied to c= line address. Something that says IN IP4 FQDN, if any A records exist for this DNS name and IN IP6 FQDN if only AAAA records exist. Once candidate is nominated, address family in c= line should match address family used for communications. This will definitely require a lot more work and discussion.

b. Specify that FQDN connection addresses should be ignored until their handling is defined in a future specification. This seems easy and only requires a sentence or two to fix.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 1 Feb 2019 16:06:18 -0500

In this case section 4.1 of ice-sip-sdp should be updated to allow FQDN in
connection-address and, perhaps specify that FWDN which return multiple
results should be ignored.

Would this work for everyone?

Regards,
_____________
Roman Shpount

On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg <
[email-masked]> wrote:

> If we want to define ICE usage of FDNSs resulting in MULTIPLE
> addresses:ports, I really think that should be a separate document - it
> should NOT be added as a last minute thing to draft-ice-sip-sdp.
>
>
> ------------------------------
> *From:* rtcweb <[email-masked]> on behalf of Roman Shpount <
> [email-masked]>
> *Sent:* Friday, February 1, 2019 10:22 PM
> *To:* Justin Uberti
> *Cc:* Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
> *Subject:* Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN
> is used for the default candidate?
>
> resolution result is not going to work here..
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Feb 2019 21:16:55 +0000

Hi,

> results should be ignored.

I suggest MUST be ignored, perhaps with a note saying that a future specification will have to define how to use FQDNs that return multiple results.

> Would this work for everyone?

It would work for me.

Regards,

Christer

On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Christer

From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Roman Shpount <[email-masked]<mailto:[email-masked]>>

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 1 Feb 2019 15:27:56 -0800

That works for me as well - it then becomes a clarification of 5245, rather
than a removal of functionality.

On Fri, Feb 1, 2019 at 1:17 PM Christer Holmberg <
[email-masked]> wrote:

> I suggest MUST be ignored, perhaps with a note saying that a future
> specification will have to define how to use FQDNs that return multiple
> results.
>

---

From: Alan Ford <[email-masked]>
Date: Tue, 5 Feb 2019 15:03:41 +0000

If that update was to be made, this goes against the text in draft-ietf-rtcweb-mdns-ice-candidates-02 which says:

   An ICE agent that supports mDNS candidates MUST support the situation
   where the hostname resolution results in more than one IP address.
   In this case, the ICE agent MUST take exactly one of the resolved IP
   addresses and ignore the others.  The ICE agent SHOULD, if available,
   use the first IPv6 address resolved, otherwise the first IPv4
   address.

But there’s a bigger problem here, which is how to cope with an FQDN is not resolvable. So the intention, as I understand it, is that when these host candidates leave the mDNS domain and are thus not resolvable, they will be treated as peer reflexive candidates.

But at that point there is no address family information available, so how does an ICE agent know to do pairing with these candidates, which requires the address family to be known?

Regards,
Alan

> On 1 Feb 2019, at 21:06, Roman Shpount <[email-masked]> wrote:
> 
> In this case section 4.1 of ice-sip-sdp should be updated to allow FQDN in connection-address and, perhaps specify that FWDN which return multiple results should be ignored.
> 
> On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> From: rtcweb <[email-masked] <mailto:[email-masked]>> on behalf of Roman Shpount <[email-masked] <mailto:[email-masked]>>
> On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
> I agree that FQDN should be put back into connection-address definition, but  the portion which talks about handling it is completely broken..
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Tue, 5 Feb 2019 13:19:06 -0500

On Tue, Feb 5, 2019 at 10:03 AM Alan Ford <[email-masked]> wrote:

> If that update was to be made, this goes against the text
> in draft-ietf-rtcweb-mdns-ice-candidates-02 which says:
>

This is obviously not going to work. At the very minimum ICE client should
be listening for connectivity checks on all addresses to which FQDN
candidate resolves, including IPv4 and IPv6. It also should do connectivity
checks to all addresses. Otherwise, if you have two clients, one dual stack
and another single stack, they are not going to see each other, since one
will be listening and sending connectivity checks via IPv6 and another via
IPv4. This is why language about FQDN was removed from mmusic-ice-sip-sdp
-- it was broken.

For ICE to work, you want to include all possible addresses for FQDN in the
candidate list and then proceed with nomination as if they were independent
candidates.

But there’s a bigger problem here, which is how to cope with an FQDN is not
> resolvable. So the intention, as I understand it, is that when these host
> candidates leave the mDNS domain and are thus not resolvable, they will be
> treated as peer reflexive candidates.
>
> But at that point there is no address family information available, so how
> does an ICE agent know to do pairing with these candidates, which requires
> the address family to be known?
>

I do not think this is a problem. For peer reflexive candidates, ICE agent
knows address family/local address/port where connectivity check was
received and the address family/remote address/port from which the
connectivity check was received. Everything, including the address family
is known in this case and agent can proceed with nomination as with any
other peer reflexive candidate.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Feb 2019 19:52:48 +0000

Hi,

>use the first IPv6 address resolved, otherwise the first IPv4 address.

This is what I have previously commented. The text needs to be modified.

Regards,

Christer

On 1 Feb 2019, at 21:06, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
_____________
Roman Shpount

Regards,

Christer

Regards,
_____________
Roman Shpount
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Feb 2019 16:57:21 -0800

> For ICE to work, you want to include all possible addresses for FQDN in
> the candidate list and then proceed with nomination as if they were
> independent candidates.
>

I don't think this is correct behavior, but it's really beside the point
since we can ignore it if we have the one-FQDN-per-address concept we
discussed.

>
> But there’s a bigger problem here, which is how to cope with an FQDN is
>> not resolvable.. So the intention, as I understand it, is that when these
>> host candidates leave the mDNS domain and are thus not resolvable, they
>> will be treated as peer reflexive candidates.
>>
>> But at that point there is no address family information available, so
>> how does an ICE agent know to do pairing with these candidates, which
>> requires the address family to be known?
>>
>

Right - this is implemented today in Chrome and appears to be working well
so far (with a few minor bugs discovered along the way).

---

From: Roman Shpount <[email-masked]>
Date: Tue, 5 Feb 2019 20:03:38 -0500

On Tue, Feb 5, 2019 at 7:57 PM Justin Uberti <[email-masked]> wrote:

>> This is obviously not going to work. At the very minimum ICE client
>> should be listening for connectivity checks on all addresses to which FQDN

I am not sure why this is wrong, but I agree this is besides the point if
we agree on one-FQDN-per-address. If we agree on one-FQDN-per-address,
rtcweb-mdns-ice-candidates needs to be modified to match. Behavior
currently described there (each sides picks an address in random) is
definitely wrong.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Feb 2019 11:01:11 -0500

Hi All,

>From what I can see there is a new problem identified during mDNS
discussion with using FQDN: If all the candidates are FQDN and these names
do not resolve or resolve to more then one address, so all the candidates
will end up being ignored. ICE agent might end up with no remote candidates
and no candidate pairs to form. I think  RFC 8445 does not handle this
situation, but I might be missing something.

P.S. I am not arguing against FQDN, I am just trying to figure out what
needs to be done to get this documented and operational.
_____________
Roman Shpount

---

From: youenn fablet <[email-masked]>
Date: Thu, 7 Feb 2019 08:44:24 -0800

FWIW, Safari Tech Preview introduced last year an mDNS experiment
which is close to Chrome experiment.
This experiment is now on by default in Safari Tech Preview.

As of the case of no ICE candidate at all, this already happens in
Safari 12: by default, mode 3 is used.
As mentioned by Harald, peer reflexive candidates are already used in
some products to enable Safari connection with SFUs or Chrome
instances.

In some cases, implementations had to be updated to better cope with
this, in particular the case of a successful connection triggered by
peer reflexive candidates, leading to not expose server reflexive
candidates to the web site.
Providing guidance to implementors in that area might indeed be good.

Le jeu. 7 févr. 2019 à 08:01, Roman Shpount <[email-masked]> a écrit :
>
> Hi All,
>
> From what I can see there is a new problem identified during mDNS discussion with using FQDN: If all the candidates are FQDN and these names do not resolve or resolve to more then one address, so all the candidates will end up being ignored. ICE agent might end up with no remote candidates and no candidate pairs to form. I think  RFC 8445 does not handle this situation, but I might be missing something.
>
> P.S. I am not arguing against FQDN, I am just trying to figure out what needs to be done to get this documented and operational.
> _____________
> Roman Shpount
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb