to IPComp or not to IPComp and…which Vendor

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

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 🙂
Advertisements
Comments
  1. Andreas Steffen says:

    We recently fixed the ESP encapsulation of IPComp in the IKEv2 strongSwan daemon:

    http://wiki.strongswan.org/repositories/revision/strongswan/2b2c69e992d5e279ecde7d3ebf20804d59b8bf0d

    You can try the current release candidate:
    http://download.strongswan.org/strongswan-4.3.6rc1.tar.bz2

    Andreas

    • @Andreas: woooooww..Andreas Steffen on my blooggg WOOOOWWWWWW. Such on honor. WOOOW ^:)^ I will try the new fix. I know you were working on it, but..to actually have you sending me the link to the new fix here. Woow.

  2. vmp says:

    NetCocoon? You could have used Wireshark.

    As for decompressing IPcomp, https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4149

  3. Kai says:

    i have a very close setup as you have there, expect authby=rsasig.
    I’m using patched wireshark to capture my ping packets, but I can’t see IPcomp header followed after esp head in the trace, any hint?

    Thanks

  4. Kai says:

    i have a very close setup as you have there, expect authby=rsasig.
    I’m using patched wireshark to capture my ping packets, but I can’t see IPcomp header followed after esp head in the trace, am I miss something?

    Thanks

  5. Kai says:

    where is my comment?

    Thanks

  6. @Kai: hello, sorry for replying this late. I am at a customer site, so I have rare access to the Internet. Besides that, my “smart” Akismet plugin reported your comments as Spam 😐

    So, getting back to the topic: I don’t remember exactly the details, but I guess you should have a larger packet to make sure the compression kicks in – like I’ve said, I don’t remember the details 😦

    Buuut, you should also verify running the “ipsec status” command whether that particular SA has a “comp” in its description, like mine says:
    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

  7. Kai says:

    Hi cristina,

    Thanks for quick reply,

    you are absolutely right, I was sent 72 bytes ping packet, and its too small for ipcomp. After increased the ping packets size, ipcomp header appears!

    • @Kai: hey, glad you made it. Something else concerns me regarding your comments. They keep getting into the Spam folder. 😦 And I get A LOT of spam 😕 I’ll investigate.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s