Icon
Icon		Icon
Icon		Icon
Icon
2:18 AM
0 comments


Road-Warrior Scenarios (Road Warrior-to-OpenBSD/FreeBSD Gateway with IKE)

Road warriors (multiuser configurations) are roaming user clients with dynamically assigned IP addresses unknown to the home IPSec gateway or VPN concentrator. Hence the configuration has to rely on other means of authentication such as deployment of signatures or certificates. This requires a PKI.
Deployment of preshared secrets does not scale and often compromises entire architectures that rely on only one key. Because of an architectural change in the Cisco IPSec client for group authentication, interoperability with UNIX IPSec implementations has severely suffered (although arguably added benefit to Cisco-to-Cisco connections).
OpenBSD, FreeBSD, and Linux IPSec clients offer excellent granularity to adjust to interoperability requirements. As a rule of thumb, the same IPSec implementation on the client and the gateway saves lots of headaches and debugging effort. For sample road-warrior setups, see http://www.ipsec-howto.org, http://www.linuxsecurity.com/resource_files/cryptography/ipsec-howto/HOWTO.html, and http://www.allard.nu/openbsd/index.html. This last website covers certificate handling in depth.
Example 11-19 provides a certificate-based racoon example for road-warrior access.
Example 11-19. FreeBSD Gateway racoon Configuration for Road-Warrior Access
### Road Warrior to Gateway ####





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



# search this file for pre_shared_key with various ID key.

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



# racoon will look for certificate file in the directory,

# if the certificate/certificate request payload is received.

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



# "log" specifies logging level.  It is followed by either "notify," "debug,"

# or "debug2."

#log debug;



remote anonymous {

        exchange_mode main;

        generate_policy on;

        passive on;

        certificate_type x509 "my_certificate.pem" "my_private_key.pem";

        my_identifier cisco;

        peers_identifier cisco;

        proposal {

                encryption_algorithm 3des;

                hash_algorithm md5;

                authentication_method rsasig;

                dh_group modp1024;

        }

}



sainfo anonymous {

        pfs_group modp1024;

        encryption_algorithm 3des;

        authentication_algorithm hmac_md5;

        compression_algorithm deflate;

}

 

Dynamic Routing Protocols over Point-to-Point Tunnels—Transparent Infrastructure VPN

In general, IPSec tunnel setups cannot transfer routing protocols such as OSPF. IPSec does not always support the notion of an interface on which a routing engine (such as ospfd) can rely. (Remember, IPSec deals with SAs.) This can be accomplished by deploying OSPF over IP-IP/GRE tunnels over IPSec or out-of-band routing signaling not taking the crypto path.
Given the caveat mentioned with regard to TTL (TTL=1 breaks tunnel and multicasting) and MTUs, dynamic routing protocols work over tunnels pretty much the same way as over regular point-to-point links, as long as the routing engine can recognize the special interfaces associated with tunnels. Zebra/Quagga can deal with most implementations thanks to sound interface abstraction. For example setups of GRE over IPSec, see http://www.freeswan.ca/docs/HA/HA_VPNS_With_FreeSWAN.html.

IPSec Development and Evolution

The current efforts focus on specification of IKEv2, NAT-Traversal and firewall traversal, opportunistic encryption, DHCP over IKE, tight AES integration, and IPSec domains of interpretation (DOIs) for secure group communication and final touches to the IPv6 architecture. Currently, there is a significant trend toward hardware crypto-accelerator cards and chipsets that relieve the CPU from performing 3DES/AES encryption (and, most recently, that perform hashing calculations in hardware).
AES has improved crypto efficiency greatly; however, sustainable gigabit crypto throughput is still a domain of expensive commercial firewalls. An interesting addition to IPSec is the keynote trust management system that remedies some of the disadvantages of PKIs (introduced in RFC 2704 and RFC 2796). Also visit http://www1.cs.columbia.edu/~angelos/keynote.html.

If You Enjoyed This Post Please Take a Second To Share It.

You Might Also Like

Stay Connected With Free Updates

Subscribe via Email

teaser