1. Distributed Keyservers
J.W. Atwood 2008/03/11

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

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

4. 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

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

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

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

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

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

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

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

12. 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

13. ..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

14. (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

15. 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

16. ..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”

17. ..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)

18. 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?

19. 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

20. Questions?