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)
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
Setting the Environment Router identification Controlling keys Controlling adjacency Usefulness of distributed
keyservers
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
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
Examples Two “end” cases provide the
examples One key, one SA for the entire
administrative region One key, one SA for each speaking
router
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
Transport vs. Tunnel mode Two routers are acting as hosts
MUST support transport mode MAY support tunnel mode
Authentication & Confidentiality MUST support authentication
MUST support ESP MAY support AH
SHOULD support confidentiality MUST use ESP
IPsec requirements Transport mode Multiple SPDs Selectors Interface ID tagging Manual key support No stream ciphers IP encapsulation
Key management MUST support manual keying Do not preclude the use of IKE or
GSAKMP to establish keys
Manual Key Management Manual configuration at boot-up SAD entries SPD entries
Automated Key Management Cannot use IKE Could use GDOI Could use GSAKMP
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
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)
Neighbor Relationships Managed by regional GC Out of scope for this document
Number of Sas Optional: one SA for each neighbor
plus one for outgoing Mandatory: one SA for all
neighbors and one for outgoing
Rekeying Procedure for doing it Configurable KeyRolloverInterval Rekeying Interval
Manual: 90 days Automatic: Will be specified by the
key server document
IPsec Protection Barrier and GSPD Manual Keying
SAD entries SPD entries
..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
Security Association Lookup Multicast lookup uses
Sender address (not unique because of link-local addresses)
Interface ID tag SPI
Activating Anti-replay Only recommended for automatic
keying Keep sequence number per SA Keep SA per sender
SAD per interface 4601 suggests it may be desirable 4301 deprecates SAD per interface
Replaced with interface ID tags for lookup
Extended Sequence Number Suggested for use with manual
keying
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)
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
Questions?