Abstract

Many popular protocols deployed in the Internet today were designed
years before security, cryptographic authentication and data encryption
were an issue. Examples for such protocols are POP, telnet, X11-remote-display,
and FTP. These protocols are considered insecure nowadays, and
if we were living in an ideal world, they would have been replaced
by more sophisticated protocols completely.

In fact, though, Internet services based on these protocols are
used more than ever before, because of the widespread availability
of implementations for all platforms and operating systems. A
large organization or company cannot afford to discontinue services
like POP or FTP, because so many of their members or employees
are using them.

The solution for this dilemma is to tunnel the insecure protocols
through secure channels, which are protected by strong cryptography.
Even though software for this purpose is widely available already,
the Secure Shell (SSH) for example, experience has shown that
the concept of tunneling is not easy to understand.

In this paper, the authors will explain the concept of tunneling
TCP connections through secure channels in great detail. Furthermore
we will provide several examples, how tunneling can be implemented
transparently for the users of a system, explain the necessary
changes in the configuration of the server- and the client-side
of the service, and discuss the problems that arise when tunneling
is used through a firewall.

During our work in the German National Research Center for Information
Technology (GMD), we have also measured the performance penalty
that arises from encrypting and possibly compressing frequently
occurring TCP connections and will present the results here.

The paper has been written mostly for the administrators and users
of Unix and Windows NT workstations, but only very few parts actually
depend on the deployed operating systems. The underlying concepts
of tunneling are valid for all kinds of operating systems and
software implementations.

The Internet was designed to provide a robust transmission facility
of data packets that remains in operation even if parts of the
infrastructure are out of service or not available. Security was
not a major issue while defining the underlying protocols nor
while defining many applications on top of TCP/IP.

Although the fundamental vulnerabilities of computers that are
connected to the Internet have been known for a long time, the
flaws have been accommodated rather than corrected. As a result,
within the recent years, many cases of wide-scale security infractions
have occurred.

However, many users connected to the Internet rely on services
like POP, SMTP, telnet, and X11 despite their immanent security
risks. Even more, without using them there would almost be no
reason to connect to the Internet at all.

Security-enhanced versions are available for some of the vulnerable
services, but not for all of them. In addition, they are not widespread
within the Internet. One possible way to overcome these drawbacks
is the use of TCP-based tunneling solutions, as described in this
paper.

The paper is structured as follows: After the different types
of attacks to TCP-based protocols are categorized in section 2,
section 3 describes how tunnels operate in principle. Section
4 presents an overview of available software solutions. Sections
5 and 6 deal with tunneling simple and complex protocols and electronic
mail. Potential problems and performance penalties stemming from
using tunnels are discussed in section 7. Section 8
describes some alternative solutions to application-level tunneling
while section 9 concludes the paper.

Before we take a look at the technical details, it is important
to clarify the terminology used throughout this paper. The term
"service" is used to denote an Internet-specific application
like the exchange of electronic mail or the transfer of a file
from one machine to another through the network. These services
are based on specific "protocols." Electronic mail is
exchanged with the Simple Mail Transfer Protocol (SMTP), and files
are transferred via the File Transfer Protocol (FTP), etc.

The protocols discussed in this paper are based on TCP/IP, the
protocol stack of choice in the Internet. That is, a TCP connection
is opened from one machine to the other, and the protocol- or
application data is transferred through it. In the Internet, other
types of protocol layers exist, such as UDP or Multicast transmissions,
but those are beyond the scope of this paper.

Every TCP-based service in the Internet is identified via a unique
"port number." When a client initiates a connection
to a server, it chooses to connect to, say, port 25 on the
remote machine. According to [RFC 1700],
port 25 is assigned to the SMTP protocol and thus to the
service of delivering an electronic mail.

Most well-known and popular services are assigned a port number
in the range from 0 to 1024, but the valid port numbers range
from 0 to 65535.

Throughout our text, we will use the name of the protocol in question
to denote the TCP port associated to this protocol and the service
for which the protocol is deployed. Only when the context might
be misleading will the accurate distinction between the service,
the protocol, and the port number be made.

In recent years, sniffing has become a pressing problem. IP packets
are transferred on a hop-by-hop basis. So, they can be intercepted
by all intermediate hosts. In addition, these packets are generally
transferred via broadcasting media within local networks. Thus,
every host can eavesdrop on all data packets on the network it
is directly attached to.

Unfortunately, almost every popular and widespread Internet service
like SMTP, POP, HTTP, telnet, the r-commands, and X11 transmits
its data in clear text, thus allowing eavesdropping on sensitive
or private information. Even worse, many of these services rely
on a password-based authentication scheme at which accounts and
passwords are also transferred in clear text. In the case of POP,
for example, the password is transferred every time the POP client
accesses the server, which normally happens every few minutes.

Due to their passive nature, sniffers can practically not be detected.
Supporting all kind of TCP/IP-based application protocols, they
are quite convenient to use. They can store the intercepted information
locally over a long period of time so that there is no need to
initiate frequent connection requests to forward the data which
could be traitorous.

After a successful establishment and authorization, an attacker
can try to take over the connection. The targets of this very
technical attack are terminal or login services, such as telnet.
The stolen connection can then be used to initiate requests with
the access rights of the originating user and to intercept the
replies.

Many services require no authentication at all or rely solely
on IP addresses or domain names. Quite often SMTP servers accept
e-mail messages from any host without authentication. The same
holds for anonymous FTP as well as Web and gopher servers (as
long as they do not offer access to restricted documents). All
these services are subject to command channel attacks where ordinary
protocol commands are used to exploit security breaches.

Services like SMTP can also be used for data driven attacks. In
the case of SMTP, the service may be subverted for mail bombing
or for distributing (macro) viruses.

The rlogin and rsh services rely on trusted hosts
and/or trusted users to grant access to the system without requesting
a password. Also, FTP or Web servers can be configured in such
a way that they allow access to restricted data to specific hosts.
But relying on IP-addresses or domain names provides no real protection.
IP addresses can be spoofed, and even reverse or double reverse
look-ups of DNS information do not offer substantially more security
because DNS entries can also be forged quite easily by an experienced
attacker.

Besides passively monitoring a network (sniffing), an attacker
can also manipulate transmitted datagrams or inject new ones.
In general, all clear text protocols and services are vulnerable
to this kind of attack.

Being able to monitor all passing traffic and to connect to a
service (e.g., via IP spoofing) also opens an avenue for replay
attacks where parts of an ongoing legal communication are recorded
and replayed later on.

But even with a perfectly secure design, a service may suffer
from implementation bugs such as a buffer overflow which may be
used to gain access to the host. In the context of Web servers,
poor CGI scripts which pass user-provided data to a command shell
without carefully checking are wide-open avenues for attackers.

Additional security breaches may result from misconfiguration.
A poor configuration of an anonymous FTP server, for example,
may put the whole machine at risk.

With the launching of a denial-of-service attack, an existing
service is made unavailable to its authorized users. This can
be achieved by flooding the server with faked connection requests,
like the popular SYN-flood attack. While the flooding takes place,
the attacked host is virtually detached from the network.

Other attacks are protocol specific. SMTP messages received for
local users are ordinarily stored on local disk. Hence, if a SMTP
server is flooded with e-mail messages, the service can be made
unavailable for other users, and in addition the local file system
can be filled up entirely. But this is not a SMTP-specific problem;
virtually every externally accessible service can be made unavailable
by flooding it with requests.

The goal of tunneling insecure protocols is to identify networks
that are assumed to be secure. A company's internal network, for
example, is usually protected by a sophisticated IP packet filter
or firewall software, rendering all attacks to the inside of the
network unfeasible. The outside network, on the other hand, is
known to be insecure.

Let us, for example, contemplate what happens when an employee
of the company accesses his electronic mail at work from his private
workstation through the Internet, using the insecure [POP3]
or [IMAP] protocols. His user password and
the contents of the e-mail are not protected and may be eavesdropped
on.

This is a serious security threat not only to the privacy of the
employee, but also to the security of the company and the company's
internal network. Of course, eliminating this threat is simple:
Just disallow the employee to read his e-mail at home by configuring
the packet filter mechanism appropriately. Unfortunately this
may be unfeasible as employees might be required to access their
electronic mail through the Internet from wherever they are.

A secure tunnel is the appropriate solution for this dilemma.
The concept of tunneling is illustrated in figure 1
below.

Figure 1. How do tunnels work?

Using the mail-reading example from above, let us say that a user
wants to read e-mail on server A, B, or C, using the insecure
POP3 protocol. Instead of connecting directly to the server machine
at TCP port 110, he or she opens a secure connection from
the client machine to the tunnel server. This secure connection
is made with a special tunneling software that features strong
encryption and authentication.

The tunneling software, once started at the client machine ('Private
Workstation'), listens to, say, TCP port 5000. All communication
requests are forwarded through the encrypted tunnel to the tunnel
server, which in turn decrypts the incoming data and forwards
it to the mail server at port 110.

Now the users configure the POP3 software to connect to localhost,
port 5000 and engage the mail-fetching process. The POP3
connection is now tunneled through the insecure network by the
tunneling software and then transparently forwarded by the tunnel
server to the mail server again.

This works as follows: Both the client and server software speak
plain and insecure POP3 with each other, being completely unaware
of the tunnel server and the functionality it performs. The mail-fetching
process works just fine with the normal, unmodified POP3 programs.

Due to the tunnel, all data transmissions between the client machine
and the tunnel server are encrypted and have been authenticated
properly. The transmission between the tunnel server and the mail
server is an ordinary POP3 connection, but it lies within the
secure company network and can not be eavesdropped on or abused
otherwise.

This approach fixes two important problems:

The insecure POP3 protocol can be used in a secure fashion,
using the well-known software.

The packet filter or firewall software protecting the company
network does not need to have any holes to allow employees to
read their electronic mail. The packet filter needs to allow only
connections to the tunnel server -- nothing else. And this interface
is secure due to the functionality of the tunneling software.

The Secure Shell (SSH) can be found at [SSH].
Versions exist for the Unix (including full source code) and Windows
operating systems. For new users, a brief tutorial can be found
at [SSH-TUT].

The SSH is not exactly a tunneling software. In fact, the ability
to tunnel connections securely is only a byproduct of SSH's other
capabilities. Mainly, the Secure Shell is a replacement for the
well-known telnet, rlogin, and rcp services. SSH uses strong cryptography
(RSA, IDEA, 3DES, and other algorithms) and authentication to
allow users to log into a Unix machine remotely. SSH's protocol
protects against all attacks described in the first section. It
also features the ability to open secure tunnels as described
in the second section.

In our paper, we will use the SSH to demonstrate the real-world
applications of tunneling connections, because it is a very sophisticated
and useful tool and is available for free for Unix users.

The Secure Socket Layer Protocol, developed by Netscape, has become
a de facto standard. SSL implements an additional layer between
TCP and the application layers (FTP, HTTP, SMTP, etc.). Complete
authentication and encryption happen in the Secure Socket Layer.
To use SSL, special client and server programs are needed. The
applications are not involved, there are no changes necessary,
and all standard application programs will work.

SSL connections are built up in two phases. A handshake protocol
is started; server and client agree on an encryption method and
key. The server sends its certificate [X.509]
for authentication -- optional client authentication is possible.
Also, various public key encryption methods are available and
different kinds of hash functions can be chosen.

After the server certificate is verified (and optionally the client
is authenticated via the client certificate), an encryption method
is selected. A session key is exchanged via public key encryption
or token-based encryption systems. This session key can use one
out of a number of secret (symmetric) key algorithms for encrypting
the session.

Now phase two begins. The proper session starts, the message is
fragmented into blocks, a MAC (message authentication code) is
used, and the single blocks (packets) are encrypted and transmitted.
On the other side the received packets will be decrypted, verified,
put together, and delivered up to the higher levels. Client and
server certificates use X.509. This enables a complete authentication
of both client and server and guards against "man-in-the-middle"
attacks. [SSL3]

Most commercially available products use 40-bit RC4 keys for session
encryption. This is forced by the US encryption export laws. But
there are also free products available which use strong encryption
too.

A well-known application of SSL is HTTPS, but other programs like
sslftp or ssltelnet are available on the Internet (see [CERT]).
A widespread Web server with an optional SSL extension is the
[APACHE] Web server.

The following applications for secure tunnels are real-world examples
that fulfill useful functions in the authors' everyday work. We
have emphasized the practical aspects of these tunneling examples
and present actual implementations for the Unix operating system,
using the Secure Shell, SSH.

All examples can be used in a Windows environment with the SSH,
too. The differences in the SSH's user interface are trivial,
as all the concepts are exactly the same.

A "simple protocol" is one that uses only one TCP connection
to perform all its functionality. Most protocols used in the Internet
today are of this type, and tunneling them is pretty easy, once
one becomes used to the way this is accomplished.

POP3 is used to transfer electronic mail from the mail server
to the local machine and is typically implemented in the mail
reader. In our example, the mail server is called mail.my.org
and the tunnel server is called tunnel.my.org.

Now a user wants to get his e-mail from the company mail server
to his private workstation through the Internet. First of all,
the tunnel needs to be opened. This is achieved by executing the
following command:

$ ssh -L 110:mail.my.org:110 tunnel.my.org

The SSH will now log into the tunnel server and open the tunnel.
For this to succeed, the user needs an accessible shell account
on the server, into which he or she can log. This may be either
a personal account or a generic account to which all employees
have access. The authors recommend the use of personal accounts,
because this gives more power to the server administrators to
control what is occurring on their machines.

What happens now is this: When the login succeeds, SSH will start
to listen to port 110 (POP3) on the local machine, that is,
the private workstation of the user. Every connection that arrives
there is tunneled through the secure connection to tunnel.my.org.
The tunnel server will then forward the connection to the machine
mail.my.org, to port 110.

So all the user has to do is to tell his mail client that the
POP3 server to query for e-mail is the local machine: localhost.

Of course a normal telnet session can be tunneled, too. The corresponding
port is 23. So if one wants to telnet into the server server.my.org,
this command will open the tunnel:

$ ssh -L 23:server.my.org:23 tunnel.my.org

To start the telnet session, execute

$ telnet localhost

Obviously, there is little point in tunneling a telnet session
to a Unix server. One should rather log into that machine with
the SSH directly, which is easier and adds additional benefits
the SSH provides. But still there are enough machines that cannot
be equipped with an SSH server, such as ISDN routers, which frequently
need to be accessed with telnet.

A "complex" protocol is one that uses more than one
TCP connection. A good example for this is the File Transfer Protocol
(FTP) discussed below. Tunneling of complex protocols can be tricky
or flatly impossible.

The FTP protocol uses two connections: a control channel and a
data channel. Over the control channel, the user logs into the
FTP server and browses through the available files or issues any
GET or PUT commands. Once such a command has been given, the FTP
server and client open up a second channel over which the actual
data transmission takes place. When the file transfer is over,
the data channel is closed and control is given to the control
channel again.

The problem when trying to tunnel FTP is that it is not possible
to predict which ports will be used for the data channel. The
control channel is always opened at port 21, but the data
channel may use any port that is available, and the actual number
is negotiated between the client and the server on the fly.

So it is possible to tunnel the control channel, thus securing
the login and password of the user. But the actual data transmission
will take place without protection. Protecting the user and password
information is better than nothing, but the authors recommend
that one consider using the SCP tool provided in the SSH distribution,
to replace FTP for file transfers completely, when sensitive data
has to be exchanged.

An important feature of the graphical interface X11 is the ability
to forward graphical objects, like windows, through the network
to a remote machine.

Such transmissions can be secured with SSH, too, even though this
is not achieved with the usual tunnel approach. The SSH login
tool has a built-in X11 forwarding mechanism, which does this
transparently. When logging into a remote server with the SSH,
a pseudo-display is set up there and the $DISPLAY environment
variable is set automatically.

As a result, all started programs will open their displays as
usual, but internally, the transmission is tunneled through the
connection without any further effort.

A rather unexpected, useful application of tunneling is the protection
of company internal electronic mail. For the sake of the example,
let us contemplate an imaginary company of the name "Big
Bucks." Big Bucks has two major departments which are located
in Tokyo, Japan and Birlinghoven, Germany. The corresponding Internet
subdomains for each department are tokyo.big-bucks.com
and birlinghoven.big-bucks.com.

Naturally, e-mail is used a lot for internal communication between
the two departments of the company, but the problem is that this
mail is routed through the insecure Internet and consequently
is subject to eavesdropping or even modification. Because many
of the employees of Big Bucks are nontechnicians, it is not suitable
to enforce that all e-mail be sent encrypted.

A simple SSH tunnel between the two divisions of Big Bucks can
solve this problem easily and comfortably. We describe the set-up
below:

All machines are configured to deliver all nonlocal mail to
the mail server. This can be assured by blocking outgoing connections
to the SMTP port (25) via an IP packet filter or firewall software.

mail.birlinghoven.big-bucks.com and mail.tokyo.big-bucks.com
will deliver outgoing mail for recipients in the Internet, or
within the division's network, as usual.

mail.birlinghoven.big-bucks.com will send all e-mail directed
to the tokyo.big-bucks.com division to mail.tokyo.big-bucks.com
and vice versa. This delivery, though, is carried out through
a secure tunnel.

In this set-up, all company internal e-mail is transparently protected
against eavesdropping or modification -- the employees of Big
Bucks need not even be aware of this measure!

Practically, this set-up is realized as follows. We are assuming
the standard Unix sendmail program, version 8, is installed.
The tunnel is done via SSH.

Opening the required tunnels is nothing really new, so we will
keep the description brief. On mail.birlinghoven.big-bucks.com,
the tunnel to mail.tokyo.big-bucks.com is opened by logging into
the other machine with the command

Configuring sendmail is a bit more tricky. First of all, it is
essential that all machines are configured to relay all outgoing
mail via the appropriate mail server. With sendmail, this can
be accomplished by adding the following statement to the M4 configuration
file:

define(`SMART_HOST', `esmtp:[mail.birlinghoven.big-bucks.com]')

or

define(`SMART_HOST', `esmtp:[mail.tokyo.big-bucks.com]')

On other platforms, most notably Windows, this setting has to
be made in the user's mail reader (for example, Netscape), so
we will not describe it here.

Now we need to configure the mail servers. Both of them use the
following M4 file to create the sendmail.cf:

This configuration file is pretty normal, except for the definition
of the new mailer type "tsmtp." "tsmtp" is
the ordinary "smtp" driver, included in sendmail, except
for the fact that it will connect to port 5000, rather than
port 25.

Please note that this sendmail still behaves perfectly normally.
Mail is delivered with "ordinary" SMTP or ESMTP to the
usual ports. The only addition is a mailer that uses port 5000
instead.

Now comes the crucial part: On mail.tokyo.big-bucks.com, the following
file will now be installed in /etc/mail/mailertable:

.birlinghoven.big-bucks.com tsmtp:[mail.tokyo.big-bucks.com]

and then the command

$ makemap hash /etc/mail/mailertable.db </etc/mail/mailertable

is executed.

For mail.birlinghoven.big-bucks.com, the appropriate file is

.tokyo.big-bucks.com tsmtp:[mail.birlinghoven.big-bucks.com]

All e-mail addressed to recipients outside big-bucks.com is delivered
through the normal (E)SMTP client of sendmail. All other mail
stays either inside the secure company network or is tunneled
securely through the Internet to the other department's mail server.

There are various pitfalls that may cause trouble when using tunnels,
in particular with the SSH software:

On some machines, the SSH is compiled with the [TCPWRAP]
option included. TCP Wrapper is a program that controls who may
connect to certain services on the local machine. Even though
this is not obvious at first, this also affects the ability to
open tunnels on that machine.
The tricky bit is that the SSH connection will succeed just fine
and everything looks okay at first. But every time someone tries
to use the tunnel, the connection will abort without further comment
if TCP Wrapper disallows it. So if you are experiencing problems
using the tunnel, it is a good idea to specify the -v flag
of SSH when logging into the remote machine. This will turn the
"verbose-mode" on, giving you a more detailed description
of what happens and what does not happen.

In the default configuration, the SSH binary will be installed
with owner "root" and the "setuid" bit set.
This is necessary for the SSH to take advantage of the common
"rhosts" mechanism in Unix. In order to allow rhosts-authentication,
the client must engage the connection from a trusted port -- a
port number lower or equal to 1024, that is -- and these
ports can only be used as superuser.
The problem that arises from this behavior is that many company
networks are protected by an IP packet filter or firewall software
and the default configuration of these programs is to deny outgoing
and incoming connections from or to a port lower or equal to 1024.
Hence, if you attempt to log into the remote machine with SSH,
it will fail, even if you're not using the rhosts-mechanism at
all.
The solution is either to remove the "setuid-root" bit
from the SSH binary or to set the following configuration options
in /etc/ssh_config:RhostsAuthentication noThen the SSH will not use the trusted ports for outgoing
connections anymore.

In section 5.1.3, an example of
tunneling a telnet session was shown. In the example, the tunnel
was opened at the local machine on port 23. This is convenient,
because port 23 is the port assigned to the telnet service
and hence, a simple telnet localhost command would deploy
the tunnel as intended.
Often this will not be possible, though, because the local port 23
is already allocated by the telnetd program, the software
that accepts incoming telnet connections and handles them. The
same is true for an attempt to tunnel a POP3 connection from the
local machine to some remote server, using port 110. If the
local machine supports the POP3 service, too, then port 110
will be allocated already and opening the tunnel will fail.
Fortunately the solution is rather easy. Instead of opening the
local end of the tunnel at the port that is commonly assigned
to the service, one can use a random, free port number instead:
for example, port 5000. The only difference in this case
is that the client software, which initiates the connection, must
connect to port 5000 instead, rather than the port number
usually assigned to the service.
With almost any modern client software, the port number to connect
to can be configured at run time so that this doesn't pose a problem.

An interesting point to check is what encryption will cost. To
get some ideas of how encryption slows down the transmission,
we set the following experiment up:

A file of 7375432 bytes was transported between different hosts
using the built-in rcp and the scp command from the ssh-distribution.
The times were stopped for the whole rcp/scp command; both processes
used .rhosts for login authentication.

The ssh programs were compiled without any additional optimization;
we used our normal in-house network and the hosts were connected
via hubs and switches. SSH was configured not to use compression.
The encryption algorithm used was IDEA.

At first, the speed loss due to encryption may be surprising,
but it is clear that the loss suffered from the additional encryption
phase becomes more substantial the faster the network is. Practically,
this is not a big problem as the average network transmission
hardly exceeds the 10 MB/second rate in the Internet.

Furthermore, the choice of the encryption algorithm greatly influences
the performance. IDEA is considered to be the most secure algorithm
of those, available in the SSH. That's why we used it in our tests,
even though it is one of the slowest, too. Other algorithms --
for example, "Blowfish" -- are known to be a lot faster,
at the cost of some security.

There are two fundamentally different approaches to secure transactions
through the Internet: The one we described so far is on application-level;
the other one works on network-level. Both approaches have their
advantages and disadvantages.

In contrast to the method described so far by encrypting complete
sessions/associations between humans and applications, there is
also the possibility of encrypting on packet level. A new IP packet
type is added to the normal IP protocol, with security built into
each packet.

IPv4 and IPv6 use two specific headers in IP datagrams to provide
security services: the "IP Authentication Header (AH)"
and the "IP Encapsulating Security Payload (ESP)" header.
Both headers are used alternately or in combination to maintain
a Security Association (SA) for each destination network or host.
The SA is identified by a particular destination address and a
set of security parameters (Security Parameter Index, SPI) such
as authentication algorithm, encryption algorithm, or keys.

The IP Authentication Header (AH) is designed to provide integrity
and authentication without confidentiality to IP datagrams. It
holds authentication information for its IP datagram. It does
this by computing a cryptographic authentication function like
keyed MD5, DES, or CBC over the IP datagram and using a secret
authentication key in the computation. The sender computes the
authentication data prior to sending the authenticated IP packet.
The receiver verifies the correctness of the authentication data
upon reception. Certain fields needed for the transport of the
datagram are omitted from the authentication calculation. Use
of the Authentication Header will increase the IP protocol processing
costs and the communications latency.

The IP Encapsulating Security Payload (ESP) is designed to provide
integrity, authentication, and confidentiality to IP datagrams.
It does this by encapsulating either an entire IP datagram (Tunnel-mode)
or only the upper-layer protocol (e.g., TCP, UDP, ICMP) data inside
the ESP (Transport-Mode), encrypting most of the ESP contents,
and then appending a new clear text IP header to the now encrypted
Encapsulating Security Payload. The encapsulating security approach
used by ESP can noticeably impact network performance in participating
systems, but use of ESP should not adversely impact routers or
other intermediate systems that are not participating in the particular
ESP association. Use of encryption will also increase the communication
latency.

Several key management systems will be usable with AH and ESP,
including manual key configuration. Both of these IP mechanisms
can be used to increase the security provided by firewalls. Finally,
the Security Parameters Indexes (SPIs) used in the IP security
mechanisms are receiver-oriented, making them well suited for
the use in IP multicast (e.g., MBone).

Big vendors like [INTEL98] see the Virtual
Private Network Technology (VPN Technology) as a first step towards
building Internet-based networking in general by enabling secure,
private networking among LANs at multiple company sites. The reasons
for implementing this technology are not only security requirements,
but also cost, quality of service, and bandwidth issues.

Virtual Private Networks (VPNs) are implemented by encryption
software used between a firewall or router and communicating entities.
Because VPN software typically operates at the network level,
all application protocols like "FTP," "HTTP,"
or "SMTP" are encrypted transparently. The firewall/router
with VPN software simultaneously provides security services and
encryption. LAN protocol traffic is encrypted and encapsulated
in the TCP/IP protocol over the tunnel and then re-encapsulated
in the WAN protocol being used on the real WAN link.

VPNs will play an important role in the future by enabling secure
communication and cooperation in and between organizations even
over insecure networks like the Internet.

"Simple Key-Management for Internet Protocols" was developed
by Sun Microsystems, but the patents held by Sun were placed into
the public domain, so SKIP became an open standard.

SKIP handles security over the network layer, what makes the encryption
to be completely invisible for the applications and the user.
All packets between two hosts will be encrypted. The IP header
of SKIP packets has a protocol header field of 57, while TCP got
6 or UDP got 17 assigned by the Internet Assigned Numbers Authority
(IANA). The encrypted datagrams and the SKIP header, preceded
by an IP header, can be routed through every standard IP network.

The main goal of SKIP is to implement a usable key management.
Each host generates his own Diffie-Hellman (see [DIFFIE])
key pair and gets the public key certified by a certification
authority (CA).

Both hosts compute the same shared secret, using only the information
in their own secret and the other side's public key. This shared
secret will not be used to encrypt the traffic data directly.
It is used as a kind of master key in the further encryption process.
Each IP datagram is encrypted with a random traffic key, using
lightweight symmetric algorithms like DES, RC2, or triple DES.
This traffic key is encrypted with the long life shared secret
using a strong symmetric encryption algorithm. The traffic key
may be changed during the established connection due to a security
configuration or policy. SKIP is a sessionless protocol. Asynchronous
communication protocols such as UDP, ATM, ADSL, multicast traffic,
or satellite links can be handled with it.

The use of certified DH keys allows host authentication. No central
key management station is needed if all hosts are certified. Nevertheless,
SKIP may allow (due to configuration) new stations to enter the
SKIP community with dummy certificates.

There exist freely available implementations of SKIP for SunOS,
Linux, and FreeBSD. Commercial implementations are available for
several operation systems (see [SKIPSW]).

Network coupled security, as SKIP uses, is the conceptually superior
approach when it comes to protecting everyday data transmissions
over the Internet. Unfortunately it may still take several months
or even years before VPN technology reaches the acceptance and
sophistication required for everyday usage.

Until then, secure tunnels are a good way to protect network transmissions
now. The administrative effort of opening up secure tunnels
is negligible and for many applications, tunneling can be done
transparently, without the user knowing about it at all.

The costs in terms of performance are acceptable, especially with
the CPU power of computers growing constantly. For high-speed
networks like ATM, a hardware implementation of the encryption
algorithms would reduce the performance loss even further.

To sum up our experiences: There is no reason to accept the defects
of insecure or older protocols, because tunnels are available
now.