[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC tunnels for LAN-to-LAN interop issue
Howdy ()
My replies are interspersed:
Ben McCann wrote:
>
> Very interesting idea. I've scattered a couple questions through your text...
>
> [Big Snip]
>
> >
> > Processing:
> > INBOUND:
> > o Link driver receives a packet on a physical interface
> > o this interfaces updates ifTable stats
> > o recognize packet as IP
> > o run verification tests
> > o recognize as special case of addressed to me = addressed to my tunnel
> > intf
>
> Since this is a 'non-encapsulating tunnel', the destination address
> on the physical interface will be the TUNNEL interface's address,
> right? That requires the box to proxy ARP that address on the
> physical interface network, right?
I have no implementation experience with a tunneling protocol. But I
suppose this problem is no diffent than how to ARP reply from a GRE
interface. Would anyone else care to chime in here...?
>
> > o (reassemble if necessary)
> > o update ifTable stats for tunnel intf
> > o IPSec process w/ ingress interface = tunnel intf
> > o Fwd or locally receive
> >
> > OUTBOUND:
> > o After IPSec processing:
>
> Which interface's SPD is consulted to perform IPSEC processing? I assume
> it is the tunnel interface's SPD, right?
That makes the most sense. But if someone can figure out how to apply
the SPD to the true physical outbound interface and still use this
scheme effectivly, I would not be pre-disposed to precluding that.
>
> > o Route to far-end tunnel IP has true physical next hop(s) but also has
> > exit interface = tunnel Intf
>
> Why is it necessary for the route to the far-end tunnel endpoint have
> a true physical next hop but an exit interface of the tunnel Interface?
> At this point in outbound processing you've already passed through IPSEC.
IPSec has just encapsulated the packet and the new destination IP
address (outer header) is to the far end tunnel end point. We will need
the exit interface to be the tunnel so that we may update mib-2 stats.
We will need the true next hop so that we can avoid further
encapsulations.
>
> > o update stats in ifTable for tunnel intf
> > o ARP for true physical next hop
> > o append link headers for physical link
> > o update stats in ifTable for physical intf send packet
> >
>
> [Big Snip]
>
> >
> > Comparison to other options:
> >
> > 1) IPSec Tunnel is an interface:
> > There may be multiple IPSec tunnels to the same peer and these
> > IPSec tunnels may be for endpoints which are applications on hosts. Both
> > of these facts may confuse a routing protocol.
> >
> > 2) IKE Tunnel is an interface:
> > This is not an encapsulation technology... it just won't work.
> >
> > 3) GRE tunnel is an interface, All relevant IPSec tunnels run over it:
> > This works but takes a _lot_ of headers.
> >
> > 4) GRE tunnel is an interface, one IPSec transport SA carries all
> > traffic:
> > Insecure.
> >
> > 5) IPSec tunnel is an interface, rely on administrators to not come up
> > with configurations which would confuse routing protocols:
> > Yeah right.
> >
> > 6) IPSec tunnel may be marked as an interface, then the implementation
> > disallows other configuration which would confuse routing protocols:
> > Difficult to implement, reduces security flexibility.
>
> And....
>
> 7) PPP interface over L2TP with is then secured between LNS and LAC
> using IPSEC transport mode. I think this is the 'accepted' method assumed
> by the L2TP working group. It looses inbound SPD validation, lumps multiple
> flows into one SA, and it requires many layers of encapsulation. Bleh.
>
> -Ben McCann
>
Thanks for pointing this option out.
> --
> Ben McCann Indus River Networks
> 31 Nagog Park
> Acton, MA, 01720
> email: bmccann@indusriver.com web: www.indusriver.com
> phone: (978) 266-8140 fax: (978) 266-8111
--
####################################
# Ricky Charlet
# (510) 795-6903
# rcharlet@redcreek.com
####################################
end Howdy;
References: