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

From: Ravi Kumar <[email-masked]>
Date: Tue, 23 Sep 2003 09:30:25 +0530

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

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Tue, 23 Sep 2003 10:32:52 -0700

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