1 / 28

Link-local security

This document presents a draft designed to enhance link-local security within the Protocol Independent Multicast - Sparse Mode (PIM-SM). It outlines minor changes and introduces mechanisms for router identification, key management, and adjacency control. The draft discusses manual and automated keying methods, including the potential use of GSAKMP for automated key management. Key provisions related to authentication, confidentiality, and rekeying procedures are addressed, ensuring robust security for multicast communications. The draft aims to facilitate secure neighbor relationships and effective management of security associations.

bethan
Télécharger la présentation

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, S. Maziar PIM Working Group 2008/11/18 bill@cse.concordia.ca

  2. draft-ietf-pim-sm-linklocal-05 • Minor changes • Introduction sets up the environment • Notes possibility of GSAKMP for automated key management • Some housekeeping • New Stuff • Section on “Rekeying” (copied from 4552)

  3. Recent activity • Attempts to get help on the “environment” problem • Distributed key servers • Router identification • Realization that this draft is (almost) independent of those issues

  4. Setting the Environment • Router identification • Controlling keys • Controlling adjacency • Usefulness of distributed keyservers

  5. Router Identity • A mechanism exists to give each router an identity • Unique within an administrative region • PKI, HIP, etc. • See “Router Identification Problem Statement” at IETF-71

  6. Controlling keys and adjacency • GC/KS exists • Assign DEKs and SAIs • GC can answer the question, “is this router a legitimate neighbor for me?” • A “distributed key server” model may be appropriate • See “Distributed Keyservers” at IETF-71

  7. Examples • Two “end” cases provide the examples • One key, one SA for the entire administrative region • One key, one SA for each speaking router

  8. A walk through the draft • RFC 4601 is based on the new AH, and mandates authentication using AH • We draw heavily from RFC 4552 • Specify mandatory authentication and optional confidentiality • Keying • Require manual keying • Provide means of support for automatic keying

  9. Transport vs. Tunnel mode • Two routers are acting as hosts • MUST support transport mode • MAY support tunnel mode

  10. Authentication & Confidentiality • MUST support authentication • MUST support ESP • MAY support AH • SHOULD support confidentiality • MUST use ESP

  11. IPsec requirements • Transport mode • Multiple SPDs • Selectors • Interface ID tagging • Manual key support • No stream ciphers • IP encapsulation

  12. Key management • MUST support manual keying • Do not preclude the use of IKE or GSAKMP to establish keys

  13. Manual Key Management • Manual configuration at boot-up • SAD entries • SPD entries

  14. Automated Key Management • Cannot use IKE • Could use GDOI • Could use GSAKMP

  15. Communication Patterns • Each “speaker” represents a small group • All are sending on the same destination address • New rules in IPsec allow using sender address and interface ID tag to differentiate

  16. Key Server Models • Go to regional KS for keys • Go to local KS (the speaking router) for keys • (allows continuing when path to regional KS is broken)

  17. Neighbor Relationships • Managed by regional GC • Out of scope for this document

  18. Number of Sas • Optional: one SA for each neighbor plus one for outgoing • Mandatory: one SA for all neighbors and one for outgoing

  19. Rekeying • Procedure for doing it • Configurable KeyRolloverInterval • Rekeying Interval • Manual: 90 days • Automatic: Will be specified by the key server document

  20. IPsec Protection Barrier and GSPD • Manual Keying • SAD entries • SPD entries

  21. ..2 • Automatic Keying • SAD entries (created by the automatic procedure) • GSPD entries • Configured “send only” • Triggered by the automatic procedure • PAD entries • Filled by adjacency management • Out of scope for document

  22. Security Association Lookup • Multicast lookup uses • Sender address (not unique because of link-local addresses) • Interface ID tag • SPI

  23. Activating Anti-replay • Only recommended for automatic keying • Keep sequence number per SA • Keep SA per sender

  24. SAD per interface • 4601 suggests it may be desirable • 4301 deprecates SAD per interface • Replaced with interface ID tags for lookup

  25. Extended Sequence Number • Suggested for use with manual keying

  26. Security Considerations • Limitations of manual keys • Impersonation in single-key group • Pointers to • 4593 (Generic Threats to Routing Protocols) • 5294 (Specific threats to PIM-SM) • 4601 (PIM-SM)

  27. Plans • Tidy up a few housekeeping issues • Listen carefully for feedback during and after this meeting • Ask for WGLC, based on the next version of the draft

  28. Questions?

More Related