Subject: Re: [MMUSIC] [BEHAVE] [Fwd: draft-lowekamp-mmusic-ice-tcp-framework-00 draft submitted]

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 31 Oct 2008 09:39:45 +0200

On Friday 31 October 2008 01:04:03 ext Adam Roach, you wrote:
> Because I know many of the parties interested in ICE TCP are somewhat
> more active on the BEHAVE list than they are on MMUSIC, I wanted to
> cross-post Bruce's announcement here.

Looks good base to me. I am not sure if SSH tunnels really fit there, though.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Oct 2008 09:45:08 -0500

Rémi Denis-Courmont wrote:
> Looks good base to me.

Thanks.

> I am not sure if SSH tunnels really fit there, though.
>
>   

Why not? If I have a SIP client behind a firewall, I can use a SSH 
server as a perfectly good forwarding relay for TCP connections. I can 
get a passive candidate with an SSH_MSG_GLOBAL_REQUEST "tcpip-forward", 
and know when it's been connected when I get a SSH_MSG_CHANNEL_OPEN 
"forwarded-tcpip"; and I can get an active candidate pretty much 
automatically -- to try the candidate, I all I need to do is allocate a 
new sender channel with a SSH_MSG_CHANNEL_OPEN "direct-tcpip" and start 
running my checks over it.

Or, from a commandline perspective (using the OpenSSH client), I get a 
passive candidate like this:

ssh [email-masked] -R 5555:localhost:4444

(Where 5555 is the port I advertise in my SDP, and 4444 is the local 
port I'm actually listening on)

...and an active candidate like this:

ssh [email-masked] -L 
localhost:1234:the-other-guy.example.org:4321

(Where 4321 is the port I received in the SDP, and 1234 is the local 
port I'll actually send traffic to).

As far as the remote party knows, this is just another set of TCP ports 
(with the exception of the indicated priority).

The best part is: this is already widely deployed. And the key thrust of 
the document is: we can solve this problem by using what's already out 
in the field.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 31 Oct 2008 08:54:07 -0600

> the document is: we can solve this problem by using what's already out

+1!

/psa

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 31 Oct 2008 17:10:12 +0200

On Friday 31 October 2008 16:45:08 ext Adam Roach, you wrote:
> server as a perfectly good forwarding relay for TCP connections.

Because it's impractical to implement and configure.

TCP over UDP need no configuration. UPnP IGD and NAT-PMP can be autodetected. 
Teredo normally is autoconfigured by the operating system. SOCKS is already 
in the proxy settings, regardless of ICE-TCP, and it's simple enough to 
implement.

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Oct 2008 10:30:42 -0500

> Because it's impractical to implement and configure.

I'm confused. It's already implemented in several codebases, and 
configuration involves three pieces of information (userid, password, 
and ssh server).

> in the proxy settings, regardless of ICE-TCP, and it's simple enough to 

That's all true. However, on the machine that I'm sitting at, with the 
resources I have access to, none of those would work if I tried to use 
TCP-ICE with a v4-only remote party.

I don't have a TCP over UDP implementation (and it's not even fully 
specified yet -- we'd need to flesh out SDP syntax, at the very least); 
the NAT I'm using is based on Linux iptables, and I haven't installed 
UPnP IGD modules for it (which would be a bit nontrivial); as much as 
I'd like the far end to advertise a v6 address, there's nothing I can do 
to force the issue; and I don't have access to a SOCKS server.

I *do*, however, have access to several SSH servers that I can use to 
tunnel TCP connections.

Is my situation a bid odd? For a home network, yeah, it's a bit 
different. However, the properties are very similar to what your average 
user will encounter when plugging into the network in just about any 
hotel in the world.

But we can cover additional users -- myself included -- by leveraging a 
well-defined, broadly-deployed technology. I don't see any reason to 
exclude it.

/a