[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC tunnels for LAN-to-LAN interop issue
Not quite FR/ATM. When FR/ATM are used in 'LAN' mode, typically each
circuit is to a different remote site - it is rare to have a bunch of
circuits to the same site, let along collected as a bundle.
The model you suggest is the conclusion I had come to for providing
differential security between peer sites while incurring the least
over-head, but I still think it is overly complicated for most folk, and it
is a new 'thing' that will need careful explanation and generate some
interesting support calls.
For most cases, I think, folk will want a single policy for this virtual
datalink. This will mean the selectors are likely to be wide open - any src,
any dest, any prot, any port.
This is now the same as having an IPIP tunnel device, that is protected by
transport-mode on leaving a 'public' IP interface.
One advantage of this model is that the tunnel protocol (L2TP, GRE, IPIP)
does not have to have IPSEC protection if the exit interface does not
require it, and the same mechanism (strip IPSEC transport mode, deliver to
tunnel device) can be used for all IP-based tunnel protocols.
Another advantage is that I can use Interface MIB and Tunnel MIB on the
IPIP/Generic tunnel, and use IPSEC monitoring MIBs for tracking SA. I don't
think there is any intention to support the model of a group of IPSEC tunnel
SA being equated to an interface in the IPSEC MIB specs.
The up-shot of this debate for me, is that I'll support negotiating either
tunnel or transport (depending on the target device), but I'll always
perform 'transport mode' processing on the already tunneled packets. I
doubt if we will support the model of representing an interface as a
collection of IPSEC tunnels, since the possible misconfiguration problems
fill me with dread.
Thanks for the comments Eric.
Cheers, Steve.
-----Original Message-----
From: Eric Bomarsi [mailto:ebomarsi@xedia.com]
Sent: Friday, August 27, 1999 8:59 PM
To: Waters, Stephen
Cc: John Shriver; ipsec@lists.tislabs.com
Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue
"Waters, Stephen" wrote:
> 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:
...
>
>
> Basically, this is difficult to model, difficult to manage, and difficult
to
> explain to customers.
>
Stephen, I don't think that's true. The Xedia router aggregates tunnels
to a remote gateway on a virtual datalink interface beneath an IP
interface. The fact that it's a virtual interface is transparent to IP and
RIP and OSPF run just fine over it. It's analogous to an ATM or Frame
interface but instead of circuits, it has tunnels.
Eric
Follow-Ups: