27 Nov 2001 nchriss   » (Journeyer)

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).

    • Details: 

    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.

    Scenario:

    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.

  • Certificates with limited lifetimes
  • unless certificates are renewed they become useless.
  • Blacklisting nodes
  • by changing the policy file, we can prevent nodes from accepting connections from blacklisted nodes

    • Issues/Concerns

    The major issues with the above plan were:

  • Key management
  • join latency
  • rekeying

  • IP Addressing

  • subnet addressing guidelines
  • communication with multiple nodes
  • research users
  • route distribution

    • Key Management

    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.

    IP Addressing

  • Subnet Addressing:
    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.

    Multicast Ipsec

  • Problems

  • Multicast traffic consists of a multiple recipients for a single packet and many senders to a particular(multicast) address.

  • A shared group key (or tree of shared keys) is necessary.

  • An IPSec SA is defined by the triple of protocol, SPI, and destination address.

  • in a normal scenario, the destination chooses the SPI.

  • in multicast, there is not single destination for a given address.

  • the SPI would be allocated by a group controller who also may be responsible for key generation and access control(key management).

  • source authentication and key management fail in multicast environments where many entities share a key and can all send packets to the same 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.

  • A digital signature of the the keyed hash of a second packet is employed as the first packet is sent.

  • 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.
  • each keyed hash covers the entire next packet, *including* the digest of the subsequent packet, which prevents a possible hijack scenario.

  • the only requirement on the reciever end is that s/he maintain a small buffer to hold the authenticating information for the next packet.
  • limitation: sender must know all of the input prior to sending the first packet.

  • problems arise when packets are sent out of order although the technique has been extended in [1].

    Alternate Technique:

    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 [2]

    - 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?

    [1] "Digital Signatures for Flows and Multicasts" - Chung Kei Wong and Simon Lam

    [2] "Multicast Security: A Taxonomy of Secure Multicast Protocols and Effecient Authentication Schemes" - Cannetti, Garay, Itkis, Micciancio, Naor and Pinkas

    • Latest blog entries     Older blog entries

    New Advogato Features

    FOAF updates: Trust rankings are now exported, making the data available to other users and websites. An external FOAF URI has been added, allowing users to link to an additional FOAF file.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!