I have an original 6G data plan with Rogers and according to their FAQ, this is a supported feature and I am not going to get a multi-thousand dollar bill next month.

There are now a few free OpenID providers and I have setup my own account with VeriSign Labs Personal Identity Provider beta. Of course, I do not wish to expose the actual provider as my OpenID: what if I lose trust in them or they simply stop offering the service one day?

The solution to this is actually quite simple and allows you to use your own domain as your personal OpenID, exactly what I needed. The technical term is delegation and is fully documented. To implement this trick using WordPress, simply edit your themes header.php and add two meta tags. Of course you can do this with your software of choice, or even plain vanilla HTML. This is what I added to my blog:

<link rel="openid.server" href="https://pip.verisignlabs.com/server">
<link rel="openid.delegate" href="https://adam.sherman.pip.verisignlabs.com">

The above indicates that my personal OpenID is being delegated to https://adam.sherman.pip.verisignlabs.com which is hosted by the server https://pip.verisignlabs.com/server. Since the page at http://sherman.ca/ contains the above tags, I can now go to any site supporting OpenID (look for the logo: ) and simply use sherman.ca as my identifier.

I believe that OpenID’s time has come and I look forward to implementing it for some of my clients in order to give their users the ability to consume services without a registration page.

# dscacheutil -flushcache

Very useful tip.

In order for this to work, your system needs to both answer and perform multicast DNS queries. The two pieces you need for this are:

• mDNSResponder: From Apple, and covered under the APSL, but included in [Porchdog Software]‘s Howl package.
• nss-mdns: Written by Lennart Poettering, provides a plugin for the GNU Name Service Switch (NSS) functionality of the GNU C Library (glibc) providing host name resolution via Multicast DNS

As of 0.3, nss-mdns is already Debian-ready, simply build a package executing fakeroot dpkg-buildpackage from the unpacked tarball. There is an mDNSResponder package in Sarge which is rumored to be removed shortly due to license problems with APSL, so grab a copy soon.

Once these are installed, simply add mdns to the hosts line of /etc/nsswitch.conf and you’re done.

You will now be able to resolve “.local” hosts from your Debian system and also resolve this system’s hostname on other local hosts. By editing /etc/mdnsresponder/mDNSResponder.conf, you can advertise any service you want.

How does JXTA figure in relation to JINI?

Dan Creswell’s post about JINI not being RMI brought JINI back to the forefront of my technology todo list. This stuff is cool.

While IPsec has low overhead, even in tunnel mode, it requires a lot of effort to configure for use by mobile clients. First, we must now assume NATs in the field; whether they are behind the now omnipresent home gateways or on public wireless networks. Secondly, it is my experience that using a VPN system based around bridging has many advantages:

• supports services requiring broadcasts (SMB Browsing, Zeroconf/Rendezvous, etc.
• allows bi-directional routing to remote networks
• supports legacy, non-IP, protocols

I will elaborate on the routing issues. In our setup, our main gateway connects to 17 remote networks via IPsec. In order for a remote client to access a remote network, both the client and the remote gateway must have the correct routing table.

In light of the above, I decided to use OpenVPN. It fulfills my main objectives: simplicity and security. Correctly setup, OpenVPN will perform verification against both the client and server certificates and uses very strong crypto. To set this up you will need a PKI (Public Key Infrastructure).

My server-side configuration:

ca /etc/ssl/certs/ca.crt
ccd-exclusive
cert /etc/ssl/certs/gw.domain.ca.crt
client-config-dir ccd
client-to-client
dev tap0
dh /etc/ssl/dh2048.pem
float
group nogroup
keepalive 10 120
key /etc/ssl/private/gw.domain.ca.key  # This file should be kept secret
local 66.46.199.130
passtos
persist-key
persist-tun
port 1194
proto udp
push "route 10.100.0.0 255.255.0.0"
server-bridge 10.100.0.1 255.255.255.0 10.100.0.90 10.100.0.100
status openvpn-status.log
user nobody
verb 4

My client-side configuration:

dev tap0
remote gw.domain.ca
tls-remote gw.domain.ca
pull
nobind
passtos
float
tls-client
ca ts-ca.crt
cert adam.crt
key adam.key
keepalive 15 45
persist-tun
persist-key
verb 2

Note the tls-remote directive. This is critical to ensuring that the client verifies the identity of the server.

The Shoreline Firewall has full support for declaratively defining IPsec tunnels and hosts under the new IPsec support. To do this however, you will need the policy match netfilter extension from the Patch-o-Matic NG and also 4 other patches:

• ipsec-01-output-hooks.patch
• ipsec-02-input-hooks.patch
• ipsec-03-policy-lookup.patch
• ipsec-04-policy-checks.patch

While these patches are in the POM-NG, they will not cleanly apply to linux 2.6.9. Ronald Moesbergen was nice enough to port the patches are are available from the list archive.

To apply the patches, simply run patch -p1 < ipsec-* from the top of our kernel source tree. Also copy the policy match extension’s files from the POM-NG directory into your kernel tree and insert the contents of the two .ladd files into the relevant Makefile and Kconfig file. Then reconfigure, enabling the policy match, and rebuild. Then follow the documentation.

If I have time, I’ll try and add some more information here.

Since I was unable to find a clear description of setting up an IPSec-based VPN using the native IPSec stack from USAGI and KAME userland tools that are part of Linux 2.6.x, I thought I would post a short explanation.

Software

• Linux Kernel 2.6.8 from Debian Sarge
• ipsec-tools 0.3.3 from Debian Sarge
• racoon 0.3.3 from Debian Sarge (This package includes racoon-tool.)

Network Topology

I am going to explain a very straightforward topology often found in the field. You have two networks, network A (10.0.0.0/24) and network B (10.0.1.0/24). Each network has router/gateway/firewall system, gateway A (10.0.0.1) and gateway B (10.0.1.1). Each of these gateway systems as an external, public, IP address: 3.3.3.3 & 2.2.2.2.

In this topology, our end goal is to allow a hosts on network A, say 10.0.0.123, to securely contact a host on network B, say 10.0.1.158, via an IPSec tunnel.

Note: In many cases, I will provide only a single example. You must ensure the other gateway is configured similarly, often by reversing the configuration. This is left as an exercise to the reader.

IPSec

Setting up IPSec involves two steps: keying and policy. Normally, you use racoon to provide keying and setkey to establish policy. I will instead use racoon-tool as convenient shortcut. This tool was written by the Debian Maintainer of the racoon package in order to emulate some of the nice configuration syntaxt of the FreeS/WAN, an older IPSec implementation for Linux. It dynamically generates a racoon.conf (/var/lib/racoon/racoon.con) and also sets up the policy based on a single configuration file.

First, we simply state that racoon should use the notify priority when sending messages to syslogd:

global:
        log: notify

It is helpful to create a %default peer and connection in order to avoid duplication of configuration directives:

peer(%default):
        verify_identifier: on
        hash_algorithm[0]: sha1
        encryption_algorithm[0]: aes
connection(%default):
        src_ip: 3.3.3.3

The above src_ip directive simply says that our connections will be using our public IP.

Next, we define our peer, gatewayB, identifying it by address:

peer(2.2.2.2):
        peers_identifier: address

Finally, we define a policy so that packets from networkA to networkB are encrypted via gatewayB:

connection(to-gatewayB):
        dst_ip: 2.2.2.2
        src_range: 10.0.0.0/24
        dst_range: 10.0.1.0/24
        admin_status: enabled

Unfortunately, I have no idea what the admin_status: enabled directive does, or even whether it is required.

You must also add a key to /etc/racoon/psk.txt for the remote gateway:

# Entry for gatewayB
2.2.2.2 0x2eba016ffc2314869ae9f9a3b8901a173242f0c8

A randomly generated key is best, and can be created with the following command:

$ dd if=/dev/random count=20 bs=1 | xxd -ps

(The xxd command is part of the vim package.)

Make sure that you can the racoon package configured to use racoon-tool by either editing /etc/defaults/racoon or reconfiguring the package. Also, you should probably reload the tool by executing /etc/init.d/racoon reload. You can then check that your policy is in effect by running setkey -DP. You should get something like the following, followed by a bunch of default policies:

10.0.1.0/24[any] 10.0.0.0/24[any] any
        in ipsec
        esp/tunnel/2.2.2.2-3.3.3.3/unique#16385
        created: Nov 18 23:01:24 2004  lastused:
        lifetime: 0(s) validtime: 0(s)
        spid=1512 seq=9 pid=9800
        refcnt=1
10.0.0.0/24[any] 10.0.1.0/24[any] any
        out ipsec
        esp/tunnel/3.3.3.3-2.2.2.2/unique#16384
        created: Nov 18 23:01:24 2004  lastused: Nov 18 23:05:31 2004
        lifetime: 0(s) validtime: 0(s)
        spid=1505 seq=8 pid=9800
        refcnt=1

Now that the policy is in effect, the kernel will ask the racoon daemon for a security association (SA), when it needs to deal with a packet matching the policy. Racoon will negotiate an SA with the remote gateway on the fly. (This will not happen until after we’ve setup the routing, below, but you can see it by using the setkey -D command.)

Routing

In order for a packet to match the policy we have setup, and also be forwarded to the remove gateway, we must adjust the routing table using the ip command (Provided by the Debian iproute2 package.).

The policy we have setup, says that packets coming from 10.0.0.0/24 and going to 10.0.1.0/24 must be encrypted and authenticated. This is achieved by adding a slightly weird entry to the routing table on gatewayA:

$ ip route add 10.0.1.0/24 via 2.2.2.2 src 10.0.0.1

And on gatewayB:

$ ip route add 10.0.0.0/24 via 3.3.3.3 src 10.0.1.1

Once you have added the new entries to the routing tables on both gateways, we test the tunnel. If you ping 10.0.1.0 from gatewayA, and then execute setkey -D, you will see the new SA that has been automatically created.

This is the routing table you should have on gateway “A”:

root@gatewayA:/tmp# ip route show
3.3.3.0/24 dev eth1  proto kernel  scope link  src 3.3.3.3
10.0.1.0/24 via 3.3.3.1 dev eth1  src 10.0.0.1
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
default via 3.3.3.3 dev eth1

Followed by the routing table present on gateway “B”:

root@gatewayB:/tmp# ip route show
2.2.2.0/24 dev eth1  proto kernel  scope link  src 2.2.2.2
10.0.1.0/24 dev eth0  proto kernel  scope link  src 10.0.1.1
10.0.0.0/24 via 2.2.2.1 dev eth1  src 10.0.0.1.1
default via 2.2.2.1 dev eth1

In the above examples, 2.2.2.1 & 3.3.3.1 are the default gateways that connect your public networks. (The routers usually provided by your ISP.)

Note: if you have any firewall rules enabled, you are going to have hassles. Notice that the IPSec tunnel doesn’t have it’s own device: the encrypted packets are going through a public interface. This will confuse any firewall rules that expect to be able to categorize packets by interface. I intend to figure out a good solution and post it at a later date.

Update: I now have a fully working IPsec gateway/router/firewall. See this other post.

Update: It seems that when the external addresses of the gateways on are different subnets, which was not the case during my testing, you must add a route like ip route add OTHER_NETWORK via LOCAL_DEFAULT_GW src INTERNAL_IP. Otherwise, you will get an error: RTNETLINK answers: Network is unreachable. Please leave a comment if you can clarify this.

Instant messaging has boomed and become an almost integral part of our society, with youth leading this integration. Have we not noticed that this form of communication is almost entirely controlled by a select few corporations? To name a few:

• AOL (AIM & ICQ)
• Microsoft (MSN)
• Yahoo

This is all a Bad Thing™! Lets reminisce for a moment about good, old fashioned, email service. This technology is completely decentralized and relies on each entity having their own SMTP system. If I want to send you mail, I simply do a DNS lookup to find your mail server and off I go. This server can either be provided by your ISP, out-sourced to another provider or you may have set it up internally.

Contrast this with IM, where your messages are being routed by a third-party who:

• Is not receiving money from you
• Made you accept a disclaimer that basically guarantees less than nothing
• Doesn’t really want to interface with the other IM providers

To actually start discussing VoIP now, the above prevents good presence for VoIP applications.

Thankfully, the defacto VoIP protocol, SIP, has full support for an SMTP-like distrbuted model using SRV records in DNS. This allows the DNS system to be queries for the correct SIP server for a domain and therefore gives us nice, convenient addresses for voice communications using the familiar “user@domain” form.

Built on top of SIP, there is SIMPLE or the S I M P L E. This upgrades your SIP infrastructure to support full presence and instant messaging capabilities. So far, I know of very few clients that have full SIMPLE support:

• X-Ten‘s eyeBeam (Commercial, Win32 & Mac OS X)
• Pulver‘s pulver.Communicator (Win32)

Also, I believe that Microsoft‘s Windows Messenger is available in a SIP edition.

A major open instant messaging protocol, Jabber, also has the above mentioned SRV capability. It seems to be under implemented in practice, however, with many people not even bothering. Jabber uses the XMPP protocol and bridges exist to allow SIMPLE to interoperate with it.

I’m rambling here. To get to the point, it seems that integrating SIP hardware devices : Analog Telephone Adapters (ATAs), like those from Sipura, and desk phones like those from Polycom; with presence provided either by SIMPLE or XMPP, is a problem. See, when you are using a great hardware phone for actual calling, you can’t do decent presence. How will my Jabber client know that I’m on the phone in order to set my status to “On the phone”?

My conclusion is that we should really be using softphones. Why not? Don’t we all have laptops and Bluetooth headsets? Well, I intend to get myself fully setup this way. To heck with all the other ways of getting voice service. Also, Jabber isn’t a great candidate unless you use something like the myJabber Instant Messaging Client for XMPP and myJabber AE Soft Phone combination, which is non-standard.

More to come on this topic once I get a copy of eyeBeam for Mac OS X to play with.