Steps for configuring the partner company model (host-to-host with IPSec)

The partner company model consists of two interconnected networks, with the server protecting traffic that originates from hosts outside the internal network.

Before you begin

The following statements and concepts are covered in the discussion of this model:

Dynamic host-to-host IKE negotiations
Key exchange rules
Local and remote security endpoints
Use of wildcards in Location and Identity
IpLocalStartAction
Granularity
RSA signature peer authentication
Certificates and certificate authorities
On-demand activation
Remote activation

Figure 1 shows the partner company portion of the security model network.

Figure 1. Partner company model

z/OS host, thru public address 9.2.2.2 to IP router, connected to partner company (9.4.0.0/16) thru address 9.4.4.4

The partner company model is similar to that of the internal network, but an increased need for security means that a greater number of connections rely on data authentication and encryption. Although some services are allowed in the clear, sensitive data needs IPSec protection. To apply IPSec to a connection, the traffic that flows over that connection must match an IP filter rule that has an ipsec action.

For this example, assume you must meet the following requirements to allow network communications from a partner company in an untrusted zone B over a connected network (9.4.0.0/16) to a public IP address (9.2.2.2) on this host:

Allow IKE traffic from untrusted zone B to this host.
Allow secure FTP traffic (using TLS/SSL) from untrusted zone B to a secure FTP server running on this host.
Secure FTP has its own security mechanism. Although IPSec can be used together with TLS/SSL, using both adds processing expense. For this example, secure FTP is allowed without IPSec protection.
Allow Enterprise Extender (EE) traffic from untrusted zone B to an EE service running on this host using a dynamic IPSec tunnel with strong encryption and authentication.
Because there is no encryption mechanism used in this example for EE, IPSec provides the secure service.
Allow FTP traffic from untrusted zone B to an FTP server running on this host using a dynamic IPSec tunnel with strong AH authentication.
The dynamic IPSec tunnel for EE comes up when outbound EE traffic is detected (on-demand activation).
A dynamic IPSec tunnel for normal FTP control activates for each remote host that initiates an FTP connection (remote activation).
A dynamic IPSec tunnel for normal FTP data activates for each outbound data connection to a remote host (local activation).
Peers authenticate themselves using the RSA signature method.

Procedure

Perform the following steps to meet these requirements and configure the partner company model.

For each zone, determine what services are allowed:
- IKE traffic
- Normal FTP traffic
- Secure FTP traffic
- Enterprise Extender traffic

Define an IpService statement for each wanted service.

IKE uses UDP, port 500 for message exchanges:

IpService                    IKE-local
{
  SourcePortRange            500
  DestinationPortRange       500
  Protocol                   UDP
  Direction                  bidirectional
  Routing                    local
  SecurityClass              0
}

For normal FTP traffic, allow inbound connections but do not allow outbound connection requests, other than data. Two services are required, one for the control connection and one for the data connection:

IpService                    FTPServer-Control
{
  SourcePortRange            21
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional InboundConnect
  Routing                    local
  SecurityClass              0
}

IpService                    FTPServer-Data
{
  SourcePortRange            20
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional OutboundConnect
  Routing                    local
  SecurityClass              0
}

For secure FTP traffic, allow inbound connections but do not allow outbound connection requests, other than data. Two services are required, one for the control connection and one for the data connection.

IpService                    SecureFTPServer-Control
{
  SourcePortRange            990
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional InboundConnect
  Routing                    local
  SecurityClass              0
}

IpService                    SecureFTPServer-Data
{
  SourcePortRange            989
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional OutboundConnect
  Routing                    local
  SecurityClass              0
}

For Enterprise Extender traffic, allow both inbound and outbound traffic:

IpService                    Enterprise-Extender
{
  SourcePortRange            12000 12004
  DestinationPortRange       12000 12004
  Protocol                   UDP
  Direction                  bidirectional
  Routing                    local
  SecurityClass              0
}

IP services can be grouped together for convenience, flexibility, and reuse of configuration. Any IP filter rule that includes an IP service group will be expanded to include all of the services from that group. The following IP service groups include the IP services that define the FTPServer and the SecureFTPServer:

IpServiceGroup FTPServer
{
   IpServiceRef FTPServer-Control
   IpServiceRef FTPServer-Data
} 
IpServiceGroup SecureFTPServer
{
   IpServiceRef Secure-FTPServer-Control
   IpServiceRef Secure-FTPServer-Data
}

Determine the data endpoints to be protected. In this example, the local data endpoint is the public address of the server, and the remote data endpoint is the entire subnetwork in zone B:
```
Local public IP address:  9.2.2.2
Remote subnet: 9.4.0.0/16
```

Determine what level of security is needed between each set of data endpoints:

IKE traffic - permit
Secure FTP traffic - permit
EE traffic - IPSec encryption and authentication
FTP traffic - IPSec authentication

Configure an IpGenericFilterAction statement for the level of security that is required. The requirements stated that IKE and secure FTP should be allowed, and that EE and normal FTP traffic required IPSec protection. Notice that the parameters of the IpGenericFilterAction statement include ipsec as well as permit and deny. Because no logging requirements were specified, two actions are needed, permit and ipsec:
```
IpGenericFilterAction    permit-nolog
{
   IpFilterAction       permit
   IpFilterLogging       no
}

IpGenericFilterAction    ipsec-nolog
{
   IpFilterAction       ipsec
   IpFilterLogging       no
}
```
If IPSec is required between any two endpoints, take the following actions:
1. Configure a key exchange policy that defines the parameters of the phase 1 negotiation as follows:
  1. Determine the required type and strength of protection for the phase 1 Security Association. Phase 1 Security Associations must use both authentication and encryption. Because strong encryption was specified for phase 2, use strong encryption for phase 1:
```
Authentication, SHA1 algorithm
Encryption, 3DES algorithm
DHGroup, Diffie-Hellman Group2 
```
    Tip: The greater the Diffie-Hellman group specified, the greater the protection provided.
  2. Decide what type of peer authentication is used:
```
RSA signature
```
    Because the remote data endpoint represents multiple hosts in this example, RSA signature is used. RSA signature authentication provides greater flexibility, scalability, and security than pre-shared key authentication. Because there are potentially multiple remote peers in the partner company's subnet, RSA signature is a reasonable choice.
    
    The use of RSA signature requires setup of RACF® certificates and certificate authority information. Both IKE peers need access to a key ring with at least one X.509 digital certificate to identify itself. To set up the IKE daemon for certificates, see Steps for preparing to run IP security. The site should decide what certificate authorities are recognized. A certificate authority can be an outside commercial entity, or it can be defined locally in RACF. For information about installing certificate authorities in RACF, see z/OS Security Server RACF Security Administrator's Guide.
    
    In this example, the IKEv1 protocol is used and the IKE daemon is using the native certificate service. A certificate authority with label CA4PartnerCompany is used, which is presumed to have been defined as a certificate authority in the RACF database. The label CA4PartnerCompany should be added to the iked.conf file as a recognized certificate authority as follows:
```
SupportedCertAuth CA4PartnerCompany
```
    Guideline: For more efficient processing of certificates when the IKED is using the native certificate service, you should code SupportedCertAuth for each acceptable certificate authority that will be used to sign certificates for remote IKE peers.
  3. Configure a KeyExchangeOffer statement that defines the parameters for the phase 1 negotiation, including type of peer authentication, strength of encryption, and how often the phase 1 keys are refreshed. Because KeyExchangeOffer statements are reusable, give it a descriptive name as follows:
```
KeyExchangeOffer RSA-SHA1-3DES-DH2
{
   HowToEncrypt    3DES
   HowToAuthMsgs   SHA1
   HowToAuthPeers  RsaSignature
   DHGroup         Group2
   RefreshLifetimeProposed  480
   RefreshLifetimeAccepted  240 1440
   RefreshLifesizeProposed  none
   RefreshLifesizeAccepted  none
}
```
  4. Decide whether NAT traversal will be allowed.
    In this example, the following parameter is used:
```
AllowNat No
```
  5. Determine the negotiation mode. Main mode is used for phase 1, providing added security by encrypting the identities of the two IKE peers during the phase 1 negotiation.
  6. Configure a KeyExchangeAction statement that defines the control information for the phase 1 negotiation. The key exchange action determines the mode of the phase 1 negotiation and the parameters that are included in the KeyExchangeOffer statement. Although multiple KeyExchangeOffer statements are acceptable, only one is required. Both peers must agree on the parameters. Use the KeyExchangeOffer statement that was configured in step 6.a.iii:
```
KeyExchangeAction Main-RSA-SHA1-3DES-DH2
{
   HowToInitiate       main
   HowToRespondIKEv1   main
   KeyExchangeOfferRef RSA-SHA1-3DES-DH2
}
```
  7. Configure a LocalSecurityEndpoint statement and RemoteSecurityEndpoint statement. In this example, the local security endpoint is the local host. An identity and IP address of the local IKE peer is required as follows:
```
LocalSecurityEndpoint  Public_IKED
{
   Identity      IpAddr  9.2.2.2
   Location      9.2.2.2
}
```
    Similarly, the same information is needed for remote hosts. Notice that in the RemoteSecurityEndpoint statement, an IP address range is specified for both identity and location. Although it is possible to configure a RemoteSecurityEndpoint statement for every host in the remote subnetwork, unless they have unique key exchange requirements, it is not necessary. Wildcards can be used for the Identity and Location parameters. Any of the identity types can potentially contain wildcards to include a group of remote hosts with similar identities.
```
RemoteSecurityEndpoint   ZoneB_IKED
{
   Identity      IpAddr   9.4.0.0/16
   Location      9.4.0.0/16
   CaLabel       CA4PartnerCompany
}
```
    The use of an IPv4 address on the Identity parameter for the Local_IKED security endpoint requires that the X.509 digital certificate for the local IKE daemon include the IPv4 address in the Subject Alternative Name field of the certificate. The use of an IPv4 subnet on the Identity parameter for the ZoneB_IKED security endpoint requires that an IPv4 address within that subnet (9.4.0.0/16) appear in the Subject Alternative Name field of the X.509 digital certificate for the remote IKE daemon.
    
    The inclusion of the CaLabel parameter in the ZoneB_IKED security endpoint emphasizes the fact that the local host requests that the remote host use only certificates that are signed by the certificate authority that is identified by the label CA4PartnerCompany.
    
    Rule: For RSA signature mode authentication, the identity of a security endpoint must be contained in its X.509 digital certificate, either in the Subject Name field or the Subject Alternative Name field.
    
    For detailed specifications on the use of wildcards in the RemoteSecurityEndpoint statement, see z/OS Communications Server: IP Configuration Reference.
  8. Configure a KeyExchangeRule statement that includes the two endpoints and the key exchange action:
```
KeyExchangeRule              ZoneB_KeyExRule1
{
   LocalSecurityEndpointRef  Public_IKED
   RemoteSecurityEndpointRef ZoneB_IKED
   KeyExchangeActionRef      Main-RSA-SHA1-3DES-DH2
}
```
  9. Include the key exchange rule in the KeyExchangePolicy statement:
```
KeyExchangePolicy
{
   KeyExchangeRuleRef    ZoneB_KeyExRule1
}
```
2. Configure an IpDynVpnAction statement that defines the parameters of the phase 2 negotiation as follows:
  1. Determine the required type and strength of IPSec protection for the phase 2 Security Association.
    In this example, there is a unique requirement for each traffic type. Therefore, there are two types of IPSec protection for each type of traffic as follows:
```
EE traffic - strong encryption: ESP, 3DES
             strong ESP authentication: Hmac SHA1
Normal FTP traffic - strong AH authentication, Hmac SHA1
```
    This information eventually translates into two IpDataOffer statements.
  2. Determine whether tunnel or transport mode is required.
    Tunnel mode is required only if either endpoint of the Security Association is a secure gateway. The choice is optional in a host-to-host configuration, but transport mode is typically used.
  3. Configure IpDataOffer statements that define the parameters of the phase 2 negotiation.
    - Authenticated offer for FTP:
```
IpDataOffer TRAN-AHSHA-NOENCR
{
   HowToEncap Transport
   HowToEncrypt DoNot
   HowToAuth    AH HMAC_SHA1
   RefreshLifetimeProposed 240
   RefreshLifetimeAccepted 120 480
   RefreshLifesizeProposed  none
   RefreshLifesizeAccepted  none
}
```
    - Encrypted and authenticated offer for EE:
```
IpDataOffer TRAN-ESPSHA-3DES
{
   HowToEncap Transport
   HowToEncrypt 3DES
   HowToAuth    ESP HMAC_SHA1
   RefreshLifetimeProposed 240
   RefreshLifetimeAccepted 120 480
   RefreshLifesizeProposed  none
   RefreshLifesizeAccepted  none
}
```
  4. Determine which peer is allowed to initiate the negotiation.
    Because the EE VPN activates when outbound EE traffic is detected, you need to be able to start the negotiation locally. The remote host initiates the negotiation of the Security Association for the FTP control connection, so local initiation is not required. The FTP data connection is initiated from the local host, so to activate the Security Association, local initiation is required.
  5. Configure an IpDynVpnAction statement that defines the control information for the phase 2 negotiation.
    The IpDynVpnAction statement can control which host is allowed to initiate the negotiation. You must allow the IPSec VPN for the FTP control connection to be initiated by the remote peer, and the data connection by the local host. EE should be allowed to initiate an IKE negotiation locally.
    - Authenticated VPN action for FTP:
```
IpDynVpnAction FTP-vpnaction
{
   Initiation           either
   InitiateWithPfs      group2
   AcceptablePfs        group2
   VpnLife              1440
   IpDataOfferRef       TRAN-AHSHA-NOENCR
}
```
    - Encrypted and authenticated VPN action for EE traffic:
```
IpDynVpnAction EE-vpnaction
{
   Initiation           localonly
   InitiateWithPfs      group2
   AcceptablePfs        group2
   VpnLife              1440
   IpDataOfferRef       TRAN-ESPSHA-3DES
}
```
3. Decide how the Security Association is to be activated as follows:
  1. Configure an optional LocalDynVpnPolicy statement, if command-line activated or autoactivated.
    Neither the EE nor FTP VPNs require a LocalDynVpnPolicy statement, because neither is command-line activated or autoactivated.
  2. Configure an optional IpLocalStartAction statement, if the Security Association is to be activated locally (that is, on-demand, command-line, or autoactivation) and one of the security endpoints is acting as a security gateway (that is, not a host-to-host Security Association). Include a reference to the IpLocalStartAction statement in the IP filter rule.
    Before a phase 2 negotiation can initiate, the IKE daemon needs to know the IP addresses, ports, and protocols that the Security Association covers. In most cases, these can be inferred from the filter rule, or from the packet that started the on-demand activation. An IpLocalStartAction statement explicitly defines where these parameters are obtained. The granularity setting determines whether the information comes from the matching filter rule, or from the packet. By explicitly specifying packet, you can guarantee that a new Security Association is created for each connection request.
```
IpLocalStartAction           ZoneB-Start-Action
{
   AllowOnDemand             yes
   LocalPortGranularity      packet
   RemotePortGranularity     packet
   ProtocolGranularity       packet
   LocalIpGranularity        packet
   RemoteIpGranularity       packet
   LocalSecurityEndpointRef  Public_IKED
   RemoteSecurityEndpointRef ZoneB_IKED
}
```
    In this example, specifying packet is not required. IKE detects that the filter rule has a range of ports specified and resorts to packet granularity instead of the default of rule. Specifying packet is required, however, if the EE and FTP rules had all ports specified. In that case, one Security Association is negotiated for all ports, not a single port. To avoid confusion, it is better to specify your intention.
  3. Set the global PreDecap parameter of the IpFilterPolicy statement to off, or create an IpFilterRule statement that allows IPSec traffic (AH and ESP).
    When the system begins to process encapsulated traffic, the encapsulated packets are subject to filtering. The encrypted and authenticated packets are denied unless they are explicitly allowed. There are two options to configure this that are subtly different. The first is less restrictive, allowing AH and ESP packets from anywhere and not subjecting them to filtering until after the packets have had their IPSec headers removed. The second method is to add an IpFilterRule statement that explicitly permits the IPSec-encapsulated traffic. This option adds an additional layer of security, in that you can control exactly who is allowed to send encrypted traffic. This protects system resources by preventing the processing of IPSec packets unnecessarily, such as might happen in the case of a malicious attack of IPSec packets. Although more secure, this solution is less efficient because it requires additional processing resources to filter all IPSec-encapsulated traffic.
    
    For the first option, in the main IpFilterPolicy block, code PreDecap off as follows:
```
IpFilterPolicy
{
   PreDecap off
   ⋮
}
```
    For the second option, configure a filter rule in the IpFilterPolicy block that explicitly allows AH and ESP traffic as follows:
```
IpFilterRule           Allow-IPSec-traffic
{
   IpSourceAddr        9.2.2.2
   IpDestAddrSet       9.4.0.0/16
   IpService                    AH-traffic
   {
      Protocol                  AH
      Direction                 bidirectional
      Routing                   local
      SecurityClass             0        		
   }
   IpService                    ESP-traffic
   {
      Protocol                  ESP
      Direction                 bidirectional
      Routing                   local
      SecurityClass             0        		
   }
   IpGenericFilterRef    permit-nolog
}
```
    Tip: In most cases, unless the extra security is deemed a necessity, use the PreDecap off global option to allow IPSec packets to flow with minimum overhead.

Define an IpFilterRule statement for each set of data endpoints. The secure host and subnetwork B represent the data endpoints. The IpService statements were defined in step 2. Place the IpDynVpnAction statements that were created in step 6 with the appropriate rule.

IpFilterRule              ZoneB-Permitted-traffic
{
   IpSourceAddrRef           PublicServerAddress
   IpDestAddrSetRef          ZoneB-subnet
   IpServiceRef              IKE-local
   IpServiceGroupRef         SecureFTPServer
   IpGenericFilterActionRef  permit-nolog
}


IpFilterRule              FTPServer-ZoneB
{
   IpSourceAddr              9.2.2.2
   IpDestAddrSet             9.4.0.0/16
   IpServiceGroupRef         FTPServer
   IpGenericFilterActionRef  ipsec-nolog
   IpDynVpnAction            FTP-vpnaction
   IpLocalStartActionRef     ZoneB-Start-Action
}
IpFilterRule             EE-ZoneB
{
   IpSourceAddr          9.2.2.2
   IpDestAddrSet         9.4.0.0/16
   IpService
   {
      SourcePortRange       12000 12004
      DestinationPortRange  12000 12004
      Protocol              udp
      Direction             bidirectional
      Routing               local
      SecurityClass         0
   }
   IpGenericFilterActionRef  ipsec-nolog
   IpDynVpnAction            EE-vpnaction
   IpLocalStartActionRef     ZoneB-Start-Action
}

Because both IKE and Secure FTP need to be permitted without IPSec protection, an IpFilterRule statement for both is not needed. The two services can be combined into one rule.

Tip: Any services that share the same data endpoints and the same security requirements can be placed together in one IpFilterRule statement.

Include the IpFilterRule statements in the IpFilterPolicy block. The IpFilterRule statement allowing IKE traffic should always be at the top of the list. The rest of the IpFilterRule statements are disjointed, and their relative placement within the IpFilterPolicy is irrelevant.
Tip: If it is known that one particular type of traffic is the most frequent, placing that rule near the top of the list results in faster filter lookups.

Define an IP filter group for each zone and include the IpFilterRule statements that belong to that zone. Although the creation of reference objects and groups is not mandatory, they provide for ease of maintenance as the IP security policy grows more complex.

A completely configured policy, including all objects and their references, is as follows:

# IpFilterPolicy for secure public server

IpFilterPolicy
{
   PreDecap             off
   IpFilterGroupRef     ZoneB
}

KeyExchangePolicy
{
   KeyExchangeRuleRef   ZoneB_KeyExRule1
}

###### All reusable statements follow #######
IpFilterGroup           ZoneB
{
   IpFilterRuleRef      ZoneB-Permitted-traffic
   IpFilterRuleRef      FTPServer-ZoneB  #IPSec-protected
   IpFilterRuleRef      EE-ZoneB         #IPSec-protected
}

######################################
# IpFilterRules                      #
#   defines:                         #
#      data endpoints                #
#      Allowed services              #
#      Actions (permit, deny, ipsec) #
######################################
IpFilterRule            ZoneB-Permitted-traffic
{
   IpSourceAddrRef           PublicServerAddress
   IpDestAddrSetRef          ZoneB-subnet
   IpServiceRef              IKE-local
   IpServiceGroupRef         SecureFTPServer
   IpGenericFilterActionRef  permit-nolog
}

IpFilterRule           EE-ZoneB
{
   IpSourceAddrRef           PublicServerAddress
   IpDestAddrSetRef          ZoneB-subnet
   IpServiceRef              Enterprise-Extender
   IpGenericFilterActionRef  ipsec-nolog
   IpDynVpnActionRef         EE-vpnaction
   IpLocalStartActionRef     ZoneB-Start-Action
}

IpFilterRule           FTPServer-ZoneB
{
   IpSourceAddrRef           PublicServerAddress
   IpDestAddrSetRef          ZoneB-subnet
   IpServiceGroupRef         FTPServer
   IpGenericFilterActionRef  ipsec-nolog
   IpDynVpnActionRef         FTP-vpnaction
   IpLocalStartActionRef     ZoneB-Start-Action
}

#######################
# Local Start Actions #
#######################
IpLocalStartAction           ZoneB-Start-Action
{
   AllowOnDemand             yes
   LocalPortGranularity      packet
   RemotePortGranularity     packet
   ProtocolGranularity       packet
   LocalIpGranularity        packet
   RemoteIpGranularity       packet
   LocalSecurityEndpointRef  Public_IKED
   RemoteSecurityEndpointRef ZoneB_IKED
}

####################
# IpService groups #
####################
IpServiceGroup            FTPServer
{
   IpServiceRef           FTPServer-Control
   IpServiceRef           FTPServer-Data
}

IpServiceGroup            SecureFTPServer
{
   IpServiceRef           SecureFTPServer-Control
   IpServiceRef           SecureFTPServer-Data
}

##################################
# Services provided by this host #
##################################

IpService                    IKE-local
{
  SourcePortRange            500
  DestinationPortRange       500
  Protocol                   UDP
  Direction                  bidirectional
  Routing                    local
  SecurityClass              0
}

IpService                    SecureFTPServer-Control
{
  SourcePortRange            990
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional InboundConnect
  Routing                    local
  SecurityClass              0
}

IpService                    SecureFTPServer-Data
{
  SourcePortRange            989
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional OutboundConnect
  Routing                    local
  SecurityClass              0
}

IpService                    Enterprise-Extender
{
  SourcePortRange            12000 12004
  DestinationPortRange       12000 12004
  Protocol                   UDP
  Direction                  bidirectional
  Routing                    local
  SecurityClass              0
}

IpService                    FTPServer-Control
{
  SourcePortRange            21
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional InboundConnect
  Routing                    local
  SecurityClass              0
}

IpService                    FTPServer-Data
{
  SourcePortRange            20
  DestinationPortRange       1024 65535
  Protocol                   tcp
  Direction                  bidirectional OutboundConnect
  Routing                    local
  SecurityClass              0
}

######################
# Security Endpoints #
######################
LocalSecurityEndpoint  Public_IKED
{
   Identity      IpAddr  9.2.2.2
   Location      9.2.2.2
}

RemoteSecurityEndpoint   ZoneB_IKED
{
   Identity      IpAddr   9.4.0.0/16
   Location      9.4.0.0/16
   CaLabel       CA4PartnerCompany
}

##########################
# Generic filter actions #
##########################

IpGenericFilterAction    permit-nolog
{
   IpFilterAction       permit
   IpFilterLogging       no
}

IpGenericFilterAction    ipsec-nolog
{
   IpFilterAction       ipsec
   IpFilterLogging       no
}

##################################
# Key Exchange offers            #
#   defines:                     #
#     Authentication type        #
#     Encryption type            #
#     Peer authentication method #
#     Refresh limits             #
##################################
KeyExchangeOffer RSA-SHA1-3DES-DH2
{
   HowToEncrypt    3DES
   HowToAuthMsgs   SHA1
   HowToAuthPeers  RsaSignature
   DHGroup         Group2
   RefreshLifetimeProposed  480
   RefreshLifetimeAccepted  240 1440
   RefreshLifesizeProposed  none
   RefreshLifesizeAccepted  none
}

##################################
# Key Exchange Actions           #
#  defines:                      #
#    Negotiation mode            #
#    List of Key exchange offers #
##################################
KeyExchangeAction Main-RSA-SHA1-3DES-DH2
{
   HowToInitiate       main
   HowToRespondIKEv1   main
   KeyExchangeOfferRef RSA-SHA1-3DES-DH2
}

######################################
# KeyExchangeRules                   #
#   defines:                         #
#      A pair of security endpoints  #
#      permitted in IKE negotiations #
######################################
KeyExchangeRule              ZoneB_KeyExRule1
{
   LocalSecurityEndpointRef  Public_IKED
   RemoteSecurityEndpointRef ZoneB_IKED
   KeyExchangeActionRef      Main-RSA-SHA1-3DES-DH2
}

############################
# Data Offers              #
#   defines:               #
#      Encapsulation mode  #
#      Authentication type #
#      Encryption type     #
#      Refresh limits      #
############################
### Authenticated offer ###
IpDataOffer TRAN-AHSHA-NOENCR
{
   HowToEncap Transport
   HowToEncrypt DoNot
   HowToAuth    AH HMAC_SHA1
   RefreshLifetimeProposed 240
   RefreshLifetimeAccepted 120 480
   RefreshLifesizeProposed  none
   RefreshLifesizeAccepted  none
}

### Encrypted offer ###
IpDataOffer TRAN-ESPSHA-3DES
{
   HowToEncap Transport
   HowToEncrypt 3DES
   HowToAuth    DoNot
   RefreshLifetimeProposed 240
   RefreshLifetimeAccepted 120 480
   RefreshLifesizeProposed  none
   RefreshLifesizeAccepted  none
}

##############################
# Dynamic VPN Actions        #
#   defines:                 #
#     Initiation role        #
#     Pfs group              #
#     Lifetime of connection #
#     List of Data offers    #
##############################
IpDynVpnAction FTP-vpnaction
{
   Initiation           either
   InitiateWithPfs      group2
   AcceptablePfs        group2
   VpnLife              1440
   IpDataOfferRef       TRAN-AHSHA-NOENCR
}

IpDynVpnAction EE-vpnaction
{
   Initiation           localonly
   InitiateWithPfs      group2
   AcceptablePfs        group2
   VpnLife              1440
   IpDataOfferRef       TRAN-ESPSHA-3DES
}

################
# IP addresses #
################

IpAddr    PublicServerAddress
{
   Addr   9.2.2.2
}

IpAddrSet ZoneB-subnet
{
   Prefix 9.4.0.0/16
}

Include all configured statements in the stack-specific IP security configuration file.