freeswan/klips/doc/klipsNGreq/requirements/010/requirement010.tex

   1 \subsection{010: routing above tunnel layer}
   2
   3 %  3.1   Multiple Tunnels to Same Subnet
   4 %
   5 %   Suppose  West is a FreeS/WAN box that is connected to two different wild-side ISPs. It has
   6 %   two  different  wild-side  addresses.  It  would be very nice to set up two connections to
   7 %   Sunrise-net.  This  would  allow load-sharing, and it would also improve reliability if we
   8 %   could arrange failover from one connection to the other.
   9 %   Unfortunately,  if  you  try  to  set  up multiple connections to the same subnet (Sunrise
  10 %   subnet)  using  FreeS/WAN  version  1,  the result is fratricide. The second connection is
  11 %   treated as a replacement for the first.
  12 %   You  can  work  around this by not making subnet connections. Instead, as suggested by Joe
  13 %   Patteson,   make   host-to-host   connections   between   East  and  West,  and  then  run
  14 %   GRE-encapsulated  traffic  over  these  connections,  as discussed in section 2.2. You can
  15 %   perform load-balancing and failover with respect to the GRE virtual devices.
  16 %   If East has N ISPs and West has M ISPs, you could conceivably want M×N IPsec connections.
  17 %   Note the following imperfect parallelism:
  18 %     * IPsec  tunnel  mode  is  sometimes  described (imperfectly) as follows: Set up an IPIP
  19 %       tunnel, and then apply transport-mode encryption to the encapsulated traffic.
  20 %     * In  this  case,  we encapsulate using GRE, and then apply transport-mode encryption to
  21 %       the encapsulated traffic.
  22 %
  23 %    On  the  other  hand,  it is not 100% correct to view tunnel mode as IPIP plus encryption,
  24 %  because  real  tunnel  mode  allows allows the system to verify that the correct subnet is
  25 %   being  carried  over  the  tunnel; that is, the inner headers can be checked. In contrast,
  26 %   using  IPIP+encryption  or GRE+encryption, the inner headers are just data in some obscure
  27 %   format that cannot be checked by the IPsec system per se.
  28 %   On  the  third  hand,  since  FreeS/WAN relies on you, the user, to implement the security
  29 %   policy  anyway,  using the firewalling system, you can perfectly well check the packets as
  30 %   they enter the GRE device. So all the necessary functionality can be achieved.
  31 %   Also  note that the GRE links, as the name implies, were designed with routers in mind, so
  32 %   their up/down state is meaningful, and their metric is meaningful to routing daemons.
  33 %   It  sure  would  be nice if the next-generation IPsec system could do this itself, without
  34 %   requiring  us  to  resort  to  GRE.  We  need  multiple  tunnels  to the same subnet, with
  35 %   meaningful  up/down  state  and  meaningful  metrics. And we need the ipsec device to play
  36 %   nicely with routing daemons.
  37
  38
  39
  40 \subsubsection{010: Definition of requirement }
  41
  42 %   http://www.quintillion.com/fdis/moat/ipsec+routing/
  43 %especially section 3 therein, i.e.
  44 %   http://www.quintillion.com/fdis/moat/ipsec+routing/#sec-routing-above
  45 %
  46 %That was written over a year ago.  The big ideas haven't changed, but a few
  47 %details need polishing.
  48 %  *) In particular, there are several places where it speaks of a "device"
  49 %going down whereas is should say "link" going down.
  50 %
  51 %  *) Also the rationale is given in terms of failover and load-sharing, and
  52 %we now know that mobility is a third important motivator for doing this.
  53 %
  54 %  *) Also the terminology
  55 %         a) routing above the tunnel
  56 %         b) routing below the tunnel
  57 %has been deemed unnecessarily confusing to Muggles.  It would be better to
  58 %speak of
  59 %         a) routing the inner headers (plain text)
  60 %         b routing the outer headers (crypto text)
  61 %but the intended meanings are unchanged.
  62 %
  63 %===========
  64 %
  65 %Tangentially relevant remark: Routing above the tunnel is one of the big
  66 %motivations for having a virtual device.  A detailed look at how this might
  67 %work, as worked out at OLS, was posted to the list at 02:15 PM 7/30/01 -0400.
  68
  69 see JSD documents.
  70