1. Link-local security J.W. Atwood, S. Islam PIM Working Group 2007/07/25 bill@cse.concordia.ca

2. Draft-ietf-pim-sm-linklocal-01 Minor changes, to reflect output from San Diego meeting Requirement to support SAD per interface (IPv6 speakers can use link-local addresses) Use ALL_PIM_ROUTERS for secure exchanges

3. (2) Minor changes Insist on Authentication and suggest Confidentiality (c.f. RFC 4552 OSPF) Suggests changing the title of the I-D from “Security Issues in PIM-SM Link-local Messages” to “Authentication and Confidentiality in PIM-SM Link-local Messages” Require SAD per interface, or use of Interface ID tag in SA lookup Revised Fig 1 and Fig 2

4. New stuff Identifying the “groups” that communicate within an administrative region Note the need to establish adjacency relationships (see below)

5. draft-liu-ospfv3-automated- keying-req-01 Requirements document for automated keying for OSPFv3. (Intended to complement RFC 4552, which only specifies manual keying.) Requirements are very similar to the requirements for PIM-SM link-local messages, except that an OSPF router cannot assume when it boots that it has any route to the group controller/key server.

6. Requirements Document for PIM-SM Link-local Messages To help ourselves understand the problem, we have started to write a requirements document (based on draft-liu) If this would be useful, I can submit a “draft-atwood” or “draft-ietf” document outlining the requirements.

7. Communications among peers draft-liu has a “subnet-centered” view of the problem We may wish to adopt a slightly different view. (outlined later)

8. SA Management: Two Models Two SAs for the entire region One SA for all outgoing traffic (SAo) One SA for all incoming traffic (SAi) One SA per speaker Implies that router must maintain n+1 SAs: one for each peer, and one for itself

9. Network example (from liu) RT3RT4RT5 RT2RT1 N4 N5N6 N1 N2N3

10. OSPF needs some form of KS (or GCKS) on segment N1, because of a “one hop to KS” requirement RT3RT4RT5 RT2RT1 N4 N5N6 N1 N2N3 KS

11. Four GCKS models (draft-liu) Decentralized Physical GCKSs One (real) GCKS per segment Decentralized Logical GCKSs One (logical) GCKS per segment Decentralized KSs, Centralized GC One KS per segment Decentralized Delegates, Centralized GCKS One delegate per segment

12. SA Requirement The draft-liu view (subnet centered) actually requires one group (with associated keys) per router, per interface This requires more keys than our original idea, which was one key per speaker (sending router).

13. Four possibilities (1) SAi, SAo for the whole domain Two SAs on a router 2 keys in total for entire region SAi, SAo for a subnet 2*M SAs on a router, but 2*N keys in total M = number of interfaces on a router N = total number of subnets in the region

14. Four possibilities (2) SA per speaker P+1 keys per router total keys = R P = number of peers for a single router R = total number of routers in the region SA per speaker per subnet P+M keys per router total keys = R*(avg # of interf per router)

15. Adjacency Matrix in GCKS Question of deciding who to distribute keys to Option 4 requires GCKS to keep track of adjacency of each router, with interface information Option 3 requires GCKS to keep track of adjacency of each router, but not of the interface information

16. Validity of the Adjacency Design Question If a router comes up, does it use some form of neighbor discovery to find its neighbors, and then ask for keys for each of these neighbors OR Does it ask the GCKS to send it the keys for its neighbors OR Does it send the list of its discovered neighbors and have the GCKS “verify” that list against the “permitted adjacency” table in the GCKS ?

17. Plans Complete requirements statement Map requirements statement onto the group key management protocol(s), to see which one(s) would work. (Any comments on which to try first would be welcome!)

18. Questions?