End of the Line for Racoon at Kame.net

I've used security/racoon for years to manage the IPSec key exchange problem. I just read that the Kame project has ceased supporting Racoon; they direct users to IPSec-tools. That projects advertises itself as "a port of KAME's IPsec utilities to the Linux-2.6 IPsec implementation... [that] supports NetBSD and FreeBSD as well." Here's a recent thread on running IPSec-tools on FreeBSD.

If you're looking for an alternative to Racoon, I know of one for FreeBSD: security/isakmpd, imported from OpenBSD. I'm a little worried, since the FreeBSD port hasn't been modified since December, while the CVS interface to the OpenBSD code shows recent changes. I'm also not sure what to make of this how-to, since there is no date on it; i.e., do the problems describe therein still plague isakmpd on FreeBSD?

Speaking of IPSec, you may have seen the NISCC announcement, or the US-CERT vulnerability note. The vulnerability is really one of poor configuration. According to NISCC:

"These [vulnerable] configurations use Encapsulating Security Payload (ESP) in tunnel mode with confidentiality only, or with integrity protection being provided by a higher layer protocol. Some configurations using AH to provide integrity protection are also vulnerable. In these configurations, an attacker can modify sections of the IPsec packet, causing either the cleartext inner packet to be redirected or
a network host to generate an error message."

The IPSec-tools list mentions it, and the way to address the issue is to "Configure ESP to use both confidentiality and integrity protection."

I think this is old news, if one reads Steve Bellovin's previous work. Furthermore, it appears the stock racoon.conf protects against this, as shown here:

path include "/usr/local/etc/racoon" ;

path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

path certificate "/usr/local/etc/cert" ;

padding
{
        maximum_length 20;      # maximum padding length.
        randomize off;          # enable randomize length.
        strict_check off;       # enable strict check.
        exclusive_tail off;     # extract last one octet.
}

timer
{
        # These value can be changed per remote node.
        counter 5;              # maximum trying count to send.
        interval 20 sec;        # maximum interval to resend.
        persend 1;              # the number of packets per a send.

        # timer for waiting to complete each phase.
        phase1 30 sec;
        phase2 15 sec;
}

remote anonymous
{
        #exchange_mode main,aggressive;
        exchange_mode aggressive,main;
        doi ipsec_doi;
        situation identity_only;

        #my_identifier address;
        my_identifier user_fqdn "sakane@kame.net";
        peers_identifier user_fqdn "sakane@kame.net";
        #certificate_type x509 "mycert" "mypriv";

        nonce_size 16;
        lifetime time 1 min;    # sec,min,hour
        initial_contact on;
        support_mip6 on;
        proposal_check obey;    # obey, strict or claim

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key ;
                dh_group 2 ;
        }
}

sainfo anonymous
{
        pfs_group 1;
        lifetime time 30 sec;
        encryption_algorithm 3des ;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

The "authentication_algorithm hmac_sha1;" takes care of authentication. You enforce encryption policy in your ipsec.conf file, which works with setkey. For example, this snippet for one of my ipsec.conf files mandates ESP tunnel mode for traffic in this VPN.

spdadd 10.4.12.10 10.4.12.1 any -P in ipsec 
 esp/tunnel/18.235.153.37-78.172.25.27/require;

If anyone would care to comment, I'd appreciate some additional interpretations of this issue.