1 / 22

Link-local security

Link-local security. J.W. Atwood, S. Islam PIM Working Group 2007/12/04 bill@cse.concordia.ca. Draft-ietf-pim-sm-linklocal-02. Minor changes Title: Authentication and Confidentiality … Some housekeeping New Stuff Enlarged section on “Communications Patterns”. Recent activity.

phillipsandoval
Download Presentation

Link-local security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Draft-ietf-pim-sm-linklocal-02 • Minor changes • Title: Authentication and Confidentiality … • Some housekeeping • New Stuff • Enlarged section on “Communications Patterns”

  3. Recent activity • (Not yet reflected in the draft) • Discussion with Brian Weis and Ya Liu about common features among OSPF, PIM-SM and RSVP •  an idea for extending GDOI for our use • Development of ideas on controlling adjacency

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

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

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

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

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

  9. Communications among peers • The previous slides illustrate that the communication is, effectively, N little groups, each of which has a single sender, and a receiver set consisting of all of its immediate neighbors. • Even though all these groups share one (multicast) address, the Source Address can be used to distinguish them.

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

  11. Key management architecture • For the first case, the GC/KS needs to distribute the (shared) key to all routers • For the second 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 • We can model this as a central Group Controller (GC) and N distributed Key Servers (KS) (one per router)

  12. ..2 • 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” • On startup, the last known configuration of adjacencies is used, and then refreshed from the GC after an appropriate interval.

  13. ..3 • Only the GC needs to be replicated for reliability (if an individual router is down, it is not needed as a key server)

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

  15. Similarities to OSPF work • OSPF has the same (link-local) problem, except that they cannot assume unicast connectivity to the central KS when they boot up, so they “really need” the local key server to retain its last configuration across restarts

  16. Similarities to other work that could be done • RSVP does next-hop (almost link-local) communication; at least some of the ideas here will map to their requirements • Other protocols surely exist that could use this kind of “near-neighbor” communication

  17. Suggestion • Extract this common problem • Generate a separate Internet Draft to describe and solve it. • For now, we will use “key management for control planes” as a label for this sub-problem.

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

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

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

  21. Plans • Complete the exploration of the adjacency control issues • Define the extensions to GDOI (in MSEC wg) and create an Internet Draft • Create an Internet Draft on the (sub-) problem of “key management for control planes” (with others) • Rewrite the link-local Internet Draft to use the GDOI extensions (in PIM wg)

  22. Questions?

More Related