Re: NAT is not a mechanism for securing a network.. but.. HELP!
From: Floyd L. Davidson (floyd_at_apaflo.com)
Date: 08/27/05
- Next message: hmartz: "FORTIGATE 200 PORT FORDWARDING DNS PROBLEM"
- Previous message: kmd4000_at_remove.hotmail.com: "assigning ip addresses in wireless network"
- In reply to: Nicky: "Re: NAT is not a mechanism for securing a network.. but.. HELP!"
- Next in thread: Nicky: "Re: NAT is not a mechanism for securing a network.. but.. HELP!"
- Reply: Nicky: "Re: NAT is not a mechanism for securing a network.. but.. HELP!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 27 Aug 2005 06:10:36 -0800
"Nicky" <hackeras@gmail.com> wrote:
>Sorry but still tunneling is not clear to me, only proxying is clear.
With a proxy, each packet is modified to change the IP addresses
and ports but uses the same protocol (e.g., TCP, UDP, etc).
With a tunnel, each packet is used as the data load to form a
packet for a different protocol. A trivial (and unlikely)
example would be if we have the TCP protocol but not the UDP
protocol and want to be able to run programs that use UDP. We
build a "tunnel", where UDP packets are actually sent using the
TCP protocol.
A tunnel fakes one protocol, and instead uses a mutually
exclusive alternate protocol.
To understand why that is done, perhaps understanding the
layered approach to networking is required. All communications
links have various layers of protocols...
You've probably heard of the "OSI Layered Model" that labels 7
layers? And you've probably seen comparisons with TCP/IP, which
doesn't really have all 7 of those layers because it combines
some of them? Here is a comparison chart:
OSI Model Typical Internet Implementation
Application 7 --+
|
Presentation 6 |-- Application
|
Session 5 --+
Transport 4 ----- TCP / ICMP / RAW / UDP / OTHER
Network 3 ----- IPv4 / IPv6
Datalink 2 ----- Device Driver
Physical 1 ----- Hardware
Notice that each layer can have multiple /different/ protocols.
For example we have several "Transport" layer protocols to
choose from, and any given application might use TCP or ICMP or
UDP or one of the other (not listed) protocols. Some
applications may even allow the user to choose which protocol is
used.
At each layer the connection to the next layer is to one
specific protocol selected from the several that are available.
Here is a diagram of a typical example, which in this case is
the connection between a web client and a web server that are on
an Ethernet LAN.
Client Server
Host Host
Application Protocol
Web Client <- - - - - - - - - - -> Web Server Applications Layer
| |
| TCP Protocol |
TCP <- - - - - - - - - - -> TCP Transport Layer
| |
| IPv4 Protocol |
IP <- - - - - - - - - - -> IP Network Layer
| |
| Ethernet Protocol |
Ethernet <- - - - - - - - - - -> Ethernet Datalink Layer
Driver Driver
| |
| 10baseT Protocol |
Ethernet <- - - - - - - - - - -> Ethernet Physical Layer
NIC & Cable NIC & Cable
| (CAT5 cable) |
+----------------------------------+
Note that each "stack" of protocols is the same on both the
client and the server hosts. The dashed horizontal lines
represent "virtual connections" between the layers on each host,
and ideally the layers above any given dashed line do not know,
or care, about what is below that line. (That ideal situation
doesn't always exist though!)
Okay, so that is the way it is *supposed* to happen. Each layer
should be *totally* isolated from anything more than one layer
away from it. Hence an application would select TCP (as opposed
to UDP or ICMP etc) and then would not know or care what the
datalink layer actually was. The fact that it is Ethernet
rather than Token Ring or PPP is not supposed to make any
difference.
However, the fact is it *does* make a difference, and sometimes
we can't control that. Lets say you have an existing
implementation of protocol 'A' (in any of those layers), and
purchase a program that is fine tuned to run *only* when used
with protocol 'B', which is not available. That would be one
instance where a "tunnel" might be used. Rather than add a
/real/ protocol 'B', the program is provided with something that
looks like it comes from 'B', but it actually connects to your
existing 'A' protocol.
A really simple example would be if for some reason UDP was not
available (perhaps a mid-link firewall does not allow UDP
packets). No problem, just write a UDP to TCP tunnel for each
end of the connection. The program expects UDP, so it thinks
the virtual connection will look like this:
Client Server
Host Host
Application Protocol
Client <- - - - - - - - - - -> Server Applications Layer
| |
| |
UDP <- - - - - - - - - - -> UDP Transport Layer
| |
| |
IP <- - - - - - - - - - -> IP Network Layer
| |
~ ~
But since there is no usable UDP protocol available, but the TCP
protocol does work, a "tunnel" is put into place, and it ends up
looking like this:
Client Server
Host Host
Application Protocol
Client <- - - - - - - - - - -> Server Applications Layer
| |
| UDP Virtual connect |
UDP--+ <- - - - - - - - - - -> +--UDP
| | \
| | \
UDP-TCP TUNNEL UDP-TCP TUNNEL > Transport Layer
| | /
| TCP Virtual connect | /
TCP--+ <- - - - - - - - - - -> +--TCP
| |
| IP Virtual connect |
IP <- - - - - - - - - - -> IP Network Layer
| |
~ ~
What the tunnel actually does is _connect_ _between_ _two_ _protocols_
_in_ _the_ _same_ _layer_, and encapsulate the data from one into
appropriate data for the other. That usually means taking a
packet from the first protocol and using the entire packet as
the data load for a packet suitable for the second protocol.
A tunnel looks like one protocol to the layer above it, and like
a different protocol to the layer below it. In the above
example the Application Layer is dealing with UDP, while the
Network Layer below is talking to a TCP protocol.
The example of tunneling UDP through a TCP connection is perhaps
a bit far fetched, and probably is never done. But examples
where a tunnel actually is used are available for each layer.
For example, if we want to encrypt all of our data, regardless
of what program is used, we might replace the entire transport
layer with a tunnel. Each protocol would be available, but
instead of connecting directly to the Network Layer below, every
packet would then be encrypted, put into a TCP packet, and sent
on its way.
Another example is PPPoE, where we have an Ethernet, but want
the Network Layer to deal with certain Ethernet frames as if
they come from a PPP connection.
-- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
- Next message: hmartz: "FORTIGATE 200 PORT FORDWARDING DNS PROBLEM"
- Previous message: kmd4000_at_remove.hotmail.com: "assigning ip addresses in wireless network"
- In reply to: Nicky: "Re: NAT is not a mechanism for securing a network.. but.. HELP!"
- Next in thread: Nicky: "Re: NAT is not a mechanism for securing a network.. but.. HELP!"
- Reply: Nicky: "Re: NAT is not a mechanism for securing a network.. but.. HELP!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
