[918] in Commercialization & Privatization of the Internet
Re: Software Sales via e-mail
daemon@ATHENA.MIT.EDU (Dennis Ferguson)
Mon Jul 8 01:35:36 1991
From: Dennis Ferguson <dennis@MrBill.CAnet.CA>
To: SEAN@dranet.dra.com
Cc: com-priv@psi.com
Date: Sun, 7 Jul 1991 21:59:48 +0100
>>I will grant that commercial transactions across the public NSFnet
>>Internet might be considered disclosed, but commercial customers are
>>able to use internet technology and commercial internet service to move
>>sensitive documents from one place to another with no fear of de facto
>>disclosure. I would certainly think that that should hold today if I
>>was moving something from a site on PSInet to a site on CERFnet.
>I don't know if it is really a technological issue. I'm not sure about
>the contractual relationship between PSINET and CERFNET. But assuming it
>exists, it should be possible to entrust a packet of information to one
>for delivery to the other. Although most of the contracts for IP services
>I've seen disclaim all possible responsibility for delivering the packet
>at all, let alone to the correct recipient.
I didn't see the original note, but as stated I do think this is at least
in part a technological issue. One issue is that we are missing routing
technology to enforce usage restrictions and "appropriate use" routing.
For example, my understanding is that PSInet and CERFnet will be connected
at a single spot, which represents a single point of failure. Traceroute
tells me that both networks default route to the NSFnet, which means that
without fairly careful routing policy construction a failure at the point
of connection between the two networks will result in a fall back routing
via the NSFnet. If crossing the NSFnet represents disclosure of information
you wanted to keep private (even ignoring the violation of their usage
policies) you really don't want this to happen. Yet the only way we
have to prevent this is to prevent the fallback for all traffic between
that source and destination, and this might be a little unfortunate if
the bulk of the traffic between the two locations actually is appropriate
for the NSFnet routing and you'd really only like the business stuff
held up by the failure.
Another related example is that of a company which has access to the
research parts of the Internet, perhaps to play with the big-bandwidth
stuff, but also wishes to send business traffic via a lower-speed
commercial service. How does it keep the two separate?
There are a couple of items I think are worth thinking about:
(1) The Internet routing system is complex, and the technology used
on the public Internet was designed with more attention to "keep
it working at all costs" robustness than to things like "secure"
or "appropriate" routing. A commercial internet service provider
would have to think very hard about guaranteeing any particular
routing for any particular data. You can't depend on routing if
you need guaranteed privacy, you will need to use end-to-end
encryption. The latter is immature technology on the Internet.
(2) This still leaves the problem of ensuring that packets follow
appropriate routing for their contents when you make significant
use of both the research and the commercial parts of the Internet.
Ideally, when the CIX broke, you'd really like PSInet-CERFnet R&E
traffic to fall back through the NSFnet, but have strictly-business
traffic stopped dead until the problem is fixed. This, as an
example of the general problem of sharing the same infrastructure
for various, routing-sensitive purposes, is an interesting
application for type-of-service routing. What would be neat
is having a Strictly-Business (and maybe a Pornographic-GIF) TOS
class to make sure things go where they are supposed to. Rudimentary
TOS support exists in some modern routing protocols, but this
tends to be largely unimplemented (perhaps because no one found
the existing classes practically useful enough to expend the
effort of implementing).
I know privacy technology is receiving attention, though to tell the
truth some of your government's policies concerning this technology seem
to me to sometimes be a considerable inhibition to quick progress. TOS
routing is receiving no serious attention that I know of. If the latter
is interesting it might be worth while expressing this to the IETF.
Dennis Ferguson
