Link-local security

J.W. Atwood, S. Islam, S. Maziar

PIM Working Group2008/11/18

bill@cse.concordia.ca

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?