This document discusses
the Datacryptor® IP unit and how to deploy it to create a secure
tunnel. We will first of all look at a site without Datacryptor® and
then look at
different ways the units can be deployed in this environment.
Click
on picture thumbnail to view diagram The diagram above shows two private networks connected over the
public internet. Each PC on each network uses it respective router
as its default gateway. So, if PC 192.168.0.2 on site A wants to
ping 192.168.1.2 on site B the data path is:
192.168.0.2 >> 192.168.0.1 >> 195.0.0.1 >> <public
IP network> >> 196.0.0.1 >> 192.168.1.1 >> 192.168.1.2
The problem with this configuration is that anyone sat on the public
network can capture and read/modify the data contained in the IP
packets - consider this network insecure. Next we will look at the
different ways in which the Datacryptor® can be added to this
network.
- Datacryptor® in tunnel mode
First we look at tunnel mode. Tunnel mode is the most secure mode
as IP header and the data payload of the IP packet are encrypted.
The benefit of encrypting the data payload of the packet is obvious
- it prevents anyone reading the data contained in the packet. The
benefit of hiding the IP header is that anyone monitoring the packets
on the public network has no way of knowing what IP addresses are
being used on each site. This makes it much more difficult to map
and/or attack the internal network.
A Datacryptor® is added to each site as pictured below. The
configurations of the Datacryptor® are also below.
Click
on picture thumbnail to view diagram
|
 |
Click
on picture thumbnails to view diagrams |
|
 |
Click on
picture thumbnails to view diagrams |
For the hosts on network A and B nothing has changed
- they still have a default gateway of 192.168.0.1 and 192.168.1.1
respectively. The difference now is that these addresses correspond
to the Datacryptor® rather than the routers.
We have introduced a new network to each site. On site A we have
created a network of 172.16.0.x which sits between the Datacryptor® network
port (172.16.0.2) and the router's ethernet port (172.16.0.1). On
site B we have created a network of 172.16.1.x which sits between
the Datacryptor® network port (172.16.1.2) and the router's
ethernet port (172.16.1.1).
If PC 192.168.0.2 on site A wants to ping 192.168.1.2 on site B
the data path is now:
192.168.0.2 >> 192.168.0.1 >> 172.16.0.2 >> 172.16.0.1 >> 195.0.0.1 >> <public
IP network> >> 196.0.0.1 >> 172.16.1.1 >> 172.16.1.2 >> 192.168.1.1 >> 192.168.1.2
As you can see from the config files above it is necessary to add
Private Network Selectors (PNS) to each Datacryptor®.
The PNS list defines the addresses on the protected side of the Datacryptor® (e.g. the "host" or "red" or "private" side).
When the Datacryptor® receives a packet on its host port it
compares the source address with its PNS list - if the address is
not in the PNS
list it will be rejected (reporting an "ICMP destination unreachable" back
to the sender). If it is in the list the Datacryptor® will
look for a destination address match in its list of remote selectors/passthrough
policies
and process the packet accordingly.
On Datacryptor® A we have defined a PNS of 192.168.0.0 255.255.255.0
which means that this Datacryptor® is protecting a network
of hosts in the address
range 192.168.0.0 to 192.168.0.255. This is a "mask" type
of PNS - it is also possible to define a "single" (individual
host e.g. 192.168.0.50) or a "range" (range of addresses
e.g. 192.168.0.1 to 192.168.0.100).
Note how the routing has changed on our two routers. In the original
configuration without the Datacryptor® the routers had routing
entries for 192.168.x.x, now they have routing entries for 172.16.x.x.
Now if
we were to sit on the public network and view the traffic all we
would see would be packets going between 172.16.0.2 and 172.16.1.2.
The data payload would be encrypted and the original IP addresses
(192.168.0.x and 192.168.1.x) would also be encrypted. This is the
concept of the "tunnel" which exists between the two Datacryptor® -
the entry and exit points of the tunnel are the two host ports of
the Datacryptor®.
- Datacryptor® in transport mode
Transport mode differs from tunnel mode in the fact that the IP
headers of the packets remain intact. As was mentioned above, in
tunnel mode IP packets going across the network are encapsulated
into new IP packets with source/destination addresses of 172.16.0.1
and 172.16.1.2. This is not the case in transport mode - whilst the
data payload is still encrypted the IP header remains unchanged.
Click
on picture thumbnails to view diagrams
The routing entries become more complicated now. Consider the routes
on Router A:
192.168.1.0 255.255.255.0 via 196.0.0.1 - this
entry routes packets from site A to site B via Router B,
172.16.1.0 255.255.255.0 via 196.0.0.1 - this
entry routes packets from Datacryptor® A to site B via Router B - this
is needed so that key exchanges
between the two Datacryptor®s work.
192.168.0.0 255.255.255.0 via 172.16.0.2 - this
entry tells Router A to route incoming packets destined for site
A to the network port
of Datacryptor® A.
We could obviously simplify things by making the routers and the
Datacryptor®s each others' default gateway but static routes have been used
to illustrate the various IP traffic routes traversing the router.
- Datacryptor® in trunk mode
Trunk mode operates in the same way as transport mode (the data
payload is encrypted but the IP header is not modified). The key
difference is that in trunk mode the overall packet length is not
increased. In tunnel and transport mode the encryption process adds
several bytes overhead to the packet. Trunk mode ensures that the
packet length does not increase by fragmenting the packet, adding
the encryption and ensuring that the resultant packet length is the
same as the original packet length.
The diagram used above for the transport mode example is equally
applicable for trunk mode.
- Datacryptor® in passthrough mode
Passthrough mode does exactly what it says - it passes packets through
unmodified with no encryption. No modification of the packets occurs.
Passthrough can either be configured as the "default mode" (i.e.
the Datacryptor® will pass ANY packet from private to public and vice versa)
or a specific policy can be configured which specifies source/destination
address. If there is an overlap, for example if you had a tunnel
configured AND passthrough set as the default mode, the Datacryptor® will
favour the encrypted tunnel over the passthrough.
|
)
)
)
)
)
)
)
