[JDEV] DSPS
Ben Schumacher
ben at blahr.com
Wed Jul 24 14:12:57 CDT 2002
(cross-posting again. i'm such a bad man.
stpeter, maybe you should just boot me from the list.)
While I agree with your point, I personally don't think its as big of a
problem as you think. Personally, I find it to be rather unlikely that any
public Jabber servers will even run a DSPS component on their server, at
least in a public environment. While I can see it getting used with
corporate networks, because it provides useful abilities (read:
multicast), anybody who's paying for bandwidth and running a public server
won't want these "virtual" network connections to be causing increased
load on their network.
If you don't believe that, consider the behavior of every file sharing
network out there. While some of these are true peer-to-peer (Gnutella,
Kazaa?) and others use a hybrid peer-to-peer/server approach (Napster,
eDonkey 2000) all of them share one thing in common, file transfer always
take place peer-to-peer.
I really think people are missing this larger issue in DSPS. That's why I
would propose that the protocol be modified to be able to be used to
negotiate peer-to-peer connections if possible, and use the
client-server-client connections if necessary. Even in this case, I think
any implementation of this protocol will need to have the ability to
disabled server assisted file transfers (at the cost of potentially
blocking some users from being able to establish a "stream"), otherwise it
will never be adopted by companies that have to pay for their bandwidth
and are running public servers.
Cheers,
bs. (jid: rynok at jabber.com)
On Wed, 24 Jul 2002, Richard Dobson wrote:
> I dont think you quite get the point, ordinary NAT servers (without port
> forwards) do not allow incoming connections into local machines so people
> inside cannot setup servers that people on the internet could connect to.
> But using DSPS people inside a NAT can setup servers that people outside can
> connect to (that is its function afterall) via the proxy'd socket on the
> DSPS server bypassing the NAT and its security, which if people are not
> allowed to host servers (listening sockets) to the outside world (which a
> NAT usually prevents) will possibly get the person bypassing the security
> sacked (or if at an educational institution expelled), and also make the
> network admins start blocking jabber access. You cant expect all network
> admins to have forseen all possible sources of breaches (especially for
> protocols that are extremely new, i.e. DSPS), also in my experience network
> admins react to breaches and start blocking things, rather than pre-blocking
> potensial things, either because they havent got the time, dont know about
> the possible breaches or cant be bothered, not a good thing but is a fact of
> life.
>
> The whole point of this is that sure, they may not oridinarily be too
> worried about outgoing connections, but DSPS allows the creation of virtual
> incoming connections that would not ordinarily be possible.
>
> Richard
>
> ----- Original Message -----
> From: "Dave" <dave at dave.tj>
> To: <jdev at jabber.org>
> Sent: Wednesday, July 24, 2002 6:04 PM
> Subject: Re: [JDEV] DSPS
>
>
> > If they're worried about outgoing connections, they should setup a
> > firewall that blocks them, too. If their firewall allows outgoing
> > connections without having to hack around something (or crack into
> > something), they're allowing you to create outgoing connections as a
> > matter of policy (since NAT and IPMasq both involve very _active_ roles
> > that the firewall must play in order to _allow_ you to create outgoing
> > connections - clearly, a company wouldn't be so foolish as to implement
> > an added feature only to disallow its use).
> >
> > - Dave
> >
> > Hmm ... so much for my plan not to reply :-(
> >
> >
> > Richard Dobson wrote:
> > >
> > > Yes but if a SOCKS server will not be setup and it is because of network
> > > security etc then you shouldnt really be trying any method of breaching
> the
> > > firewall, as that will most likely be against company network use
> policies
> > > and could quite possibly get you sacked.
> > >
> > > Sorry to put a dampener on this it looks for for some uses (helping
> people
> > > with home nats) but it has problems where it may be possibly breaching
> > > security policies, it may also cause the network admins to actively
> block
> > > all jabber connections if they find people using it to breach network
> > > security even if they wernt too worried about it being a threat before.
> > >
> > > Richard
> > >
> > > ----- Original Message -----
> > > From: "Dave" <dave at dave.tj>
> > > To: <jdev at jabber.org>
> > > Sent: Wednesday, July 24, 2002 2:03 AM
> > > Subject: Re: [JDEV] DSPS
> > >
> > >
> > > > Often, the problem is not technical (a SOCKS server can't be setup
> because
> > > > it'd compomise network security), but is rather administrative (a
> SOCKS
> > > > server can't be setup because there's too much beauracracy involved,
> > > > plus the possibility that the network admin is too scared to poke
> holes
> > > > in his firewall, not realizing that allowing outgoing connections is
> > > > already poking a hole big enough for people to create virtual incoming
> > > > connections). Also, an old hardware-based firewall may not even
> support a
> > > > SOCKS add-on. Finally, there's no real reason for people to have to
> setup
> > > > a rather complex piece of software on their firewalls just so they can
> > > > transfer files in Jabber; let them use a server-based solution
> instead.
> > > >
> > > > - Dave
> > > >
> > > > BTW - Due to my bad luck at avoiding running over my quota for daily
> > > > messages when answering your emails, I don't plan to reply to any more
> > > > messages in this thread.
> > > >
> > > >
> > > > Richard Dobson wrote:
> > > > >
> > > > > Why not just get people to use SOCKS5 ?? or similar instead of
> trying to
> > > > > reinvent the wheel as it were. If on a corporate LAN and there is a
> > > firewall
> > > > > with no SOCKS server then people probably shouldnt really be trying
> to
> > > > > bypass the company firewall anyway. If not then they need to pester
> the
> > > > > network manager to set up a SOCKS server to service the jabber
> clients.
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com>
> > > > > To: "JDEV Mailing List" <jdev at jabber.org>;
> <standards-jig at jabber.org>
> > > > > Sent: Tuesday, July 23, 2002 7:51 PM
> > > > > Subject: Re: [JDEV] DSPS
> > > > >
> > > > >
> > > > > > The original intent of DSPS was to address the problems
> transferring
> > > > > > data to/from "firewalled" clients, without introducing new issues
> (as
> > > > > > with PASS).
> > > > > >
> > > > > > The current spec talks solely about components, although a
> > > "stand-alone"
> > > > > > server could be utilized. Also, although it is not by design,
> this
> > > > > > could handle direct connections, with one of the clients acting as
> a
> > > > > > DSPS "server" (for connection-handling only; I know I wouldn't
> want
> > > > > > someone trying to tell my client to create a DSPS connection for
> them
> > > > > > (-: ). This (a client-side DSPS "server") is something I've
> thought
> > > > > > about just recently, while looking at how we can "clean up" the
> > > current
> > > > > > specification.
> > > > > >
> > > > > > At its core, DSPS is fairly easy to support from a client (as
> others
> > > > > > have stated). Also, it's "required" functionality (which, I
> admit, is
> > > > > > not clearly differentiated from "optional" functionality) is not
> all
> > > > > > that difficult to implement, and (with modifications, or a new
> spec)
> > > > > > could be used in direct, P2P connections.
> > > > > >
> > > > > > Personally, I think a single "standardized" method of handling
> "data
> > > > > > connections" needs to be defined for Jabber, whether it be via
> DSPS,
> > > > > > PASS, or even modifications to the current OOB mechanism.
> Currently,
> > > I
> > > > > > can see DSPS as becoming an adequate, maybe even preferred, method
> of
> > > > > > doing this.
> > > > > >
> > > > > > This is my opinion, although your mileage (and opinions) may (most
> > > > > > likely) vary.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, 2002-07-23 at 10:50, Ben Schumacher wrote:
> > > > > > (Cross-posting, cause I think it applies to both lists.)
> > > > > >
> > > > > > I agree, that using a stream layer separate from the file
> transfer
> > > > > would
> > > > > > be preferred, I just think we shouldn't rely on a server as a
> > > passthru
> > > > > in
> > > > > > all situations. Working around firewall issues is a problem
> that
> > > has
> > > > > been
> > > > > > solved by nearly every peer-to-peer network in existence, so I
> > > assume
> > > > > > there has to be a solution that will work for Jabber. In fact,
> by
> > > > > keeping
> > > > > > the stream layer separate, it should be possible to initiate
> the
> > > > > connect
> > > > > > from either side and then do a data transfer in either
> direction.
> > > This
> > > > > way
> > > > > > if I am behind a firewall, but the person I'm communicating
> with
> > > > > isn't, I
> > > > > > can open a connection to them and then push my data across.
> > > Perhaps
> > > > > the
> > > > > > DSPS spec should be expanded/altered to the point where it
> doesn't
> > > > > > necessarily imply that a proxy is necessary.
> > > > > >
> > > > > > Currently, the server doesn't have any knowledge of what a
> user's
> > > IP
> > > > > is
> > > > > > beyond socket creation, and I would guess that this will stay
> this
> > > way
> > > > > in
> > > > > > the open source implementation -- it is a privacy concern,
> after
> > > all.
> > > > > That
> > > > > > being said, however, it would be pretty easy to write
> something
> > > that
> > > > > would
> > > > > > have this information (a DSPS component?) available if it was
> > > > > necessary.
> > > > > >
> > > > > > Does any of this make sense? I'm just trying to avoid
> > > > > designing/developing
> > > > > > something that will not be used, because servers probably
> won't
> > > want
> > > > > to
> > > > > > take the extra bandwidth hit just to provide their users with
> the
> > > > > ability
> > > > > > to do file transfers.
> > > > > >
> > > > > > bs.
> > > > > >
> > > > > > On Tue, 23 Jul 2002, Justin Karneges wrote:
> > > > > > > The problem is that there is otherwise no real clean way to
> > > > > establish a direct
> > > > > > > connection. Everyone is behind a firewall these days.
> > > > > > >
> > > > > > > Maybe jabberd should support a way of getting your external
> IP
> > > > > address, so
> > > > > > > that there could be some sort of stream negotiation between
> two
> > > > > clients. As
> > > > > > > it stands, clients don't even know what their real external
> > > address
> > > > > is unless
> > > > > > > you were to specify it directly (not exactly user-friendly).
> > > > > > >
> > > > > > > The "stream" idea IMO makes more sense than just http URLs,
> > > because
> > > > > it implies
> > > > > > > more possibilities than just file transfer. It also keeps
> the
> > > > > stream
> > > > > > > handshake as a separate layer, which simplifies things when
> you
> > > > > consider the
> > > > > > > various possible methods of transport (TCP, DSPS, PASS,
> > > > > XML-thru-server??),
> > > > > > > SSL, reverse-connections, etc. I completely agree with Rob
> > > about
> > > > > keeping the
> > > > > > > stream layer _separate_ from the file transfer.
> > > > > > >
> > > > > > > DSPS is dead-easy to use from a client perspective. What we
> > > need is
> > > > > something
> > > > > > > similar to it, as a standard part of jabberd, that allows
> > > clients to
> > > > > ask for
> > > > > > > a stream to another JID. Something very simple like: "Oh,
> you
> > > want
> > > > > > > joe at blow.org/Home? Connect to this IP address." This might
> be
> > > > > through DSPS,
> > > > > > > or it might be direct, or whatever. I'm just saying, we
> need a
> > > > > simple way
> > > > > > > for clients to ask for a stream. DSPS seems to have a nice
> > > > > interface, but it
> > > > > > > assumes we want to route through an external point. Maybe
> the
> > > real
> > > > > solution
> > > > > > > is to have an even smarter component that will hook you up
> > > directly
> > > > > to the
> > > > > > > other person if possible, otherwise fall back to DSPS (all
> > > hiding
> > > > > this from
> > > > > > > the client).
> > > > > > >
> > > > > > > The current situation is not optimal.
> > > > > > >
> > > > > > > -Justin
> > > > > >
> > > > > > _______________________________________________
> > > > > > jdev mailing list
> > > > > > jdev at jabber.org
> > > > > > http://mailman.jabber.org/listinfo/jdev
> > > > > > --
> > > > > >
> > > > > > Matt "Linuxwolf" Miller
> > > > > >
> > > > > > - Got "JABBER"? (http://www.jabbercentral.org/)
> > > > > >
> > > > > > _______________________________________________
> > > > > > jdev mailing list
> > > > > > jdev at jabber.org
> > > > > > http://mailman.jabber.org/listinfo/jdev
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > jdev mailing list
> > > > > jdev at jabber.org
> > > > > http://mailman.jabber.org/listinfo/jdev
> > > > >
> > > >
> > > > _______________________________________________
> > > > jdev mailing list
> > > > jdev at jabber.org
> > > > http://mailman.jabber.org/listinfo/jdev
> > > >
> > >
> > >
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > >
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> >
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
More information about the JDev
mailing list