Re: How to reduce number of IPSEC security policies that need to be configured?

["Srinivasa Rao Addepalli" <srao@intotoinc.com>]

Hi Ravi,
     Two solutions which don't require additions/changes to the current standards.
     1. Use L2TP over IPSEC:
         This creates an interface and the packets going to/from this interface are secured
          using IPSEC/IKE tunnel. If your SG needs to establish tunnels to 'N' number of sites,
          then you require 'N' L2TP PPP interfaces and 'N' IPSEC data policies and 'N' IKE policies.
          You can create route to the remote site network using the appropriate L2TP PPP interface.
          Due to this, site to site traffic and traffic generated by proxies will be tunneled via L2TP
          interface which in turn is secured by IPSEC/IKE tunnels.
          It also has advantage where the Security Gateway gets the WAN IP address dynamically
          either via DHCP Client OR PPPoE in case of DSL networks.

     2.  IPinIP Tunnels:
          This is similar to above in the sense that it also creates network interface and all the packets
          going to/from this interface can be tunneled using IPSEC/IKE tunnel.
          But, I am not sure how it works when the SG gets the dynamic IP address for its WAN interface.
          In that way, L2TP over IPSEC interface may be better.

     Disadvantage: More per packet overhead.
 
Srini

Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com
----- Original Message ----- 
From: "Ravi Kumar" <ravivsn@roc.co.in>
To: "ipsec.mailingList" <" <ipsec@lists.tislabs.com>"@roc.co.in>
Sent: Monday, September 22, 2003 9:00 PM
Subject: How to reduce number of IPSEC security policies that need to be configured?


> Hi,
>        I stumbled upon a problem and appreciate any feedback from the group.
>        We are creating a Security Router with Firewall, IPSEC, IKE and
>        L2TPoIPSEC AND transparent proxy for  EMAIL (SMTP) for Spam
>        control and antiVirus.
> 
> 
>        When proxy is  enabled, we observed that we needed to create multiple
>        IPSEC policies between two sites. With more number of sites, number 
> of policies
>        that are required to be configured go up and that could be a big 
> deployment problem.
> 
>        Let me explain the two site scenario:
> 
> 
>         HO 
> Network-----SecurityGateway(HO)-----Internet-------SecurityGateway(BO)----BO 
> Network.
> 
> 
>         HO Network: 10.1.5.0/24
>         HO WAN side IP address: 1.2.3.4
>         BO WAN Side IP address: 5.6.7.8
>         BO Network: 10.1.6.0/24
> 
> 
>         Typically one security policy of type:
>                  10.1.5.0/24 to 10.1.6.0/24 ----> Apply Security with 
> 3DES+SHA1  on HO SG
>         would be good enough for securing the traffic from HO to BO.
> 
> 
>         When SMTP Spam control proxy is enabled, the connection from the 
> client is terminated at
>         the proxy and proxy creates new connection. New connection's source 
> IP is now 1.2.3.4.
>         This does not fall on above Security Policy. Due to this, one more 
> Security policy needs to
>         be created i.e
>              1.2.3.4 to 10.1.6.0/24 --------> Apply Security with 3DES+SHA1 
> on HO SG.
> 
> 
>         Similarly, for BO Security Gateway Proxy to work, we need to create 
> one more Security policy
>         on HO SG  i.e.  10.1.5.0/24  to 5.6.7.8 ----> Apply Security with 
> 3DES+SHA1.
> 
> 
>         Two more extra policies have to be created apart from Network to 
> Network Security policy.
>         If we have more number of WAN IP addresses and more branch offices, 
> the number of policies
>         that are to be created will go up dramatically.
> 
> 
>         As a box vendor, we would like to reduce the number of policies 
> that need to be created between
>         two sites by the end users.  Ideally, we would like one security 
> policy for each peer site.
> 
> 
>         I could think of two  proposals:
>         Proposal 1:
>            IKE/IPSEC allow security policy with multiple IP address and 
> Port ranges. IKE  allows
>            multiple ID payloads OR a single ID payload with multiple IP 
> address ranges and Port ranges.
>        Proposal 2:
>            Negotiation of opaque ID in quick mode. Either explicit 
> selectors can be negotiated OR
>            opaque ID can be negotiated. IN case of opaque ID negotiation, 
> both peers are assumed to
>            relate set of selectors to the opaque ID. In above example, all 
> three security policies have
>            one opaque ID shared between them. Whenever there is any packet 
> matching any of these
>            three security policies, opaque ID is sent as part of QM ID 
> payload. Security bundles, that are
>            created due to this, will be applicable for all three security 
> policies. On the receiving side, once
>            the packet is decrypted, it should be allowed to pass, if it 
> matches with any of the three inbound
>            security policies.
> 
> 
>        Any other solutions which does not require modifications to standards?
> 
>      Regards
>      Ravi
> 
> The Views Presented in this mail are completely mine. The company is not 
> responsible for what so ever.
> 
> ----------
> Ravi Kumar CH
> Rendezvous On Chip (I) Pvt Ltd
> Hyderabad, INDIA
> 
> ROC HOME PAGE:
> http://www.roc.co.in
>