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; } } } }