Archive for January, 2010

Come Rugiada al cespite

Posted: January 29, 2010 in media-culture
Tags: ,

by Placido Domingo – Verdi – Ernani first scene

That kind of voice and interpretation that just gives you thrills all over your body and never lets you get away from the iPod

Come rugiada al cespite
D’un appassito fiore,
D’aragonese vergine
Scendeami voce al core;
Fu quello il primo palpito,
il primo palpito
D’amor, d’amor che mi beò
Il vecchio Silva stendere
Osa su lei la mano
Domani trarla al talamo
Confida l’inumano.
Ah, s’ella m’è tolta, ahi, misero!
D’affanno morirò!
S’ella m’è tolta, ahi, misero!
D’affanno morirò!
D’affanno, d’affanno, d’affanno morirò!
D’affanno morirò!
D’affanno morirò!

Advertisements

Stoke is quite a cool company when it comes to VPN gateways, and I mention here the SSX-3000, the only device I had the pleasure of working with. I could see on their website that new investments are made in LTE technologies, which should make this company even more attractive for me.

Well, this post is going to be about a specific thinggie of the SSX-3000 and StokeOS, that funky colored box, namely how they work with digital certificates. The scenario I am using them on is a classic Remote-Access scenario, for IKEv2. The StokeOS gateway is getting authenticated by the roadwarrior via digital certificate, while the roadwarrior authenticates via EAP.

First of all, we need digital certificates for the StokeOS. Following the User Guide got me nowhere, so we had to be inventive 😀

A. The official version

1. Create a CSR on the Stoke:

Stoke[local]#certificate request new name newcsr.pem days 100 keylength 1024

2. Copy – paste the content of the CSR (or copy the file onto an ftp/tftp server), then generate a certificate using a CA (I had a Windows 2003 Server) => results a signed certificate – I used to download them in base64 format

3. Copy – paste the CA’s certificate and the Stoke’s certificate we’ve just signed onto Stoke and run the command:

Stoke[local]#certificate device-certificate new ca-certfile cacert.pem format pemcertfile signed-ssx-ca.pem format pem name mypkcs12

— This command should “link” the CA, the signed certificate and the Stoke’s private RSA key to a PKCS12 file that this device uses for authentication. This is how Stoke authenticates 🙂

*** PROBLEM: when generating the CSR, the private key doesn’t get saved anywhere. I have looked everywhere:  ” -r” : /hd/…, /cfint, /cfext… – so, the latest mightiest command is not working.

B.  The working version

1. Do not create the CSR on the DUT 😛

2. Generate a “Server Certificate” from IE and download it to a tftp/ftp server – it will be in pfx format

3. Export the private key to a separate key file – I have used openssl

4. Upload the CA’s certificate, signed certificate and the private key file on SSX and run the command (assuming I have put these files on /hd/Certs directory):

Stoke[local]#certificate device-certificate new name SSX format pem ca-certfile /hd/Certs/cacert.pem format pem signed-certificate /hd/Certs/signed-ssx-ca.pem format pem private-key /hd/Certs/signed-ssx-ca-key.pem

and now it works 🙂

as you can see from

Stoke[local]#sh certificate device-certificate all

Certificate Name

————————

SSX

Further on, create a context – I have called it test and a name for the radius session – I have called it ikev2, instruct the Stoke to do session authentication on radius, create a management interface on the same subnet as the radius machine, configure a radius server (where the Stoke should connect for session authentication) and, of course, the IKEv2 policies that make it work and the Configuration Payload (as we like to call the famous “mode-configuration” in IKEv2). The config should look like this:

stoke

(more…)

home therapy

Posted: January 26, 2010 in media-culture
Tags: ,

Because nothing is better than a good relaxing movie when you get home after 10 hours of IPsec and eGTP…monsieur spoils me everytime.

This time (yesterday) he overcame all my expectations:

http://www.imdb.com/title/tt0281358/

Who said guys are not romantic anymore? 😕

Recently I’ve had the opportunity of playing a bit with a CheckPoint UTM NGX R65 – ze mighty solution from the CheckPoint guys. Ignoring the obvious impediments (Romanian posts) I had when configuring the device from GUI, it left me a nice impression.

These guys are not quite the interop gurus ever, but they strive to implement the crankiest drafts that ever appeared from IETF. Running this on my own, the interop even with this device worked well, but trying to make it work with StrongswanI’ve got into big trouble.

Why? Well, let’s take a look at the most common IPsec – IKEv1 implementations. They usually pick one/more of the following standards:

– RFC 2407

– RFC 2408

– RFC 2409

– RFC 3706 – should you like DPD – Dead Peer Detection

– RFC 3947 and RFC 3948 for NAT-T

mode-cfg-02 draft – for the most common Mode-Configuration operations (perfectly inter-operable by Cisco, Juniper’s ScreenOS, Strongswan, Sonicwall, Stoke and Clavister) – as you may have guessed, NO, NOT with CheckPoint

draft-beaulieu-ike-xauth-02 – for xAuth authentication of clients – inter-operable on Cisco, NetScreen, Stoke and Sonicwall (not sure about Clavister – haven’t tried it yet) – and, yes, not on CheckPoint

As a nice old guy would say: “Security through obscurity” , not quite my favorite idea of _security_. Still, a good to follow idea for CheckPoint. Why? Because, even though they implement the RFC 2407, 2408 and 2409, they have decided not to implement the most common xAuth draft (presented above), feeling that symmetrical authentication is just too lame, so they have implemented draft-zegman-ike-hybrid-auth-01, which defines how to do uni-directional independent authentication on the remote-access scenarios – procedure enforced by the CheckPoint VPN Client (only, if you ask me, though I haven’t tried too many others).

Once you bypass this authentication procedure, configuring the UTM to authenticate the clients using X.509 certificates, you end up in yet another dead-end: the so-called Office-Mode, which is the CheckPoint way of saying “Mode-Configuration”, with a significant difference: the actual packet exchange is not standard. We have tried, me and my programmer fellows (by the way: thanks for enduring this by my side), to “reverse-engineer” this mighty exchange, but even with the CheckPoint debug and hacking into our friend pluto, we didn’t manage to get it right.

I have talked to a tech-support guy from CKP, a very nice person, still incapable of saying anything about their solution without first asking for permission from his PM/Management/whatever. So, up until today, I haven’t been able to pull this through. This is why the things I’m going to describe below are only ALMOST CheckPoint IPsec…

(more…)

What about those LTE bearers? What exactly is a bearer?

Well, if we are to believe the 3GPP guys (3GPP TS 23.401 version 8.6.0 Release 8), an EPS bearer is a data structure (that appears on the UE, MME, SGW and PGW), a way of uniquely identifying a traffic flow between the UE and the PGW. We need to _uniquely_ identify these flows because of the QoS we want to use for that UE traffic.

When are these bearers created?

First of all, there are at most 11 bearers that can be created for a specific UE. 11 bearers TOPS – per UE. Why is this so important?

Because:

1. the first time an UE connects to an anchor point (PGW) – procedure called Initial Attach, simply by allowing that UE access on the PGW – a new (default) bearer is created – and, yes, those 11 bearers tops decrease once this happens!!!

2. an UE can be “attached” to more than 1 anchor point (PGW) – which means, an UE can have more than 1 “default”/”initial” bearers (of course, created via multiple Initial Attach procedures) – which means those 11 bearers tops decrease again

Leaving us with the rest of the bearers, those NOT created “by default” at the Initial Attach procedure, those which we call dedicated bearers.

***Note: there are not necessarily 11 bearers up and running all the time. The “11” is just the max number that can be active at a certain moment.

How do I use the bearers for QoS?

Each bearer, once created, has assigned a certain TFT set. “TFT” stands for Traffic Flow Template, the set of all packet filters associated with that certain bearer (we’ll look later on soon at the wireshark capture to see exactly how these “bearer” and “tft” look like).

How do I use the TFT for QoS?

TFT, being a set of packet filters, resides as a database tuple in the PCRF – Policy Control and charging Rules Function, a separate cute device that tells the PGW how to route, where to route, and what QoS to use for traffic flowing to and from a certain UE.

! Moment of thinking 1:

HSS – Home Subscriber Server

PCRF – Policy Control and charging Rules Function

The HSS is a database that holds only information regarding the default bearer (which basically identifies the UE as belonging to this network), while the PCRF has the role of “traffic shaping”.

! Moment of thinking 2:

Although the default bearer is more or less automatically created when the UE attaches to this network, as a network confirmation that this UE belongs to it, the dedicated bearer is NEVER initiated by the MME/UE (even if it is, the PGW will gracefully ignore it 😛 ) – the dedicated bearer will ALWAYS be initiated by the PGW, in response to a certain traffic pattern matching a rule in PCRF, though triggering the creation a new and shiny TFT.

As I was telling you about in a previous post – my first eGTP test, the reply (first reply) to a CreateSessionRequest message is a CreateSessionResponse message, described below. This message contains:

1 2 3 4

 

5

– GTPversion 2, Message Type information, in this case, this is a Response, the length of the message, the sequence number (1) and the TEID (tunnel Endpoint Identifier) – which is copied from the CreateSessionRequest message

– the Cause field indicates this is a Response for an Accepted Request – in case there would be any error, the Cause Source field would indicate the cause of the error

– PDN Address Allocation (PAA) – field which is completed at this moment  (in the CreateSessionResponse) by the SGW with the IP address of the PDN – should you remember, in the CreateSessionRequest message, this field indicated the type of address (IPv4) and value 0.0.0.0; as per 3GPP TS 29.274 – this value is a fixed IPv4/IPv6 address as indicated by the HSS registers, or it leaves the value to 0.0.0.0 indicating that the PDN GW address is assigned dynamically

– F-TEID (Fully Qualified Tunnel Endpoint Identifier) – as mentioned also in the previous post, there are 2 F-TEIDs: one for the S11 interface, and another one for the S5/S8 interface, both source IP addresses of GTP-C:

— one for the S11 interface (the one between MME and SGW) – the SGW end – the IP of the SGW from the S11 interface

— one for the S5/S8 interface (the one between SGW and PGW) – the IP address of the APN server

– APN Restriction header – as per 3GPP TS 29.274, it “denotes the restriction on the combination of types of APN for the APN associated with this EPS bearer Context.” – haven’t  used it yet, so I cannot say too much about it

– Bearer Context – information I have neglected to describe in sufficient detail in the CreateSessionRequest description. Here, in the CreateSessionResponse message, the Bearer Context header has 6 sub-headers:

— EPS Bearer ID

— Charging ID

— F-TEIDs : here both of the identifiers contain the IP address of the SGW’s S11 interface – the source GTP-U interface

— Cause : here is Request Accepted, no Cause Source

— Bearer QoS, which contains the QCI label and some other QoS identifiers that shall be described – hopefully I’ll be able to see them at work till then

…because people don’t usually make the difference / know there _is_ a difference between these types of hats.

I am tired of listening to discussions and to be witness to people stating intrigued that “hackers are bad”, “hackers should be punished”, “hackers to stay in prison”…etc…etc…

Well, my dear friends, first of all, hacker are NOT bad. Actually, first of all, there is a distinction between bad people with strong computer/networking knowledge and good people with strong computer/networking knowledge. Some make this distinction by calling the former crackers and the later hackers, some others use the terms black hats for the former and white hats for the later. Please feel free to prove me wrong, I am neither a hacker,  nor a cracker, so maybe I’ve got them wrong. Still. Just being very good with computers doesn’t instantly turn you into America’s Most Wanted. And, yes, strong computer skills are not always gathered by reading a lot of stuff,  but mostly by doing and experimenting all that stuff.

You can get very good by practicing, not necessarily by breaking into a server, but nasty experience is still experience. I’m not saying we should praise people that break into servers, but people that do not actually do any harm should not stay in prison. Technology is neutral. There are people that use it for good purposes and that use it for bad purposes. There will _always_ be people with high technological skills, so, instead of pointing fingers at poor little Cristina who just encourages everybody to improve their computer skills, we should be more concerned on greater issues of our society, for example, _what_ exact factors determine a highly-trained computer professional to break into servers, the actual reason behind the cyber-crime.

Not all computer geeks are criminals, actually, most of them are not criminals, and stating that it’s WRONG to have high computer skills, all you will gain is a lot of good people refraining from getting computer knowledge, or a lot of good people deciding they should fight against this lack of freedom or a lot of good people turning bad >:) . You need good professionals to fight the crime against bad hackers.

My observation so far is that society, as always plays a major role. Some people are just good and are just using their knowledge to fight the good fight, while other are just bad. Blaming the technology and the eagerness to learn technology for all the cyber-crime and stating that it’s best for us to stick to a medium level of knowledge, because, for God’s sake, if we are too highly prepared we might just “become haackkeerss…” uuuu…that I find just oppressive and unfair to everybody.

looking through old memories

Posted: January 14, 2010 in technical
Tags: , , , ,

I’ve been searching for some old e-mails from a few years ago, trying to find a missing contact and bumped into this…

The initial instructions were something like this: ” so, it needs to call a person, play the wav and wait for dtmfs until the guy presses #.; afterwards play another wav and hang up”. I was young (and restless 😛 ), not sure I’ve covered the request completely, but I was doing this:

– picked-up good old asterisk server and abused its sip.conf extension:

[general]
context=tutorial
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; tutorial
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; my users 😛
[cristina]
type=friend
username=cristina
callerid=cristina
secret=buhuhu
host=dynamic
context=tutorial
mailbox=666@mb_tutorial

I say definitely to Summit. A very peculiar device, that amazed me instantly.

It is one of the products of Extreme Networks, don’t know how big of a company, but I got to love their solution. Even one of the smallest and lowest performance solution they have (Summit48si)  distinguished by its loads of features, performance, ease of configuration and, above all, STABILITY, something I haven’t found at the mighty Cisco solution that everybody loves.

A while back I needed to do something very specific: I wanted to separate traffic coming from two networks on trunks. My device should have reunited all this traffic and forward it to a different machine that would NAT it forward on to my servers. Each done by any device easily. But – what I wanted more was at the authentication level. I wanted to do 802.1x authentication on trunks and forward the authenticated traffic to a secondary device that would do EAPoverUDP for some of the traffic and WebAuth for the rest of the traffic, all based on the ACLs configured on a separate Radius (ACS) server. Now, I won’t get into details about the EoU, WebAuth, nor ACS configuration, but rather describe what I have managed to do with Summit.

First of all, unlike other devices, this one allows the premises of my topology: it lets me configure 802.1x on a trunk port – which I wasn’t able to obtain from Cisco after long hours of pain and swearing. So, traffic is coming from my supplicants, on 3 ports of this Summit device, let’s say 1,2 and 3. Ports 1 and 2 carry only 802.1x authenticated traffic, while port 3 is a combination of 802.1x, EoU and WebAuth. So, I have defined 4 vlans: 1,2,3 and 4. As part of my traffic is only authenticated with 802.1x, I left the first 2 ports authenticated in 802.1x on vlan 1, and assigned the next port (3) on all of the other 3 vlans: 2,3 and 4. This is this the access portion of the topology.

The second part, I have to switch all this traffic through another device, that deals with EoU and WebAuth, so I have defined 5 “exit” ports: 1 for the 802.1x authenticated traffic that wouldn’t need any other authentication (this traffic I trust to be secure only as part of the Summit authentication), 2 ports for the mixed-authentication traffic (this traffic I have authenticated via 802.1x in Summit, and I trust it), and 2 more ports for the traffic I want to further re-authenticate: 1 for the mixed traffic that has 802.1x and EoU and that I intend to authenticate via EoU and 1 port for the mixed 802.1x and WebAuth traffic that I intend to authenticate via WebAuth further on. The scenario would look something like this:

top

—where:

-‘vlan 1’ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via EoU here

– ‘vlan 2’ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via WebAuth here

Some of the traffic is only authenticated via EoU and WebAuth, so I have to let it pass through Summit without asking it for credentials.

From these 2 vlans, the traffic passes back into the internal network where the servers reside – this is of no further interest in this case. Still, I had to create 2 vlans, because of the default gateways that I need to assigned to my supplicants. One would be the layer 3 address of vlan 1 and the second would be the layer 3 address of vlan 2.

The cool part of this entire topology is how to fragment the traffic in Summit, in order to make sure that each type of authentication takes place where it is supposed to.

Of course, the ports belonging to vlans 1 and 2 are “access mode” untagged ports. Ports from 11 to 15 on the Summit device are also untagged ports, while ports 1 and 2 are untagged in a specific 802.1x vlan (let’s say 111), ports 3, 4 and 5 are double-tagged on a separate vlan (as they have mixed traffic that is to be authenticated on EoU and WebAuth separately further on, let’s say 117 for traffic that is to be forwarded to EoU authentication ports and 118 for traffic that is to be forwarded to WebAuth authentication ports) and untagged on vlan 113 – also an 802.1x enabled access vlan (as they also carry 802.1x information). Now, all this funky division is necessary for the netlogin information (as Summit calls the 802.1x authentication).

And the actual config looks like this:

# Config information for VLAN v111.
configure vlan “v111” tag 111
configure vlan “v111” protocol “ANY”
configure vlan “v111” qosprofile “QP1”
# No IP address is configured for VLAN v111.
configure vlan “v111” add port 1 untagged
configure vlan “v111” add port 2 untagged
configure vlan “v111” add port 11 untagged
# Config information for VLAN v113.
configure vlan “v113” tag 113
configure vlan “v113” add port 3 untagged
configure vlan “v113” add port 4 untagged
configure vlan “v113” add port 5 untagged
configure vlan “v113” add port 12 untagged
configure vlan “v113” add port 13 untagged
# Config information for VLAN v117.
configure vlan “v117” tag 117
configure vlan “v117” protocol “ANY”
configure vlan “v117” qosprofile “QP1”
# No IP address is configured for VLAN v117.
configure vlan “v117” add port 14 untagged
configure vlan “v117” add port 3 tagged
configure vlan “v117” add port 4 tagged
configure vlan “v117” add port 5 tagged
#
# Config information for VLAN v118.
configure vlan “v118” tag 118
configure vlan “v118” protocol “ANY”
configure vlan “v118” qosprofile “QP1”
# No IP address is configured for VLAN v118.
configure vlan “v118” add port 15 untagged
configure vlan “v118” add port 3 tagged
configure vlan “v118” add port 4 tagged
configure vlan “v118” add port 5 tagged
The netlogin command has been issued for ports 1,2,3,4,5, but only on vlans 111 and 113.
# Network Login Configuration
enable netlogin port 1 vlan v111
enable netlogin port 2 vlan v111
enable netlogin port 3 vlan v113
enable netlogin port 4 vlan v113
enable netlogin port 5 vlan v113
configure netlogin base-url “network-access.net”
configure netlogin redirect-page “http://www.extremenetworks.com”
disable netlogin Session-Refresh  3
enable netlogin logout-privilege
disable netlogin web-based
enable netlogin dot1x
The show netlogin command shows, at any moment, the status of the port (per un/tagged vlan), looking something like this:
> sh netlogin ports 1 vlan v111
Port: 1 Vlan: v111
Port State:     Not Authenticated
Temp IP:        Unknown
DHCP:           Not Enabled

MAC                IP address      Auth   Type      ReAuth-Timer User
——————————————————————
When in non-authenticated state. When actually authenticating a supplicant, the command displays the MAC address, IP (if the case), auth type and name of the user.
And, to actually be able to _authenticate_ users, I have to define  a Radius server where to connect:
# Radius configuration
#
enable radius
configure radius primary shared-secret encrypted “ABC”
configure radius timeout 30
configure radius primary server 1.2.3.4 1645 client-ip 1.2.3.5
configure radius primary server 1.2.3.5 timeout 30
disable radius-accounting
The “1.2.3.5” IP is the Summit IP address, that I have assigned on a separate vlan. Of course, ACS should have defined this IP as a client with a password of “ABC” – encrypted form and profiles for my users.
But about ACS in the next episode 😛

manual …keying

Posted: January 6, 2010 in technical
Tags: , , , , , ,

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 0x1000 enc “cbc(aes)”  0x12345678abcdef12f4f71dbccd2c1b07bce4e63b4c315414  auth “hmac(md5)” 0x012345abd9abcdeff1e0d3c2b5a4909a

ip xfrm state add src 2001:0::1 dst 2001:0::2 proto esp spi 0x2000 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 0x00001000 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 0x00002000 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!