Subject: [MMUSIC] ICE Finishing: Design choices

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2006 12:56:39 -0400

There are several issues at play here around when ICE is done, and I 
think its worth separating them out into several separate questions:

1. Is ICE ensuring that each side agrees on the same pair to use, or can 
each side end up with different pairs? The latter would result in the 
RTP not being symmetric.

This came up on last weeks call. It was suggested that with the 
keepalives being generated on the media stream, it was not so important 
to retain symmetric RTP. I remain opposed to this. Symmetric RTP seems 
to be the assumption these days, and I think it will be maximally 
interoperable with firewalls and various other intermediate things if we 
retain this property.

2. Assuming the goal is to agree on a single pair, how do we ensure that 
the same pair is used by both sides? There are several approaches here:

   a. one side picks the pair and signals it to the other side. This is 
what is in ICE-10. It does mean that one agent is basically telling the 
other agent which of their own candidates to use. The benefit of doing 
that is that it allows for a pair selection algorithm (like minimal ping 
time) to be run by just one side, and for the pair resulting from that 
algorithm to be used. The drawback is that it is odd (though I found no 
problem per se) that one side TELLS the other what candidate to use in 
its answer.

   b. one side picks its own candidate, lets the other side pick its 
candidate, and the resulting pair is used. With this approach, you still 
get symmetry, but its possible that the pair that is used was never 
validated by either side (though highly unlikely), and it would make it 
impossible for either side to run a pair-oriented selection algorithm 
without the other side supporting it too.

3. How are the choices in #2 signaled? This is what we're debating in 
the other thread posted by Derek. The options as I see it are:

   a. done explicitly through ICE, no re-invite
   b. done explicitly through ICE, and a re-invite, but the ICE 
selection takes precedence and overrides whats in the re-invite (Derek's 
proposal)
   c. done through a re-invite, though an early guess may be used 
through ICE exchanges (this is what is in ICE-10)
   d. done exclusively through a re-invite (this was in some older 
versions of ICE)

I still prefer (c) for the reasons I explained in the other note.

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: "Rohan Mahy" <[email-masked]>
Date: Tue, 26 Sep 2006 13:04:41 -0700

Hi Jonathan,

I'm including my opinions in-line.  I think questions 2 and 3 imply a
choice between business as usual for middleboxes and some very minimal
level of ICE-support for at least one middlebox in any network that
wants to enforce non-optimal paths.

More below.

> interoperable with firewalls and various other intermediate things if we

I am strongly in favor of symmetric RTP.  I don't think we have good
motivation for asymmetric RTP and the mechanism needed to validate
unidirectional paths is significantly more complicated than ICE-08.
We just made a decision to simplify things for ICE-10 and I do not
want to reverse that.

> without the other side supporting it too.

I am strongly in favor of 2a.  I want ICE to fail safe.  In the
unusual case where the a pair is chosen that is not validated at all I
dont want ICE to have "suceeded".  In terms of the benefits of 2b, I
think you can get many of the custom candidate prioritzation of 2b by
just manipulating the priority values and running 2a.

> selection takes precedence and overrides whats in the re-invite (Derek's

I am a strong proponent of 3b.  I'd like to go through several of the
cases we could be in and look at what happens here.

I. Lets say there is a generic ALG or a hotel ALG or an SBC which is
trying to be "helpful" by "fixing" the signaling for NAT traversal
reasons.  (I will get to boxes that change the signaling for policy
reasons later).  This ALG or SBC will either i) completely mangle the
m/c line or it will yield a valid candidate which ii) may or iii) may
not be the best candidate.

i) If the hotel ALG completely magles the m/c line, the peers can
verify that the m/c line is not a valid candidate and should use the
best valid candidate.  I believe this should be communicated via ICE
and then signaled via an UPDATE or reINVITE at the earliest
opportunity.  The important issue here is that the peers found a valid
path and can communicate.  They did the best they can under the
circumstances. The peers can verify that this has happened by
comparing the m/c line with the candidate lines.  We can prevent
generic ALGs from mangling the candidate lines by encoding IPv4
addresses with "!" instead of "." (ex: 10!1!1!102 instead of
10.1.1.102).

ii) if the received m/c line is best candidate, the answerer does not
know if the received m/c line was the m/c line the offerer sent.  To
confirm which one to use, there needs to be some confirmation via
STUN.

iii) if the m/c line is not the best candidate, I think we still want
the best candidate to be used. The peers can agree on the best pair,
confirm via STUN, then UPDATE or reINVITE at the earliest opporuntity.
 This insures that the best path is used from the beginning.  It
prevents cases where we use the best path for a while, then suddenly
loose audio or switch to a much worse path, only to switch back again
when the signaling is rationalized.

II) Lets take the policy use cases next. Here we have an SBC that is
*modifying* the signaling  (i'll mention passive monitoring a bit
later).  If the SBC is also policing the media traffic, the behavior
will not change since connectivity checks will fail for all the
unauthorized candidates. Perhaps the SBC is trying to enforce routing
through a media relay even when one is not strictly needed.  These
SBCs can i) support ICE or ii) not.

i) if the SBC supports ICE, it could remove or modify candidate lines
to insure that only candidates approved by policy are allowed through,
or to insert a media relay.  Note that I am not recommending this kind
of behavior, just acknowledging that folks do this today (without ICE)
and some will still want to do this.  ICE connectivity checks will
still work.

ii) if the SBC does not support ICE, the behavior I suggest would
bypass the policy of the SBC unless the SBC removed a=candidate:
lines.  An SBC (or an earlier SBC) that does not really support ICE
can pretty easily remove all a=candidate lines to force the peers to
fallback to only using the m/c line.

Now some folks might complain that if SBCs do nothing, the ICE clients
ignore the m/c line in this case.  They might say that we are making
vendors implement some new feature (however minor) in order to get
current policy behavior whenever both peers support ICE.  "You are
breaking functionality". I would like to use this opportunity to point
out that most of these policy enforcing SBCs are already breaking
several rules in the spec by modifying the SDP body in the first
place.  We are adding significantly useful functionality to find the
best path even in cases where the NATs misbehave or an ALG is mangling
the m/c line in a misguided attempt to "help".  We are not breaking
functionality for any device that follows the rules in RFC 3261.  We
are also going to great lengths to make it easy for non-compliant SBCs
to still do policy enforcement with only a very minor change.

III. Finally lets examine what happens if I have "read-only" signaling
boxes (for recording, qos reservations, etc).  These can support ICE
or not support ICE.  If they support ICE, they will can monitor all
the candidates, or they can modify the candidate list.  If they don't
support ICE, they will only monitor or promote the candidate in the
m/c line.  There might not be QoS or monitoring on the active
candidate pair until the reINVITE or UPDATE arrives.  In the
monitoring case, the recording might not include the early media, but
the recording should have the complete human conversation.  Likewise,
there might not be QoS for the early media (who cares), but QoS will
be enabled as soon as an actual conversation starts. If QoS is
"mandatory" then the peers can use preconditions to insure that there
is no ringing before the UPDATE is sent.

The alternative (sending only using the pair represented in the m/c
line or switching to the m/c line after a timer expires) could result
in no early media or early media that works breifly then stops working
suddenly.

In conclusion, I think 3b is the best choice we could make.  In every
case where you could make a phone call, you get to have a
conversation, even in the face of hotel ALGs or generic ALGs.  SBCs
and ALGs that try to help no longer do any harm. SBCs that use media
policing still work. Networks that force a media relay where one is
not actually needed would need at least one SBC to either understand
ICE or at least remove a=candidate lines.  QoS classifiers and
monitoring devices continue to work.

thanks,
-rohan

---

From: <[email-masked]>
Date: Wed, 27 Sep 2006 15:39:48 +0300

Hi,

On 26 September 2006,  Jonathan Rosenberg wrote:
>This came up on last weeks call. It was suggested that with 
>the keepalives being generated on the media stream, it was not 
>so important to retain symmetric RTP. I remain opposed to 
>this. Symmetric RTP seems to be the assumption these days, and 
>I think it will be maximally interoperable with firewalls and 
>various other intermediate things if we retain this property.

I don't have strong opinions on this, but what would be the use cases
where symmetric RTP is really needed when ICE is used? 

As clients cannot really assume a continuous flow of RTP packets 
throughout a session (due to aggressive VAD for instance), you anyways
need to send STUN packets to keep the RTP/RTCP flows alive. From
middle-box
point of view, each client will have "two symmetric-RTP flows" per
session (one
for receiving and one for sending, but both have the STUN traffic). 

Symmetric RTP does have some benefits (only one flow needed at stateful 
middle-boxes), but it's not that obvious that the benefits outweight
possible 
added complexity in ICE to always achieve one symmetric RTP flow.

-- 
[email-masked] (Kai Vehmanen)
Networking Technologies Laboratory, Nokia Research Center

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Sep 2006 20:03:29 -0500

After going through all this, I can say I agree with all of Rohan's 
opinions in this email. That is, I am in favor of enforcing symmetric
RTP, of 2a, and 3b.

The one minor point I have is that I am somewhat opposed to mangling
the IP address in the candidate lines (with the ! instead of .) in
order to prevent ALGs mangling even more the IP addresses. These ALGs
are going to mangle IP addresses in other fields anyways, and just makes
our
spec more obscure than it already is. I believe that doing this will
only 
ENCOURAGE the worst of the worst ALGs. And I am hightly sceptical that 
just obfuscating the IP address will actually be successful, since any 
ALG that is that stupid will break other stuff too. If one really wants
to 
support these ALGs, then just using TLS to make the signalling
un-mangledable 
is probably best. 

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Tuesday, September 26, 2006 1:05 PM
> To: Jonathan Rosenberg
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] ICE Finishing: Design choices
> 
> Hi Jonathan,
> 
> I'm including my opinions in-line.  I think questions 2 and 3 
> imply a choice between business as usual for middleboxes and 
> some very minimal level of ICE-support for at least one 
> middlebox in any network that wants to enforce non-optimal paths.
> 
> More below.
> 
> > 1. Is ICE ensuring that each side agrees on the same pair 
> to use, or 
> > can each side end up with different pairs? The latter would 
> result in 
> > the RTP not being symmetric.
> >
> > keepalives being generated on the media stream, it was not so 
> > important to retain symmetric RTP. I remain opposed to 
> this. Symmetric 
> > RTP seems to be the assumption these days, and I think it will be 
> > maximally interoperable with firewalls and various other 
> intermediate 
> > things if we retain this property.
> 
> I am strongly in favor of symmetric RTP.  I don't think we 
> have good motivation for asymmetric RTP and the mechanism 
> needed to validate unidirectional paths is significantly more 
> complicated than ICE-08.
> We just made a decision to simplify things for ICE-10 and I 
> do not want to reverse that.
> 
> > 2. Assuming the goal is to agree on a single pair, how do we ensure 
> > that the same pair is used by both sides? There are several 
> approaches here:
> >
> >    a. one side picks the pair and signals it to the other 
> side. This 
> > is what is in ICE-10. It does mean that one agent is 
> basically telling 
> > the other agent which of their own candidates to use. The 
> benefit of 
> > doing that is that it allows for a pair selection algorithm (like 
> > minimal ping
> > algorithm to be used. The drawback is that it is odd 
> (though I found 
> > no problem per se) that one side TELLS the other what 
> candidate to use 
> > in its answer.
> >
> > candidate, and the resulting pair is used. With this approach, you 
> > still get symmetry, but its possible that the pair that is used was 
> > never validated by either side (though highly unlikely), 
> and it would 
> > make it impossible for either side to run a pair-oriented selection 
> > algorithm without the other side supporting it too.
> 
> I am strongly in favor of 2a.  I want ICE to fail safe.  In 
> the unusual case where the a pair is chosen that is not 
> validated at all I dont want ICE to have "suceeded".  In 
> terms of the benefits of 2b, I think you can get many of the 
> custom candidate prioritzation of 2b by just manipulating the 
> priority values and running 2a.
> 
> 
> I am a strong proponent of 3b.  I'd like to go through 
> several of the cases we could be in and look at what happens here.
> 
> I. Lets say there is a generic ALG or a hotel ALG or an SBC 
> which is trying to be "helpful" by "fixing" the signaling for 
> NAT traversal reasons.  (I will get to boxes that change the 
> signaling for policy reasons later).  This ALG or SBC will 
> either i) completely mangle the m/c line or it will yield a 
> valid candidate which ii) may or iii) may not be the best candidate.
> 
> i) If the hotel ALG completely magles the m/c line, the peers 
> can verify that the m/c line is not a valid candidate and 
> should use the best valid candidate.  I believe this should 
> be communicated via ICE and then signaled via an UPDATE or 
> reINVITE at the earliest opportunity.  The important issue 
> here is that the peers found a valid path and can 
> communicate.  They did the best they can under the 
> comparing the m/c line with the candidate lines.  We can 
> prevent generic ALGs from mangling the candidate lines by 
> encoding IPv4 addresses with "!" instead of "." (ex: 
> 10!1!1!102 instead of 10.1.1.102).
> 
> ii) if the received m/c line is best candidate, the answerer 
> does not know if the received m/c line was the m/c line the 
> offerer sent.  To confirm which one to use, there needs to be 
> some confirmation via STUN.
> 
> iii) if the m/c line is not the best candidate, I think we 
> still want the best candidate to be used. The peers can agree 
> on the best pair, confirm via STUN, then UPDATE or reINVITE 
> at the earliest opporuntity.
>  This insures that the best path is used from the beginning.  
> It prevents cases where we use the best path for a while, 
> then suddenly loose audio or switch to a much worse path, 
> only to switch back again when the signaling is rationalized.
> 
> *modifying* the signaling  (i'll mention passive monitoring a 
> bit later).  If the SBC is also policing the media traffic, 
> the behavior will not change since connectivity checks will 
> fail for all the unauthorized candidates. Perhaps the SBC is 
> trying to enforce routing through a media relay even when one 
> is not strictly needed.  These SBCs can i) support ICE or ii) not.
> 
> i) if the SBC supports ICE, it could remove or modify 
> candidate lines to insure that only candidates approved by 
> policy are allowed through, or to insert a media relay.  Note 
> that I am not recommending this kind of behavior, just 
> acknowledging that folks do this today (without ICE) and some 
> will still want to do this.  ICE connectivity checks will still work.
> 
> ii) if the SBC does not support ICE, the behavior I suggest 
> would bypass the policy of the SBC unless the SBC removed a=candidate:
> lines.  An SBC (or an earlier SBC) that does not really 
> support ICE can pretty easily remove all a=candidate lines to 
> force the peers to fallback to only using the m/c line.
> 
> Now some folks might complain that if SBCs do nothing, the 
> ICE clients ignore the m/c line in this case.  They might say 
> that we are making vendors implement some new feature 
> (however minor) in order to get current policy behavior 
> whenever both peers support ICE.  "You are breaking 
> functionality". I would like to use this opportunity to point 
> out that most of these policy enforcing SBCs are already 
> breaking several rules in the spec by modifying the SDP body 
> in the first place.  We are adding significantly useful 
> functionality to find the best path even in cases where the 
> NATs misbehave or an ALG is mangling the m/c line in a 
> misguided attempt to "help".  We are not breaking 
> functionality for any device that follows the rules in RFC 
> 3261.  We are also going to great lengths to make it easy for 
> non-compliant SBCs to still do policy enforcement with only a 
> very minor change.
> 
> III. Finally lets examine what happens if I have "read-only" 
> signaling boxes (for recording, qos reservations, etc).  
> These can support ICE or not support ICE.  If they support 
> ICE, they will can monitor all the candidates, or they can 
> modify the candidate list.  If they don't support ICE, they 
> will only monitor or promote the candidate in the m/c line.  
> There might not be QoS or monitoring on the active candidate 
> pair until the reINVITE or UPDATE arrives.  In the monitoring 
> case, the recording might not include the early media, but 
> the recording should have the complete human conversation.  
> Likewise, there might not be QoS for the early media (who 
> cares), but QoS will be enabled as soon as an actual 
> conversation starts. If QoS is "mandatory" then the peers can 
> use preconditions to insure that there is no ringing before 
> the UPDATE is sent.
> 
> The alternative (sending only using the pair represented in 
> the m/c line or switching to the m/c line after a timer 
> expires) could result in no early media or early media that 
> works breifly then stops working suddenly.
> 
> In conclusion, I think 3b is the best choice we could make.  
> In every case where you could make a phone call, you get to 
> have a conversation, even in the face of hotel ALGs or 
> generic ALGs.  SBCs and ALGs that try to help no longer do 
> any harm. SBCs that use media policing still work. Networks 
> that force a media relay where one is not actually needed 
> would need at least one SBC to either understand ICE or at 
> least remove a=candidate lines.  QoS classifiers and

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 27 Sep 2006 23:03:45 -0400

Howdy,
After reading the various threads (sorry couldn't make the calls), I figure
I should point out a few issues/concerns regarding the "do we let ICE
override m/c mismatch" debate.  

1) One argument for ignoring the m/c/ice mismatch has been that the
middle-boxes are not standards compliant and ergo should be bypassed if
possible.  I find that argument contradictory, since by definition a UA not
using m/c lines for media addressing is breaking other standards.  I'm not
sure breaking standards to get around other boxes that break standards is
such a good idea. (I can see the arms race coming :)  

2) If there were no middle-box, but the far-end UA was broken and sent
mismatched, we would be letting the media layer override the signaling.
That scenario is essentially what a B2BUA would be doing as a middle-box if
it did this incorrectly - as a b2bua it is a UA, and the UA being
communicated with in signaling.  So what we're really talking about is if a
UA-to-UA session should ignore the m/c lines if STUN says something else
works, that the local UA likes better.  To me, that means we're changing the
fundamental signaling/media control model.

3) If an ALG/SBC/FW/B2BUA changed the m/c lines, then it probably has a good
reason for doing it.  You may personally disagree with the reasons, and
think you know better, but I don't understand how an RFC or software program
would, a priori.  One example is an enterprise Firewall/ALG.  The Enterprise
may well have some legitimate reasons for wanting media to follow a specific
path inside their network, and externally in/out their network.  These may
be security related, regulatory, or even performance.  I'm sure the major
vendors could upgrade their code to strip Ice lines, but I imagine it takes
quite some time for all the boxes to be upgraded.

4) STUN messages provide you a connectivity check.  That's it.  They don't
verify media works.  By that I mean some middle-boxes change m/c lines to
receive media, in order to do media-level things.  For example: transcoding,
2833 conversion, IPv4/v6 interworking, SRTP termination, etc.  Some of those
things are done in such a way that the candidate lines won't "get through"
anyway (e.g. via 3pcc to media servers), and some of them won't work for
STUN anyway (v4/v6 in particular); but some of them are done by modifying
SDP as a b2bua.  My point is non-standard boxes do non-standard things, but
generally to help people communicate at a media level.  If you try to bypass
them and media ends up failing, people may blame the middle-boxes, but they
will turn off ICE and phone vendors will not make it enabled by default.

5) An interesting "feature" some of these middle-boxes have is no-media
detection.  If they don't see any media cross them in a certain time-period,
they tear down the call.  If the UA bypasses it, it assures itself of a
limited-duration call.  Or should we also have the UA keep media up and
disregard a SIP BYE?  That would be the next logical move. 

In general I don't think I care too much which way is chosen.  I'll be fine
with deleting more and more SDP lines. ;) 

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 27 Sep 2006 23:15:53 -0400

> Sent: Tuesday, September 26, 2006 4:05 PM
> To: Jonathan Rosenberg
> Cc: IETF MMUSIC WG

I don't know why people keep claiming they're non-optimal paths.  The UA has
no idea what the "optimal" path is.  The middlebox path may be more optimal,
or less, or the same.  It depends on many things, most of which are
unknowable to a UA, some of which are knowable to a middlebox.   

(size(1) != all.fit();)

-hadriel