Subject: RE: [SIP] SIP through firewalls without SIP proxy

From: [email-masked]
Date: Sat, 30 Sep 2000 13:33:58 -0600

When you say 'without SIP proxy', I assume you mean without resorting to the
sort of techniques outlined in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-firewalls-00.txt

... or perhaps a case in which the SIP client effectively acts as the ALG
described in that document. I can understand why, if that's where you're
coming from, you'd take this to AFT, but I'd thought that the AFT group had
a slightly different focus (certainly SOCKS does, anyway), in so far the
problems of firewall traversal for protocols like SIP are not matters of
user-level authentication.

In fact, there has been talk (out of the foglamps mailing list) of
chartering a new group to pursue this protocol in particular. This group is
developing a framework document to describe the characteristics of such a
firewall control protocol, see:

http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt

From a casual glance at your sketch below, it seems that your work is in
line with the efforts in that community of interest. I'm sure that group
would be happy to see more support of the exploration of these sorts of
protocols.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Simon Barber [mailto:[email-masked]]
Sent: Saturday, September 30, 2000 1:33 AM
To: [email-masked]
Subject: [SIP] SIP through firewalls without SIP proxy

I currently have a commercial need to make my SIP client operate from
networks with firewalls that will not allow SIP or RTP traffic through. I
have just posted a proposal to the AFT mailing list for a generic mechanism
to allow any protocol to operate through HTTP only firewalls. I've included
a copy of the message below - but this is definately off topic for the SIP
mailing list. Please post your replies on the AFT mailing list.

Simon Barber

------

proxy sockets

firewall admins will hate this.

This is a varient on the SOCKS protocol, with a couple of significant
differences. SOCKS V4 only allows a single TCP connection to be mapped to a
single SOCKS connection. SOCKS V5 is similar to V4 for TCP, and for UDP uses
a second UDP connection to transport the data for the socket that is
proxied.

Increasingly applications are finding that they have to run behindfirewalls,
with restricted access out. Either only TCP, or even HTTP connections may be
possible. As as result any protocol the application requires must be mapped
down to these protocols.

Here I propose a simple RPC mechanism for the berkeley sockets API, to run
over any bi-directional character stream. This could be implemented over
whatever the user wishes - TCP, TLS, HTTP, HTTPS or whatever connection is
available.

Multiple TCP connections, incoming and outgoing, and UDP connections would
all be supported over a single bi-directional character stream.

The protocol is defined in binary, to conserve bandwidth, especially
important since it is envisioned one use will be to carry RTP traffic over
TCP and HTTP connections. These connections are rate-limited, where RTP is
not. Because of this it is considered important to not add to the session
bandwidth. This would exacerbate problems with real-time media during
periods of congestion.

It is recommended that this protocol is implemented on the client as a
library - with a similar API as the berkeley sockets API. This will make it
simple to port non firewall friendly apps to use this protocol.

Messages, client->server:

Format:

1 byte - message number
followed by:

(todo: map API calls to binary messages)
Create
Bind
GetLocalAddr
Listen
GetPeerAddr
Connect
Send
SendTo
Close
IoCtl (used for multicast sockets)

Messages server->client

Create result
Bind result
Accept
Connect result
Recv
IoCtl result

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip