Archive for January 6th, 2010

6
Jan

manual …keying

   Posted by: cristina_crow    in technical

Everybody loves IPsec. It does a lot of cool stuff protecting our traffic from one side to another, it is fairly easy to understand the general concept, but quite difficult to actually implement in real-life, mostly because a lot of vendors have their own idea of usability and each one has its own idea of actually implementing those numerous standards. Some of them decide to implement drafts (see Cisco, see CheckPoint) and some of them implement their own “drafts” – which makes things even more interesting.

Some other vendors decide to overcome the entire negotiation fuss and use predefined keys for the IPsec traffic, bypassing all the IKE negotiation and using manual keying. Here we have Cisco, Juniper, Sonicwall or our lovely Linux solutions.

In order to manually configure IPsec, the admin alters the SAD (Security Association Database) and SPD(Security Policy Database) databases of the device/kernel. The SAD contains specific traffic transformations, like the encryption/authentication algorithms, while the SPD indicates the traffic selectors/proxy-ids for the traffic that is to be transformed by the stuff described in SAD and indexed by an SPI.

An SAD entry would include:

  • Dest IP address
  • Ipsec proto (SA or ESP)
  • SPI (cookie)
  • Sequnce counter
  • Seq O/F flag
  • anti-replay window info
  • AH type and info
  • ESP type and info
  • Lifetime info
  • tunnel/transport mode flags
  • PATH MTU info

An SPD entry would contain:

  • pointer to active SAs
  • Selector fields

***Let’s take a simple site-to-site tunnel mode case, where the security gateways are 2001::1 (local gateway) and 2001::2 (remote gateway) and the subnet behind the local gateway is 2002::/112 and the one behind the remote gateway is 2003::/112. As you can imagine, I want to encrypt traffic between 2002::/112 and 2003::/112 with aes-cbc, let’s say and authenticate it with hmac-md5.

In order to configure manual keying on linux, we need to have:

- xfrm modules in ze kernel:

xfrm4_mode_transport     1792  0

xfrm6_mode_transport     1792  0
xfrm6_mode_tunnel       2208  0
xfrm4_mode_tunnel       2304  0
xfrm_user              17856  0
xfrm4_tunnel            2304  0
tunnel4                 3016  1 xfrm4_tunnel
ipv6                  235396  33 ah6,esp6,xfrm6_mode_tunnel

- and a small script that instructs the kernel on how to populate those two databases:

ip xfrm state add src 2001:0::2 dst 2001:0::1 proto esp spi 0×1000 enc “cbc(aes)”  0x12345678abcdef12f4f71dbccd2c1b07bce4e63b4c315414  auth “hmac(md5)” 0x012345abd9abcdeff1e0d3c2b5a4909a

ip xfrm state add src 2001:0::1 dst 2001:0::2 proto esp spi 0×2000 enc “cbc(aes)” 0xf4f71123452c1b07bce4e63b4c31541d12345678abcdef12  auth “hmac(md5)” 0x912345abd9abcdeff1e0d3c2b5a49080

ip xfrm policy add dir in src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel

ip xfrm policy add dir out src 2002::/112 dst 2003::/112 tmpl src 2001:0::1 dst 2001:0::2 proto esp mode tunnel

ip xfrm policy add dir fwd src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel

—– Now we should be able to see that:
# ip xfrm state
src 2001::2 dst 2001::1
proto esp spi 0×00001000 reqid 0 mode transport
replay-window 0
auth hmac(md5) 0x012345abd9abcdeff1e0d3c2b5a4909a
enc cbc(aes) 0x12345678abcdef12f4f71dbccd2c1b07bce4e63b4c315414
sel src ::/0 dst ::/0
src 2001::1 dst 2001::2
proto esp spi 0×00002000 reqid 0 mode transport
replay-window 0
auth hmac(md5) 0x912345abd9abcdeff1e0d3c2b5a49080
enc cbc(aes) 0xf4f71123452c1b07bce4e63b4c31541d12345678abcdef12
sel src ::/0 dst ::/0
—–and
# ip xfrm policy
src 2003::/112 dst 2002::/112
dir in priority 0
tmpl src 2001::2 dst 2001::1
proto esp reqid 0 mode tunnel
src 2002::/112 dst 2003::/112
dir out priority 0
tmpl src 2001::1 dst 2001::2
proto esp reqid 0 mode tunnel
src 2003::/112 dst 2002::/112
dir fwd priority 0
tmpl src 2001::2 dst 2001::1
proto esp reqid 0 mode tunnel
—–to delete the rules simply run:
ip xfrm state flush
ip xfrm policy flush

When trying to do interop with…NetScreen, let’s say, bare in mind that this device only permits one key per connection, not as linux xfrm, which lets you select a key per direction. A NetScreen config would look something like this…
I have defined a tunnel.1 interface in the Untrust zone of the device and configured the ‘vpn’ objects like it follows (as you can see, no need for any ‘ike’ objects, as there is no IKE going on in there):
set vpn “IPv6_manual” id 0x1c1e manual 2000 2000 gateway 2001::10 outgoing-interface “ethernet2/2″  local-address “2001::1″  ah md5 key 0101010101010101,0101010101010101
—this populates the SAD of the NetScreen device, while this:

set policy id 7155 name “IPv6_TU_man” from “Trust” to “Untrust”  ”IPv6_Man2″ “IPv6_Man1″ “ANY” tunnel vpn “IPv6_manual”
set policy id 7155
exit
set policy id 15155 name “IPv6_UT_man” from “Untrust” to “Trust”  ”IPv6_Man1″ “IPv6_Man2″ “ANY” tunnel vpn “IPv6_manual”
set policy id 15155
exit
—populates the SPD of the device; of course, the IPv6_Man1 and IPv6_Man2 are names of the IPv6 interfaces (public and private, respectively)
And, as the keys are already into the device’s kernel, I can simply list them with a fairly nice command:
-> get sa active
00001c1e<        2001::10  500  ah:null/md5  00002000   n/a   n/a M/- 15155 0
00001c1e>        2001::10  500  ah:null/md5  00002000   n/a   n/a M/-  7155 0
Voila!

Tags: , , , , , ,

2 Comments
Back to top