Router Identification Problem Statement J.W. Atwood 2008/03/11

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

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.

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

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 ask MSEC to host this work

Adjacency Lists in GCKS Question of deciding which router(s) are entitled to receive keys from a speaking router To ensure that rogue routers do not appear as neighbors of a particular router, the GC can maintain an adjacency matrix or adjacency lists, and only authorize true neighbors to receive the key for a particular speaker router

Router Identification Need some form of unique identification of routers PKI for the region under consideration Trust anchors Each sender needs to retain information on its permitted neighbors Periodic refresh; update when new neighbor appears

Global Problem To control adjacencies, we need a view of the entire region The solution could be applicable to any/all routing problems: PIM-SM, OSPFv3, RSVP, etc

Where? Where is the best place to do the work? Not clear that PIM WG is the right place!

Alternate Views of Validity of the Adjacency For IPv6 May be able to use the Neighbor Discovery functionality in IPv6 to certify the validity of a particular neighbor. Alternatively, a local KS may refer to the central GC to approve the distribution of a key

..2 For IPv4 Need to use the central GC to approve the distribution of a key Alternatively, need to create an IPv4 equivalent for neighbor discovery and certification

Questions?