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

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

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?

>  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?

>  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.

>  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

-- 
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
Follow-Ups: References: