Saturday, April 22, 2006
Some Thoughts on Crypto ISAKMP Policy Configuration.
Consider the following ISAKMP policy configuration -
When I first saw something like this, I noticed that the policy indicated that the authentication method used would be pre-shared but the actual pre-shared key was itself defined outside the isakpmp-policy configuration mode as is clear from the way the key configuration statement is indented above. That didn't seem to make sense to me. I thought that it would have been more intuitive to say something like
inside the ISAKMP policy configuration mode itself. After all, why put just the key configuration outside?
Well, it just occurred to me that the way Cisco has done it makes sense after all. Consider the case where you have a single router with (say) 100 IPSec peers. In that case, the naive method I was thinking of as the straightforward way of doing this would need a policy configuration block for each peer since the key and certainly the address would be different for each of the 100 peers. The way Cisco has done it, one could have one (or a few different) ISAKMP policy configuration blocks while using the separate key/address config statements for each peer to connect to the 100 peers. The Cisco way reuses the (well) reusable parts of the ISAKMP config statements for each peer and only needs the parts that are different (the key and peer address pair) for each IPSec peer.
Yet another case where after thinking a bit something that seemed superficially strange makes sense eventually!
crypto isakmp policy 10
authentication pre-share
group 2
lifetime 65535
crypto isakmp key foobar address 10.0.0.2
When I first saw something like this, I noticed that the policy indicated that the authentication method used would be pre-shared but the actual pre-shared key was itself defined outside the isakpmp-policy configuration mode as is clear from the way the key configuration statement is indented above. That didn't seem to make sense to me. I thought that it would have been more intuitive to say something like
authentication pre-share key foobar address 10.0.0.2
inside the ISAKMP policy configuration mode itself. After all, why put just the key configuration outside?
Well, it just occurred to me that the way Cisco has done it makes sense after all. Consider the case where you have a single router with (say) 100 IPSec peers. In that case, the naive method I was thinking of as the straightforward way of doing this would need a policy configuration block for each peer since the key and certainly the address would be different for each of the 100 peers. The way Cisco has done it, one could have one (or a few different) ISAKMP policy configuration blocks while using the separate key/address config statements for each peer to connect to the 100 peers. The Cisco way reuses the (well) reusable parts of the ISAKMP config statements for each peer and only needs the parts that are different (the key and peer address pair) for each IPSec peer.
Yet another case where after thinking a bit something that seemed superficially strange makes sense eventually!
