[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tunnel Vs Transport
Sorry I have been offline, so to speak as I get situated in my new job
(that will be tightly tied into this workgroup for a while :).
I will attempt to typify my view of Tunnel vs Transport and why I feel that
Transport is better, but Tunnel what we will be doing for some time....
I am writing this at a conference during a presentation that I only care a
little about, compared to getting this note off. So it might be a little
garbled...
In transport, we slide IPsec between the IP and transport headers. This
works just great on a host to host in a NON-NAT environment. IE Intranets
and Global Internet users. It cannot reliably be used in a NAT environment
and in many roadwarrior senarios. It cannot be used in NAT as the SA is
tied into the destination IP address, so for a road warrior, you will have
to be prepared to let external addresses run wild within your network and
support default routing to your IPsec box regardless if you do the IPsec on
your NAT box or the end system. The same applies to a non mobile Internet
user not behind a IPsec gateway.
Thus transport is severly limited due to NAT. Oh, and AH is worst than ESP
in this manner as the IP address in the header are immutable, so the IPsec
must be done after the NAT.
Some NATs are more functional than others that might make this workable,
but this is very complex for the average implementor.
In tunnel mode the IP packet is packed into another IP packet along with
the IPsec header. Fine and dandy. In a host to host environment, there is
a question as to what addresses to use for the inner and outer IP headers.
If they are the same, that leaves a lot of known text to attack the
packets. Bad news. So for the host to host, as indicated above, Transport
is better.
For the roadwarrior to gateway, Tunnel works well and in fact this is the
MUST implement mode per the IDs. It is advisable that the above mentioned
known text issue be addressed. Timestep has a draft out for the gateway to
assign the inner source address. Besides this addressing the Known text,
it can also help for those applications that are registered by IP address
(so unuseable by ISP addresses of the roadwarrior). A 'standard' way of
doing this assignment (INTEL is proposing using DHCP) is an IPsecond item.
The inner destination address may not be an issue, as it is the address of
the destination server, whereas the outer destination is the address is
address of the gateway.
For gateway to gateway tunnel is the only mode that can work consistantly.
To use transport in this situation requires both networks to be globally
addressed. Since it might be hard for an administrator to know which
network they work with is or is not globally addressed, this can end up
being intensive, administratively. This is added to the obvious packet
reassembly issue of transport that was noted earlier.
>From all of this, tunnel is used whenever the IPsec ends at a gateway.
this is for network to network and remote system (roadwarrior or other) to
network. Transport is used for end-to-end which is Intranet or exposed
global systems. Transport might also be used in gateway management; tunnel
could be used, but that might yield known text challenges (but since most
gateways have at least 2 addresses, games can be played for the destination).
i plan on starting with only tunnel mode deployment recommendation for the
ANX (i am no longer involved in the deployment :). But transport mode will
come up, Intranet-wise and gateway support. Transport mode will also come
up when we can nest modes with transport end to end with tunnel between
gateways.
got to pay attention to the presentation again ;)
Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com