[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC tunnels for LAN-to-LAN interop issue
"Waters, Stephen" wrote:
> There are three models that can be used here (using the example of an
> IP-inIP tunnel):
>
> 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode
> protection to the IP-in-IP packets as they leave.
>
> 2) IPSEC tunnel is modeled as an interface, and just negotiates tunnel mode
> and exposes the resulting tunnel as an interface. This is akin to marrying
> an SDP policy with an Interface.
>
> 3) IP tunnel device tunnels packets, IPSEC then applies tunnel mode
> protection.
>
>
> Option 3) seems wasteful since in most cases two identical header have been
> added.
> Option 1) is in the mould of L2TP tunnel protection and is a generalised way
> to protect pre-tunneled data
> Option 2) is mean and lean.
>
Howdy ()
Correct me where I'm wrong, I'm going to give some of my impressions of
these options.
Option 3): Let this one die.
Option 1): Good thing = routing works. Bad thing = security is impaired.
It seems like we have automatically limited and forced all traffic
traveling through a particular peer SGW to utilize the same SA and this
SA is incapable of distinguishing and discriminating against any
traffic. I suppose, Steven, that your implementation relies on packet
filtering to guard against what enters the IPIP interface? Is packet
filtering then to be seen as a mandatory prerequisite to this
impelmentation strategy?
Option 2): Good thing = security works. Bad thing = routing <in some
circumstances probably> fails. If we have multiple SAs between the same
peers, then which of these SAs is the routing interface?
So here is a new suggestion:
Its a modified Option 2)
Allow a user configurable switch on a Policy Entry to tell this entry
to become a routable interface. Now we introduce some extra limitations
which would have to be drafted up: Symetric configuration of both peers
is required. Once such a 'routable interface SA' switch is toggled on,
no port or protocol selectors are allowed in this policy. We draft up a
keep-alive mechanism (or take one from somewhere else) and start that
state machine on the new SA-interface. Routing information between the
two peers travles down this SA-interface. Link down and link up
notifications cause normal routing responses. 'Interface-SAs' to
different 'tightnesses' of subnet mask are allowed to be confiured.
(repeating my self here) 'Interface-SAs' to ports or protocols are not
allowed to be configured. Multiple 'interface-SAs' to the same far end
SGW are permissable if and only if they 'attach' to different interfaces
on the far end system (these would be like load balanced multiple
paths). A non-interface SA (the ones we are all used to so far) with
selectors pointing to particular ports and protocols within the same
subnet as an Interfaces SA is permitted and the non-interface SA SHOULD
be listed above the interrface-SA in the Policy Database.
This option allows routing to work (I hope, no implementation
experience speaking here) but still forces security policy down to some
unified theme. The Interface-SA would have to be configured to match all
traffic you anticipated... But the difference would be that your
Interface-SA could also be configured to match _only_ the traffic you
wished to allow.
--
####################################
# Ricky Charlet
# (510) 795-6903
# rcharlet@redcreek.com
####################################
end Howdy;
References: