[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC tunnels for LAN-to-LAN interop issue
It seems to me that the whole problem described in this thread exists
because routing protocols that assume their peers are 1 hop away are
being used-- e.g. the multicast addresses used for OSPF and RIP are
from the "local segment usage only" range. So the problem becomes how
to tunnel these packets to hide this from the protocol, which would go
away if the protocol did not have this requirement.
So let me ask again, what is the problem with BGP? There would be no
need for any bizarre tunneling scheme and the BGP session can be protected
with transport mode IPSec if you're concerned about that (no need for
the ambiguity of "is transport-mode protected IPIP actually tunnel mode?").
BGP sounds like the right tool for the right job here. No need to short
circuit the IPSec access control mechanisms nor add unnecessary headers (as
Steve K noted) to the packets. And, most importantly, it achieves the goal.
Dan.
On Tue, 31 Aug 1999 11:22:29 EDT you wrote
> Stephen,
>
> >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.
>
> One can do this if the goal is to eviscerate the access controls provided
> by IPsec, and there is a desire to add unnecessary protocol layers (e.g.,
> L2TP and GRE) when carrying IP traffic :-).
>
> Steve
Follow-Ups:
References: