69th IETF, 26 July 2007 Michael Behringer Francois Le Faucheur A Framework for RSVP Security Using Dynamic Group Keying draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt 69th IETF, 26 July 2007  Michael Behringer Francois Le Faucheur 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Where are we coming from? Writing Security Considerations section for each new “RSVP extension for Foo” I-D (painfully) showed that: Applicability of existing RSVP security mechanism is not sufficiently documented Existing key approaches have limitations New key approaches could help alleviate/remove some some limitations 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Per Neighbor / Interface Keys for RSVP Authentication today Per Neighbor / Interface Keys for RSVP Authentication Shared keys (K2, K3, K4) per peer / interface Today typically statically configured Operationally heavy  typically not used K3 (PATH)3 R3 K3 (PATH)2 K2 K2 K4 R1 R2 (PATH)4 non-RSVP K4 R4 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Dynamic Group Keying for RSVP draft-weis-gdoi-for-rsvp-00 new proposal Dynamic Group Keying for RSVP draft-weis-gdoi-for-rsvp-00 Use a group key server (GKS) to distribute group keys (GK) and policy to RSVP nodes; used for RSVP Authentication GDOI distributed group keys are dynamically provisioned  easier to use than static peer/if keys GKS GK GK GK R3 GK R1 R2 GK R5 R4 zone of trust 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Objective of this Document Different keying approaches for RSVP traditional: per peer, per interface new: per group (GDOI) Different security, applicability Usage: RSVP Authentication and Encryption Goal of document: describe applicability, security of these keying approaches for RSVP 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Per Neighbor / Interface Keys Works intra-domain Works inter-domain Does not work easily across non-RSPV nodes Note: regular RSVP (without authentication) does! Key 3 R3 PATH R1 R2 R5 Key 4 non-RSVP R4 which key to use? 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Group Keys Work intra-domain Do not work inter-domain (not applicable). Assume: domain = zone of trust  Cannot apply same key across zones of trust Works across non-RSVP nodes Group Key PATH R3 R1 R2 R5 Group Key non-RSVP R4 use group key! 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Impact of Subverted Nodes Subverted: Not trusted Under control of hacker, misconfigured, buggy, etc Single subverted node can reserve all bandwidth through it  local DoS, theft of service modify / fake path message global impact, since rsv message goes end-to-end fake src / dst  potential DoS anywhere in domain fake phop  potential DoS, local modify / fake reservation message local impact, since rsv message goes hop by hop 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Impact of Subverted Nodes – Protection with Authentication With peer / interface keys: Path message: Can still fake all fields, including src/dst Can create new fake messages Rsv message: Can fake and create, but local impact only With group keys: Same impact 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

What Does RSVP Authentication Do? RSVP Authentication (with any key type) ensures the origin and integrity of the message (*); it does not ensure the correctness of the message content. (*) and replay protection 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Conclusions peer or interface key group key works intra-domain y works inter-domain n works with non-RSVP hops in path protects against subverted nodes Usage of the key for encryption (instead of authentication) has the same properties as shown in the above table for authentication. 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

Questions Does the document add value? What are the areas that need be added, expanded,…? We solicit review and further input 69th IETF, 26 July 2007 draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt