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

RE: IPSEC tunnels for LAN-to-LAN interop issue

Hi John,

I think I disagree with the statement that "Anything else will violate RFC
2401". A security gateway is perfectly entitled to protected 'originating
traffic' with transport-mode, and if the traffic source is a tunnel device
(IPIP, L2TP, GRE...), then IPSEC can quite fairly protect this with
transport mode to a remote peer/security gateway:

" Note that for the case where traffic is destined for a
   security gateway, e.g., SNMP commands, the security gateway is acting
   as a host and transport mode is allowed."

It is convenient, I think, to model generic traffic between two security
gateways as transport-mode, regardless of the protocol.

The model you suggest below of a routing interface being represented by a
'collection of IPSEC SA going to the same peer' has some problems as a
model, I think:

o when has the interface failed, such that re-routing can occur?
o you need to explicitly ensure that routing traffic can be exchanged, 
  and this may depend on matching policy ordering
o According to RFC 2401, IPSEC tunnel mode strips a header, and 
  removes ESP/AH/IPCOMP. How do you then find the 'interface' to count 
  this against?
o how do I apply interface specific packet filtering to this 'interface'?
o and so on...

Basically, this is difficult to model, difficult to manage, and difficult to
explain to customers. 

Whereas, an IPIP tunnel device that then has transport-mode protection
applied, is not.

Outbound processing:
o Packet is forwarded to a Virtual IP interface 
  which has an Intranet address, and RIP enabled.
o Packet is queued to the data-link (generic tunnel device)
o Tunnel device does the tunnel job, and delivers the packet to 
  IP forwarding as a generated packet.
o Packet is routed to a real IP interface (say, to the Internet ISP)
o SPD on this interface enforces transport-mode protection
o packet is sent to data-link (say PPP), and out into the Internet.

Inbound processing:
o IP packet arrives from Internet connection
o SA look-up done, finds transport-mode policy
o ESP or AH striped out to reveal an IP packet with next-prot 
  of IP-in-IP (or whatever the tunnel is) addressed to a local IP address
o packet delivered to the 'protocol listeners'
o Tunnel demuxer delivers the tunnel packet to the appropriate tunnel device
o tunnel device strips tunnel overhead, updates counters on device interface
o tunnel device delivers resulting data 'up' to the Virtual IP interface
o packet counted on virtual IP interface
o packet put back to IP forwarder

Cheers, Steve.

-----Original Message-----
From: John Shriver [mailto:jas@shiva.com]
Sent: Friday, August 27, 1999 3:34 PM
To: dharkins@network-alchemy.com
Cc: Stephen.Waters@cabletron.com; ipsec@lists.tislabs.com
Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue

   To: "Waters, Stephen" <Stephen.Waters@cabletron.com>
   cc: ipsec@lists.tislabs.com
   Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue 
   Date: Thu, 26 Aug 1999 17:19:41 -0700
   From: Dan Harkins <dharkins@network-alchemy.com>

     Perhaps RIP is not the right tool for this job. Can't you run BGP
   the SGWs?


The fundamental challenge is that we have redefined the IP protocol in
adding IPSec to it.  Packets are no longer forwarded based soley on
their IP address.  A security gateway has to forward packets at the
connection level.  This isn't IP, it's more like X.25 (with IKE as the
call setup protocol).

There is no defined IP routing protocol that routes to the connection
level.  Not RIP, not OSPF, not IGRP, not EGP, not GGP, not Dual IS-IS,
not (please no!) BGP4.

So, a "brutally honest" IP Security Gateway can only use static
routes.  (At least if each IPSec tunnel mode "connection" is an
interface.)  Anything else will violate RFC 2401.

We've basically made a certain set of IP routers connection-oriented.

If you want to stick with tunnel mode IPSec, and run real dynamic
routing between a pair of security gateways, what I've figured you do
is aggregate all the tunnel mode SA's between the two SG's into one
"interface" that you present to the IP forwarder.  One of those SA's
has to be a tunnel (or transport?) one that allows the routing
protocol itself to pass between the two SG's.  Then, once it's time to
forward a packet over the "interface", something below the IP
forwarder picks the right SA in the SAD to send it over.  If there is
no SA (or entry in the SPD allowing the creation of the SA), then you
drop the packet.

Also, the user could configure the SPD with a rule of "everything I
learn from OSPF as a type 1 internal route from this peer SG is
allowable in the SPD, using these transforms."

Now, what I think the market will do for Intranet over Internet
LAN-to-LAN connections (due to Windows 2000) is use transport mode
between security gateways, and run L2TP inside that, with IP over PPP
inside L2TP.  This lets them run their favorite IGP over that IP
"interface".  Now they have something just like their leased line, but
it runs over a shared IP network between the sites.  All the SPD says
is that "L2TP is allowed in transport mode to/from these peer SGs".

But, this is only suitable for a security gateway that will only speak
to preconfigured peer security gateways under the same administrative
ownership.  It's not suitable for a security gateway that has an SPD
or policy allowing it to "talk to strangers".  (That's the general
case that nobody has figured out how to practically express policy for
yet, so it's just not happening yet.)