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

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

Hi Paul,

I agree with keeping it simple, with the same level (3DES/SHA) for all
tunnel traffic. 

I think I have an understanding of the two models now. I'm not trying to
suggest how you've actually implemented, just get a model clear in my head:

Virtual Data-link approach (your model Paul?):
--------------------------------------------

IP Interface
   |
  SPD
   |
Virtual Data link


The remote peer for all IPSEC tunnels over this virtual data link is the
same. In effect, the peer is tied to the Virtual Data Link.  The SPD in this
case contains one or more 'Secure' policies that share the same peer, or
defer that information to the Virtual data link. 

Another way to look at this is to consider the SPD as the virtual Data Link:

IP Interface
   |
SPD Data Link


The rules for this SPD data link is again that all policies have the same
peer.


In the simple case, the SPD will contain a single policy to allow all
traffic to be send/received between the peers.

Am I close?  Both of these seem to present new concepts: Specialist SPDs,
and Null tunnel data-links.


Compared to the alternative, Tunnel Data-link model:
---------------------------------------------------

IP Interface
   |
 SPD - optional
   |
 Tunnel device (IPIP, L2TP, GRE ...)
   |
 SPD - optional, e.g. transport-mode


IPSEC (preferably, transport-mode), can optionally be applied to the output
of the Tunnel device.

I think this is a cleaner model, with no need for specialist SPDs, NULL
virtual data links. Both work just as well for VPN IP tunnels, but this
alternative model is more flexible for generic tunnel protection, and holds
for unprotected tunnels as well. 

We'll probably code to this second model, and emulate the first to allow
interop of LAN-LAN routing.

Cheers, Steve.
  


-----Original Message-----
From: Paul Koning [mailto:pkoning@xedia.com]
Sent: Friday, August 27, 1999 10:28 PM
To: Stephen.Waters@cabletron.com
Cc: ebomarsi@xedia.com; ipsec@lists.tislabs.com
Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue


Stephen,

Keep in mind that many applications have no need for multiple tunnels
between the same pair of security gateways.  Given high speed crypto,
a good argument can be made that the whole notion is overkill -- just
protect all traffic with strong crypto.  Standard examples of multiple 
tunnels show "important" traffic protected with 3DES and "unimportant" 
protected with 1DES, but why do that if you can do them both at wire
speed, as you can with hardware assist?

Apart from that, the virtual interfaces we're talking about live above 
the tunnels, and correspond to the entire connectivity (over the
entire set of tunnels) to a particular remote security gateway.  Thus
they are a direct analog of a point to point connection.

	paul