Configuring IPSec Dynamic SAs

Problem

You want IPSec to automatically generate keys and negotiate the SA parameters.

Solution

Use dynamic IPSec to automatically generate keys and negotiate SAs. First, create an IKE SA proposal and policy:

	[edit security ike proposal site1-site2-ike-proposal ]
	aviva@router1# set authentication-method pre-shared-keys 
	aviva@router1# set dh-group group1 
	aviva@router1# set authentication-algorithm sha1 
	aviva@router1# set encryption-algorithm 3des-cbc 
	aviva@router1# up 
	[edit security ike]
	aviva@router1# edit policy  10.0.97.62 
	[edit security ike policy 10.0.97.62 ]
	aviva@router1# set proposals  site1-site2-ike-proposal 
	aviva@router1# set pre-shared-key ascii-text  $1991poPPix 

Next, create an IPSec SA negotiation proposal and policy:

	[edit security ipsec proposal site1-site2-ipsec-proposal ]
	aviva@router1# set protocol bundle 
	aviva@router1# set authentication-algorithm hmac-sha1-96 
	aviva@router1# set encryption-algorithm 3des-cbc 
	aviva@router1# up 
	[edit security ipsec]
	aviva@router1# edit policy  site1-site2-ipsec-policy 
	[edit security ipsec policy site1-site2-ipsec-policy ]
	aviva@router1# set perfect-forward-secrecy keys group1 
	aviva@router1# set proposals  site1-site2-ipsec-proposal 

Then, associate the policy with the dynamic SA:

	[edit security ipsec]
	aviva@router1# set security-association  site1-site2-dynamic  mode tunnel 
	aviva@router1# set security-association  site1-site2-dynamic  dynamic replay-window-size  64 
	aviva@router1# set security-association  site1-site2-dynamic  ipsec-policy  
site1-site2-policy 

Configure two firewall filters. These are the same as those for the manual SA. The first directs all traffic from the local site into the IPSec tunnel:

	[edit firewall filter traffic-into-ipsec-tunnel ]
	aviva@router1# set term  into-ipsec-tunnel  from source-address  10.0.12.0/24 
	aviva@router1# set term  into-ipsec-tunnel  from destination-address  10.0.97.0/24 
	aviva@router1# set term  into-ipsec-tunnel  then count ipsec-tunnel 
	aviva@router1# set term  into-ipsec-tunnel  then ipsec-sa  site1-site2 
	aviva@router1# set term  last-term  then accept 

The second firewall filter accepts all traffic returning from the remote site:

	[edit firewall filter traffic-out-of-ipsec-tunnel ]
	aviva@router1# set term out-of-ipsec-tunnel from source-address 10.0.97.0/24 
	aviva@router1# set term out-of-ipsec-tunnel from destination-address 10.0.12.0/24 
	aviva@router1# set term out-of-ipsec-tunnel then accept 

Finally, apply the firewall filters as we did with the manual SA. Apply the first one, directing traffic into the tunnel, on the interface that comes from the local site into the security gateway:

	[edit interfaces fe-0/0/0]
	aviva@router1# set unit 0 family inet address 10.0.12.2/24
	aviva@router1# set unit 0 family inet filter input traffic-into-ipsec-tunnel

Apply the second filter on the ES interface that goes from the local security gateway to the remote security gateway:

	[edit interfaces es-3/0/0 ]
	aviva@router1# set unit 0 tunnel source 10.0.12.33 
	aviva@router1# set unit 0 tunnel destination 10.0.97.62 
	aviva@router1# set unit 0 family inet ipsec-sa site1-site2-dynamic 
	aviva@router1# set unit 0 family inet filter input traffic-out-of-ipsec-tunnel 

Configure the router at the remote site in the same way, substituting the correct address and interface names.

Discussion

In the IPSec manual SA setup, you predefine all SA parameters. It is generally a bother to manually coordinate keys with the administrator in charge of the remote site, so it is more common and practical to use dynamic SAs so that key negotiation and authentication are automated. For a dynamic SA, you define your preferences and IPSec negotiates the SA parameters, using IKE to establish and exchange keys. So you still define an IPSec SA and associate the SA with the ES interface. You also have to set up an IKE SA and a firewall filter to direct traffic into the tunnel. Again, this recipe is for M-series and T-series routers with ES PICs.

The IKE negotiation happens in two phases, Phase 1 and Phase 2. In Phase 1, the IKE SA is negotiated based on the IKE policy and IKE proposal, and the result is the creation of an IKE SA. This negotiated IKE SA is then used to secure the Phase 2 exchange, which uses the IPSec proposal and IPSec policy to create an IPSec SA pair (one SA for inbound and a second for outbound traffic). The IKE policy is used for the negotiation during Phase 1, and IPSec policy is used for the negotiation in Phase 2. This means that the IKE and IPSec proposals can use different algorithms.

For IKE, this recipe defines a negotiation proposal, here called site1-site2-ike-proposal, that creates an IKE SA based on the stated authentication and encryption algorithms. The set dh-group command configures this proposal to use 768-bit Diffie-Hellman prime modulus group when establishing the IKE session keys. By default, the IKE SA is valid for 3,600 seconds (1 hour). When it expires, a new one is negotiated. The IKE SA references an IKE policy (here, policy 10.0.97.62) that defines the preshared key to use for negotiation. The policy is identified by the IP address of the security gateway at the remote end of the tunnel, which is the tunnel destination addresses configured on ES interface es-3/0/0.

For IPSec, also define a proposal (here, site1-site2-ipsec-proposal) and a policy (site1-site2-ipsec-policy). The proposal uses the same parameters as in the manual SA in Recipe 3.1. By default, the negotiated SA is valid for 28,800 seconds (8 hours). When it expires, a new one is negotiated. On the ES PIC, anti-replay is disabled by default. (On the AS PIC, it is enabled by default with a default window size of 64 bits.) This recipe enables anti-replay with a window size of 64 bits.

The lifetime of both the IKE and IPSec proposals is configurable by using the set lifetime-seconds command. Here, you change the IKE proposal lifetime to 2 hours and the IPSec proposal lifetime to 10 hours:

	[edit security ike]
	aviva@router1# set proposal site1-site2-ike-proposal lifetime-seconds 7200
	[edit security ipsec]
	aviva@router1# set proposal site1-site2-ipsec-proposal lifetime-seconds 36000

The IPSec policy, site1-site2-ipsec-policy, defines which proposals IKE should consider and in which order (if you configure more than one). This recipe also enables perfect forward secrecy (PFS) security for keys, which means that the shared key material can be used to drive the IPSec SA keys only once. With PFS, if an IKE SA is present (Phase 1 of the negotiation), then during the IPSec SA negotiation (Phase 2 of the negotiation), a Diffie-Hellman exchange is required for every rekeying to generate the shared key material. Without PFS, a Diffie-Hellman exchange is done only during the initial keying but is not done again during the rekeying operation. PFS is considered to be more secure because it gets fresh keying material every time an IPsec SA is renegotiated.

As the last step, associate the dynamic SA with the tunnel on the ES interface.

You create firewall filters to direct traffic into and out of the tunnel and you have to configure the interface on the security gateway router that faces the local site. These configurations are the same as those shown in Recipe 3.1.

Configure the security gateway router at the remote site in the same way, using the appropriate address and interface names.

Verification of the dynamic IPSec SA is similar to that for the manual IPSec SA. You can use ping and traceroute to check the reachability of a host at the remote site and can look at the IPSec SA to verify that it is active and to see the SA parameters:

	aviva@router1> show ipsec security-associations detail
	Security association: site1-site2-dynamic, Interface family: Up

	 Local gateway: 10.0.12.33, Remote gateway: 10.0.97.62
	 Local identity: ipv4_subnet(any:0,[0..7]=10.1.12.0/24)
	 Remote identity: ipv4_subnet(any:0,[0..7]=10.1.56.0/24)

	 Direction: inbound, SPI: 2133029543, AUX-SPI: 0
	 Mode: tunnel, Type: dynamic, State: Installed
	 Protocol: BUNDLE, Authentication: hmac-sha1-96, Encryption: des-cbc
	 Soft lifetime: Expires in 26212 seconds
	 Hard lifetime: Expires in 26347 seconds
	 Anti-replay service: Enabled

	 Direction: outbound, SPI: 1759450863, AUX-SPI: 0
	 Mode: tunnel, Type: dynamic, State: Installed
	 Protocol: BUNDLE, Authentication: hmac-sha1-96, Encryption: des-cbc
	 Soft lifetime: Expires in 26212 seconds
	 Hard lifetime: Expires in 26347 seconds
	 Anti-replay service: Enabled

The last thing to check is the IKE SA:

	aviva@router1> show ike security-associations detail
	IKE peer 10.0.97.62
	 Role: Initiator, State: Matured
	 Initiator cookie: b5dbdfe2f9000000, Responder cookie: a24c868410000041
	 Exchange type: Main, Authentication method: Pre-shared-keys
	 Local: 10.0.12.33:500, Remote: 10.0.97.62:500
	 Lifetime: Expires in 401 seconds
	 Algorithms:
	 Authentication : sha1
	 Encryption : des-cbc
	 Pseudo random function: hmac-sha1
	 Traffic statistics:
	 Input bytes : 1736
	 Output bytes : 2652
	 Input packets : 9
	 Output packets: 15
	 Flags: Caller notification sent
	 IPSec security associations: 3 created, 0 deleted
	 Phase 2 negotiations in progress: 0

Here's what the relevant portions of the dynamic SA configuration look like, with comments added:

	[edit security ike]
	proposal site1-site2-ike-proposal { # <-- IKE proposal
	 authentication-method pre-shared-keys;
	 dh-group group1;
	 authentication-algorithm sha1;
	 encryption-algorithm 3des-cbc;
	}
	policy 10.0.97.62 { # <-- IKE policy to peer security gateway router
	 proposals site1-site2-ike-proposal; # <-- pointer to IKE proposal
	 pre-shared-key ascii-text "$9$6…"; ## SECRET-DATA
	}

	[edit security ipsec]
	proposal site1-site2-ipsec-proposal { # <-- IPSec proposal
	 protocol bundle;
	 authentication-algorithm hmac-sha1-96;
	 encryption-algorithm 3des-cbc;
	}
	policy site1-site2-ipsec-policy { # <-- IPSec policy
	 perfect-forward-secrecy {
	 keys group1;
	 }
	 proposals site1-site2-ipsec-proposal; # <-- pointer to IPSec proposal
	}
	security-association site1-site2-dynamic { # <-- dynamic IPSec SA
	 mode tunnel;
	 dynamic {
	 replay-window-size 64;
	 ipsec-policy site1-site2-ipsec-policy;
	 }
	}

	[edit interfaces]
	fe-0/0/0 { # <-- interface facing local site
	 unit 0 {
	 family inet {
	 filter {
	 input traffic-into-ipsec-tunnel;
	 }
	 address 10.0.12.2/24;
	 }
	 }
	}
	es-3/0/0 { # <-- interface facing remote security gateway router
	 unit 0 {
	 tunnel {
	 source 10.0.12.33;
	 destination 10.0.97.62;
	 }
	 family inet { # <-- associate IPSec SA with interface
	 ipsec-sa site1-site2-dynamic;
	 filter {
	 input traffic-out-of-ipsec-tunnel;
	 }
	 }
	 }
	}