FreeS/WAN Weekly Summary: IPsec on the Zaurus and more

    Date10 Oct 2002
    CategoryCryptography
    3500
    Posted ByAnthony Pell
    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 issue, we have reports of FreeS/WAN running on the Sharp Zaurus (item 1) and having a few small issues with Red Hat 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.
     Date: Thu, 10 Oct 2002 05:15:05 -0400 (EDT) From: Sam Sgro  To: This email address is being protected from spambots. You need JavaScript enabled to view it. 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 This email address is being protected from spambots. You need JavaScript enabled to view it. This issue, we have reports of FreeS/WAN running on the Sharp Zaurus (item 1) and having a few small issues with Red Hat 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 Red Hat 8.0, mostly resulting from this release being the first to use gcc 3.x. Red Hat originally brought on to our notice: https://bugzilla.Red Hat.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 Red Hat 8 and tried to recompile the ipsec.o module like I've done prevously with Red Hat 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 Red Hat 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 Red Hat 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  
    You are not authorised to post comments.

    LinuxSecurity Poll

    Has your email account ever been pwned in a data breach?

    No answer selected. Please try again.
    Please select either existing option or enter your own, however not both.
    Please select minimum 0 answer(s) and maximum 2 answer(s).
    /component/communitypolls/?task=poll.vote
    12
    radio
    [{"id":"53","title":"Yes","votes":"5","type":"x","order":"1","pct":83.33,"resources":[]},{"id":"54","title":"No","votes":"1","type":"x","order":"2","pct":16.67,"resources":[]}]["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"]["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"]350
    bottom200

    We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.