Posts Tagged ‘ipsec’

inside the ESP

Posted: August 24, 2013 in technical
Tags: , , , ,

Let’s go somewhere where the bad guy should never go 😛

As I am listening to Blind Guardian, I have such a taste to write some more about my dear IPSec. As many of my other IPSec-related posts, this one either couldn’t have been possible without the help of my colleague and IPSec guru, vmp.

The entire purpose of the fancy IKE (IKEv1, IKEv2) negotiation is to establish a secure tunnel between the 2 IPsec peers, in order to protect the traffic between the sensitive entities, which are:

(more…)

Advertisements

— looking forward to playing with it 🙂

via Andreas Steffen

Hi,

we are proud to announce the first release candidate of our major new
strongSwan 5.x branch which is offering a single monolithic charon
daemon combining both IKEv1 and IKEv2 functionalities in a consistent
way. Since the old pluto daemon which goes far back to the FreeS/WAN
project will not be needed any more, all pluto code has been completely
removed. The strongSwan 4.x branch will now go into maintenance mode
but support will still be available.

For further details please refer to my blog entry:

http://www.strongswan.org/blog/2012/06/20/bye-bye-pluto.html

Please test the release candidate and report any bugs, IKEv1
interoperability problems with other vendors and missing features.
ETA for the stable 5.0.0 release is end of June 2012.

Best regards

Tobias Brunner, Martin Willi, Andreas Steffen

The strongSwan Team

======================================================================
Andreas Steffen                         andreas.steffen@strongswan.org
strongSwan – the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

One of the best IPsec devices I have worked with so far is Stoke. And when I am saying best I mean it in a sense of compliance, flexibility, stability and performance.

Although it has its minuses, like any device on earth, the pretty SSX-3000 solution I’ve got my hands on knew most of the Remote-Access scenarios I could think of and EAP authentication on top. Besides that, I could do my work undisturbed, while my colleagues were experimenting on their own. Why? Because of the contexts: each one of these “virtual” routers minds its own business, permitting me to play around with my stuff, while the others could work very well, without having to worry about Cristina’s ideas. Now, 240k IPsec tunnels in remote-access with EAP authentication versus Radius and support for digital certificates sounds pretty good if you were to ask me. Mwell…not good enough for the Stoke guys…it seems. So they came up with an even more interesting idea: LAN-to-LAN. Now..hmm..this powerful machine, able of doing so much on RA…could it also be doing site-to-site? So, I’ve contacted my favorite Japanese techie and asked for instructions.

This is the way it works:

Let’s assume there are 2 security gateways, Tokyo (10.1.1.2) and Bucharest (10.1.1.1). Tokyo gateway protects a network (5.1.1.0/24), while in Bucharest we have another network (6.1.1.0/24). Stoke has the concept of “tunnel-enabled interface”, which is a only /32 IP address of an interface type “tunnel”. The following services are not allowed on a tunnel-enabled interface: static IP hosts, ARP, and routing protocols.

So, in our case, let’s assume the tunnel interface for Tokyo is 9.9.9.1/32 and for Bucharest it is 9.9.9.2/32.

As everything on an SSX is done via a context, let’s assume that Tokyo has a context called TB1 and Bucharest has a context called BT1, on which they have this LAN-to-LAN configuration. The configuration on Tokyo would look something like this:

context TB1

interface Tokyo-LAN

arp arpa

ip address 5.1.1.0/24

exit

interface Tokyo-Bucharest

arp arpa

ip address 10.1.1.2/24

exit

interface Tokyo-Tunnel tunnel

ip address 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Tokyo-Bucharest-TUN type ipsec protcol ip44 context TB1

enable

ip local 10.1.1.2 remote 10.1.1.1

bind interface Tokyo-Tunnel TB1

ip route 6.1.1.0/24

ip route 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 1/1

bind interface Tokyo-LAN TB1

exit

enable

exit

port ethernet 1/0

bind interface Tokyo-Bucharest TB1

exit

service ipsec

enable

exit

While the Bucharest config should be like this:

context BT1

interface Bucharest-LAN

arp arpa

ip address 6.1.1.0/24

exit

interface Bucharest-Tokyo

arp arpa

ip address 10.1.1.1/24

exit

interface Bucharest-Tunnel tunnel

ip address 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Bucharest-Tokyo-TUN type ipsec protcol ip44 context BT1

enable

ip local 10.1.1.1 remote 10.1.1.2

bind interface Tokyo-Tunnel TB1

ip route 5.1.1.0/24

ip route 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 2/1

bind interface Bucharest-LAN BT1

exit

enable

exit

port ethernet 2/0

bind interface Bucharest-Tokyo BT1

exit

service ipsec

enable

exit

To verify the config, run:

Stoke [TB1]# sh ike-session list

—————————————————————————-

SLOT : 1
Session Handle : f4100214
IKE Version : 2 <LAN<->LAN>
Remote IP : 10.1.1.1
IKE-SA ID : 10.1.1.1
Session State : IPSEC-ESTABLISHED, IKE-SA DONE, CHILD-SA MATURE
——————————————————————————-
While
Stoke[TB1]#sh ike-session detail handle f4100214
displays a lot of details about this session, like ports, type of authentication, lifetime values and algorithms.

Stoke[local]#sh tun
Name CctHdl Type Admin State
—————————— ——– ———- ——- ———–
Tokyo-Bucharest-TUN ce000013 ipsec:ip44 enable up
Bucharest-Tokyo-TUN ce000014 ipsec:ip44 enable up
2 objects displayed.
Stoke[local]#sh tun name Tokyo-Bucharest-TUN
will display the details of this particular tunnel.
For the moment, afaik, this is only IPv4-over-IPv4, but I can’t hardly wait to have another e-mail from these guys saying that I can also play with mixed transport on one of their new StokeOSes. 😀

Invite to Technical…stuff

Posted: February 22, 2010 in technical
Tags: , , , , ,

I am inviting you to visit one of my favorite sites:

http://tech-invite.com/ — no longer valid

http://www.in2eps.com/3g0/tk-3gpp-netarch-108.html

The reason this is one of my favorite sites is that it is, firstly, VERY TECHNICAL 😛 of course. There are several sections where the articles are placed: Organizations, Standardization work, IETF topics, 3GPP topics, ETSI topics and…Other topics. I have to thank my VoIP guru colleague Alin for telling me about this site.

To be honest, I’ve never used any other categories, other than 3GPP and IETF topics. But these ones I have used extensively. Ranging from packet by packet IPsec negotiation, to SIP headers description, example, and a lot of scenarios, database infrastructure to UMTS and SAE architecture and scenarios, with a very welcome RFC and TS classification, I believe this site is one of the best locations where one could go to clarify technical things, to view scenarios and to take a look at packets and headers along with their analysis.

The latest link I’ve used is a secure SIP basic call from roaming, using the IMS architecture over UMTS. There are diagrams with each step of the flow, the packet dump and explanations for each packet. Gold, I say 🙂

So take a look.

Screen-shot-2010-02-22-at-10.56.00-PM1

It occurred to me today…how ’bout trying an IPcomp scenario? Of course, looking at RFC 3173, I was very excited about running a test and actually viewing Next Header / Protocol = 108, as the IETF guys say.

Basically, the “Compression” part of this IPsec traffic is negotiated just as  any other protocol: AH, ESP, EAP…via IKE, or manually configured on a device. Now…as I’ve got to devices….good question: _what_ device could I use if I want IPsec IPCompression?

Look at this: http://www.vpnc.org/vpnc-ipsec-features-chart.html. Scroll down to “Features (HTML table). The vendors that actually implement this, as per VPN Consortium (and for some of them I could tell you from direct experience), are CheckPoint, Cisco, McAfee, SafeNet, StoneSF and TeamF1. A bit disappointed that I didn’t have the opportunity of working on all of these devices, I am redirecting my attention to what I do have: a big, shiny and fluffy Debian, with Strongswan installed and xfrm module also on.

So, lets get down to business. I have taken the simplest scenario I could think of at the moment, a transport mode scenario, having as Initiator 192.168.0.10 and as Responder 192.168.0.1. These two hosts negotiate 3des-md5-dh2 algorithms, doing PSK authentication. No PFS, no other kinky stuff. Just basic IKEv2 negotiation. The Strongswan config is as simple as possible.

*Note 1 : on strongswan.org people say that IKEv2 does not support compression – I have run a test with IKEv2 and compression and it works very well 🙂 But, in order to humor the strongswan guys, I have used IKEv1 in the following scenario

*Note 2 : in order to actually _see_ the encapsulated packets, I have used ESP-NULL Encryption for data encapsulation. Yes, I could have used a NetCocoon analyzer, but that – in the next episode 😛

So: IKEv1, Transport mode, Main Mode, Null Encryption, ESP only, IP Comp:

config setup
plutostart=yes
charonstart=no
plutodebug=all
crlcheckinterval=180
strictcrlpolicy=no
# Add connections here.
conn %default
keyingtries=1
keyexchange=ikev1
authby=secret
mobike=no
pfs=no
type=transport
compress=yes
auto=start
ike=3des-md5-modp1024
esp=null-md5
leftfirewall=yes
rekey=yes
conn network1
left=192.168.0.1
right=192.168.0.10
# ipsec status
000 “network1”: 192.168.0.1[192.168.0.1]…192.168.0.10[192.168.0.10]; erouted; eroute owner: #3
000 “network1”:   newest ISAKMP SA: #2; newest IPsec SA: #3;
000
000 #3: “network1” STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2488s; newest IPSEC; eroute owner
000 #3: “network1” esp.525b0b48@192.168.0.10 (0 bytes) esp.5511d8c2@192.168.0.1 (0 bytes) comp.1169@192.168.0.10 comp.527e@192.168.0.1; transport
000 #2: “network1” STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2488s; newest ISAKMP
000

Yes, it worked.

Now…I am not sure what exact compression algorithms this Strongswan daemon has, but I can tell you for sure it uses at least DEFLATE(  RFC 2394 ). Ciscoon the other hand, uses only LZS (RFC 2395 ) – as far as I have seen – to be updated if anybody else tested it versus DEFLATE.
The process of actually obtaining this cute ESP packets is the following:
a. get the Data from the upper layers of the TCP stack – doh, we need data
b. compress the Data above using the chosen algorithm – you will notice the CPI – Compression Parameter Index – which has well know identifiers for the well known compression algorithms
c. set the Next Header value of the IPComp header to the layer 4 protocol (in this case, TCP)
d. encapsulate everything in ESP, put on the corresponding SPI, set the Next Header value of the ESP header to 108 (0x6c)
e. wrap it up in IP and… we are all set

— You can admire the ESP of IKEv1 in the screenshot attached
ipcomp

Now, what happens differently with IKEv2? I was telling you before the on Strongswan, IKEv2 and AH is a no-no for the moment, ESP with null encryption does a weird thinggie that vmp was so kind to point it out for me (while I was feeling actually quite happy about myself being able to do an IPComp test via IKEv1).
The thing is that, unlike the (correct) way of doing IPComp in IKEv1 (see the aboe a. to e. steps), IKEv2 implementation of Strongswan does a weird thing:
a. get the Data ..blah-blah
b. compress the Data with whatever compression algorithm and put on the IPComp header with CPI value and all
* c. put on another IP header (the internal one, in case of a tunnel mode scenario)
d. put on the ESP header
e. wrap everything up

— Unfortunately, you CANNOT admire the ESP of IKEV2 in a screenshot, because my current wireshark has no idea on how to do decompression of this type of packet. Once it does, I will update 🙂

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…)

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!