Subject: [MMUSIC] ICE-10 Issue #7: Forking and Receipt of Media

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 00:43:41 -0400

ICE-10 (and indeed previous versions) had specified that if an agent 
receives a media packet, it doesn't play it out unless it had previously 
received a check on that same 5-tuple. The benefit of this check is that 
it can prevent attacks whereby an attacker just sends RTP packets to 
ports known to be for media (for example, a PSTN gateway which uses a 
large port range) in the hopes of getting their media injected into a 
voice conversation. ICE doesn't prevent this attack entirely (really 
SRTP is needed), but it makes it such that the attacker would need to 
employ source IP spoofing to accomplish it.

The check works great in networks where everyone supports ICE. But it 
has a problem in mixed mode environments with SIP forking.

The problem is that agent A sends a SIP INVITE. Agent A supports ICE. 
Their INVITE forks, and one of the recipients is a non-ICE PSTN GW, 
which immediately starts sending early media. This early media is 
received at user agent A. Shortly thereafter, it gets a provisional 
response which may or may not contain SDP, from that GW. The 'right' 
thing here is that agent A plays early media, both prior to the receipt 
of any answer and even after the provisional response. Because A has 
elected to play early media without getting a STUN check, we've 
basically invalidating the very safeguard that this requirement was 
meant to introduce.

The ICE-10 spec has some kind of weasel words around this, saying that 
the feature only works in environments that aren't mixed mode. This 
doesnt seem very good to me, though none of the options I can think of 
work particularly better:

1. discard the feature entirely; always play early media after an offer 
per rfc3264. If you want security for media, use SRTP

2. keep the current text which limits applicability to closed 
environments where you know everyone supports ICE

3. apply the restriction, but only after the INVITE transaction has 
fully completed. At that point, agent A would know whether its peers are 
ICE compliant or not. Prior to that point, play early media.

I think approach 2 is brittle, since there is no way for a UA to know 
whether this condition is true. Approach 3 still leaves a big window. 
I'm inclined to go with option 1.

Comments?

-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: "Francois Audet" <[email-masked]>
Date: Tue, 12 Sep 2006 11:25:18 -0500

I'm not sure what to do about it.

Seems to me that many devices will only be able to play ONE stream.
If it has the choice between two streams, one that has done an
ICE check, and another one that doesn't, it probably be wise to
play the one with the ICE check.

The problem you are describing can occur for other reasons that
"attacks" as you describe. I've seen it with Conference bridge
that continue streaming to a User (e.g., a PSTN GW) that rebooted,
but where the conference bridge is unaware of the call leg being 
gone. It results in "ghost voice".

But if it warrants any wording in ICE is a different story. 
I'm tempted to think it's out of scope.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, September 11, 2006 9:44 PM
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE-10 Issue #7: Forking and Receipt of Media
> 
> ICE-10 (and indeed previous versions) had specified that if 
> an agent receives a media packet, it doesn't play it out 
> unless it had previously received a check on that same 
> 5-tuple. The benefit of this check is that it can prevent 
> attacks whereby an attacker just sends RTP packets to ports 
> known to be for media (for example, a PSTN gateway which uses 
> a large port range) in the hopes of getting their media 
> injected into a voice conversation. ICE doesn't prevent this 
> attack entirely (really SRTP is needed), but it makes it such 
> that the attacker would need to employ source IP spoofing to 
> accomplish it.
> 
> The check works great in networks where everyone supports 
> ICE. But it has a problem in mixed mode environments with SIP forking.
> 
> Their INVITE forks, and one of the recipients is a non-ICE 
> PSTN GW, which immediately starts sending early media. This 
> early media is received at user agent A. Shortly thereafter, 
> it gets a provisional response which may or may not contain 
> SDP, from that GW. The 'right' 
> thing here is that agent A plays early media, both prior to 
> the receipt of any answer and even after the provisional 
> response. Because A has elected to play early media without 
> getting a STUN check, we've basically invalidating the very 
> safeguard that this requirement was meant to introduce.
> 
> The ICE-10 spec has some kind of weasel words around this, 
> saying that the feature only works in environments that 
> aren't mixed mode. This doesnt seem very good to me, though 
> none of the options I can think of work particularly better:
> 
> 1. discard the feature entirely; always play early media 
> after an offer per rfc3264. If you want security for media, use SRTP
> 
> 3. apply the restriction, but only after the INVITE 
> transaction has fully completed. At that point, agent A would 
> know whether its peers are ICE compliant or not. Prior to 
> that point, play early media.
> 
> 
> I think approach 2 is brittle, since there is no way for a UA 
> to know whether this condition is true. Approach 3 still 
> leaves a big window.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 13 Sep 2006 02:55:31 -0500

Jonathan,

I would tend to agree with you with respect to going with option 1. It
may have been present in earlier revisions. Using ICE to resolve early
media issues (including making recommendations about prioritizing ICE
endpoints over non-ICE endpoints for early media) would seem to open the
spec up to other issues that are out of scope.

Regards,
Brian  

> Sent: Tuesday, September 12, 2006 12:44 PM
> To: IETF MMUSIC WG

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 13 Sep 2006 10:01:36 +0200

Hi,

I still don't believe in the
receive-media-once-you-have-sent-the-INVITE-before-you-have-received-an-
SDP-answer, but let's not go into that.

One possible way would be to mark the streams inactive (or sendonly) in
the initialoffer, and later change to sendrecv when the STUN checks are
done. That pretty much requires that the remote end supports 100rel and
UPDATE, though, because otherwise the new offer can't be sent until
after 200 OK.

However, I am a little confused about ICE and inactive in the initial
offer. As I said in another mail, the text is a little unclear regarding
ICE and inactive in the initial offer.

Regards,

Christer

> Sent: 12. syyskuuta 2006 7:44
> To: IETF MMUSIC WG