FreeS/WAN 2.05; IPsec over Satellite; Certicom Patent Attempt

-----BEGIN PGP SIGNED MESSAGE-----



lists.freeswan.org Email Summary for Wednesday, February 11, 2004
===============================================================================
by Claudia Schmeing                                        [email protected]



This week saw FreeS/WAN 2.05, our first release with Authentication
Header removed. More in Item 1. We also talked about using IPsec over a 
satellite link (Item 2), and more. In our last item, we look back to last 
November and over to another list, for an interesting discussion 
about intellectual property rights and the IETF.

Enjoy.



In Brief....

1.  FreeS/WAN 2.05 released
2.  IPsec via Satellite       
3.  Compiling on Slackware
4.  Detecting Memory Leaks
5.  Certicom Patent Attempt

 ------------------------------------------------------------------------------

1.  FreeS/WAN 2.05 released
    =======================
    1 post Feb 9
    http://lists.freeswan.org/archives/users/2004-February/msg00384.html


In keeping with our goal of creating a lightweight, secure OE (opportunisitic
encryption) implementation, the FreeS/WAN team presents 2.05, our first
release with AH (Authentication Header) removed. The release also features 
assorted bug fixes, and our still experimental lwdnsq (lightweight DNS queue)
resolver, now DNSsec capable. For more detail, see
http://lists.freeswan.org/archives/users/2004-February/msg00384.html



2.  IPsec via Satellite
    ===================
    4 posts Jan 28 - 29
    http://lists.freeswan.org/pipermail/users/2004-January/msg01183.html


Ever thought of using FreeS/WAN over a satellite link? It might be more tricky
than you'd hope. In theory, as Paul Wouters explained, FreeS/WAN encrypts and 
authenticates any IP packets, regardless of how these arrive at the computer:

    Wether the ESP packet comes from Outter Space, or Copper Phone, [FreeS/WAN]
    will just do the crypto and either accepr or disgard the packet.

However, Paul reported this "gotcha" specific to one-way satellite links:

    lots of Satellite people are doing heavy duty NATing, and there might
    be a catch with NAT's and asymmetrical links, eg the nat-traversal might 
    fail here.

Also, depending on your provider, there may be other filtering on the link.
Justin Kreger had this to say:

    I know starband (everything was carried over satellite) filtered esp 
    packets [e.g., IPsec traffic] out though.  This was three or so years ago 
    when radioshack was selling starband.  They may not be now. We never had 
    any problems with ike, but we would never see any esp packets come down 
    the downlink.

An older post from Gerhard Gessler shows that, with some help from other
technology, you can successfully run FreeS/WAN over a one-way or two-way
satellite link. On Oct. 21, 2003 Gerhard wrote:

    it is possible to integrate... ...Protocol Enhancing Proxies (e.g.
    the one from Mentat) in a network scenario where e.g. a central head 
    office is connected to several branch offices using a satellite uplink 
    and terestrial return link via Internet with IPsec encryption done with 
    FreeSWAN. Using two satellite links for up- and downlink is also possible.
    2 colleagues of mine and I have setup such a scenario for ESA (European 
    Space Agency) together with lots of applications, servers and also done 
    performance measurements.

    (http://lists.freeswan.org/pipermail/users/2003-October/msg00235.html)

The final thought I'll leave to Paul, who advised:

    But again, unless this pays per hour, don't do it.



3.  Compiling on Slackware
    ======================
    4 posts Feb 5   
    http://lists.freeswan.org/pipermail/users/2004-February/msg00188.html


When compiling FreeS/WAN on some Slackware releases, you may need to suppress
a C flag (-Wpointer-arith). Dragos "Birkoff" Dionisie was compiling FreeS/WAN
2.04 on a Slackware 7.1 (glibc 2.2.2, gcc 2.95.3) when he ran into a number
of errors of the form, "spi.c:767: warning: pointer of type `void *' used in 
arithmetic". He had not seen this problem with FreeS/WAN 1.96, nor on 
a more recent Slackware (9.1). User support person Sam Sgro answered:

    2.x series FreeS/WAN is a bit more picky when it comes to warnings/errors, 
    and Slackware can get bit by this (but not more recent Slackware releases,
    apparently).

For more explanation, Sam pointed at an older post from D. Hugh Redelmeier 
explaining the nuts and bolts behind the issue. Redelmeier wrote:

    The -Werror [used in a standard FreeS/WAN compile] asks for warnings to 
    be treated as errors.  We like to do this to keep us clean and honest.

    Unfortunately, the header files on your system violate the ISO
    standard for the C language.  Since this isn't true of our systems, we
    don't have this problem.  In ISO C, arithmetic with a void * is
    undefined.  Silly GNU folks decided that they knew better than the
    standard (when Microsoft does this, we call them "evil", not "silly").
    You could avoid this problem by upgrading to a conformant set of
    headers.  Or you could find where CFLAGS is set and remove -Werror.
    Or you could instead remove -Wpointer-arith.



4.  Detecting Memory Leaks
    ======================
    15 posts Feb 5 - 10
    http://lists.freeswan.org/pipermail/users/2004-February/msg00185.html


Memory leaks are a type of error that occur when a program writes to memory 
outside its allotted space. They're little fun at the best of times, and
particularly undesirable in security software. FreeS/WAN 2.00 prereleases had 
bugs of this type, as David Santinoli may recently have experienced. His 
description:

    The problem is that every 54-55 days some oddities begin to show up in 
    the logs, and the gateways go crazy.  I have to stop IPsec and start it 
    again - then I'm fine for another 55 days.

The error had the form "ERROR: pfkey write()...", where PFKEY is the mechanism
by which the kernel and userspace portions of FreeS/WAN communicate.
Sam Sgro remarked David may have triggered old memory allocation bugs in the
KLIPS SA (Security Association) database, which were discovered and fixed in 
the 2.00 prereleases, and advised him to upgrade.

James F. Carter commented that this looked like a KLIPS memory leak.
He explained how to detect a kernel memory leak: "consistent upward trends in 
statistics from /proc/slabinfo or /proc/meminfo are seen". He cited other
observations that supported his interpretation of the error:
                                                                                
    It's interesting that the problem is cured if you stop FreeS/WAN (removing
    the kernel module) and restart it -- a reboot wasn't necessary.  So the
    module accepts responsibility for the (hypothetical) memory allocations.

Paul Wouters offered a variation on the theory:

    It could also be [a memory leak in] pluto.
    What you can do is compile pluto with [-DLEAK_DETECTIVE]
    (programs/pluto/Makefile)Then after a few days, restart ipsec, and the 
    detected leaks will be logged.

Paul commented that there were known memory leaks in 2.00pre3's OE
(Opportunistic Encryption) which have since been fixed, but that more may yet 
be undiscovered. David agreed to upgrade to 2.04, to run a pluto compiled 
with the appropriate flag and to keep an eye on kernel memory use statistics. 
If the bugs weren't fixed, we'll certainly know more about them thanks to 
David's detective work.
                                                                               


5.  Certicom Patent Attempt
    =======================
    1 post Nov 3
    http://lists.freeswan.org/pipermail/design/2003-November/msg00005.html


Back in November, Michael Richardson informed us that Certicom Corp., known 
for its work on Elliptic Curve Cryptography, seems to be attempting to patent 
numbers used in the IETF's (Internet Engineering Task Force's) IKE (Internet 
Key Exchange) standard.

Anyone interested in this topic and its political ramifications might like to 
read the letter from Certicom's Ian McKinnon, archived at 
http://www.sandelman.ottawa.on.ca/ipsec/2003/10/msg00207.html ,
and the discussion on the IETF Security Area Advisory Group. That discussion 
speculated on the legitimacy of Certicom's claims, and their possible political
ramifications. Michael Richardson offered a Canadian perspective:

    Industry Canada people who care, have suggested that Canada would never 
    honour a claim to a prime number, and that the OncoMouse is prefectly
    adequate precedent. I naturally can't predict what US courts will do.

Steve Bellovin, chair of the IETF's IPR (Intellectual Property Rights) working 
group, noted the IETF's official, neutral position in cases of intellectual 
property disputes:

    Speaking as AD and as chair of the IPR wg...  The IETF per se can take 
    no position on the validity of any patents or on the desirability of 
    standardizing a technology that may be encumbered.  However, the 
    members of each WG can and should make their own judgments -- aided, if 
    they wish, by the advice of their own counsel -- on the validity of any 
    IPR claims, and they're perfectly entitled to use those judgments, and 
    any philosophical biases they have, in deciding whether or not to 
    standardize such technology.  Any choice has its costs.  
    Sometimes, those costs are royalty fees or the difficulty in producing 
    free implementations.  Sometimes, the costs are poorer performance or 
    lack of functionality from deciding to avoid encumbered technology.

Philosophically, Tim Shepard noted "this issue seems to be closely related to 
other issues", in the way it blurs the line between (free) speech and 
(less than free) software implementation. To Scott Bradner's claim that 
"patent violations come from implementing and distributing technology not 
from publishing it", Tim remarked:

    But that is the mess we've gotten into since in the 20th century we
    learned that there is no clear line separating speech (language) from
    machinery (technology).  (I thank Hal Abelson for explaining this so
    succinctly at a seminar at MIT on the legal issues surrounding DVD
    descrambling a few years ago.)

For more, read the thread starting here:
http://jis.mit.edu/pipermail/saag/2003q4/000797.html
It remains to be seen what real world effects Certicom's claims might have, in 
the short or long term.


 ------------------------------------------------------------------------------
lists.freeswan.org Email Summary                   Wednesday, February 11, 2004

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBQCptZHDIYXPDEHodAQF8igQAn2InwzNqd7z1nqKwKQeRZp09mZ2z3zEB
igjb5cmUXn7qSxDCFBqKCaeySx2rgJxiNcEavWMl2cXjRzQiNVNlNXU4Tx9X84P4
5o9LqG6bFsAP0IE+Mqv4HK189SBv8cY6ssD5yMx2XD9BKOflofP6CgjuzudHS5xH
JiU2QdngeY4=
=RlJl
-----END PGP SIGNATURE-----