Link-local%20security

1
Link-local security

• J.W. Atwood, S. Islam
• PIM Working Group
• 2007/07/25
• bill_at_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 n1 SAs one
  for each peer, and one for itself

9
Network example (from liu)
N2
N3
N1
N4
N5
N6
10
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
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
• 2M SAs on a router, but 2N 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
• P1 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
• PM 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?