Subject: [Ice] Clarification on RFC 6724 text citation

From: Justin Uberti <[email-masked]>
Date: Wed, 18 Jul 2018 07:39:48 -0700

The latest version of ice-sip-sdp contains the highlighted text below. I'm
probably missing something that was previously discussed, but I couldn't
figure out what the "candidate pair" refers to.

It sounds like the client should use RFC6724 to select the best IPv6
address on a per-local-candidate basis, e.g., a different remote address
might be selected for a host candidate versus a relay candidate. Is that
what was intended?

> 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 record.  The rules from section 6 of
> [RFC6724] is followed by fixing the source address to be one from
> the candidate pair to be matched against destination addresses
> reported by FQDN, in cases where the DNS query returns more than
> one IP address.

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 23 Jul 2018 10:57:06 -0700

I wasn't involved in writing that text, and it's in the MMUSIC WG, not the
ICE WG, but it does seem like the intention changed to what you are saying.

In 5245 that text was "If the DNS query returns more than one IP address,
one is chosen, and then used for the remainder of ICE processing."  And the
text before it (in both 5245 and ice-sip-sdp) says "when receiving an offer
or answer".  So it's clear that the 5245 intention was to make one decision
for a remote candidate and then apply that same one for all candidate pairs
with that remote candidate.

But this text removes "for the remainder of ICE processing" and treats 6724
section 6 as a function that takes two arguments: the remote (destination)
addresses *and *the local (source) address.  Clearly doing so could end up
with different choices depending on the local (source) IP address.  So it
seems intentional to allow each candidate pair to have a different IP
address even though they share the same remote candidate FQDN.

I find the new text confusing and think it would be more clear as something
like "If the DNS query returns more than one IP address, followt the rules
in section 6 of [RFC6274] for each local candidate by using the address of
the local candidate as the source address and the addresses from the result
of the DNS query as the list of destination addresses.  This may result in
different candidate pairs having different remote addresses even though
they share the same remote candidate".

If all of this is true and this change was intentional and the rules are
meant to be run for each local candidate, then I think trickle would need
to specify that such rules need to be applied whenever a new local
candidate is gathered, which means an implementation would need to remember
the entire list of destination addresses until ICE processing is complete.

On Wed, Jul 18, 2018 at 7:40 AM Justin Uberti <juberti=
[email-masked]> wrote:

> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jul 2018 07:20:56 +0000

Hi,

A candidate is per definition associated with an IP address, so it sounds confusing to me how a DNS query for a FQDN associated with that candidate would return multiple addresses.

Wouldn’t that mean that the FQDN represents multiple candidates (one for each returned IP address)?

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: 23 July 2018 20:57
To: Justin Uberti <juberti=[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Clarification on RFC 6724 text citation

I wasn't involved in writing that text, and it's in the MMUSIC WG, not the ICE WG, but it does seem like the intention changed to what you are saying.

In 5245 that text was "If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing."  And the text before it (in both 5245 and ice-sip-sdp) says "when receiving an offer or answer".  So it's clear that the 5245 intention was to make one decision for a remote candidate and then apply that same one for all candidate pairs with that remote candidate.

But this text removes "for the remainder of ICE processing" and treats 6724 section 6 as a function that takes two arguments: the remote (destination) addresses and the local (source) address.  Clearly doing so could end up with different choices depending on the local (source) IP address.  So it seems intentional to allow each candidate pair to have a different IP address even though they share the same remote candidate FQDN.

I find the new text confusing and think it would be more clear as something like "If the DNS query returns more than one IP address, followt the rules in section 6 of [RFC6274] for each local candidate by using the address of the local candidate as the source address and the addresses from the result of the DNS query as the list of destination addresses.  This may result in different candidate pairs having different remote addresses even though they share the same remote candidate".

If all of this is true and this change was intentional and the rules are meant to be run for each local candidate, then I think trickle would need to specify that such rules need to be applied whenever a new local candidate is gathered, which means an implementation would need to remember the entire list of destination addresses until ICE processing is complete.

On Wed, Jul 18, 2018 at 7:40 AM Justin Uberti <juberti=[email-masked]<mailto:[email-masked]>> wrote:
The latest version of ice-sip-sdp contains the highlighted text below. I'm probably missing something that was previously discussed, but I couldn't figure out what the "candidate pair" refers to.

It sounds like the client should use RFC6724 to select the best IPv6 address on a per-local-candidate basis, e.g., a different remote address might be selected for a host candidate versus a relay candidate. Is that what was intended?

An IP
[email-masked]<mailto:[email-masked]>

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 24 Jul 2018 13:43:38 -0700

It depends on if you're talking about the signaled candidate or the remote
candidate used in the candidate pair.  The signaled candidate can be a
FQDN, so it can have multiple IPs.  But a candidate pair can only have one
IP on its remote end.  So we need a mapping from one to the other.  The old
mapping was "pick one with unspecified behavior when you receive the
signaling and use it for all candidate pairs".  The new mapping seems to be
"pick one when doing candidate pairing using section 6 of RFC 6724 and each
candidate pair may choose a different one".

On Tue, Jul 24, 2018 at 12:21 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> A candidate is per definition associated with an IP address, so it sounds
> confusing to me how a DNS query for a FQDN associated with that candidate
> would return multiple addresses.
>
>
>
> *From:* Ice [mailto:[email-masked]] *On Behalf Of *Peter Thatcher
> *Sent:* 23 July 2018 20:57
> *To:* Justin Uberti <juberti=[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Ice] Clarification on RFC 6724 text citation
>
>
>
> text before it (in both 5245 and ice-sip-sdp) says "when receiving an
> offer or answer".  So it's clear that the 5245 intention was to make one
> decision for a remote candidate and then apply that same one for all
> candidate pairs with that remote candidate.
>
>
>
> But this text removes "for the remainder of ICE processing" and treats
> 6724 section 6 as a function that takes two arguments: the remote
> (destination) addresses *and *the local (source) address.  Clearly doing
> so could end up with different choices depending on the local (source) IP
> address.  So it seems intentional to allow each candidate pair to have a
> different IP address even though they share the same remote candidate FQDN.
>
>
>
> I find the new text confusing and think it would be more clear as
> something like "If the DNS query returns more than one IP address,
> followt the rules in section 6 of [RFC6274] for each local candidate by
> using the address of the local candidate as the source address and the
> addresses from the result of the DNS query as the list of destination
> addresses.  This may result in different candidate pairs having different
> remote addresses even though they share the same remote candidate".
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jul 2018 22:11:44 +0000

Hi,

>It depends on if you're talking about the signaled candidate or the remote candidate used in the candidate pair.  The signaled candidate can be a FQDN, so it >can have multiple IPs.  But a candidate pair can only have one IP on its remote end.

In my opinion a candidate always have ONE IP addresses associated. I see no difference about a signalled candidate or a remote candidate used in a candidate pair – it’s the same candidate.

I do understand why one wants to use a FQDN in signalling – but it is still representing that one candidate, with that one associated IP address.

(Note that I am aware that this issue already exists in the MMUSIC draft, so it was not introduced by the mDNS proposal.)

> So we need a mapping from one to the other.  The old mapping was "pick one with unspecified behavior when you
> receive the signaling and use it for all candidate pairs".  The new mapping seems to be "pick one when doing candidate
> pairing using section 6 of RFC 6724 and each candidate pair may choose a different one".

If you get multiple addresses, and picks one (no matter what policy you use for picking), there is no guarantee that the address you pick is the address used be the remote peer for the candidate. Maybe the remote peer doesn’t listen to that IP address.

Or, as you saying that the peer signalling a candidate using a FQDN must create local candidates for *each* IP address that the FQND can resolve to?

Regards,

Christer

On Tue, Jul 24, 2018 at 12:21 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Ice [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Peter Thatcher
Sent: 23 July 2018 20:57
To: Justin Uberti <juberti=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] Clarification on RFC 6724 text citation

An IP

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 24 Jul 2018 15:35:58 -0700

On Tue, Jul 24, 2018 at 3:11 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> >It depends on if you're talking about the signaled candidate or the
> remote candidate used in the candidate pair.  The signaled candidate can be
> a FQDN, so it >can have multiple IPs.  But a candidate pair can only have
> one IP on its remote end.
>
>
>
> In my opinion a candidate always have ONE IP addresses associated. I see
> no difference about a signalled candidate or a remote candidate used in a
> candidate pair – it’s the same candidate.
>
>
>
> I do understand why one wants to use a FQDN in signalling – but it is
> still representing that one candidate, with that one associated IP address.
>

A FQDN has more than on IP associated with it, so you have to pick one.  We
can debate what a "candidate" means, but it doesn't really matter.  What
matters is that when a FQDN is signaled, the agent has to pick an IP
address.  And the spec for  when the picking is done and how it is done
seems to have changed.

>
>
> (Note that I am aware that this issue already exists in the MMUSIC draft,
> so it was not introduced by the mDNS proposal.)
>
>
>
> > receive the signaling and use it for all candidate pairs".  The new
> mapping seems to be "pick one when doing candidate
>
> If you get multiple addresses, and picks one (no matter what policy you
> use for picking), there is no guarantee that the address you pick is the
> address used be the remote peer for the candidate. Maybe the remote peer
> doesn’t listen to that IP address.
>

If a host advertises/signals a FQDN, why would it not listen to each IP
that FQDN resolves to?  If you stick an IP in a DNS entry and don't listen
to that IP, you're broken.  Don't do that.

>
>
> Or, as you saying that the peer signalling a candidate using a FQDN must
> create local candidates for **each** IP address that the FQDN can resolve
> to?
>

If you don't want to listen to more than one IP, don't make the FQDN
resolve to more than one.  If you do want to resolve the FQDN to more than
one IP, listen to each IP.  Seems pretty straightforward.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jul 2018 14:37:18 +0000

Hi,
 
>>> It depends on if you're talking about the signaled candidate or the remote candidate used in the candidate pair.  
>>> The signaled candidate can be a FQDN, so it >can have multiple IPs.  But a candidate pair can only have one IP 
>>> on its remote end. 
>> 
>> In my opinion a candidate always have ONE IP addresses associated. I see no difference about a signalled candidate 
>> or a remote candidate used in a candidate pair – it’s the same candidate.
>>
> A FQDN has more than on IP associated with it, so you have to pick one.  We can debate what a "candidate" means, but 
> it doesn't really matter.  What matters is that when a FQDN is signaled, the agent has to pick an IP address.  And the spec for  
> when the picking is done and how it is done seems to have changed.
 
I think it DOES matter if we now assume that a candidate can be associated with multiple IP addresses. I don't think any of the ICE processing procedures support that.
 
Also, as became clear in Montreal, I don't think we have ever really looked into usage of FQNDs in detail, so just because there is a sentence is the spec mentioning FQDN it doesn't mean it actually works - or, at least it is not fully specified how it works.

>> If you get multiple addresses, and picks one (no matter what policy you use for picking), there is no guarantee that the 
>> address you pick is the address used be the remote peer for the candidate. Maybe the remote peer doesn’t listen to 
>> that IP address.
>
> If a host advertises/signals a FQDN, why would it not listen to each IP that FQDN resolves to? 

Because there is no concept of a candidate being associated with multiple IP addresses. By definition, a candidate has one transport address (IP address, port and transport).

> If you stick an IP in a DNS entry and don't listen to that IP, you're broken.  Don't do that.  

It is more than just listening.

For example, while gathering candidates, are you going to split the "multi-address" into different individual candidates, with different foundations etc? What if some of them get pruned, or removed for other reasons?

And, once the check lists is done, is the host also supposed to send connectivity checks from each of the addresses? Are you going to maintain the IP addresses throughout the session? Etc etc etc.

Perhaps it's possible to solve all that, and perhaps it's an easy task to do. But, it is currently not described, and I think it takes more work than just saying that the receiver of an FQDN shall "pick one of the resolved addresses" in order to describe it.

>> Or, as you saying that the peer signalling a candidate using a FQDN must create local candidates for *each* IP address that the FQDN can resolve to?
>>
> If you don't want to listen to more than one IP, don't make the FQDN resolve to more than one.  If you do want to resolve the FQDN to more than 

As commented above, I think that supporting "multi-address candidates" requires more than that. 
 
Again, I am saying it doesn't work, I am just saying that such candidates have more impacts on the ICE procedures that need to be described.

Regards,

Christer

On Tue, Jul 24, 2018 at 12:21 AM Christer Holmberg <[email-masked]> wrote:
Hi,

 
Regards,
 
Christer

 

 

 
 
On Wed, Jul 18, 2018 at 7:40 AM Justin Uberti <juberti=[email-masked]> wrote:
The latest version of ice-sip-sdp contains the highlighted text below. I'm probably missing something that was previously discussed, but I couldn't figure out what the "candidate pair" refers to.

An IP