Openswan; 2.05 candidate; Virtual systems with NFmark

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



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


Openswan, a new FreeS/WAN variant, has appeared. Read all about it in Item 1.
Meanwhile FreeS/WAN continues to become a simpler, secure product capable of 
Opportunistic Encryption (OE). You can chart its direction in Item 2.

Enjoy.



In Brief....

1.  Openswan released
2.  FreeS/WAN 2.05 candidate ready
3.  IPsec virtual systems with NFmark
4.  How also= works


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

1.  Openswan released
    =================
    1 post Jan 2
    https://lists.freeswan.org/archives/design/2004-January/msg00000.html


The folks who distributed Super FreeS/WAN (http://www.freeswan.ca) have 
re-branded that feature-rich product to issue the first Openswan release.
Its code is built on the final Super FreeS/WAN version. As a result Openswan 
1.99x is a mature codebase which combines vanilla (FreeS/WAN-based) IPsec with 
many add-ons (X.509, AES, NAT-T, XAUTH, DPD).

Openswan 2.x is built on the FreeS/WAN 2.x codebase, and includes 
2.6 kernel support, improved OE facilities and simplified configuration files,
along with "SuperFreeS/WAN" style extended features.

Added-value technical support for Openswan (and more) is provided by the 
Xelerance Corporation, at http://www.xelerance.com. For more information and 
Openswan downloads, go to http://www.openswan.org.



2.  FreeS/WAN 2.05 candidate ready
    ==============================
    4 posts Dec 21-23
    https://lists.freeswan.org/archives/design/2003-December/msg00017.html


A FreeS/WAN 2.05 candidate is now available. In keeping with the team's goal 
of delivering a simple, secure and OE-capable product, they have removed the 
largely unused AH (Authentication Header) code. Key length variance, recently 
discussed on-list, is a new feature. List support person Sam Sgro announced:

    All AH code has been removed from KLIPS and pluto.
                                                                               
    ipsec newhostkey will use the new "ipsec rsasigkey --vary" option to
    generate keys from 1536 to 4096 bits in size. Includes tests for this
    functionality.

The final cut will likely also feature a fix to an unregister_netdevice bug.
This bug, which sees FreeS/WAN or related code hanging the kernel, is 
discussed at:

https://lists.freeswan.org/archives/design/2004-January/msg00041.html
https://lists.freeswan.org/archives/design/2004-January/msg00045.html

Post-2.05, proposed developments include smoother DNS timeout handling for OE,
and better integration with 2.6 native IPsec. The latter is still very 
much experimental; for the latest on that topic, see the Design list.



3.  IPsec virtual systems with NFmark
    =================================
    2 posts Jan 6
    https://lists.freeswan.org/archives/design/2004-January/msg00003.html


Wayne Schroeder was working on an interesting FreeS/WAN application:
to treat multiple remote networks with the same IP ranges differently.
He accomplished this by implementing separate "Virtual Systems" using
NFmark (Network Firewall mark) tags. Wayne explained:

    Virtual systems are something I was first introduced to on a netscreen
    device.  The basic concept is to have the ability to break up your ipsec
    concentrator into virtual routing domains and to be able to route
    packets in a 'virtual router / system' environment where packets from
    one system would never be seen on the other unless specifically routed
    to it.  

He described how he implemented this concept using NFmark. In part:

    I noticed that packets that hit the routing tables in linux coming from 
    ipsec0 were tagged with an spi identifier in the nfmark field.  I went 
    ahead and changed this to mark the packet with the 32bit ipv4 address of 
    the remote gateway from where the packet came in.  Now I can do specific 
    routing on this packet based on the nfmark (which is static, not dynamic 
    like spi).

NFmark sounds like a good tool for the job, since it allows networking 
applications to pass stateful information about existing connections, easily
and with few side effects. Jim Carter had another possible application of 
Wayne's Virtual Systems/NFmark strategy:

    On cursory reading, I suspect this technique might help in the 
    longstanding problem with IPSec-NAT: two different NAT routers 
    (with different public IP addresses) assign the same private address 
    to their respective clients. This is very likely to happen...

New approaches to thorny problems around IPsec, particularly IPsec and NAT,
always make interesting list fodder. I am curious to see how Jim's and Wayne's 
work evolves.



4.  How also= works
    ===============
    4 posts Jan 20 - 25    
    https://lists.freeswan.org/archives/design/2004-January/msg00050.html


Once in a while we get a quick, concise look under FreeS/WAN's hood. This time 
it's at the useful "also=" feature. This is an ipsec.conf shorthand which 
allows you to include one connection definition in another, so that multiple 
connections can share common information.

How does it work? D. Hugh Redelmeier explained,

    _confread processes the file strictly sequentially, only looking for conns
    that are in its list of goals.
                                                                               
    The goal list starts out being the conn-name explicitly requested.
                                                                               
    When _confread finds a conn not named in its goal list, it ignores that 
    conn.
                                                                               
    When _confread finds a conn that is named in its goal list, _confread
    processes the conn.
                                                                               
    When _confread finds an also=conn-name within a conn that it is
    processing, _confread adds that conn-name to its list of goals.
                                                                               
    This explains why also= references must be forward references.

On behalf of those who've wondered: thanks, DHR!
For more information on how to use this feature, see man ipsec.conf.


 ------------------------------------------------------------------------------
lists.freeswan.org Email Summary                        Wednesday, Jan 28, 2004

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

iQCVAwUBQBiUoXDIYXPDEHodAQHqGAQAhX77VbcbBaoqtF++0PnbnC4Kde7jaqIL
cEHp4mxNdLE1BgJAXgMEU78l6In1yfSUuZoiuQQ+DQEjdH+XvLRZ5n2yeQ3BZveY
uOthBCMk8Eoryw4FTIzjcnQm4l1ukwdAxcGe9UR1iakWE8VdxIsY0jjVElM03W+9
/geM375jnko=
=C2Si
-----END PGP SIGNATURE-----