[1211] in Commercialization & Privatization of the Internet
Re: Interesting new player
daemon@ATHENA.MIT.EDU (Stan Hanks (bcm))
Sat Aug 24 21:40:04 1991
Date: Sat, 24 Aug 91 11:43:15 CDT
From: "Stan Hanks (bcm)" <stan@karazm.math.uh.edu>
To: kwe2@bbn.com, stev@ftp.com
Cc: com-priv@psi.com, edtjda@magic322.chron.com
> To: "Kent W. England" <kwe2@bbn.com>
> Subject: Re: Interesting new player
> From: stev@ftp.com (stev knowles)
> Cc: edtjda@magic322.chron.com, com-priv@psi.com
> Sender: stev@ftp.com
>
>
> >Metropolitan's new services are protocol-transparent. Using technology
> >designed primarily by Stan Hanks, they pick up the information,
> >encapsulate it, transmit it and offload it in a process they swear
> >is the hottest thing for network security since sliced bandwidth. :)
> >
> Joe, we call those things "bridges" where I come from. --Kent
>
> i would also be interested in hearing about the security aspect of it. . . .
OK, I guess I'll talk about what this stuff is and how it works. First,
I can't take full credit for "inventing" the encapsulator. See RFC 1241,
where Dave Mills and Woody Woodburn devised a similar scheme for encapsulating
traffic between *hosts* across the Internet. It also provides the necessary
vocabulary for discussing this stuff.
The basic concept is to make a routed IP network transparent to other
networks. This is done by creating closed virtual flows from point to point
or to multiple points. These flow endpoints then become entry and exit points
into a data cloud, which to the attached networks becomes a "opaque data
TRANSPORT object", indistinguishable from a piece of wire.
Note that this is very different from the concepts which we have developed
over the last 8 years of IP usage, which insist that internetworking devices
are themselves transparent to hosts, but networks are visible. This change
in paradigm is important to note, and is necessary to facilitate the
implementation of *secure* common-carrier style networks as opposed to the
"one big happy family" style Internet community.
Anyway, what an encapsulator does is pretty straightforward. Much like a
bridge (or for that matter a gateway) it decides what traffic needs to
be forwarded, to which flow it should be forwarded, then the *whole MAC
datagram* is encapsulated as the data portion of an IP encapsulation protocol
packet, which is then injected into the IP routed network. On arrival at
the target decapsulator, verification is done that this encapsulated packet
is OK to unpack, at which point the MAC datagram is forwarded to the external
network the decapsulator represents.
So, if you look at it from the external network side, yes, it does look
like a bridge, or possibly a repeater, depending on how you handle the
decision on what packets get forwarded. On the other hand, you could decide
to ignore IP traffic and allow it to be routed normally while encapsulating
non-IP traffic. Note that this would allow you to manage an IP backbone
while using any other protocols you needed to use for other business
reasons.
Yet, if you look at the encapsulator from the internal network side, it
is a host, transmitting datagrams to other hosts. By doing this you
have none of the disadvantages of building a bridge network, all of the
advantages of an IP-routed network (including multipath routing, which
gets to be important for capacity reasons). You get to transport lots
of protocols without having to manage the routing of these protocols. You
get to transport non-routable protocols without having to introduce bridges
into the network.
On security: in the MFS case, the internal network is not IP reachable
from external networks. The only traffic present in the network is either
encapsulator-to-decapsulator traffic, or MFS internal network management
traffic. In addition, all of the encapsulators are locked into MFS managed
space and are inaccessible to non-MFS personell, providing additional
physical security. If you want to hack the network and re-route traffic
between encapsulators, fine. You send your packet out, and the first thing
that happens is it gets encapsulated. As soon as that happens, it is effectively
neutralized until it gets delivered at the destination decapsulator, where
on receipt it is immediately passed to the external network on other
side. If you want to send the packet to someone you're not authorized
to talk to, you're out of luck as there's no way for you to affect the
mapping of traffic to virtual flows without being able to access the
MFS network management system. After substantial review, we think it's
at least as secure at the phone system 8{).
Anyway, I'm willing to discuss this either in this forum or off-line if
anyone has questions. I'm finalizing the documentation for this, and plan
on submitting it as an RFC. We're also going to make implementors guides
freely available. Don't hold me to this timetable, but I'd guess that
some info will be available in the first week of September and that the
full set will be out by October. I have this minor side-trip to the UK
for a few weeks that gets in the way of doing it sooner....
Regards,
Stanley P. Hanks Principal Scientist
Technology Transfer Associates, P.O. Box 2087, Bellaire TX 77402-2087
e-mail: stan@karazm.math.uh.edu voice: (713) 661-2084 fax: (713) 662-8504
