Subject: [Ice] ICE Premature: No Candidates From Peer

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2019 14:01:32 +0000

Hi,

Section 3.1 of draft-holmberg-ice-premature-00 says that it’s legal (we should change that to “allowed” or something…) to provide zero candidates of its own.

In non-trickle cases, is that really true? My understanding of 8445 is that an agent will at least provide a default candidate.

In trickle cases, the text is true as far as the initial ICE exchange is concerned. I don’t know if trickle mandates to actually provide any candidates at any point, but I assume that a trickle agent will at least provide a default candidate at some point – at least I did not find any text in trickle-ice overriding that rule.

So, unless I’m wrong in my assumptions above, my suggestion would be to scope the section to trickle, and clarify that it applies to the initial ICE exchange.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Mar 2019 13:27:50 -0500

Technically speaking we are updating RFC 8445 for exactly this reason.

In ice-sip-sdp, default candidate in c= and m= line can be IN IP4 0.0.0.0
with port 9, with no candidates listed. This is essentially an offer with
no candidates. This was added for trickle, but nothing prohibits doing this
when trickle is not used. There is a good use case for this, when client is
connecting from behind NAT to an end point with public address. This way,
no addresses will need to be collected on the client side when session
description is sent. When session description from the end point on public
address is received, connectivity check can be sent from the client behind
NAT without binding to a specific interface, which will allow this client
to use default route to connect to the server on public address. This
simplifies the client and has some privacy benefits when VPNs are used.

Also, default candidate can be a FQDN, which resolves to more then one
address, or an unsupported address family, so it can end up being ignored
and you will end up with no candidates at the start of ICE nomination.

Regards,
_____________
Roman Shpount

On Thu, Mar 7, 2019 at 9:01 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> Section 3.1 of draft-holmberg-ice-premature-00 says that it’s legal (we
> should change that to “allowed” or something…) to provide zero candidates
> of its own.
>
>
>
> In non-trickle cases, is that really true? My understanding of 8445 is
> that an agent will at least provide a default candidate.
>
>
>
> In trickle cases, the text is true as far as the initial ICE exchange is
> concerned. I don’t know if trickle mandates to actually provide any
> candidates at any point, but I assume that a trickle agent will at least
> provide a default candidate at some point – at least I did not find any
> text in trickle-ice overriding that rule.
>
>
>
> So, unless I’m wrong in my assumptions above, my suggestion would be to
> scope the section to trickle, and clarify that it applies to the initial
> ICE exchange.
>
>
>
> Regards,
>
>
>
> Christer
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2019 20:52:51 +0000

Hi,

> In ice-sip-sdp, default candidate in c= and m= line can be IN IP4 0.0.0.0 with port 9, with no candidates listed. This is essentially an offer with no candidates.
> This was added for trickle, but nothing prohibits doing this when trickle is not used. There is a good use case for this, when client is connecting from
> behind NAT to an end point with public address. This way, no addresses will need to be collected on the client side when session description is sent.
> When session description from the end point on public address is received, connectivity check can be sent from the client behind NAT without binding
> to a specific interface, which will allow this client to use default route to connect to the server on public address. This simplifies the client and has some
> privacy benefits when VPNs are used.

My understanding of RFC 8445 is that the default candidate is always provided. Trickle may override that.

We can check whether we need to change that in RFC 8445, but that is not the original reason we wrote the draft. The original reason was that one or more candidates are provided, but all of them are either discarded or fail.

> Also, default candidate can be a FQDN, which resolves to more then one address, or an unsupported address family, so it can end up
> being ignored and you will end up with no candidates at the start of ICE nomination.

As I’ve said in the mDNS discussion, the ICE procedures do not support candidates that resolve into multiple addresses. The procedures are written with the assumption that each candidate is associated with ONE address. And, if we want to change that, it’s a separate draft.

Regards,

Christer

On Thu, Mar 7, 2019 at 9:01 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

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

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Mar 2019 17:48:42 -0500

HI Christer,

On Thu, Mar 7, 2019 at 3:52 PM Christer Holmberg <
[email-masked]> wrote:

> > In ice-sip-sdp, default candidate in c= and m= line can be IN IP4
> 0.0.0.0 with port 9, with no candidates listed. This is essentially an
> offer with no candidates.
>
> > This was added for trickle, but nothing prohibits doing this when
> trickle is not used. There is a good use case for this, when client is
> connecting from
>
> > behind NAT to an end point with public address. This way, no addresses
> will need to be collected on the client side when session description is
> sent.
>
> > When session description from the end point on public address is
> received, connectivity check can be sent from the client behind NAT without
> binding
>
> > to a specific interface, which will allow this client to use default
> route to connect to the server on public address. This simplifies the
> client and has some
>

The initial candidate list is created based on rules defined in
ice-sip-sdp. Everything, including DNS resolution and pruning candidates
with dummy or unsupported addresses is defined there, not in RFC 8445. The
ice-sip-sdp draft also deals with default candidate. RFC 8445 does not care
about the default candidate, since it only needed for interop with non-ICE
endpoints. Based on rules defined in ice-sip-sdp, the initial list of
candidates is created and then processed based on rules defined in RFC
8445. What we figured out is that initial candidate list produced based on
ice-sip-sdp rules from the remote session description can be empty, but ICE
nomination process must still continue and wait for STUN connectivity
checks that can produce peer reflexive candidates. This is why ICE
premature draft is written and RFC 8445 is updated.

> We can check whether we need to change that in RFC 8445, but that is not
> the original reason we wrote the draft. The original reason was that one or
> more candidates are provided, but all of them are either discarded or fail.
>
>
>
> address, or an unsupported address family, so it can end up
>
> As I’ve said in the mDNS discussion, the ICE procedures do not support
> candidates that resolve into multiple addresses. The procedures are written
> with the assumption that each candidate is associated with ONE address.
> And, if we want to change that, it’s a separate draft.
>
>
>
We are not changing this. What I am saying that if FQDN in ICE candidate
cannot be resolved or resolves to more then one address, then it is
discarded. It is possible to have such FQDN in the c= line (default
candidate), which result in session description with ICE candidate in the
list and default candidate in the c=/m= line which produces an empty remote
candidate list in the beginning of ICE nomination.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 7 Mar 2019 15:31:29 -0800

> premature draft is written and RFC 8445 is updated.

Agree with Roman. I didn't see any normative language in 8445 that requires
> 0 candidates. It might be worthwhile to update ice-sip-sdp to explicitly
allow this; we could also adjust the 3.1 text to mention trickle. These
examples are not normative, just informative, so we don't need to be
super-precise here.

Trickle, however, is quite clear on this:

      Full Trickle:  The typical mode of operation for Trickle ICE agents,
      in which the initial ICE description can include any number of
      candidates *(even zero candidates)* and does not need to include a
      full generation of candidates as in half trickle.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Mar 2019 15:25:05 +0000

Hi,

...

>> < Roman's comment>
> Agree with Roman. I didn't see any normative language in 8445 that requires 0 candidates. 

I guess you are right. The 8445 text only talks about picking a default candidate, but not when/if it is exchanged.

...

>      candidates (even zero candidates) and does not need to include a

Good.

Regards,

Christer