[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSec Complexity
Hi, what a cracker this note is! For me, the most interesting question is
the topic of differential protection. If this is not required (mostly), then
the model could be made simpler - which is certainly tempting for VPN
aggregation devices.
Here are some implementation details/defaults we have taken in an attempt to
offer simpler LAN-LAN and Client access configuration on a VPN gateway. We
have basically split the functions of an IPSEC-tunnel/SPD into routing, the
tunnel, IP protection and filtering. The text below is not meant to be the
answer, and I'm not sure how much it adds to this debate, but here it is
anyway..
1) We make use of transport-mode for L2TP, and IPIP tunnel when doing
LAN-LAN routing, i.e. where dynamic routing protocols are required. The
IPSEC protection is applied via a 'Socket' interface API to IPSEC that L2TP
and IPIP call at boot time (create-ipsec-policy), and for each packet sent
(apply-ipsec-policy). There is no SPD. A routing lookup provided the IPIP
tunnel interface as the exist 'port' - which adds the IPIP tunnel header and
then calls apply-ipsec-policy to protect (transport mode), then out.
This 'socket' approach can also be used to protect management traffic ports
on a gateway.
If any filtering is required, it is applied with standard interface-based
filtering on the virtual (tunnel) interface. All traffic is protected in the
same way.
2) For LAN-LAN static links (static routes, as may be used to connect a
large number of small site to a hub), we are looking into adding an 'IPSEC
Static route' concept. This is much like an IP static route, expect is
contains protection policy and peer information. This can be tunnel-mode or
transport-mode+tunnel. Again, no SPD, just let the routing table take the
strain - use the routing table to find the outbound SA.
3) Client access. Well, since we don't make one of these, we have to play
whatever game the available IPSEC clients can support, and they typically do
not support an IPIP tunnel+IPSEC transport mode, but it could be done that
way. Again, no SPD is needed, since once the client has been assigned an
Intranet address, a dynamically created static route can be used to resolve
the outbound SA.
4) Filtering. Since the IPSEC implementation is unable to negotiate complex
filtering rules, we have found it necessary to apply secondary filtering
anyway. We make most use of this with client access: When the client
connects, a policy delivers the additional filtering. Each packet (in and
out) has to be checked against the policy filtering and the IPSEC policy
negotiated by IKE.
5) Differential protection. If this is a hard requirement, then the existing
model is necessary, since only the current SPD model (or something like it)
can deliver this. THE question to answer, is whether this is a real
requirement. If it is not, and all traffic is protected in the same way, we
can separate the filtering and security functions.
With the dawn of desk-top IPSEC (W2K, Unix, Linux), perhaps differential
protection can be left to the desk top, and gateways can just tunnel (IPIP
tunnel) and apply transport mode IPSEC authentication?? Bring back AH :)
Cheers, Steve.