Re: Remove tunnel mode from ipsec-tunnels-02?

[Fred Baker <fred@cisco.com>]

On Sep 7, 2006, at 3:57 PM, Pekka Savola wrote:
> On Wed, 6 Sep 2006, Fred Baker wrote:
> > given that there are significant networks that operate in tunnel  
> > mode, including both corporate VPNs and military networks that use  
> > tunnel mode between encryption devices with a specific view to  
> > hiding interior addressing and therefore military asset  
> > distribution from prying eyes, this proposal seem profoundly silly.
>
> Our assumption has been that transport mode is applied to a tunnel  
> interface (such as IPv6-in-IPv4, GRE etc).  That hides the inner  
> addresses from those observers that would have been on-path in the  
> tunnel.

well, yes, that's one way that tunnel mode is often implemented. It's  
hardly the only way.

> When IPsec tunnel mode is _NOT_ modelled as an interface, then this  
> is OK though IMHO suboptimal because you cannot in practice run  
> neighbor discovery, routing protocols, multicast etc. over such  
> tunnels.  Due to the link-local issues mentioned previously, tunnel  
> mode is not something we can recommend when it's modelled as an  
> interface.

I'm not entirely sure what the modeling question means to you. Are  
you objecting to the use of a tunnel header, or the configuration of  
an interface to do this?

Good grief.

So I'm sitting on a computer. I'm located, at this instant, in  
Shanghai, and in the morning will be visiting a professor from the  
Chinese Academy of Sciences. While I slept, this computer has been  
downloading email, and I am right now replying to one of yours.

The computer's connection to Cisco, where my mail services are at, is  
over the wild and woolly internet, and uses an IPSEC VPN. This  
particular VPN runs over TCP, like this:

         +-----------+-----+------+-----------------------------+
         | IP host   |IPSEC|      | +----+----------------------+
         | to        | ESP | TCP  | | IP |                      |
         | decryptor |     |      | +----+----------------------+
         +-----------+-----+------+-----------------------------+

My VPN software could just as easily run it over UDP. The point is  
that I have a security association from my host to a firewall device,  
and the datagrams I send contain an interior header that is used  
within Cisco's network and uses addressing that is not advertised to  
the world outside.

There are numerous military encryptors, some of them manufactured in  
the US for US customers and some manufactured in other places for  
NATO customers and countries that use NATO specifications, and yes,  
if you go to the right web site you can find a Cisco-manufactured  
device of this type. The description of "tunnel mode" in RFCs 4303,  
2709, and 3456 is pretty much motivated by this particular usage. In  
these devices, there is a "red" or plaintext interface and a "black"  
or ciphertext interface. Packets handed to the device on the red side  
are correlated with one of a potentially large number of security  
associations, encrypted, an IPSEC ESP or IPSEC-like header and an IP  
header added to get the thing to its decryptor, and it is fired out  
the black side. At the remote end, the payload is decrypted and  
forwarded to a red side device such as a router.

         +-----------+-----+-----------------------------+
         | IP host   |IPSEC| +----+----------------------+
         | to        | ESP | | IP |                      |
         | decryptor |     | +----+----------------------+
         +-----------+-----+-----------------------------+

And Oh yes, the router at my home office runs essentially the same  
model using civilian encryption technologies and connects me to Cisco  
when I am at home. As you say, in this case a GRE tunnel is  
configured on a virtual interface:

        +-----------+-----+-----+-----+-----------------------------+
        | IP host   |IPSEC| UDP | GRE | +----+----------------------+
        | to        | ESP |     |     | | IP |                      |
        | decryptor |     |     |     | +----+----------------------+
        +-----------+-----+-----+-----+-----------------------------+

These are each instances of a tunnel mode VPN; the "military" one is  
specifically the one recommended in RFC 4303.

Now, I will agree with you that the military version uses less bits  
and accomplishes the same thing that the two civilian versions do. If  
that's your complaint, then please state your complaint. But  
recommending against the use of tunnel mode as a class (including the  
version defined in RFC 4303) and saying that people should always use  
transport mode limits the utility of your document. The simple fact  
is that folks are going to run all of the above for a long time to  
come in both IPv4 and IPv6, sometimes because they choose to hide the  
content of the encrypted datagram, and sometimes because they by  
policy choose to run their networks in a manner in which not only the  
end systems are responsible for the security of the inter-system  
exchange, but the network administration is responsible for the  
admission of traffic to the network. Telling people that the only  
security that matters is host-to-host, and that the security of the  
network itself is irrelevant, is a good way to get laughed at.