IPSec Mesh Notes
Problem: We have remote sites which need authenticate and confidential access between themselves. IPsec provides the necessary functions, but bandwidth required to support multiple full-time tunnelled IPSec sessions through one central location (e.g. hub-spoke) is taxing (how 'taxing', we have yet to measure). Additionally, the latency cost associated with what would be an inherent ineffeciency in routing due to uknowns about geography is also unacceptable (through a central location, a node in NY and a node in FL would have to speak through the central node, for instance, in CA).
Solution: Among other solutions, the concept of an IPSec 'mesh' was proposed by ajaxx and azure, although the functional solution, at the time, was tentative. The benefits of the mesh IPSec configuration are illustrated in the following:
the configuration can be used to link all nodes together without the added performance limit of keeping full-time tunnels open.
as follows from the above, tunnels will be 'on- demand'
IPSec communication between nodes can occur with only light participation of an intermediary (the CA).
The following is a first attempt at a concrete functional solution so that we can start listing the requirements for establishing the mesh. To start out, here's a simple skeleton:
The overall solution consists of a simple Central Authority which will authenticate the validity of communicating nodes.
Communication between nodes A and B is desired by node A.
Endpoint A of the VPN tunnel presents a certificate that is signed by our central cert. authority. Node B does not need to have previous knowledge of node A since the certification authority vouches for the authenticity of (the certificate presented by) A. The subsequent session is then negotiated via isakmpd.
There is no on-line communication with the CA during the negotiation.
Endpoint B has the public key of the CA and can thus verify the certificate presented by A.
A does not trust B and so B must also present a certificate to A.
The second certificate must be signed by a CA acceptable to A.
In our system, all keys are signed by the same CA.
Revocation Two possible mechanisms can prevent compromised nodes from linking to the VPN.
unless certificates are renewed they become useless.
by changing the policy file, we can prevent nodes from accepting connections from blacklisted nodes
The major issues with the above plan were:
join latency rekeying
subnet addressing guidelines communication with multiple nodes research users route distribution
Join Latency: This wouldn't be an issue, as it turns out, because there's not underlying fabric to join. When discussing groups of IPSec communicators, I immediately began reasoning along the lines of a 'fabric-oriented' approach, which starts sounding much more like multicast- IPsec than what's really necessary for our requirements. This is not to say we can't tie all nodes together in a multi-cast-like setting, but I would say that's for a future implementation. The complication of source authentication and key management make a potential solution difficult, although I have provided possible solutions below. We may want to start a project on multicast IPSec. This particular point is only important when considering a more seamless level of resource sharing.
In the above proposed scenario, keys can be distributed and updated using a simple automated method such as CVS. Certificates need to be kept for both independent researchers and nodes so as to allow the same. As the scale of the network increases, we can develop something more automated, which is described below.
This should also be a non-issue. We should provide guidelines that administrators stick to 10.0.*/24 and even hand out address spaces, but largely IPSec communication between two or more IPSec nodes can go ungoverned. To keep life sane for everyone, we should make sure to specify what subnets.. the CA only authenticates nodes.
Communication with multiple nodes: Communication between from Node A and Node B to Node C may saturate node C's link. This is partially a disadvantage to the IPSec mesh, as over a hub-spoke arrangement, only one tunnel is necessary to carry multiple sessions between endpoints. It can be recommended that nodes employ the use of bandwidth shaping/rate limiting to prevent this from becoming a problem on popular nodes.
Research Users: The above may be further exasperated when considering that researchers are logically, their own nodes (albeit, single machine nodes). Multiple researches hitting one node may be undesirable for the same reason. This actually brings up additionaly issues about the quality of research which I'll bring up at some other time.
Route Distribution: This was also another issue that cropped up when thinking about the mesh in a 'fabric-oriented' way. This also becomes a non-issue as nodes are subject to their own routing impedence and there's no need to know private address routes.. as they don't exist in the proposed scenario. We can move towards route sharing in the future, but I see IPsec multicast as possibly being the best way to send non-contiguous, non-canonical route updates.
Multicast IPSec - Brief Treatment to be expanded at a later time
These are just notes.
in a normal scenario, the destination chooses the SPI.
in multicast, there is not single destination for a given address.
Source Authentication Solutions
Gennarro and Rohatgi describe a system where a single public-key (asymmetric) signature and a symetrically-keyed hash can be used to effectively authenticate the source of a packet based on the fact that a sender knows what the next packet it is going to send will be.
The digest of the first packet, which is a keyed hash of the second packet, can be checked when the secon packet is recieved.
The second packet then holds a digest for the keyed hash in the third packet.
When the keyed hash of the second packet holding the digest for the third packet can verify the signature sent in the first packet, the sender of the first packet can be absolutely identified and so on up to packet #n.
G. Itkis describes a technique using the authentication employed in AH, but adapted to use additional digests such that:
for any particular sender of a group, there are 'n' keys. Each member of the group/recipient of multicast traffic is granted k of the n keys, where k < n Each packet is sent with n digests of a keyed hash appended for each of the n keys. The recipients validate the digests based on how they correspond to the keys that s/he holds. if the recepients digests are correct, the reciever must assume that the rest of the digests are correct as well. one member could forge packets to members in the rest of the group, but if we have a suitably large 'n' and a relatively small 'k' the number of members that share the same keys will be small.
This idea has limitations, but has been incorporated into 
- can't finish this post at the moment, next post will correlate to CBT - RFC1949 using GKDCs and cores and MKMP using GKMs and GKDs ... enough acros y'think?
 "Digital Signatures for Flows and Multicasts" - Chung Kei Wong and Simon Lam
 "Multicast Security: A Taxonomy of Secure Multicast Protocols and Effecient Authentication Schemes" - Cannetti, Garay, Itkis, Micciancio, Naor and Pinkas