Subject: [MMUSIC] Remaining ICE open issues

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 14:56:47 -0400

On the last ICE call, I indicated that I thought we were mostly done, 
but that I'd check for straggler open issues. Here is my list of whats 
closed and whats left, which we'll discuss on the call tomorrow. Please 
let me know if you see something that is an issue in your mind and not 
on either list:

Open
----

MacDonald-1: Determination of controlling endpoint: through O/A 
negotiation or heuristic?
Status: actively debating

MacDonald-2: where should we put text for ICE-for-gateways, and should 
we hold up ICE for it?
Status: actively debating

Issue #5: Removing a peer derived candidate. There is currently no way 
to do it.
Status: I suggested no one asked for this feature anyway, may as well 
leave it as is. No responses posted.

Issue #8: The need for connectivity preconditions when you are running 
ICE is far from clear.
Status: I put some text in -11 around this; saying they are only needed 
if you want the explicit signaling they provide. Need some feedback on 
whether this text is OK.

Issue #9 (never posted AFAICT - just in the slides). Question is that 
3pcc Flow III doesnt work with ICE-10.
Status: Whether it will work depends on the algorithm for selecting the 
controlling entity. This has to be something that survives reordering of 
m/c lines, which can happen in flow III.

Issue #10: ICE hammer. STUN checks themselves can cause lots of traffic 
on the network, and can be used to launch an attack. What to do about it?
Status: I posted some ideas on the list, no response.

Issue #11: ICE pacing. Should we allow ICE checks to go faster if codecs 
are at a faster rate?
Status: There was some discussion of this on the calls, no real 
conclusion. We did agreed to make the Ta interval configurable and that 
some research would ideally be needed to find a good value. But thats 
about it.

Issue #12: (never posted, in slides only). Question is whether to adjust 
the retransmit interval for STUN when used with ICE. Argument is that 
ICE transactions will often completely timeout
Status: My suggestion in the slides and in the related discussion on 
behave was to leave it alone

Issue #15: Obfuscation of candidate lines to protect from generic ALG
Status: I propoed we not do this. There was agreement on the list from 
Francois and Christer. But it has come up on the calls.

Holmberg-1: Christer proposed a way to return a STUN Server in a 
REGISTER response. The idea is to find one in a local network.
Status: I proposed it be out of scope for ICE. Some back-and-forth with 
Christer, not clear where we are. I still think its out of scope.

Holmberg-2: Christer raised an issue about handling of new media streams 
in a re-offer. You basically need to start a fresh.
Status: I agree; with the ICE-states below, the idea is that there would 
be a set of logic that applies in the 'running' state, anda  stream 
enters the running state when its new. My plan is to make changes in 
ice-12 to accomodate this. But would be good to make sure we're aligned 
on the approach.

Holmberg-3: ICE checks for inactive lines? b=0 lines?
Status: we agree ice checks are done if a line is a=inactive. Christer 
asks about b=0. Not clear.

Holmberg-6: Reliable provisionals
Status: Christer argues that the stuff in ICE about resending the 18x 
until a stun request arrives is a hack, we should be requiring reliable 
provisionals. No conclusion in discussions.

Closed
-------

Issue #1: Unified or separate checks across media streams
Conclusion: ICE-11 has separate checks, though still coupled via the 
Frozen algorithm

Issue #2: 32 bit space limit for priorities
Conclusion: New formula in ICE-11 provides more than enough space

Issue #3: limits on number of media streams
Conclusion: Resolve in ICE-11 by having separate check lists for each 
stream. Now there are no limits on the number of media streams

Issue #4: when is ICE done?
Conclusion: this is NOT in iCE-11 yet. We have agreed to signal 
conclusion via the stun checks, and to have the stun checks indicate 
which pairs are selected. ICE is done when the done flag has been set 
for each component of each media stream by the controlling entity.

Issue #6: what to do if keepalives fail?
Conclusion: a few comments agreed with my suggestion to do nothing, that 
this was otuside the scope of ICE to solve

Issue #7: forking and receipt of media
Conclusion: ICE had this statement that you don't play media you receive 
unless you had received a check. This completely fails with forking. So, 
the functionality was removed from -11

Issue #13: when to send media?
Conclusion: We agreed (though this is not in ICE-11) that media could be 
sent once done-ness is signaled via ICE, and could flow in both 
directions. I will have that in ICE-12

Issue #14: ICE states? DO we need them?
Conclusion: Not in ICE-11, but we agreed I think that this made sense. I 
was going to add the three states per media stream. The need for this 
goes along with the resolution to #13.

Holmberg-4; Option tag?
Status: agreed to add an option tag. This will go into ice-12

Holmberg-5: port of zero? IP address of 0.0.0.0?
Status: we agreed that no checks are sent for port of zero. We agree 
that checks are not sent for IP address of 0.0.0.0, and text needs to be 
added to say that ICE endpoints cannot use that to implement call hold 
when talking to another endpoint. That will go into ice-12

Matthews-1: spec mentions several times decisions made on whether you 
are the offerer or answerer. What if an O/A is in progress while the 
decision ahs to be made and this causes role reversal? Its a race condition.
Status: agreed that, if needed, the role would be based on the initial 
role of offerer vs. answerer

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 17 Oct 2006 14:44:27 +0200

Hi,

A very good collection of the open issues.

I have a couple of issues:

FIRST, assume that the UAC supports ICE, but it is NOT located behind a
NAT (or, it has no knowledge of any STUN/TURN servers). Now, the remote
UAS may also support ICE, and it may be located behind a NAT. Now, if
the UAC does not indicate support of ICE, my understanding is that the
remote UAS will not use ICE either. I guess it would be good to describe
(or refer to) "ice-lite" behavior in this case.

SECOND, we have been talking about what happens when new media lines are
added etc in the offer. But, what if the media parameters in the offer
do NOT change (the UAC may change an offer e.g simply to do an
hold/resume), but the media parameters in the answer change. I would
just like to verify whether we think that is already covered in chapter
9.2 and 9.3.

Regards,

Christer

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 16. lokakuuta 2006 21:57
> To: IETF MMUSIC WG
> Subject: [MMUSIC] Remaining ICE open issues
> 
> On the last ICE call, I indicated that I thought we were 
> mostly done, but that I'd check for straggler open issues. 
> Here is my list of whats closed and whats left, which we'll 
> discuss on the call tomorrow. Please let me know if you see 
> something that is an issue in your mind and not on either list:
> 
> Open
> ----
> 
> MacDonald-1: Determination of controlling endpoint: through 
> O/A negotiation or heuristic?
> MacDonald-2: where should we put text for ICE-for-gateways, 
> and should we hold up ICE for it?
> Issue #5: Removing a peer derived candidate. There is 
> currently no way to do it.
> Status: I suggested no one asked for this feature anyway, may 
> as well leave it as is. No responses posted.
> 
> Issue #8: The need for connectivity preconditions when you 
> are running ICE is far from clear.
> Status: I put some text in -11 around this; saying they are 
> only needed if you want the explicit signaling they provide. 
> Need some feedback on whether this text is OK.
> 
> Issue #9 (never posted AFAICT - just in the slides). Question 
> is that 3pcc Flow III doesnt work with ICE-10.
> Status: Whether it will work depends on the algorithm for 
> selecting the controlling entity. This has to be something 
> that survives reordering of m/c lines, which can happen in flow III.
> 
> Issue #10: ICE hammer. STUN checks themselves can cause lots 
> of traffic on the network, and can be used to launch an 
> attack. What to do about it?
> Issue #11: ICE pacing. Should we allow ICE checks to go 
> faster if codecs are at a faster rate?
> Status: There was some discussion of this on the calls, no 
> real conclusion. We did agreed to make the Ta interval 
> configurable and that some research would ideally be needed 
> to find a good value. But thats about it.
> 
> Issue #12: (never posted, in slides only). Question is 
> whether to adjust the retransmit interval for STUN when used 
> with ICE. Argument is that ICE transactions will often 
> completely timeout
> Status: My suggestion in the slides and in the related 
> discussion on behave was to leave it alone
> 
> Status: I propoed we not do this. There was agreement on the 
> list from Francois and Christer. But it has come up on the calls.
> 
> Holmberg-1: Christer proposed a way to return a STUN Server 
> in a REGISTER response. The idea is to find one in a local network.
> Status: I proposed it be out of scope for ICE. Some 
> back-and-forth with Christer, not clear where we are. I still 
> think its out of scope.
> 
> Holmberg-2: Christer raised an issue about handling of new 
> media streams in a re-offer. You basically need to start a fresh.
> Status: I agree; with the ICE-states below, the idea is that 
> there would be a set of logic that applies in the 'running' 
> state, anda  stream enters the running state when its new. My 
> plan is to make changes in
> ice-12 to accomodate this. But would be good to make sure 
> we're aligned on the approach.
> 
> Status: we agree ice checks are done if a line is a=inactive. 
> Christer asks about b=0. Not clear.
> 
> Status: Christer argues that the stuff in ICE about resending 
> the 18x until a stun request arrives is a hack, we should be 
> requiring reliable provisionals. No conclusion in discussions.
> 
> Closed
> -------
> 
> Conclusion: ICE-11 has separate checks, though still coupled 
> via the Frozen algorithm
> 
> Conclusion: Resolve in ICE-11 by having separate check lists 
> for each stream. Now there are no limits on the number of 
> media streams
> 
> Conclusion: this is NOT in iCE-11 yet. We have agreed to 
> signal conclusion via the stun checks, and to have the stun 
> checks indicate which pairs are selected. ICE is done when 
> the done flag has been set for each component of each media 
> stream by the controlling entity.
> 
> Conclusion: a few comments agreed with my suggestion to do 
> nothing, that this was otuside the scope of ICE to solve
> 
> Conclusion: ICE had this statement that you don't play media 
> you receive unless you had received a check. This completely 
> fails with forking. So, the functionality was removed from -11
> 
> Conclusion: We agreed (though this is not in ICE-11) that 
> media could be sent once done-ness is signaled via ICE, and 
> could flow in both directions. I will have that in ICE-12
> 
> Conclusion: Not in ICE-11, but we agreed I think that this 
> made sense. I was going to add the three states per media 
> stream. The need for this goes along with the resolution to #13.
> 
> Holmberg-4; Option tag?
> Status: we agreed that no checks are sent for port of zero. 
> We agree that checks are not sent for IP address of 0.0.0.0, 
> and text needs to be added to say that ICE endpoints cannot 
> use that to implement call hold when talking to another 
> endpoint. That will go into ice-12
> 
> Matthews-1: spec mentions several times decisions made on 
> whether you are the offerer or answerer. What if an O/A is in 
> progress while the decision ahs to be made and this causes 
> role reversal? Its a race condition.
> Status: agreed that, if needed, the role would be based on 
> the initial role of offerer vs. answerer
> 
> Thanks,
> Jonathan R.
> 
> 
> 
> 
> 
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Oct 2006 11:38:10 -0400

inline.

> (or refer to) "ice-lite" behavior in this case.

I don't follow. Support for ICE is different from the controlling/lite 
role negotiation we've been discussing. If a UAC supports ICE, it will 
have one or more candidates. If the UAS supports it, it will also have 
one more more candidates. ICE will then be used, period.

Now the question is who is controlling. If the UAC for some reason 
inserted a single candidate and indicated non-controlling, but the UAS 
indicates controlling, the UAS is in controlling role.

> just like to verify whether we think that is already covered in chapter

I dont think its covered. I think you'd need a rule that says don't do 
that. If you want to update media lines which requires an ICE restart, 
you have to send a new offer without a=remote-candidates to do that.

-Jonathan R.