From: John S. Denker (jsd_at_monmouth.com)
Date: Tue Jan 14 2003 - 14:06:07 CET
Ken Bantoft wrote:
> you can't have two matching eroute's using FreeS/WAN.
Right. But as discussed below, you can have
multiple transport-mode tunnels.
This raises a number of design issues, so I'm
going to CC: the design list.
> There's a number of ways to work around this
Right.
> the eql driver, or
> multilink PPP over the two links, bonding them. That would give you
> full use of both links, at the cost of PPP overhead.
Or, as Ken previously mentioned, GRE.
> with no ugly routing hacks.
I'm missing an antecedent here.
What ugly routing hacks are we talking about?
The Subject: line speaks of routing; for that
reason among others I assume some routing needs
to take place.
The whole purpose of routing is to solve some
ugly problems such as link failure; I'm not
sure it's fair to blame the routing for the
ugliness.
> There's probably a few other ways of doing it - find a way to get a single
> path between the two sites, and then run IPsec over that.
Hmmm, that's overly restrictive. That corresponds
to item "A" in the following list, whereas item "B"
is my favorite.
At the highest level, there are two strategies:
A: (private (multiple paths))
B: (multiple (private paths))
where the "multiple" keyword contains all the complexity
associated with routing, health-monitoring, failover,
load-sharing, and bonding.
It is instructive to compare Strategy B with ordinary
IPsec tunnel mode. To a good approximation, the latter
can be described as:
C: (ipip (private path))
... meaning that at a low level you use IPsec transport
mode to set up a private path, and then you run ipip
encapsulation over that path. That is, the packet
processing looks like:
in --- ipip ipip --- out
encap decap
\ /
IPsec IPsec
transport-mode transport-mode
encryption encryption
\ /
eth0 ----- eth0
<digression>
BEWARE: The terminology for discussing Strategies
A, B, and C is a source of potential confusion.
It depends on whether you view things in terms of
-- processing-steps and protocol-layers, or
-- bits on the wire.
My notation (ipip (private path)) is based on the
protocol-layers viewpoint. Clearly the IPsec
encryption is the "lower-layer" protocol. The
notation suggests that it is the "inner" protocol,
if you look at the nesting of the parentheses.
Similarly if you look at the flow diagram, the
encryption is "inside" the ipip encapsulation.
But (!) from a bits-on-the-wire point of view, the
IPsec header is the _outer_ header.
It is the _inner_ processing steps that act on the
_outer_ header and vice versa. Get used to it.
This is a terminological booby-trap, a source of
confusion just waiting to happen. There is no
easy way around it. AFAICT the only defense is
to recognize it and to be really explicit about
what viewpoint is being used.
</digression>
I suspect for most folks, Strategy B is the way to
go. The diagram looks something like this:
(West) (East)
eth0 --- eth0
/ \
IPsec0 IPsec0
transport-mode transport-mode
/ \
GRE0 GRE0
/ \
Sunset --- Routing Routing --- Sunrise
\ /
GRE1 GRE1
\ /
IPsec1 IPsec1
transport-mode transport-mode
\ /
eth1 --- eth1
That is, we set up a transport-mode tunnel from the
eth0 interface of machine West to the eth0 interface
of machine East. We set up a second transport-mode
tunnel from eth1 to eth1. There is no conflict
between the eroutes, because these are singleton
networks, i.e. they have a /32 netmask, and on
each machine eth0 has a different IP address from
eth1.
There is a profound analogy between this and plain
old IPsec tunnel mode; this uses (gre (transport))
whereas tunnel mode uses (ipip (transport)). One
advantage is that GRE is a more capable encapsulation
protocol.
West can use ordinary routing commands to set up a
route to East (and Sunrise-net) via GRE0, and another
route to the _same_ destinations via GRE1. The advantage
is that this can be done without causing the IPsec
layer to get confused. In contrast, ordinary FreeS/WAN
tunnel mode would get horribly confused. That's
because it unwisely uses the destination subnet to
identify the tunnel. The concept of multiple tunnels
to the same destination subnet is incompatible with
the FreeS/WAN low-level design. (I sure hope these
issues get fixed as part of the current redesign
work. The gre device can serve as a guide to the
design.)
If the metrics are equal for the two routes, we
can get equal-cost multipath routing. If unequal,
we can get failover from one to the other.
In general, the gre device is better behaved than
the ipsec device.
-- the gre device plays nicely with routing
daemons; ipsec doesn't.
-- the ipsec device uses what its designers
call "stoopid routing tricks"; gre doesn't.
================
One slight complexity must be discussed.
It is only roughly true, not exactly true, that
IPsec tunnel mode looks like (ipip (transport-mode)).
The difference is that transport mode must
transport whatever data it is presented, without
trying to interpret the data; in the case of
(ipip (transport-mode)) the IPsec transport is
not allowed to examine the inner header of the
ipip encapsulation. In contrast, genuine IPsec
tunnel mode is able to interpret the inner and
outer headers. Indeed according to the RFCs,
any IPsec tunnel-mode implementation _must_ have
an SPD (security policy database) with enough
expressive power to select packets based on
their inner-header properties among other things.
It turns out that the FreeS/WAN software that
you download from freeswan.org is not _by itself_
a complete RFC-compliant IPsec implementation,
because it lacks many of the mandatory SPD
capabilities. But don't panic. FS is rather
like hamburger helper; one of the key ingredients
is not supplied in the package -- so you have
to obtain it separately. You can use iptables
and iproute2 advanced routing to implement a
fair approximation of an SPD, especially for
input selectors, i.e. on the encapsulating
side. (I've never needed much beyond rather
modest processing on the decapsulating side,
so for now I won't opine about the general
case on that side.)
So, because of the modular "hamburger helper"
design of FS, you have little to lose by using
(ipip (IPsec-transport)) or (gre (IPSEC-transport))
rather than genuine IPsec-tunnel mode. Of
these, gre is markedly more powerful.
I think (gre (IPsec-transport)) is the way of
the future. I wish IPsec had from the very
beginning used something like gre rather than
ipip encapsulation.
One can imagine a slight :-) extension to Pluto
whereby one could specify in ipsec.conf that
one prefers (gre (transport)) tunnels rather
than (ipip (transport)) tunnels, and Pluto
takes care of setting everything up.
==============================
Ken has documented some related ideas in
http://www.freeswan.ca/docs/HA/
although that is mainly aimed at solving
a different problem, namely failure of an
endpoint; that requires drastic measures
including such things as IP stealing via
gratuitous ARP.
In contrast, the current discussion is aimed
at a situation where the endpoints stay up
but the links between them may come and go.
This can be handled by less-drastic measures
such as conversations between router daemons.
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Wed Jan 15 2003 - 20:11:39 CET