Subject: Re: [MMUSIC] Should we have ICE TCP lite?

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Jan 2011 10:11:54 +0100

Simon Perreault skrev 2010-12-17 17:27:
>> if you don't send any
>> > connectivity checks, there's a chance for someone hijacking the media
>> > connection
> IMHO, this is not an important problem. ICE's raison d'être is not security.
> 

Actually, ICE has quite strong protection against malicious hijacking of
flow association. And that is by design and necessity. I don't see it as
acceptable to leave a gapping hole where you don't know that you have
connected to the right peer.

Actually if there are no STUN connectivity checks there is no mechanism
to determine if the association is correct, even without malicious
attempts. As a ICE agent doesn't know where it is topologically in
relation to its counter part it can never know (in the general case) if
the peer is on one local network or in some completly different address
domain. Thus one needs to verify that the one accepting the TCP
connection is actually the intneded party. This could easily be a
service that accept all incomming on a completely unrelated machine to
the ICE connectivity attempt.

So I see big problem with not performing connectivity checks using STUN
with the user name + password combination to ensure that you have
connected to the right party.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Jan 2011 08:32:27 -0500

> connected to the right party.

The thing is that there is another way to get that feature without ICE
(e.g. SRTP, or in this case TLS for TCP-based media). So dropping that
feature from ICE-TCP wouldn't mean being caught with our pants down.

I'm not advocating for actually doing it. I'm just saying that I don't
think it would be a big deal *if* we end up doing it.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ari Keranen <[email-masked]>
Date: Tue, 25 Jan 2011 18:39:23 +0200

On Dec 17, 2010, at 5:56 PM, Ari Keranen wrote:
> The question is, do we want to revert that decision and define ICE lite for TCP, or should we stick with only co-media?

Based on the on- and off-list discussions, restoring the lite mode seems reasonable. Here's how it could look like:
http://users.piuha.net/akeranen/drafts/draft-ietf-mmusic-ice-tcp-12.txt

In practice, the new revision proposes the following:
 - Lite mode applies to both UDP and TCP candidates
 - Lite implementations gather only passive candidates
 - If both agents are lite, the controlling agent (offerer) makes a new offer using co-media and selects the most preferred candidate pair
  - the controlling agent MAY initiate the (media) TCP connection in parallel with the new offer (to speedup the process)

Also, in addition to editorial fixes, a few small updates were made:
 - Added text saying STUN retransmissions are not needed with TCP since TCP takes care of them
 - Updated security considerations with text about lack of authentication with two lite-mode agents

Diff against the previous published (-12) version, containing also the prioritization changes and SDP examples, is available here:
http://users.piuha.net/akeranen/drafts/draft-ietf-mmusic-ice-tcp-12-diff.html

This should close the remaining open comments/issues on the draft.

Cheers,
Ari

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 25 Jan 2011 18:18:37 -0500

I somewhat wish the security recommendations were stronger, but I
think they're appropriate.

Changes look good to me.

Bruce

On Tue, Jan 25, 2011 at 11:39 AM, Ari Keranen
<[email-masked]> wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Jan 2011 09:32:10 +0100

> think they're appropriate.

I think the security consideration section should be stronger in
pointing out that unless globablly unique addresses are used, e.g.
private addersses in combination with lite on both sides, there is a
risk for misassociation that isn't validated by ICE. I would actually in
this case go as far as require the higher layer protocol to authenticate
the counter part.

But, I think one at least needs to point out this case specifically.

Cheers

Magnus Westerlund

---

From: Ari Keranen <[email-masked]>
Date: Wed, 26 Jan 2011 11:08:17 +0200

> this case go as far as require the higher layer protocol to authenticate

Yes, this is one of the reasons why a lite implementation must not be behind a NAT.

> But, I think one at least needs to point out this case specifically.

I clarified this in the draft. The Lite Implementation Requirement sections says now (added the "i.e." part):

   If an offerer meets the criteria for the lite mode as described in
   Appendix A of [RFC5245] (i.e., it will always have a public, globally
   unique IP address), it MAY use the lite mode of ICE also for TCP
   candidates.

And I added the following to the security section's part about lite implementations:

   [...] The lack of connectivity checks is
   especially problematic if one of the hosts is behind a NAT and has an
   address from a private address space: the peer may accidentally
   connect to a host in a different subnet that uses the same private
   address space.  This is one of the reasons why a lite implementation
   MUST NOT be located behind a NAT.

Updated doc and diff:

Cheers,
Ari

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 26 Jan 2011 07:38:53 -0600

>     MUST NOT be located behind a NAT.

Maybe that should be worded a bit differently; a UA that implements both 
full ICE and ICE-lite can certainly be located behind a NAT, but it must 
not choose lite mode when it is behind a NAT. In addition, the 
restriction should be based on communicating *across* the NAT, not the 
location of the implementation. It should be perfectly acceptable for an 
ICE-lite implementation to talk another ICE-lite implementation on a 
private network that is also behind a NAT to a public network, if the 
two implementations are not attempting to communicate across the NAT.

It's too early in the morning here for me to attempt to draft some text, 
but I'll try later today if nobody else has taken a stab at it :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Ari Keranen <[email-masked]>
Date: Wed, 26 Jan 2011 17:46:47 +0200

On Jan 26, 2011, at 3:38 PM, Kevin P. Fleming wrote:
> Maybe that should be worded a bit differently; a UA that implements both full ICE and ICE-lite can certainly be located behind a NAT, but it must not choose lite mode when it is behind a NAT.

Good point. The last sentence could be changed into:

This is one of the reasons why the lite mode MUST NOT be used by an ICE agent located behind a NAT.

> In addition, the restriction should be based on communicating *across* the NAT, not the location of the implementation. It should be perfectly acceptable for an ICE-lite implementation to talk another ICE-lite implementation on a private network that is also behind a NAT to a public network, if the two implementations are not attempting to communicate across the NAT.

I think two lite agents communicating in the same private subnet is not a good idea. How would the lite agent know (for sure and without any additional mechanisms) that the peer is in the same subnet?

> It's too early in the morning here for me to attempt to draft some text, but I'll try later today if nobody else has taken a stab at it :-)

Text contributions are always welcome :)

Cheers,
Ari

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Jan 2011 11:05:47 -0500

> I think two lite agents communicating in the same private subnet is not a good idea. How would the lite agent know (for sure and without any additional mechanisms) that the peer is in the same subn…

Static configuration.

A dual-stack private network is a fine use-case for ICE-lite. We need to
support it to help IPv6 transition.

Simon

---

From: Ari Keranen <[email-masked]>
Date: Thu, 27 Jan 2011 11:07:34 +0200

>> I think two lite agents communicating in the same private subnet is not a good idea. How would the lite agent know (for sure and without any additional mechanisms) that the peer is in the same sub…

Well, that would qualify as "an additional mechanism" :)

But what would you configure? Obviously just "IP addresses of the hosts in the same subnet" is not sufficient since the same address can be used in a different private network.

> support it to help IPv6 transition.

IMHO, ICE-lite should be used only on public hosts and once scenarios get more complex than that, one should use full ICE instead. I can think of many ways to find out if peers are in the same subnet, but none of them are as good as simply using full ICE.

Cheers,
Ari

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Jan 2011 08:35:45 -0500

> But what would you configure? Obviously just "IP addresses of the hosts in the same subnet" is not sufficient since the same address can be used in a different private network.

There are plenty of devices out there that just never talk to anyone
outside of a private network. So it could be as simple as setting a
single global "ICE-lite" bit.

When you control the network, you're pretty much free to do whatever you
want...

Simon

---

From: Ari Keranen <[email-masked]>
Date: Thu, 27 Jan 2011 16:18:10 +0200

> single global "ICE-lite" bit.

And when one day one of these lite-bit-agents happens to be connected by a host in another network, strange errors start to emerge.

> When you control the network, you're pretty much free to do whatever you

..including violating an RFC and using lite mode behind a NAT :)

Basically these devices would need ICE only as a way to negotiate whether v4 or v6 should be used. But if the network is really that tightly under provider's control, is there anything to negotiate? Instead of "lite bit" you could have a "v6 bit", right?

Cheers,
Ari

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 28 Jan 2011 17:55:54 -0800

Am I the only person annoyed by the spelling "lite"?

	Ross.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 28 Jan 2011 18:03:49 -0800

> Am I the only person annoyed by the spelling "lite"?

That does not keep me up at nite.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org