[standards-jig] DTCP Relay (proxy)

Ben Schumacher ben at blahr.com
Thu Dec 12 23:01:43 UTC 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin-

Please accept this criticism from somebody who has been a network
administrator for several service providers before moving on to software
development. What you are suggesting will not work in the real world,
and the "bad rap" that PASS received was because of its failure to
provide a real world solution for the problem of NAT'd addresses and
tight firewalls. Let me explain further below.

Justin Karneges wrote:
| Even so, the idea of using PASS is not as bad as it sounds.  I admit I
had not
| read the JEP fully until last night.  Now I wonder how it got such a
bad rap
| in the first place.  The old criticism about it using too many ports is
| easily solved using the <oneshot/> option.  The use of PASS allows
everything
| we want (compatibility with DTCP, end-to-end SSL, transparency to the
| target), and is already an Active JEP!  It almost seems too good to be
true.

That's because it is not good, because 1) it is simply an informational
JEP (not Active), 2) it provides no assurances that you are
communicating with the correct party, 3) it is not scalable, 4) it is a
nightmare for anybody administrating a network.

Let me expand on each one of those individually. And I'd like to
apologize to Jer, as I know he originally concepted and wanted something
simple, but its simplicity is what doomed it.

1) This is self-explanitory. It is an Informational JEP, meant to
document something that exists in the protocol, but isn't necessary, nor
necessarily useful. There is no reason for developers to support it, nor
should they.

2) The obvious arguement to this claim is to suggest using SSL over the
socket, and certificate verification. I will suggest that this is often
uncessary overhead, and a simple key exchange protocol like the one
documented in JOBS should be sufficient. I don't want people to be grab
whatever is being sent across to me, simply because they decided to do a
port scan.

3) Creating a new listen socket each time somebody new wants to send a
file from one NAT'd machine to another is not scalable. Period. Arguing
otherwise, won't change this fact. It is what it is.

4) As somebody who has managed networks and firewalls, I promise you
that I would never install software that would require a range of ports
to be open to use. If I'm running a service that unknown users could
connect to, I want to make damn sure I know what port they will be
connecting to. You will never convince me, or anybody else who is in
that position otherwise, it just doesn't make sense. When you're doing
network administration, you want to leave as little possibility for
error as possible. Its all an issue of risk/rewards analysis, and I
would never accept that risk for the reward of allow some of my users
the ability to transfer files. This just too much possibility for a
configuration mistake that opens up another server to attack.

The point is, saying that you don't want to deal with these things in
DTCP because its adds complexity is not sufficient. This issues need to
be addressed. The unfortunate thing is that expanding DTCP to address
all of these problems will most likely ultimately end up being very
similar to JOBS, and there will be a lot of lost time because some
parties have decided to be stubborn and not work together.

If you reread JOBS, you will notice that part of what makes it seem
complex is simply a result of the attention to detail that Matthew
Miller put into the design of the specification. It is my opinion that
there has been a lot of hand waving on the issue of DTCP, and I believe
that it is important to look behind the curtain for any JEP that is
considered by the JSF. Honestly, in some of the discussions that have
recently revolved around the issue bytestreams, I think that JOBS may
have some room for improvement (I especially like Dizzy's idea of using
'\0' as a separator.), but I still feel that it offers a more solid
basis for a solution.

Please understand that all I'm trying to provide here an alternate
perspective that you may not have considered.

Cheers,

bs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9+RVVUpoGqensAXIRAiZRAJ42dFfWKa2i5MIT7hgMbPwILmAbUwCglx0Y
VGrN0+/yKjQaMMI383giGGU=
=9w78
-----END PGP SIGNATURE-----




More information about the Standards mailing list