[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC tunnels for LAN-to-LAN interop issue
I will admit to not having followed the entire thread, but:
>>>>> "Ricky" == Ricky Charlet <rcharlet@redcreek.com> writes:
Ricky> Intro: IPSec introduces some problems for routing protocols. IGPs
Ricky> anticipate that routing peers are reachable via a logical
Ricky> interface within 1 hop. These IGPs then learn/construct routes to
Ricky> subnets. IPSec tunnels are unsuitable for IGPs to run over as
Ricky> interfaces because they may reach destinations which are more
Ricky> specific than a subnet and there may also be _very_ many IPSec
Ricky> tunnels between peers. Creating a seperate generic tunnel
I'm not sure I see the issue here. If you mean that you are unable to get
the IGP packet into the tunnel because it is a per-host tunnel, then I agree.
But, in many ways this is a variation of the ICMP problem. ICMP errors don't
fit in those tunnels either.
Ricky> interface is also unsuitable because although it allows the IGP to
Ricky> function, IPSec must either shunt all traffic into a transport
Ricky> mode SA to cross the tunnel (which is insecure), or IPSec must
I don't understand this statement.
Ricky> encapsulate its own tunnels and deliver the packet to the logical
Ricky> generic tunnel interface which will encapsulate the packet in a
Ricky> point to point link protocol and then also encapsulate the packet
Ricky> in IP again (which is inefficient). BGP has been suggested as a
Again, less understanding on my part here.
Ricky> routing protocol to use to avoid the problem since it does not
Ricky> require the asumption that a peer router be reachable on a
Ricky> particular interface within one hop. But even if BGP is shown to
Ricky> be workable (still under debate at this time), it introduces the
Ricky> administrative burden of managing a set of Autonomous Systems.
I thought that IBGP could deal with this problem.
Ricky> This memo (could become a draft if it doesn't get shot down to
Ricky> badly) proposes to use an interface contstruct which does not
Ricky> encapsulate packets. Since IPSec tunnels have alread acomplished
Ricky> that work, doing so again is redundant. The only reason an
Ricky> 'interface' is needed at all is to facilitate IGPs. A
Ricky> non-encapsulating tunnel interface carries all of the IPSec
Ricky> tunnels which are desinted to the same peer.
I see where you are getting at here. It is a useful idea. It may be
a useful abstraction. Let me think more.
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Follow-Ups:
References: