Link-local security

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

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

(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

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

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.

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.

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

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

RT1 RT2 RT3 RT4 RT5 Network example (from liu) N2 N3 N1 N4 N5 N6

RT1 RT2 RT3 RT4 RT5 OSPF needs some form of KS (or GCKS) on segment N1, because of a “one hop to KS” requirement N2 N3 N1 KS N4 N5 N6

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

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

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

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)

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

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 ?

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!)

Questions?

Link-local security