[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: