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

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

  I-BGP!!!

  Dan.

On Tue, 31 Aug 1999 17:16:13 PDT you wrote
> I have been partially tuned to this thread and I do _not_ see BGP as
> the 'right tool' here. From what I understand an IGP is all that is
> needed (for example I need to connect two private networks using a
> secure tunnel through the Internet).
> 
> evan
> -
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > Sent: Tuesday, August 31, 1999 3:12 PM
> > To: Stephen Kent
> > Cc: Waters, Stephen; ipsec@lists.tislabs.com
> > Subject: 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
> >
>
References: