[JDEV] DSPS
Dave
dave at dave.tj
Wed Jul 24 12:04:33 CDT 2002
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
>
More information about the JDev
mailing list