[pim] Guaranteeing adjacency for PIM routers--some questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[pim] Guaranteeing adjacency for PIM routers--some questions
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: bill at cse.concordia.ca
1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.