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:

# 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 ). Cisco on 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 (0×6c)

e. wrap it up in IP and… we are all set

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

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

De ce? Pentru ca e super simandicos si pretentios si sclifosit si vrea sa aiba mereu procentajul ideal de grasime versus muschi/oase…si ce-o mai fi in corp. De-aia era mereu nemultumit de mancarea pe care o gaseam primprejur si s-a gandit sa rezolve el problema.

Azi am comandat mai multi de la Smart Food si am fost foooarte multumiti. Preturile sunt cam ca peste tot, dar mancarea e fff buna, te saturi, da’ nu simti ca dai pe-afara, nu e grasa si e gatita ca sa isi pastreze componentele hranitoare. Conceptul Smart Food este enuntat de Alex pe pagina de  …Concept

Smartfood s-a nascut din dorinta de a oferi clientilor un gust aparte si un mod sanatos de preparare a produselor, fara aditivi, fara conservanti si fara compromisuri. Conceptul s-a nascut dupa o experienta personala materializata in cautarea unui echilibru alimentar, incercarea de a ajunge la o greutate ideala, completate de sport. Dupa cativa ani de studiu, 20 de kg mai putin si multiple incercari am ajuns la o formula ce ofera deopotriva mancare gustoasa si sanatoasa….

Alaturi de mancarea etichetata frumos sa nu ne incurcam intre noi am primit si sloganuri speciale, ale mele sunt asa:

Supa crema de ciuperci – IKEv2 si niste terci

Pui balsamic – ai grija la degete

Pentru maine am comandat:

supa de broccoli cu branza de capra
somon aglio olio

Abia astept sa vina!!!

Meniul e la adresa :

http://smartfood.ro/meniu.html

— from a friend, now studying Cybernetics in Bonn

“you have the attention of a dirac distribution”…

So, last year, a few months ago, he decided to solve this problem and opened Smart Food. Today I’ve ordered Mushroom soup and Balsamic chicken with vegetables. I am simply HAPPY, I’ve eaten all the food, very fast, I just couldn’t help myself . Some other colleagues ordered two other types of soups and fish, I have tasted all, of course. My opinion: WONDERFUL.

Finally, good quality food, what Alex and his team had in mind all the time. The Smart Food concept is the following: “Smartfood was born out of the wish to offer our customers a special taste and a healthy way of preparing our products: no additives, no preservatives and no compromises”…read the rest on the Smart Food site.

Alex practiced sports when he was in highschool and gained a lot of weight in the past few years. Over more than a year, he actually eats everyday the type of food he sells to us. When I met him at a coffee shop 2 months ago I simply didn’t recognized him: very very fit, looking much younger and simply gorgeous. I have decided to go to the gym at least 3-4 times a week (for the past month I have went almost 5 days every week) – following his advice and be more careful about what I eat and when I eat. The Smart Food products are very nourishing, but have a big advantage: they help me stay in shape and…boy, I looove shapes…I’m gonna go to the gym and run again at least 6km…as in the past couple of weeks – talk to you later

Click here to view the embedded video.

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ò!

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:

— 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:

context test

aaa profile

user authentication local

session authentication radius

service authorization local

exit

session name ikev2

ip address pool

password encrypted 3A0C060A

exit

radius strip-domain

radius session authentication profile

timeout 60

retry 3

max-outstanding 127

server 10.205.17.172 port 1812 key ipsec

exit

ip pool 40.0.0.2 1024

interface Mngmt management

arp arpa

ip source-address context-default

ip address 10.205.17.238/24

exit

interface session1 session loopback

ip session-default

ip address 40.0.0.1/32

exit

interface Untrust_1

arp arpa

ip address 200.0.0.1/24

exit

interface Trust_1

arp arpa

ip address 201.0.0.1/24

exit

ip route 50.0.0.0/16 200.0.0.2

ip route 70.0.0.0/16 201.0.0.2

ipsec policy ikev2 phase1 name RAv2

custom

gw-authentication certificate name SSX password encrypted 3A0C060A

peer-authentication eap

hard-lifetime 3600 secs

encryption triple-des

hash md5

d-h group2

prf md5

exit

exit

ipsec policy ikev2 phase2 name RAv2

any

exit

exit

port ethernet 0/0

bind interface Mngmt test

exit

enable

exit

port ethernet 1/0

bind interface Untrust_1 test

ipsec policy ikev2 phase1 name RAv2

ipsec policy ikev2 phase2 name RAv2

exit

service ipsec

enable

exit

port ethernet 1/2

bind interface Trust_1 test

exit

enable

exit

DEFAULT Auth-Type := EAP, Cleartext-Password := “md5″

Service-Type = Framed-User,

Framed-IP-Address = 255.255.255.254,

As I am a nutcase sometimes, this time I wanted to run with full Stoke power, which is 240K IPsec sessions, this is why I didn’t want to be concerned with the Radius authentication, and this is why I have this DEFAULT entry in my users file

- in the proxy.conf file I have:

realm NULL {

authhost        = LOCAL

}

*** GIVEN SITUATION:  StokeOS uses the notion of contexts in order to identify virtual separate router configurations. Basically, this machine has 4 slots, each with 4 ports on. I can define simultaneously a large (I don’t know _how_ large) number of configurations that reside in parallel on the machine. In order to apply one of them (or more) on the actual physical ports, I assign a port to a specific context (as you can see above in the config). It’s like… I have my any number of router configurations running and I apply on the actual ports either one I want, or more routers, on more ports, keeping in mind the rule: one port can only belong to one router – fair enough, I’d say

*** PROBLEM: In the Remote-Access scenarios, more exactly, at the user authentication on the machine, StokeOS identifies the users by matching them against a given context, so that, even if a user defined on context X arrives on a port belonging to context Y, the authentication fails. The problem this thing imposes when doing EAP versus Radius is that the StokeOS strips the context name, so:

- I have a user called roadwarrior1 in context test. The string this client should send to Stoke is roadwarrior1@test, otherwise Stoke fails to authenticate it

- Once Stoke authenticates the user, it forwards the username (roadwarrior1), to the Radius server, so that in radius this user arrives with realm NULL

- The problem appears when doing the actual radius authentication, because radius gives an error:

Identity does not match User-Name, setting from EAP Identity

I have looked around the Internet, but found none actual solution to this.

So, I have called a friend again – a friend of mine, _and_ a friend of C and we hacked into

freeradius-server-2.1.6/src/modules/rlm_eap/eap.c

file replacing:

vp = pairfind(request->packet->vps, PW_USER_NAME);

with:

vp = NULL;

everywhere (2 places) and recompiled the EAP so (thanks, vmp )

Now everything is fine, I have 240K IPsec roadwarriors happily authenticated via EAP on Stoke’s SSX-3000.

Me Happy

***CLARIFICATIONS:

As far as I know (and with lots of help from vmp ), there are 3 documents that “deal” with IKEv2-EAP authentication thinggie:

a. RFC 4306 - 3.16. Extensible Authentication Protocol (EAP) Payload – which treats EAP as an IKEv2 extension that appears in the IKE_AUTH packets (the first IKE_AUTH packet, coming from the IKEv2 Initiator actually contains no Authentication Payload, then the IKE_AUTH reply from the IKEv2 Responder contains the Responder’s digital certificate and an EAP-Identity Request method) —or some varying interpretations..

b. http://tools.ietf.org/html/draft-eronen-ipsec-ikev2-eap-auth-07 - which identifies basically an EAP-IKEv2 method, meaning that IKEv2 is a method of EAP’s, and, as far as vmp could explain to me the EAP in this case deals with the Authentication and IKEv2 does the negotiation “inside” EAP

c. RFC 4739 - Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol – which should be some twisted multiple authentication, one EAP authentication after another – vmp stopped explaining at this point and I didn’t have enough time to dig through that

This time (yesterday) he overcame all my expectations:

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

Who said guys are not romantic anymore?

These guys are not quite the interop gurus ever, but they’ve strived to implement the crankiest drafts that ever appeared from IETF. Running this on the company I work for, interop even with this device worked well (so buy Ixia products if  you want IPsec testing ), but trying to make it work with Strongswan I’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…

So, once you have installed NGX R65 (of course, I only  had a trial version), define a main interface, generate a self-signed certificate for the UTM, and allow GUI clients to administer the device via SmartDashboard:

1. Open SmartDashboard > Network Objects > CheckPoint > double-click the name you gave to the current UTM (mine is CKP-R65) > General Properties > check the VPN box under “Check Point Products”

still on CKP-R65- > under Topology tab, Edit the networks there as to identify as “This network” the main IP address, the one you bound to the RSA, and put the secondary one (of course, you’ve defined a secondary one) as “External”

still on CKP-R65- > under VPN tab, Add “Remote Access” to the upper Area, stating that “This module participates in the following VPN Communities”

still on CKP-R65- > under Remote Access > under Office Mode I have checked the “Do not offer Office Mode” option

Hit OK, then go to Menu > Policy > Install Database… and install it on the UTM.

2. In the main Dashboard window > Network Objects > right-click on Networks > Create new network, give it a name and then configure it. This shall be the Remote-Access pool for Office Mode (which we won’t do, cuz we don’t get till there with pluto)

3. In the main Dashboard window > (fifth tab) Users > right-click Users Group, create a new group, then right-click on Users and create a new user, assigning it to the previously created Remote-Access group

4. Now would be a good moment to save everything on the UTM > Install Policies.

5 – version 1. What I’ve done next is to create a new (external) CA (which is a 2003 Server CA I had at hand), enroll the CheckPoint to this CA and try to create a user certificate for my CheckPoint user. I thought of exporting this user certificate on my Strongswan and authenticate it to the gateway. Unfortunately, I’ve seen no way of indicating to which CA the user certificate gets enrolled – the user certificate I have created from the user page always got enrolled to the CheckPoint’s self-signed CA – not exactly what I had in mind

5 – version 2. I have done some more reading on the Internet, and found a procedure of actually exporting the CheckPoint’s self-signed cert from the UTM, to a p12 file. God-like! I have exported the CKP-R65’s certificate, then put it under the …/ipsec.d/cacerts directory on debian. This way, it seems that strongswan passes the authentication stage – still not hybrid, but still authentication

[Show as slideshow]

My Strongswan machine has an IP address (20.0.0.2) and tries to do Remote-Access to the CheckPoint. The Strongswan config looks like this:

having ipsec.secrets:

: RSA /usr/local/etc/ipsec.d/private/user1_key.pem “password”

Now, the solution may seem simple, BUUUT:

a. CheckPoint does not want to use its DNS name as Identification Payload for IKEv1 for the Remote-Access scenarios

b. Also, the certificate cannot be generated for external networks, so there has to be 10.205.17.251.

c. ALSO, although not recommended for security purposes, even if I configure Strongswan to identify the DUT per its 10.205.17.251 IP address, still I get the INVALID_KEY_INFORMATION error.

*** Now, should any one of you nice readers have solved this scenario and actually get a CheckPoint device to work with another solution (not necessarily open-source), please have mercy on my poor soul and let me know

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.

[Show as slideshow]

- 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 GW – 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