The freeswan-snap1998May28 is still broken, other problems too

  In testing todays FreeS/WAN snapshot (freeswan-snap1998May28) I find that the denial of service attack/bug I found yesterday is still there. just as bad as before.
  I will describe how this bug works in more detail and point out some some other minor problems that I found along the way.   In the not so good department I just noticed that even if I reboot both SG's there is no communication between them (one is 0.8 and the other is the current snapshot). Yet more fun.

  First here is now the denial of service attack/bug works. Set up a the 'standard' test setup of two SG's and a ping machine behind each. Set things up and then run 'ping -s other_client' for a while to run up the replay counters.
  Then reboot the SG you want to see crash and start up the ping from the far ping host, add "-s 4096" to make it go quicker (this eats up memory very fast!).

  Next I was going to make a run with debugging turned on, but debbugging control is broken currently as you can see:

root@west > klipsdebug --version
klipsdebug, $Id: klipsdebug.c,v 1.4 1998/05/27 18:48:21 rgb Exp $ root@west >
root@west > klipsdebug --help
usage: klipsdebug {set|unset} {all|tunnel|netlink|xform|eroute|spi|radij|esp|ah} root@west > klipsdebug set all
write: Invalid argument
root@west >

  Next it seems that we are missing data in the various /proc/net/ipsec_* files that was there before. I understand that IV's and Keys etc. need to be kept private, but still something is missing.

• New output ------------------------------------------------- root@west > cat /proc/net/ipsec_* EROUTE:
  (209.157.90.160/255.255.255.248 -> 209.157.90.152/255.255.255.248) =>
  (209.157.90.145, 0x110)

SPI:
(209.157.90.145, 0x110, IPv4 Simple Encapsulation: [209.157.90.146 -> 209.157.90.145])

SPIGRP:
(209.157.90.145, 0x110, IPv4 Simple Encapsulation)

TNCFG:
ipsec0 -> eth0
ipsec1 ->

• Old output ------------------------------------------------- # cat /proc/net/ipsec-eroute
  (209.157.90.152/255.255.255.248 -> 209.157.90.160/255.255.255.248) => (209.157.9
  0.146, 0x00000115)

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

# cat /proc/net/ipsec-spi
(209.157.90.146, 00000115, 1: [209.157.90.145 -> 209.157.90.146])
t = 00000000, win = 0 flags = 0 <RESPONDER>)
(209.157.90.145, 00000111, 10: iv = 00 00 00 00 00 00 00 00 seq = 0x00045d03, bi
t = 00000001, win = 0 flags = 0 <RESPONDER>)

  Ah, looking at the output of the scripts that set up the hand keyd link I see why the new output looks skimpy:

+ /usr/local/sbin/spi 209.157.90.145 111 esp 3des-md5-96 i <key...> usage error in f_blkrply
Usage: spi <dstaddr> <spi>
...

+ /usr/local/sbin/spi 209.157.90.146 113 esp 3des-md5-96 i <key...> usage error in f_blkrply
Usage: spi <dstaddr> <spi>

  So this util has changed in some way that breaks it, or the --help doc and CHANGES files faild to change to reflect the code.

  Well I think that is enough churn for one email message. It is clear that there are interesting attacks and bugs in this system yet! Well I should get back to something useful... Enjoy.

		||ugh Daniel
		hugh@toad.com
			Systems Testing & Project mis-Management
			The Linux FreeS/WAN Project
			
http://www.xs4all.nl/~freeswan