Date: Thu, 10 Oct 2002 05:15:05 -0400 (EDT)
 From: Sam Sgro 
 To: briefs@lists.freeswan.org
 Subject: [Briefs] OE on the Zaurus; FreeS/WAN on RH 8.0; Routing Protocols and
     IPSec
 
 
 
 
 lists.freeswan.org              Email summary for Wednesday, October 9th, 2002
 ==============================================================================
 by Sam Sgro                                                   sam@freeswan.org
 
 
 This issue, we have reports of FreeS/WAN running on the Sharp Zaurus (item 1)
 and having a few small issues with RedHat 8.0 (item 2). Claudia Schmeing has
 posted a new revision of our interoperation document (item 3). Item 4 has a
 great discussion on the use of routing protocols with FreeS/WAN.
 
 
 This Week in Brief...
 
 
 1.  OE and IPSec on the Zaurus
 2.  FreeS/WAN on RH 8.0
 3.  Interop Document Revised
 4.  Routing Protocols and IPSec tunnels
 
 
 
 1.  OE and IPSec on the Zaurus
     ==========================
     1 post, Oct 9
     http://lists.freeswan.org/pipermail/design/2002-October/003709.html
 
 
 Jens Liebchen has recently posted his work to port FreeS/WAN to the Sharp
 Zaurus handheld. Using Jens' modules and tips, Hugh Daniel reported success
 with OE:
 
     I feel this is a major breakthrough and so I am going to speak up!
     I just got Opportunistic Encryption (OE) working on a Sharp Zaurus!
     Now where ever my Z is it can Opportunistically initiate IPsec to any
     OE/DNS enable host on the net!
 
     Security & Privacy on the move!
 and
     Some preliminarily rough timing numbers, but real world (real Zaurus,
     access a public server (running OE) in Europe over nothing slower then
     a T1):
 
 	DNS/IPsec/HTTP setup time:	3 seconds
 	Peek file transmission rate:	72.25 KB/s @ 75% CPU usage
 
     The above numbers are VERY suspect, it's running over 802.11b and
     performance measurement tools I have are crude (top) etc.  Still my
     average test transfer file did about 30 kibibytes/sec on the Zaurus
     where my 1.2 gigahz laptop got the same.
 
     Roughly these numbers are about half the performance of a 150 MHz
     586 test box, but it had hand crafted assembly crypto code.
 
 HD had a few recommendations on how to improve FreeS/WAN's usability on the
 Zaurus:
 
     Fourth, it would be good to get the two things that FreeS/WAN
     critically needs, awk and libgmp included in the next retail flash
     load.
 
     Fifth, if this is going to end up a tool that the average Zaurus
     buyer on the street uses it needs a bit of interface with the human on
     the box.
 
 Any Zaurus GUI programmers out there who want to make a contribution?
 
 You can download Jen's code here:
 
 http://www.liebchen-online.de/vpn-zaurus_en.html
 
 Additional libraries for the Zaurus can be found here:
 
 http://www.killefiz.de/zaurus/
 
 
 
 2.  FreeS/WAN on RH 8.0
     ===================
     7 posts, Oct 2-6
     http://lists.freeswan.org/pipermail/users/2002-October/014937.html
     http://lists.freeswan.org/pipermail/design/2002-October/003681.html
 
 
 With the recent release of "Psyche", our developers and users have reported
 some issues with FreeS/WAN on RedHat 8.0, mostly resulting from this release
 being the first to use gcc 3.x. RedHat originally brought on to our notice:
 
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72212
 
 The problem lies in the DES library we use; specifically, the issue originates
 with a perl script which produces gcc2-like output, and defines
 "gcc2_compiled" in the resulting .s file. This results in the problem Ian
 Brown reported when building 1.98b:
 
     Recently loaded redhat 8 and tried to recompile the ipsec.o module like
     I've done prevously with redhat 7.3 but ran into an odd error:
 
     ipsec_setup: /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o: The module
     you are trying to load (/lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o)
     is compiled with a gcc version 2 compiler, while the kernel you are
     running is compiled with a gcc version 3 compiler. This is known to not work.
 
     the only version of gcc that I have is the version that redhat 8 loaded...
     rpm -qa| grep "gcc" shows:
     gcc-g77-3.2-7
     gcc-c++-3.2-7
     libgcc-3.2-7
     gcc-3.2-7
 
 Tom Hughes posted a simple patch to FreeS/WAN 1.98b, which removes this
 one line flag from the assembler code of libdes. The resulting code runs
 without complaint.
 
 The developers are still considering their options as to a permanent fix.
 
 Additionally, D. Hugh Redelmeier has been addressing some of the minor code
 changes necessary for warning-free compilation of our development branch using
 gcc 3.2. The next full release, FreeS/WAN 2.00, will have no trouble with
 RedHat 8.0.
 
 
 
 3.  Interop Document Revised
     ========================
     1 post, Oct 8
     http://lists.freeswan.org/pipermail/users/2002-October/015085.html
 
 
 Claudia Schmeing has submitted a new version of our interop document
 for public review:
 
     I am rewriting the freeswan.org interop document. The main feature
     is a clickable chart showing whether different IPsec implementations
     are compatible with FreeS/WAN using PSK, X.509, etc.
 
     When you click on a name, ie. "SafeNet" it will bring you to a list
     of HOWTOs, with a brief description of what each contains...
 
     Here's where you come in, gentle reader: Know any HOWTOs I've missed?
     Any particularly informative mailing list posts I could index?
     Have any information to fill in the blank spots in the chart?
 
 Your practical experience can help other users make FreeS/WAN work for them;
 take a look at the document to see if you can help.
 You can check out the latest revision here:
 
 http://www.freeswan.ca/code/old/freeswan-Snapshot/doc/interop.html
 
 
 
 4.  Routing Protocols and IPSec tunnels
     ===================================
     15 posts, Oct 8-9
     http://lists.freeswan.org/pipermail/users/2002-October/015069.html
 
 
 Subnet-to-subnet IPSec tunnels are easy enough to deploy using FreeS/WAN.
 However, that solution doesn't always solve the problems arising from larger,
 more complex networking environments. When machines that need to communicate
 across your office network are distanced by several intra-company hops and an
 IPSec tunnel, not only do your routers need to comprehend their own local
 network routes, it becomes necessary for them to acquire the routing info for
 accessible remote networks as well.
 
 Routing protocols provide the best solution to this problem. One option is to
 broadcast routes across the IPSec connection itself. Alternatively, by
 extending the standard _updown script, the FreeS/WAN machinery can communicate
 the routes it is aware of beyond its own routing table.
 
 Joe Patterson outlined some of the networking hurdles that need to be
 overcome to run some of the standard routing protocols over IPSec tunnels:
 
     First, with the notable exception of bgp, most routing protocols use
     broadcast or multicast to communicate with their neighbors.  Ipsec
     interfaces are unicast only.
 
     Second, ipsec configurations specify a security policy, which can translate
     to a routing policy.  Unless your routing protocol is capable of
     transmitting policy information (and none of them are), then you will end
     up with a route going through an interface that will reject the packets
     because of their source, even though their destination is theoretically
     reachable.
 
     The solution to this is to run ipsec in transport mode (although this is not
     necessary, tunnel mode will also work) and run some other encapsulation
     protocol (my favorite is GRE) over top of it.  Then run your routing
     protocol over the encapsulated protocol.  The virtual interface created by
     the encapsulation protocol will be point-to-point, but multicast-capable.
     It will also have no implicit routing policy.
 
 Paul Krumviede advised:
 
     agreed. one thing to be careful of here is which interfaces the
     routing protocol should ignore..
 
 JP replied:
 
     I would say, generally avoid running a routing process on ipsec*.  Also make
     sure that you've got a static host route to your gre peer, or else you're
     likely to start running into recursive tunneling issues, but that's a
     general gre thing and not specific to ipsec or any particular routing
     protocol.
 
 Ken Bantoft made a few comments on how he uses zebra/ospfd to redistribute
 his IPSec routes:
 
     what I've done in the past is redistribute all of the kernel
     routes added by klips into my internal network via ospf.  Since I had 2
     IPSec gateways, both injecting the routes, the internal routers would pick
     the gateway with the lowest metric and ship the packets that way.  Thus
     the current limitations of FreeS/WAN (ie: you can't have two conn's to the
     same destination network with the same source network) can be overcome by
     using 2 boxes.  Overkill, but sometimes redundancy is nice.
 
 Ken is also in the process of producing some HOWTOs on these subjects:
 
     the HA FreeS/WAN (FreeS/WAN + Heartbeat + Zebra/ospfd) is under peer
     review at the moment.  The +GRE+bgpd I haven't started yet, but will soon.
 
 Thanks to everyone who participated in this thread.
 
 
 ==============================================================================
 lists.freeswan.org Email summary                  Wednesday, October 9th, 2002