Subject: [MSEC] Guaranteeing adjacency for PIM routers--some questions

From: JW Atwood <[email-masked]>
Date: Wed, 07 Feb 2007 21:17:26 -0500

As this topic concerns group security as much as it does PIM-SM, I am 
cross-posting it to the msec mailing list.  My apologies to those who 
see it twice.

  Bill Atwood

As we have begun to investigate the details of how to secure the
link-local messages for PIM-SM (see draft-ietf-pim-linklocal), a "more
general" problem has appeared, which is how to ensure that the
(supposedly) adjacent routers are

a) who they claim to be,

b) really adjacent.

A solution to this problem will be applicable to all exchanges with
"adjacent" routers.  Thus, the work could be useful in securing PIM-SM
link-local exchanges, OSPFv3 exchanges (see RFC 4552) and (possibly)
other peer exchanges.

As noted in draft-ietf-pim-linklocal, link-local communication actually
is in the form of a set of independent groups, each with one speaker and
several listeners.  In each router, there is one incoming Security
Association (SA) for each peer, plus one outgoing SA for this router as
a sender.  Thus, in a specific region, there will be as many SSM groups
as there are routers, and each SSM group will have one SA associated
with it. The GCKS will maintain membership information of these groups,
and will generate and distribute keys to all pertinent routers.

In reading the RFC on the Group Domain of Interpretation (RFC 3547), it
is clear that the operation of any secure group (including the secure
groups formed by adjacent routers) is going to have two phases: Phase 1
establishes Security Associations between the Group Controller/Key
Server (GCKS) and each of the individual routers.  Phase 2 establishes
the Group Security Association and distributes the keys that will be
used for the group communication. We expect to use either GDOI itself,
or necessary parts of it, for phase 2.

The basic principle is simple: whenever a router will be added or
joined, the GCKS will create a new SA for the SSM group for which the
added or joined router will be the speaker, and distribute the necessary
information to the listeners (all the adjacent routers).  The question
to be resolved is how will the GCKS get the list of adjacent routers to
the newly joined router?  Two options are possible:

a) Dynamic mode: Take the arrival of a message from a peer as prima
facie evidence that the peer is adjacent.  (This implies two
assumptions: 1) that routers will not forward link-local messages, and
2) that no "rogue" router is on the subnet.)  In this case, the only
property of the peer to be verified is whether the peer is "legitimate" 
(which should eliminate "rogue" routers). It permits only validating the
router itself, not its adjacency matrix.  However, the "authority" 
(typically the GCKS) could build up dynamically an image of the topology
by examining the requests for validation.

The "legitimacy" of a particular router could be based on some
pre-configured secret, stored in a configuration file on the router, or
in a unique hardware device associated with the router.

b) Static mode: The GCKS or "authority" will maintain an adjacency
matrix (which in turn requires that the system administrator maintain
the information in a machine-accessible format). However, it permits
maintaining significantly more control over the router-to-router
communication within the network.

Clearly the first option requires that less information be maintained by
the "authority", whereas the second option may reduce the traffic flow.

Our primary question is, "Is it worthwhile exploring none, the first,
the second, or both options?"  A secondary question is, "Will any of
these options be operationally viable, or will they require the
maintenance of information where the average systems administrator will
find it difficult to justify the time expenditure?"

Any comments from the list will be most appreciated, and will guide us
in our development of a solution to the link-local security problem.

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Professor Emeritus                fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

_______________________________________________
MSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/msec