Router implementation
In order to implement SEND on the router side, we decided to extend the Linux IPv6 Router Advertisement Daemon (radvd). This widely used program is already capable of advertising routers in a network while not being a software router implementation itself. Instead it is a linux daemon that just sends out router advertisement messages and handles incoming router solicitations respectively. The configuration of the routing itself is not in the scope of this program.
The extensions we made to radvd enable it to sign router advertisements with the RSA signature option specified in RFC 3971. The private key used to sign the data of the router advertisement packet can be configured via the configuration file of radvd. For this purpose we introduced the PathToPrivateKey attribute that can be added to an interface block once. The value of this option must be an absolute path to an RSA private key saved in the PEM format.
In addition to the signing of router advertisements, we added the necessary capabilities for the certificate exchange between radvd and other hosts on the network. Radvd is now listening for certification path solicitations and will answer them with respective certification path advertisements. The certification path can also be configured via the configuration file of radvd. We introduced the CertPathFile attribute that can be added to an interface block. The value of this option must be an absolute path to a file that contains a complete certification path in PEM format. The certificates in this file have to be ordered so that the first certificate in this file is the trust anchor and the last one is the certificate of the router itself. Also note that the router certificate is supposed to contain or inherit an IP Address Delegation Extension (see Client Implementation: Security Module for more details). The CertPathFile attribute can be added to an interface block multiple times to configure multiple certification paths.
This is especially useful for advertising multi-homed routers that route more than one address prefix or for any other case where radvd should advertise multiple address prefixes on the same interface. For this method to work properly, all router certificates of the different certification paths configured for one interface must use the same RSA keypair. Otherwise a router advertisement that contains two prefix options will not be accepted by clients because they cannot validate it. Whenever a client receives a signed router advertisement, it will check if the key hash from the RSA signature option is part of any router certificate it already has cached. If this is not the case, the client will request the certification paths of the router to possibly obtain such a router certificate. After this procedure, the client will find multiple different router certificates that contain the required key hash and each of them might contain an IP address delegation extension for one of the multiple advertised prefixes. So in case the router certificates do not contain the same key, one of the prefix options in such a router advertisements could not be validated by the client which would invalidate the whole router advertisement.
We are currently in the process of preparing our changes to radvd to be committed back to the original radvd repository. So in order to obtain our router implementation, you will be able to use the distribution channels of radvd. In case you cannot wait to try out out implementation, you can also download the contents of our repository as a zip file or use git to clone it. Instructions on how to build the source are contained in the README file.