Distributed Keyservers J.W. Atwood 2008/03/11 bill@cse.concordia.ca

Group Keying draft-tsvwg-rsvp-security-groupkeying Trust models RSVP keying models Interface, Neighbor, Group Provisioning of keys Shared security domains Separate security domains

PIM-SM Security Domains Single domain Multicast messages PIM-SM is inherently a “single administrative domain” protocol

Levels of Security One shared key per security domain No replay protection No data origin authentication Possible to do manually One key per sender (n+1) SAs per router “harder” to manage Must have automatic key management

Similarities and Differences RSVP Unicast communication Intervening router may not support RSVP PIM-SM Multicast communication Neighbor is guaranteed to be adjacent

..2 OSPFv3 Multicast communication Neighbor is adjacent Unicast routing may not be “up”  key may need to come from at most one hop away.

An Example Network Useful to explore the management of keys and SAs

Basic Network R6 R5 R4 R3 R2 R11 R10 R9 R8 R7 R14 R13 R12 R1

R1 as Sender R6 R5 R4 R3 R2 R11 R10 R9 R8 R7 R14 R13 R12 R1

R9 as Sender R6 R5 R4 R3 R2 R11 R10 R9 R8 R7 R14 R13 R12 R1

R1 as Receiver R6 R5 R4 R3 R2 R11 R10 R9 R8 R7 R14 R13 R12 R1

Communications Model Each router is the origin for a small group That router is the (only) sender) All its neighbors are the receivers All these groups share the ALL_PIM_ROUTERS group, but can be distinguished by the sender address

..2 To manage this, we can mandate one of the following: A single key for the entire administrative region A key per “speaking router” This will be an element of “policy” for the routers

(Group) Security Association Management The SPIs have to be centrally allocated, to ensure uniqueness, because the multicast groups have multiple receivers The GC will do this

Key management architecture For the single key case, the GC/KS needs to distribute the (shared) key to all routers For the one-key per router case, each speaking router needs to distribute its key to all adjacent routers Overall control of the adjacencies should be centralized, for network operator convenience

..2 We can model this as a central Group Controller (GC) and N distributed Key Servers (KS) (one per router) Each KS is initialized with its adjacencies at installation time, along with the address of the group controller for the PIM-SM “control plane key management group”

..3 On startup, the last known configuration of adjacencies is used, and then refreshed from the GC after an appropriate interval. Only the GC needs to be replicated for reliability (if an individual router is down, it is not needed as a key server)

Management of the “key management” group The GDOI GC/KS is formulated as a centralized entity. An extension needs to be specified To specify the protocol between a centralized GC and the (thousands of) individual KS  Is there interest in MSEC to host this work?

Adjacency lists in the GC/KS Question of deciding which router(s) are entitled to receive keys from a “speaking router” Some sort of global (to the secure region) unique identification Applicable to many routing protocols Represents “policy” I took it to kmart BOF

Questions?