27 Nov 2001 (updated 30 Nov 2001 at 00:54 UTC)
»
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
