[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipsec in tunnel mode and dynamic routing



Hi,

replying to a number of issues brought up in this thread:

Giaretta Gerardo wrote:
 > I have a question about using ipsec in tunnel mode together with
 > dynamic routing: I read draft-touch-ipsec-vpn-01.txt but I'm not
 > sure that I understood it clearly.

We are currently preparing an update to this expired draft for the
next IETF; it should be ready sometime this week.

The basic idea of our draft is to allow IPsec transport mode together
with IPIP tunnels as an alternative to IPsec tunnel mode. In that case,
routing is based on virtual (tunnel) interfaces, and IPsec is applied
after routing (unlike IPsec tunnel mode, which encrypts and then routes
in one step).

Derek Atkins wrote:
 > You should not use IPsec on a hop-by-hop basis. Assuming A and D are
 > your Security Gateways, all packets should be encrypted between A
 > and D, regardless of the path they take.

If your goal is to create a simple VPN to secure traffic between X
and Y, that is sufficient. If you are trying to create a multi-hop,
secure, virtual topology connecting X and Y, this is too limited.

Derek Atkins wrote:
 > The problem, of course, is detecting when a tunnel endpoint goes
 > down. This is a problem with any kind of virtual tunnel, not just
 > IPsec. With link-layer neighbors you can use the lower-layer to
 > detect a downed link; it's more difficult with a virtual tunnel.

Not so. Any routing daemon (we tested gated and mrtd) will detect
tunnel link failure like it detects failures of physical links. This
is mostly a configuration issue.

Giaretta Gerardo wrote:
 > ok, I can understand that the hop-by-hop example works only if I route
 > before I encrypt, but in ipsec documentation (i mean in ipsec RFCs), i
 > think it's not clear if the routing comes before, the encryption or
 > viceversa. Is it implementation dependent?

As far as I know, the RFCs do not address this. We follow the
developments of the major free IPsec implementations, and it looks
like most started out based on packet filters, and IPsec tunnel mode
encapsulation was handled by the IPsec stack, not existing IPIP
tunnels in the system. On outbound, packet filter processing usually
occurs before routing, and so we ended up with the IPsec tunnel mode
behavior we see today. (Which is fine for many cases where a simple
VPN is what you want.)

Ricky Charlet wrote:
 > One large point to keep in mind about that draft is that its intended
 > purpose is to create overlay networks. The interested audience for
 > this is comparatively small. It goes beyond the aims and purposed of
 > creating secure VPN networks.

Not necessarily. Using IPIP tunnels + ipsec transport mode is a full
replacement for IPsec tunnel mode, i.e. you're not loosing anything
by always using the former instead of the latter. Thus, you can use
our approach to "only" create secure VPNs, with don't need dynamic
routing.

Ricky Charlet wrote:
 > On, the other hand, I could be totally wrong and you may have asked
 > exactly what you meant. In that case, keep in mind that Joe Touch's
 > draft aslo recommends making routing decisions before encapsulation
 > to avoid just the example problem you bring up. In this sence, the
 > draft recommends a variance from the standard IPsec architecture
 > behaviour.

Exactly. The draft argues for allowing IPIP + IPsec transport mode as
an *alternative* for IPsec tunnel mode. We aren't trying to replace it.
And the driving issue behind it was exactly to allow dynamic routing
over IPsec-secured, multi-hop, virtual topologies.

Lars
-- 
Lars Eggert <larse@isi.edu>               Information Sciences Institute
http://www.isi.edu/larse/              University of Southern California



Follow-Ups: References: